AIR 30 dropping support for 32-bit in iOS apps

[Flipline]

The latest AIR 30 Beta on Adobe Labs mentions a big change for releasing iOS apps with AIR:  You'll no longer be able to release iOS apps that contain both 32-bit and 64-bit versions as it's done by default for years, and instead will only be able to release 64-bit-only apps. 

This is a huge change for anyone with customers who still use the iPad 2, iPad 3, iPad 4, iPad Mini, iPhone 5, or iPhone 5C, since all of those devices require a 32-bit version to be included in the "universal" single app alongside the 64-bit version that newer devices will use.

To clarify, I know that Apple does not accept apps that are 32-bit-only anymore.  This is concerning apps that contain both 32-bit and 64-bit code in the same single app (allowing support for iOS 9 devices as well as iOS 10+ devices), which is what AIR has done in the past and which Apple currently accepts, and which AIR 30 is dropping support for.

My biggest concern is what will happen when we need to update any of our already-existing apps in the App Store with AIR 30.  Does Apple allow you to update an app with a build that removes support for platforms?  And if so, what happens to those customers who already purchased our apps and are using them on iOS 9 devices -- will it download the update and the game they paid for will suddenly break and stop working?  Does Apple recognize they're using a 32-bit device and will prevent them from downloading the update if the update only includes a 64-bit binary?

Also I'm curious if this is something mandated by Apple -- where in the future apps will only be accepted if they're 64-bit only and won't be accepted if they include both as they do now -- or if this is Adobe's decision to drop platforms.  I haven't seen anything in the Apple Developer news or updates about dropping support for 32-bit when it's bundled with 64-bit, and Xcode seems to still create both 32-bit and 64-bit versions by default as AIR 29 currently does.

Here's the info in the release notes here:

http://fpdownload.macromedia.com/pub/labs/flashruntimes/shared/air30_flashplayer30_releasenotes.pdf

Converting Universal iOS binaries to 64-bit and making IPA 64-bit

Prior to the AIR version 30, iOS applications were packaged as universal applications. To package a 64-bit iOS application MinimumOSVersion had to be set 11.0 in the application XML.

Starting AIR version 30, all iOS and tvOS applications would be made 64-bit only, irrespective of the MinimumOSVersion tag in the application XML. Packaging universal and 32-bit iOS applications would not be supported. ANEs could be packaged using universal as well as 64-bit only native frameworks, 32-bit native frameworks would not be supported for ANEs also.

Android packaging would remain unaffected.

[Flipline]

https://forums.adobe.com/people/Colin+Holgate  wrote

For those of you who have talked about having a lot of customers using the 32 bit part of your existing 32+64 bit apps, what iOS version are they running? If it is iOS 8 or earlier, how will you update the app in a way that complies with the new iPhone X requirements?

Here's a sample of what I'm seeing for our installs in the last 90 days across multiple apps and what OS the users are running:

Papa's Freezeria HD: 

64.25% iOS 11

15.51% iOS 10

20.24% iOS 9

Papa's Pizzeria HD:

69.3% iOS 11

15.39% iOS 10

15.31% iOS 9

Papa's Hot Doggeria HD:

72.16% iOS 11

12.77% iOS 10

15.07% iOS 9

(iOS 8 is negligible, just one or two units per app)

This is a sampling of apps that were released years ago and apps released more recently, but these are all installs that were made within the last 90 days.  These are iPad figures, so I'd imagine the large volume of iOS 9 is from legacy devices that can't upgrade beyond iOS 9.3.5.  Hard to say with iOS 10, some may be iPad 4 locked into 10 and some may be newer devices and haven't updated their OS yet.

[Colin Holgate]

These are the iPads that can run 64 bit iOS but not 64 bit apps:

iPad 2

iPad 3rd gen

iPad 4th gen

iPad Mini

[Flipline]

If you unzip the ipa created by AIR 30, it has "arm64" as a required device capability for the app to run.  These devices do not support arm64 architecture and can not run apps created by AIR 30 right now:

iPad 2

iPad 3

iPad 4

iPad Mini

iPhone 5

iPhone 5C

I've attempted to install an AIR 30 on all 4 of those iPads listed, and I get errors on all of them that it is not supported.

On Apple's Device Compatibility page you can see in Table 1-7 (and 1-6 and 1-5) that these devices do not support arm64:

https://developer.apple.com/library/content/documentation/DeviceInformation/Reference/iOSDeviceCompa...

[ASWC]

I get similar figure, it's moving along nicely. Each time Apple move the minimum OS up (next os8 will be dropped) we have to handle a few customers problems but overall by the time we publish our updates most customers have the correct device/os. Don't forget also that when Apple up their minimum OS your next update is not required to support the dropped OS anymore so there's no reason to think our legacy apps will have to support 32bits once Apple drops it, most likely we'll publish a 64 without problems.

From what I was able to read it seems publishing with AIR29 works fine so as far as I'm concerned I don't see any support problem for us with our customers.

