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.

[PippoApps]

True. We should probably petition Adobe for this since AIR30 is still in beta.

[zwetan_uk]

no, there is no need to petition Adobe

first, AIR 29 is there and working

AIR 30 is only at the early beta stage, by the time it will be released in a couple of months
supporting 32-bit hardware will be even less relevant

in all case, like I mentioned earlier like el111 and others mention too, etc.
Apple QA1623 clearly indicate you can "downgrade" an hybrid (32-bit + 64-bit) app to 64-bit only

it's all there in plain text, just take the time to read and understand it

People having concerns about not being able to update their hybrid app

just don't know what they are talking about (seriously shame on you for wasting everybody time on that subject)

I really don't see why Adobe should waste their valuable time supporting both 32-bit and 64-bit iOS

when the owner of the platform Apple clearly indicate they do no want or will support 32-bit apps and devices

and btw, if you're using ANE in your iOS apps, do also check if they support 64-bit

otherwise you're in for a big surprise

As an AIR dev if you know a little bit what you're doing you do want to only do 64-bit app

that means leaner IPA, no need to support both 32-bit and 64-bit in ANE, etc.
much much less headache which is not even worth considering for 5% of old devices

[castik]

Can you please explain this?

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

Does Air 30 modify UIRequiredDeviceCapabilities ?

[Flipline]

YES, AIR 30 does modify UIRequiredDeviceCapabilities, which is in violation of Apple's policies outlined in QA1623.  It's all there in plain text that this is not allowed.

[castik]

Sorry Flipline the question was for zwetan_uk

so Zwetan_uk can you please confirm because  I believe this is our biggest problem.

You insist that is possible and other people think is not possible.

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

Does Air 30 modify UIRequiredDeviceCapabilities?

if yes then we have a problem. If no then we are good.

[castik]

Yes it is terrible not annoying for the following reasons:

1. Users will be confused because app will tell them to update but they will always see ’install’ in the store. They will probably not figure out that they must delete first to update as it is counter intuitive.

2. Our apps have a guest feature which means when app is deleted to install a new ‘same app’ their progress will be lost because a new userid guest is generated.

3. The current  store ratings will be lost.

4. Work to be done on setting up a new app in terms of IAPs, localization , art, etc

5. Current position in the tops will be divided between two same apps as the old app can not be deleted as IAPs will stop working for existing users until they update.

when we invest $ to acquire users  and we can not update our apps any longer this is not annoying it is terrible.

[ASWC]

https://forums.adobe.com/people/Josh+Tynjala  wrote

ASWC   wrote

Why a "serious issue"? We can publish our new updated 64bits only as new apps which is something many have had to do before for number of reasons anyway. It's annoying sure but really serious issue?

I'd call that much more than annoying. You're saying that thousands of AIR developers that want to update their apps that were originally built with AIR 29 or below will each need to publish a completely new app instead of updating their existing app? They'll need to try their best to inform their existing users that they need to uninstall the existing app and download the new app instead. They'll definitely get stuck with a ton of users on an old version. Some will abandon the app because it's too much effort to search for the new version, even if they liked the app.

If the app was paid, do you just offer it for free for a couple of days so that your existing users don't need to pay again? I've seen a temporary discount for a new "major" version before, but it's one thing when you make that choice yourself, and it's another when you're forced to do it because Adobe made a poor choice.

Are you saying if Adobe supports 32bits until the last moment when Apple pulls the plug on it nobody will have to face all the problems you are listing here? Is that "serious problem" going to go away forever once Adobe complies with the request here and support 32bits until Apple doesn't?

[Josh Tynjala]

ASWC  wrote

Are you saying if Adobe supports 32bits until the last moment when Apple pulls the plug on it nobody will have to face all the problems you are listing here? Is that "serious problem" going to go away forever once Adobe complies with the request here and support 32bits until Apple doesn't?

As far as I understand the situation, yes.

[ASWC]

Ok then if it's the case I will retract all my statements. But someone please explain to me why the EVENTUAL complete drop of 32bits support by Apple will not put everybody in the same situation?

[William Spence]

My thought is that when the day comes that Apple actually does drop 32-bit support 100%, they will remove the UIRequiredCapabilities restriction that keeps you from updating an app when you change your packaging to 64-bit only, because they will have to for XCode apps as well.

But of course, that is just a guess

[castik]

Yes correct Apple will have to drop the requirement when they will do it for XCode apps.

There is no way that all the apps in the store will have to be re-created as new. That would be insane and stupid at the same time.

[ASWC]

Well that's a given since 32bits will be gone I'm pretty sure they won't force you to keep delivering 32bits compliant apps but this is just one part of the problem, will this change any possible negative outcome concerning your customers or will it end up being the same problems?

[Josh Tynjala]

ASWC  wrote

Ok then if it's the case I will retract all my statements. But someone please explain to me why the EVENTUAL complete drop of 32bits support by Apple will not put everybody in the same situation?

Presumably, if Apple were to drop all support for universal apps that contain 32-bit code, they would provide a migration path for the millions of existing native apps that are currently universal.

[ASWC]

