I just submitted an app update to the iOS AppStore with 64-bit and 32-bit compatibility. I haven't changed anything except the 64-bit architecture, however the app size is now almost doubled from a pre-64-bit size of 2.7 MB to 4.5 MB.
Is this normal when compiling the app for both 64-bit and 32-bit iOS devices? Why does this happen (anyone care to explain in technical terms)? Or did something funky just happen in Xcode?
It's pretty normal because the code is compiled twice - once for 32 and once for 64-bit architectures.
See more information http://www.idownloadblog.com/2013/09/16/apple-to-devs-we-want-your-64-bit-apps-asap/
Related
My app contains a multithreaded engine that plays a game which can be compared to chess.
It performs a lot of bitwise operations (shift, and, etc.) on 64-bit words.
On a PC the 64-bit version is much faster than the 32-bit version, and on a recent phone/tablet you would expect the same.
The table below contains some test results (best result is 100, less means slower).
The benchmark consists of adding the numbers 1 through 200 million in parallel. I verified that 4 threads is faster than 2 or 1.
hardware os build threads benchmark search task
----------------------------------------------------------------------
MacBook Windows 64-bit JVM 4 100 100
MacBook Windows CN1 Simulator 4 100 42
iPhone X iOS debug armv7 4 14 2
iPhone X iOS debug arm64 4 14 2
Samsung Tab A 10.1 Android debug 4 8 1
Samsung Tab A 10.1 Android release 4 10 7
Observations:
On the MacBook the search task is performed more than twice as slow in the simulator compared to a normal 64-bit JVM.
Presumably this is because there is no (native) support for the functions Long.bitCount() and Long.numberOfTrailingZeros(),
which I had to replace by (slower) code. Question: is there a way to improve this?
There is no difference between the iPhone X armv7 and arm64 builds. How is this possible? (I tried removing the app and
restarting the phone before installing the arm64 version. The current AppStore version is 32-bit, IIRC.)
The Android release version does a much better job on the search task than the debug version: 7 times faster!
On the Samsung Tab the performance is satisfactory, on the iPhone X I would say it is below par.
Comparing the CPUs (iPhone X: 64-bit 6-core # 2.39 & 1.42 GHz, Samsung Tab A 10.1: 64-bit 8-core # 1.6 GHz)
the iPhone X should not be 3.5 times slower (score 2 vs 7).
To be sure, I looked at the iOS arm64 debug build ipa with the MacOS 'file' command and it says: Mach-0 64-bit executable.
So I am confused: why isn't the arm64 build faster on my iPhone X?
I read somewhere that 'The iPhone X’s processor is more powerful than the newest MacBook Pro' (2017), that can't be right. (My MacBook is 2015 I think.)
BTW, I use one external library, Device, to detect if a device is an iPhone X, and I tried using ios.add_libs=ExternalAccessory.framework.
EDIT
Some more information on the iOS ipa files:
32-bit Main.ipa 7.3 MB file: Mach-0 executable arm
64-bit Main.ipa 7.1 MB file: Mach-0 64-bit executable
On a 2012 iPad 4 only the 32-bit ipa installs. (The search task performance on a scale of 0-100 is 0.4.)
On an iPhone X both the 32-bit and 64-bit ipa's install, but there is no performance difference, which is odd.
The search task performance is 2.0, which is low compared to the Samsung Tab (7.0).
On the MacBook the search task is performed more than twice as slow in
the simulator compared to a normal 64-bit JVM. Presumably this is
because there is no (native) support for the functions Long.bitCount()
and Long.numberOfTrailingZeros(), which I had to replace by (slower)
code. Question: is there a way to improve this?
You can use a native interface and implement the JavaSE portion as the Long.bitCount() or Long.numberOfTrailingZeros(). This will work as fast on the simulator.
Another approach is to implement a Codename One API that does that natively to the important OS's and uses a simulation as a fallback for things you don't support. Then submit a PR to Codename One. You can do that by modifying CodenameOneImplementation.java with the fallback code then updating JavaSEPort.java, AndroidImplementation.java, IOSImplementation.java etc.
You would then expose these APIs somehow to the user which normally we do via Display but in this case might not be the ideal user API venue.
There is no difference between the iPhone X armv7 and arm64 builds.
How is this possible? (I tried removing the app and restarting the
phone before installing the arm64 version. The current AppStore
version is 32-bit, IIRC.)
64 bit is now required by apple so we no longer support building without it.
The Android release version does a much better job on the search task than the debug version: 7 times faster!
These things are hard to tell. It could be the Android JIT which iOS doesn't allow or it could be a piece of code we failed to optimize. We would need to microbenchmark the resulting code to tell.
However, the JavaSE JIT is amazingly fast and will run circles around any native compilation benchmark we throw its way. That's just not something an AoT VM can compete with. We do have other advantages such as more consistent behavior and less hiccups when running.
Our apps are both 32 bit and 64 bit compatible. With iOS 11 being released will my app run fine on 64 bit devices as iOS 11 does not support 32 bit apps.
What is the best suggestion, to remove 32 bit support and just have 64 bit to avoid any issues on iOS 11 or to have both?
Your app will work fine on iOS 11 as long as the binary has a 64-bit slice. The change that is occurring in iOS 11 affects binaries which only have 32-bit slices only. Your app will continue to work just fine, assuming you don't try to use iOS 11 APIs (which might cause linker issues — not sure if they're stubbed out — but if you're doing that, you should probably be targeting iOS 11 anyway).
If your app support both 64 bits and 32bis it will work on ios 11, if you want to change support to only 64 bits there is the link: apple developer documentation
As #Aehmlo says.The change that is occurring in iOS 11 affects binaries which only have 32-bit slices only. Your app will continue to work just fine.
Apple has tweaked the wording of that warning to note that 32-bit apps,So
iOS 11 could be the first software update to support 64-bit apps only
Hence, it won't support iPhone 5/ 5c or earlier iPhones.If you will try to install app in iOS 11 then you will notify something like
App will not work with future versions of iOS. The Developer of this app
need to update it to improve it's compatibility.
If doing this, $(ARCHS_STANDARD_32_BIT), like answers here suggested, Arm64 architecture in xcode 5.1
Will these 32 bit app be compatible with 64 bit and run well on iPhone 5S or even later?
Yes they will run on an iPhone 5S. The iPhone 5S will load the 32-bit framework into shared memory on the device, and run the app using that.
But it is worth while supporting both 32-bit and 64-bit architectures to reduce the memory usage your app consumes on a 64-bit device - even if you're not using any 64-bit specific features.
With Xcode 5.0.2 I try to run and profile an app on an iPad 1 running iOS 5.1.1.
The app is universal and based on a modern template. Deployment target is iOS 5.
To my understanding Apple expects that developers include 64-bit versions in their apps and when they do, the app bundle has 32 and 64 bit code. It seems that if your app targets iOS < 6 it can't include a 64 bit version.
So what does that mean? Must I remove the 64 bit support and will my app then run slower on a 5S? Or is there another way to ship bith 32 and 64 bit and still support iPad 1?
The short answer is, you can't.
Unfortunately 32/64 bit "fat" applications will only run on iOS 6 (I think it may even be 6.1) Previous iOS versions don't know how to read the fat binary file format.
We went through this when we had to release an update to our free app, Face Dancer. It uses face detection, and face detection is broken for 32 bit apps on the iPhone 5s and iPad air.
The previous version in the app store worked on iOS 5 and up, but we had to drop iOS 5 support in order to make a 32/64 bit build.
By the way, most apps don't need to care about 64 bit code. It's only if you're doing heavy number-crunching or heavy-duty graphics (which amounts to the same thing) that you'll notice any difference at all.
Set deployment target to 6.0 while you profile. Be sure to reset it before submitting to AppStore.
Criteria:
iPad only app. Only support iPad 2 or later.
Want to take advantage of 64 bit code for the latest iPads.
Min iOS 6.
Xcode 5.02 with iOS 7 SDK (current release)
Should I set both Architectures and Valid architectures to arm64 armv7
armv7s?
Xcode 5.0.1 can build your app with both 32-bit and 64-bit binaries included. This combined binary requires a minimum deployment target of iOS 5.1.1 or later. The 64-bit binary runs only on 64-bit devices running iOS 7.0.3 and later. If you have an existing app, you should first update your app for iOS 7 and then port it to run on 64-bit processors. By updating it first for iOS 7, you can remove deprecated code paths and use modern practices. If you’re creating a new app, target iOS 7 and compile 32-bit and 64-bit versions of your app.
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
Start by building the app for the 64-bit runtime, fixing any warnings that occur as well as searching your code for specific 64-bit issues. For example:
Make sure all function calls have a proper prototype.
Avoid truncating 64-bit values by accidentally assigning them to a 32-bit data type.
Ensure that calculations are performed correctly in the 64-bit version of your app.
Create data structures whose layouts are identical in the 32-bit and 64-bit versions of your app (such as when you write a data file to iCloud).
Reference: apple doc
Yes. You can set both architectures for your above criteria. But problem is, you should handle code for both cases(32-bit & 64-bit).
Note:
Additional Notes for you.
You can support from Minimum IOS 5.1
You can use Xcode 5.0.1 with IOS 7 base SDK