[Flipline]

One outstanding issue with AIR 29 I'm seeing is Apple rejecting apps in AIR 29 that don't include NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription keys.  Yes, we can include the keys ourselves ourselves for now with a nonsense description of "Required by Adobe SDK for some reason".  That's a temporary solution (maybe for weeks? months?), and Apple reviewers will eventually crack down and want to know why Adobe is accessing location APIs when our apps aren't using them, and will require the API access to be removed from the app instead of just adding a bogus text string as a reason.  I'm sure Adobe will eventually fix it for AIR 30, but AIR 29 will be left as-is.

For one of our own apps we squeaked by with an update on March 28th before this new restriction went into affect on April 1st, but AIR 29.0.0.122 builds have been hit with this rejection since then.

[OMA2k]

Flipline  escribió

One outstanding issue with AIR 29 I'm seeing is Apple rejecting apps in AIR 29 that don't include NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription keys.  Yes, we can include the keys ourselves ourselves for now with a nonsense description of "Required by Adobe SDK for some reason".  That's a temporary solution (maybe for weeks? months?), and Apple reviewers will eventually crack down and want to know why Adobe is accessing location APIs when our apps aren't using them, and will require the API access to be removed from the app instead of just adding a bogus text string as a reason.  I'm sure Adobe will eventually fix it for AIR 30, but AIR 29 will be left as-is.

For one of our own apps we squeaked by with an update on March 28th before this new restriction went into affect on April 1st, but AIR 29.0.0.122 builds have been hit with this rejection since then.

Well, on April 12th we uploaded to the App Store an app update compiled with AIR 29.0.0.122 without including any of those keys and it was approved, so you never know. Probably the person reviewing the app didn't notice. But still, it's a problem with AIR 29 that should be fixed.

[Flipline]

Glad to hear your update made it through, it looks like I may have been mistaken about the date the issue started, April 1st was the _IOPSCopyPowerSourcesList issue but the location issue started cropping up around April 26th.  For anyone interested, Page 4 of this topic discusses the issue with Apple's rejections from accessing privacy-sensitive data with the location services in AIR 29 (and the temporary workaround of adding a bogus explanation key to our apps while Adobe still accesses these services):

Adobe Air SDK 29 is not accepted by Apple

[OMA2k]

I see. BTW, thank you for all your informative posts, Flipline!

You're really helpful. There should be more people like you in these forums!

Just one question for you: You say that Apple will reject any iOS 11 update because AIR 30 sets the "UIRequiredDeviceCapabilities" attribute to "arm64" and Apple explicitly says "Important: Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version".

But if that's the case, how can anybody update ANY hybrid iOS app (even native Swift or Objective C apps) to iOS 11?

I'm asking this because iOS 11 requires "arm64" devices anyway (it doesn't work in "armv7"), and I don't think Apple will forbid ALL iOS developers from updating their previously hybrid apps to iOS 11 (requiring them to create new apps with different app bundle identifiers), won't it?

Also, Apple says that you can remove device support if you "target a newer version of iOS that requires a newer device". Wouldn't that be an exception to the "Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version" rule?

Thank you for your comments.

[Flipline]

OMA2k  wrote

I'm asking this because iOS 11 requires "arm64" devices anyway (it doesn't work in "armv7"), and I don't think Apple will forbid ALL iOS developers from updating their previously hybrid apps to iOS 11 (requiring them to create new apps with different app bundle identifiers), won't it?

Also, Apple says that you can remove device support if you "target a newer version of iOS that requires a newer device". Wouldn't that be an exception to the "Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version" rule?

Thank you for your comments.

From what I've seen in Apple's policies and Q&A, they want you to only change MinimumOSVersion to 11 in order to limit it to iOS 11 devices, and to not change UIRequiredDeviceCapabilties at all in the process.  Like you said, iOS 11 only runs on arm64 devices anyway so you're effectively limiting it, but by Apple's policies you can't explicitly change your device requirements, only that minimum iOS version.

For what it's worth, AIR 28 and 29 already upgraded to the iOS 11 SDK so they already do have the ability to support the newer SDK functions if you have an ANE that uses iOS 11-exclusive features, so using AIR 30 and 64-bit-only is not a requirement to get the features of iOS 11 (you'd just have to gracefully handle older devices not supporting certain APIs, etc. like most ANEs require).

[OMA2k]

Flipline  wrote

From what I've seen in Apple's policies and Q&A, they want you to only change MinimumOSVersion to 11 in order to limit it to iOS 11 devices, and to not change UIRequiredDeviceCapabilties at all in the process.  Like you said, iOS 11 only runs on arm64 devices anyway so you're effectively limiting it, but by Apple's policies you can't explicitly change your device requirements, only that minimum iOS version.

But that doesn't make sense. Why change "MinimumOSVersion" to 11 but still indicate that your app requires a device with "armv7" capabilities when iOS 11 doesn't actually support that capability? (it only supports "arm64" devices). If Apple really requires that, it doesn't make sense at all.

