Adobe Air SDK 29 is not accepted by Apple

[gameduchy]

IOS is blocking AIR, rejected for months,due to AIR has API using IOPSCopyPowerSourcesInfo

Our mobile game uses FLash, and AIR 29 to make it work on IOS devices,

However, we can't upgrade our game since half year ago, and Apple review team finally told us the reason:

REJECTED：

Thanks for your resubmission.

Guideline 2.5.1 - Performance - Software Requirements

Your app uses or references the following non-public APIs:

_IOPSCopyPowerSourcesInfo, _IOPSCopyPowerSourcesList, _IOPSGetPowerSourceDescription

The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.

Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.

Next Steps

If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third-party libraries are calling these APIs.

Resources

For information on the "nm" tool, please review the "nm tool" Xcode manual page.

If there are no alternatives for providing the functionality your app requires, you can file an enhancement request.

Then we found it's in AIR sdk, even 29.

Then we replied:

The earlier letter said our app has the following non-public APIs:

"_IOPSCopyPowerSourcesInfo", "_IOPSCopyPowerSourcesList" and "_IOPSGetPowerSourceDescription".

We checked the ipa file with the tools you suggested.

"nm" and "oTool" found none.

The tool "strings" only found "IOPSCopyPowerSourcesInfo", "IOPSCopyPowerSourcesList" and "IOPSGetPowerSourceDescription" (non-underlined) referenced.

After searched the non-underlined version from the apple develop center, we thought they are public APIs.

However, we never called them.

These were found in the popular SDK Adobe AIR, and were alone there for years.

We haven't got any alternatives beyond Adobe AIR.

[paolon86536620]

I can confirm this.

However I just got a distriqt email related to this issue that says:

"Note: At the time of writing there are still some issues with Adhoc distributions using AIR 29.0.0.122 . Adobe are aware and are working on this further issue."

[cybobear]

I have this exact same issue. No ANE's, previous build was accepted and my app certainly does not use any location information. Really hope they come out with a fix soon for this I've already missed a deadline due to it.

[Swyze]

Hey, is it normal that I still see these in winHEX even with air 29.0.0.112?

_IOPSGetPowerSourceDescription, _IOPSCopyPowerSourcesList, _IOPSCopyPowerSourcesInfo

[Flipline]

Yeah, 112 is the older version of AIR before they fixed that.

[Swyze]

Ok, just updated to 122 and I can't find it anymore thx.

[amritag9336052]

Hi,

The ad hoc provisioning profile issue has been fixed in our latest beta.You may download the latest beta from Download Adobe AIR 30 Beta - Adobe Labs.

Thanks.

[dmitrybez]

Hello,

Will the fix for adhoc provision singing will be backported to AIR 29?

Because we are still want to support 32bit ios devices.

Thanks.

[Colin Holgate]

One question for you who are having ad hoc issues: Does it not work fine if you submit to Apple with an App Store provisioning profile? If testing using ad hoc is the only issue, you can do your development and testing with a development profile, and then submit to Apple with an App Store provisioning file. Wouldn't that work?

[Flipline]

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

One question for you who are having ad hoc issues: Does it not work fine if you submit to Apple with an App Store provisioning profile? If testing using ad hoc is the only issue, you can do your development and testing with a development profile, and then submit to Apple with an App Store provisioning file. Wouldn't that work?

Submitting App Store builds using the App Store provisioning profile would work fine.  My issue is that testing with a development profile (using ipa-debug or ipa-test packaging commands) produces a very different result in the ipa performance-wise vs. an adhoc distro profile ( using ipa-ad-hoc which is as close to the ipa-app-appstore release as you can get).  Interpreter builds are even worse of course, but just the standard debug build for development runs fairly poorly.  Not exactly ideal for testing and fine-tuning for performance on device.

[Colin Holgate]

What you say suggests that developer builds are not as good performance as distribution builds. If that's the case, and you get to a point that you're happy with the app, won't the store version be bound to be better?

I only discovered Ad Hoc later on, and I do like it as a way of working. But, in the first several years of making apps I was using development profiles, and somehow survived.

One other thought, to use TestFlight you would use an App Store profile, wouldn't you? You could use TestFlight as a way to do testing in an accurate way.

[Flipline]

That's true, we could just optimize to the developer build (though I've seen it running at about 1/2 the framerate in some cases, so that's a big range to deal with).  The issue is mainly that adhoc building/testing has always worked fine until Adobe accidentally broke it when patching to .122, and by moving on to AIR 30 which suddenly drops support for 32-bit devices, anyone who tries to stick with AIR 29 to support their existing apps is left with a broken product and will need to know about all of these workarounds (and if they're legitimately releasing adhoc builds for enterprise, they're absolutely out of luck).

