I just added support. It appears to be working properly, it required some fixes in cURL and zlib, and requires a newer HXCPP library, but the tools now should build ARM64 binaries by default, and should drop ARMV6 from the set of binaries we include in Lime releases. In addition to ARMV7, it should build to ARM64 when targeting a device
I’m still unsure of what the apple change will effect, does “we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with both 32-bit and 64-bit code” mean that we will still be able to support older devices like iPhone 4 ? and will the OpenFL changes allow us to do this?
Although you will be to add or remove architectures to suit your needs, I have lime to use both armv7 and arm64 by default now, and have dropped armv6 from the default Lime binaries.
By now, I do not think armv6 is valuable for iOS. Someone who wants or needs it could build Lime from the source. Although there is a newer armv7s architecture, I think armv7 is still important for device compatibility. Rather than including three architectures, I think skipping v7s and including arm64 is the best default
Could the nightly builds of lime start including pre-built 64-bit binaries? Right now they’re missing, and it’s quite a pain to have to build them on our own.
My second question is: what do we have to do with our extensions to get them to create 64-bit binaries?
The updated lime rebuild command should now include 64-bit binaries, assuming you use a dev version of HXCPP (which is also built now at http://www.openfl.org/builds) and Lime.
For example, lime rebuild my-cool-extension ios or lime rebuild path/to/my-extension ios
Trying to compile some demo projects (generated with the latest lime) in xCode 6.1 - with the architecture settings, that includes “arm64”, have the Shell Script Invocation error:
cp: build/Debug-iphonesim-64/ApplicationMain-debug.iphonesim-64.a: No such file or directory
Without “arm64” all is ok. For what reason it can be?
That’s unfortunate, I had hoped that I could release without the newer HXCPP release, I must have had an old arm64 build present, so I didn’t see this problem in my test
Trying to compile project in xCode with the latest hxcpp 3.1.48 and the latest (fixed) 2.0.2.
With arm64 enabled (without it - all OK) next 3 errors detected:
ld: warning: ignoring file /PathToProject//lib/x86_64/liblime.a, file was built for archive which is not the architecture being linked (x86_64): /PathToProject/export/ios/Project/lib/x86_64/liblime.a
Undefined symbols for architecture x86_64:
"_lime_register_prims", referenced from:
_main in Main.o
"_zlib_register_prims", referenced from:
_hxRunLibrary in libApplicationMain.a(3252ecf0_RunLibs.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I went through and got the builds working properly, with changes in HXCPP, as well as the new architectures, some aspects of the build system were not behaving like it did on my local system.
I just released Lime 2.0.3 on haxelib, which I have just confirmed to include both arm64 and x86_64 binaries. Please let me know if this resolves the issue
I am getting a couple of errors when I try to upload the game to the app store.
Locally the game works on both simulator and real device but when I try to upload I get the error that the minimal acceptable target for 64bit is 5.1.1
I added to project.xml <ios deployment="6.0"/>
5.1.1 for some reason was not working.
And now when I try to upload the game I get the error
No image found at the path referenced under key "CFBundleIconFile': Icon.png"
Before the update everything worked fine and I did not change the icon settings.
All the icons are generated from one svg file by openfl.
I just removed the old unused CFBundleIcon stuff from the Info.plist, this was used before the move to the Asset Catalog format (which Apple recommends nowadays) and this must be what was causing the conflict. I also have updated our default deployment to 6.0 (EDIT: 5.1.1 https://github.com/openfl/lime/commit/7f178e4f4227b9ef5559d9fa9820b62a233df800), or tried to. Hopefully this should all be resolved now