Even if Apple's policies say you can't explicitly change your device requirements, they also say that "developers who wish to issue updates, but remove device support" can "target a newer version of iOS that requires a newer device". Wouldn't that be an exception to the aforementioned rule of not being able to remove device support in an update?

[Flipline]

I agree it doesn't make sense, but their Q&A mentions this in multiple spots:

Important: Because you can't add UIRequiredDeviceCapabilities restrictions after an app is in the store, be sure to plan ahead by choosing requirements you will be comfortable supporting indefinitely going forward.

Important: Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version.

For example, if your app is no longer built with armv6, you should not add armv7 to your UIRequiredDeviceCapabilities.

(I'm assuming armv7 -> arm64 applies to that last case as well)

I don't know of any exceptions to this policy, and was hoping Adobe could enlighten us on if they have additional info from Apple about this, since they'd be the most likely to have this information from the source, and have hopefully checked with Apple about this to confirm before deciding to drop support.  It would be nice to know for certain whether there are exceptions (meaning AIR 30 can be used for updates) or if there are not (meaning AIR 30 can not be used).  Looking through all of Apple's documentation on UIRequiredDeviceCapabilities and the related Technical Q&As, I haven't seen anything that would allow for any exceptions, just repeatedly stating that you can not ever change those values in an update for any reason, and must only change MinimumOSVersion.  Hoping Adobe can set the record straight for everyone, so we're not second-guessing whether Apple really means what it says in all of its documents.

[OMA2k]

Thanks for your replies, Flipline! I hope someone from Adobe can explain things clearly...

BTW, how does AIR not supporting 32-bit affects Android apps? Surely there must be LOTS of 32-bit ARM Android devices, right? Or maybe 32-bit support for Android still hasn't been dropped?

[Frédéric C.]

AIR 30 release notes say that Android apps remain unaffected by this change. Only iOS apps are.

[Flipline]

https://forums.adobe.com/people/Fr%C3%A9d%C3%A9ric+C.  wrote

AIR 30 release notes say that Android apps remain unaffected by this change. Only iOS apps are.

I just double-checked an Android build with AIR 30 and can confirm it's unaffected, still supports 32-bit with the armeabi-v7a platform, with the exact same number of supported Android devices between AIR 29 and AIR 30.

[William Spence]

Very Interesting.  Seems strange that you would be willing to put in the man hours and support 32-bit for other platforms, but not for iOS.

I think I would be happy if Adobe would release AIR 30 and beyond in 64-bit for iOS, if they would also continue to make legacy updates to AIR 29 for a year, or until Apple pulled the plug.  That would make me ecstatic.  Any chances of doing that for us Adobe???

[Amrita Gangwani]

Hi,

The latest beta AIR SDK 30 supports the universal architecture for iOS. You may download the beta from Download Adobe AIR 30 Beta - Adobe Labs

Thanks!

[chaky]

Amrita Gangwani,

Is it still possible to build 64bit only apps for iOS. With AIR SDK prior to version 30 I needed to supply minimum os version 11 to build 64bit only apps. Now that things are reverted do I need to supply minimum version again to build 64bit only apps and what is the minimum version that I can supply that will build 64bit only app?

Thanks,

Caslav

[Amrita Gangwani]

Hi,

Yes, MinimumOSVersion set as 11.0 in the application XML should work for you.

Thanks!

[cybobear]

Thanks Amrita!

Just a quick note that the expired certificate warning is still present in this latest release.

-cybo

[Flashneverdies]

Hi Cybo, can you please elaborate on that issue? Is that a warning you get after submitting to Apple, or before? I can at least publish to my device with Ad Hoc, but need to send a build to Apple soon..

[rewb0rn]

There is a warning that a certificate has expired when submitting the .ipa to the Appstore with Application Loader. Our apps are currently waiting for review with todays Air 30 Beta SDK so I don't know yet if that certificate warning will be a problem during review. But the latest release notes include this as a known issue so I assume the warning should be resolved with an upcoming release, probably at the end of the Air 30 beta cycle.

[cybobear]

Flashmonkey500​, there is a thread here concerning it:New Bug with Adobe Air 29.0.0.122

It appears to be a glitch of some sort that produces a warning during automated processing of the binary. I was able to successfully get an app approved with it occurring using the previous release of air 30 beta. Note that all the relevant team members will get an email from Apple with the warning, which is a little annoying.

Hope that helps.

-cybo

[Paul Darky]

Hi

Flashmonkey500

Could you please let us know when you get through the whole process in the AppStore?

It will be very much appreciated.

Best Regards

[Flashneverdies]

Hi Paul,

Actually I don't think I'm going to be able to finish my app update before I go away away next week.

But I'm sure someone will feedback their results very soon. If I do I'll let you know..

Thanks

[Paul Darky]

Thanks a lot Flashmonkey500!