https://forums.adobe.com/people/Josh+Tynjala  wrote

Presumably, if Apple were to drop all support for universal apps that contain 32-bit code, they would provide a migration path for the millions of existing native apps that are currently universal.

Well that's where we diverge, for me the universal apps IS the migration path and eventually Apple will indicate with some reasonable delay (usually from 6 month to a year) the drop of 32Bits. For you there will be an additional step in between that will make for an easy migration for developers and customers, well alright we will see soon enough if you got this right, personally I don't remember when was the last time Apple made a migration or anything easy for anyone.

[Flipline]

I agree that point will come in the future, but personally I think it wouldn't be as large of an issue for us if it was affecting ALL apps available on the App Store at the same time (by changes from Apple), versus a change that Adobe is making but other toolsets and engines are not currently making.  It would be much easier to explain to users that all apps they could possibly want are 64-bit only now, rather than explaining that our apps are now 64-bit-only because of the toolset we chose, while competing apps are still working just fine because those toolsets decided to wait until Apple pulls the plug themselves, however further in the future that might be.

Presumably Apple would communicate things directly to the affected users (through the App Store app itself?) that they'll no longer be able to download any new or updated apps when that time comes.  I'm not sure end users necessarily realize how antiquated their devices are, and right now they may just know that they can't get iOS 11, but they can still get Minecraft and Five Nights at Freddy's and Netflix and that's all they're really worried about.

[William Spence]

Very Well Said Flipline.  I agree 100% that all tools should be affected at the same time, and trickle down from the top - Apple.  It will make us as developers appear MUCH more competent to our clients and users for choosing to use AIR. (which is of course my favorite tool of them all)

[ASWC]

AIR 29 should allow you to do just that. It's clear that if you are gonna target Ios11 minimum (which Apple in future will require) then AIR30+ is all you need, on the other hand if you still support Ios11- then AIR29 is here for you. So I still don't really see what's missing here.

- Publish new apps compatible with any near future requirements: AIR30

- Publish universal apps so you can update old ones and support minimum OS requirements: AIR29

For me there's some logic in there.

[Flipline]

I'd love if it were as simple as that, but AIR 29 has a number of new issues with Apple's submission process that Adobe decided not to fix, and are only updating to fix those issues in the AIR 30 Beta.  Their latest build of AIR 29 also broke some features in the process while they were getting it to comply with the first round of submission issues, and I'm guessing they also won't be going back to fix those in AIR 29, since they're listed as fixes in the AIR 30 release notes and they keep directing users to download AIR 30 instead.  If they had left us with a stable usable release of AIR 29 it wouldn't be as big of a deal, but it's a bit of a mess at the moment.

[cybobear]

I have to point out that this point was made pages ago in the thread. Thanks for continuing to engage Flipline, you are patient indeed.

[ASWC]

If AIR29 is indeed not working correctly then I have to side with all of you. My argument was always based on the assumption that AIR29 was available to publish universal apps.

I apologize to cybobear for not having the 30 minutes required to read every single posts on this thread prior to me joining. (yes this is sarcastic and warranted)

[cybobear]

I sincerely applaud your ability to admit your wrong and change your stance.

Correct me if I'm wrong but most forums have sticky's asking users to do that exact thing - read the complete thread to prevent the thread from becoming bloated and redundant. However, I'll admit that I too am guilty of not always doing that or just skimming it over. Time is in short supply these days.

No sarcasm here. Hope you have a great day.

[William Spence]

ASWC, I would be happy with your solution of AIR 29 being universal, and AIR 30 for iOS 11 and above.  Sadly, Apple continues to regularly change the submission policies, thus requiring an AIR update, and then we would really be hosed.  I would not be surprised if AIR 29 is only able to successfully submit apps for a few months, not a full year or so.  Plus, as Flipline pointed out, it is broken already.

[Colin Holgate]

As far as I'm aware, the only problem with AIR 29 at the moment is that you can't do Ad Hoc builds. I'm currently working on an app update for a client, that was done in AIR 4. Because of Apple's requirement that you have to support iPhone X, that indirectly rules out iOS 8, so fortunately I only have to test on iOS 9 or later. But, the client wouldn't be very happy if the update only could work on devices that could run 64 bit apps.

I found this list of devices that can run 64 bit iOS 9, but may not be able to run 64 bit apps:

iOS 9 Will Work on Your Old iPhone But Apps Might Not

Think I will forward that to the client, see if they can cope with losing those customers.

Meanwhile, I expect I will use AIR 29 and cope with not being able to do Ad Hoc builds.

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?

[cybobear]

The other issue with 29, not sure if this is fixed in beta 30, is that the iOS simulator on OSx is broken: iOS simulator broken with new updates

Haven't received an update on that from the air team yet.

[Colin Holgate]

On the simulator issue, there is a workaround, Mohanaraj​ , can that be shared here? Meanwhile, the AIR team are looking at the problem.

Even with the work around there isn't an easy way to do iPhone X testing in the simulator, but I found a tolerable solution to that too.

I'll add a note to that other topic, which will give Mohan even more to read!