[Colin Holgate]

As a compromise, could you develop with AIR 26 Ad Hoc, and switch to AIR 29 just for the store submission version?

[Flipline]

At the moment I'm using the older 29.0.0.112 for Ad Hoc builds, though it isn't publicly available anymore, Adobe removed it from the downloads when they released the patch so it's not a solution for all users.  It's frustrating knowing that there's definitely something different going on with how it compiles for the newer 122 for appstore builds, and we can't guarantee that what we're seeing with adhoc in 112 will be what users see in the appstore build of 122.

[OMA2k]

Thank you for the new AIR 30 release, but why was 32-bit support dropped?!

Lots of people still use iPad 2, 3, 4 and Mini. Most of our customers are still on iPad 2!

This change leaves A LOT of users out.

Will we have to be stuck on AIR 29 for years to come?

[peterf19399894]

More a question for Apple than Adobe

Apple made some announcements back in Jan 2017

The future of iOS is 64-bit only: Apple to stop support of 32-bit apps | Macworld

https://9to5mac.com/2017/01/31/ios-10-3-beta-32-bit-app-warning/

64bit only going forward so not a surprise if Adobe move to only 64bit

[OMA2k]

But that news

peterf19399894  wrote

More a question for Apple than Adobe

Apple made some announcements back in Jan 2017

The future of iOS is 64-bit only: Apple to stop support of 32-bit apps | Macworld

https://9to5mac.com/2017/01/31/ios-10-3-beta-32-bit-app-warning/

But those news you're quoting are about Apple not allowing 32-bit only apps. Currently apps compiled with AIR 29 are both 64-bit and 32-bit compatible (the IPA contains both versions so each device uses the version it needs). As long as 64-bit is supported, there's nothing wrong with having the 32-bit version in the IPA as well for older devices. It doesn't impair the 64-bit version in any way and Apple is currently allowing this just fine. So why drop support for 32-bit so suddenly?

[ASWC]

It's the case also for us but keep in mind the users with those old device cannot update to the latest Ios and that means it's not just your apps they can't use/update anymore it's really any app. So while Apple policies are arguable (they obviously want to force people to buy new stuff) they also follow up but blocking the os update on old device. So what that means for your apps (and ours, and any other company) is that Apple will be the one blocking apps update/install on those old device and your users can't really blame you for this. Now Ipad 2 for sure is out and maybe IPad 3 but mini and 4 should be fine I think. I'm sure not that long ago most of your customers (and ours) were on IPad 1 so we'll survive ....

[Flipline]

ASWC  wrote

that means it's not just your apps they can't use/update anymore it's really any app.

Sorry, that's not true.  Apple 100% still supports apps that include both 32-bit and 64-bit versions within the same app, it's just Adobe that is making this change, this is not mandated by Apple in any way.  Customers using armv7 devices like iPad 2/3/4/Mini can still get app updates for all other apps on the market, providing the developers are releasing 32bit+64bit builds, which is the standard way of doing it and which Xcode, Unity, etc. still support fully.

ASWC  wrote

Now Ipad 2 for sure is out and maybe IPad 3 but mini and 4 should be fine I think.

This applies to all devices that have armv7 chips instead of arm64 chips, which is the iPad 1 (deprecated anyway), iPad 2, iPad 3, iPad 4, iPad Mini, iPhone 5, and iPhone 5c --- all currently supported by Adobe in AIR 29, all losing support with AIR 30.  I've tested AIR 30 on all of those iPads, and none are functional.  Especially for iPads, that's on average 20% of the market for current installs (people do not update their tablets as often as their phones).

[OMA2k]

ASWC  wrote

It's the case also for us but keep in mind the users with those old device cannot update to the latest Ios and that means it's not just your apps they can't use/update anymore it's really any app. So while Apple policies are arguable (they obviously want to force people to buy new stuff) they also follow up but blocking the os update on old device. So what that means for your apps (and ours, and any other company) is that Apple will be the one blocking apps update/install on those old device and your users can't really blame you for this. Now Ipad 2 for sure is out and maybe IPad 3 but mini and 4 should be fine I think. I'm sure not that long ago most of your customers (and ours) were on IPad 1 so we'll survive ....

This problem is NOT the same as iOS not supporting older devices. In that case it's Apple's fault and nothing can be done about it. But in this case Apple is perfectly supporting 32-bit apps and they will support them for quite some time still, as there are a lot of 32-bit only devices, and no, the iPad Mini is not "fine" with 64-bit apps as you say, because it's actually a 32-bit device as well with the very same old hardware as the iPad 2. It was already an outdated device when it came out, but no one noticed because Apple ;-).

As others have already pointed out, all other multiplatform frameworks support 32-bit apps. It's only Adobe AIR not supporting it.

Also, Apple doesn't allow an existing hybrid 64-bit/32-bit app in the App Store to only support 64-bit in a future update!

That means that ALL existing AIR apps won't be able to be updated AT ALL! (AIR 29 apps were always compiled as hybrid 64/32 apps). This doesn't make sense.

We should open an issue in Adobe AIR's bug tracker to explain this issue to the developers of AIR SDK. Especially because this arbitrary decision of dropping support for 32-bit was caused by a problem with Mac OS X, which is an entirely different platform! They should only drop 32-bit support in Mac OS X, but NOT in iOS!

[William Spence]

Guys, how do we make our case to Adobe?  Do we set up a poll or a petition to keep 32-bit support? Do we create a bug tracker for the AIR developers to take notice of?  Are they flexible on this issue, or is it set in stone?  This is a crucial change that is going to affect the bottom line of a lot of companies, along with our approval ratings with our customers.  Apple makes very durable and stable products and I personally have an iPad 3 that I have never felt the need to upgrade, and if I had my choice to keep my iPad or buy a new one just to be able to use a particular app, the app would lose. I'm not spending $1000 just to use a single app.  But as a developer, I cannot give up 30% of my market either just because they drop 32-bit support.

If nothing else, I would appreciate one of the AIR developers to at least make a statement behind their reasoning for this sudden and drastic change so that we have an understanding as to Adobe's reasoning behind this.

[Flashneverdies]

William - I totally agree with you. This would be a disaster. I also have an iPad 3 and it's still perfectly fine. I don't want to have to fork out for a brand new iPad just to test.

There are thousands of schools with iPads, and some of those might be 32bit devices. That's a big market and a big loss.

** I've just spoken to my client, and we are really worried. We make educational apps and since kids usually get handed down the older iPad models, that will kill off our future app funding for good. It's that serious!

Let's hear it from Adobe.

[cybobear]

Wait, so to confirm. If the future SDK's don't support the 32bit devices, isn't it still possible to update those apps with an older SDK like 28, that does support 32bit? You obviously won't get the latest fixes and enhancements, but wouldn't updating still be possible?

[Flashneverdies]

Not for long. Look what trouble we had with Air 29. Apple's software is changing all the time, and it could be literally a week or month and some new requirement will stop our old Air version from working.

Looks like this could actually be the end of my already very difficult career as an app developer!

[cybobear]

Right, though we did find a workaround with the latest manifest adds. I see your point. But to make clear, how far back can we currently go with the air SDK and still be approved by the apple store? If it's pretty far back that should offer some comfort. Until 28 won't be accepted by the store, I wouldn't really panic.

That being said, it seems that Adobe should try to support 32bit up to the point that those devices are considered deprecated from a developers point of view. I don't think iPhone 5 especially would be considered deprecated at this point.

[William Spence]

cybobear, I don't know if you have followed this entire thread, but there have been a lot of problems lately.  Apple restricted some of the code/entitlements/methods that they will allow access to.  Many older versions of the AIR SDK violated these new restrictions(I read posts claiming App Store rejections as far back as AIR 23) The problem is that Adobe came out with a quick patch in AIR 29-122, but it is full of holes regarding ad hoc provisioning and needs a solid replacement.  So we have all been waiting for Adobe AIR 30 to fix everything, but now they are dropping 64-bit support.

So you have two choices. 1) Either hobble along with Adobe AIR 29-122 for as long as you can because most older AIR SDK's are worthless for iOS.  This is risky because Apple can change a policy at any time and AIR 29 would then become worthless, and therefore so would your app or 2) Update to AIR 30 and lose the ability to update any of your 32-bit apps or to serve any of that market, you would only be able to deliver 64 bit apps and give up access to 25% of the market.

All Adobe needs is to give us a choice to export to the format that we need, but taking it away at this point is unnecessary and a bad business decision for all of their users.

Go to this thread to make a little noise and voice your opinion on this situation if you are as unhappy as the rest of us:

AIR 30 dropping support for 32-bit in iOS apps