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.

[cybobear]

I've been following it, but haven't read every post in detail. I agree as I said in my last post, Adobe should support 32bit until the devices are considered deprecated. But if AIR 29 is working with the workaround, that's a good thing. It could break again as it does working with Apple's constant policy changes and as you said then you'd be forced to use AIR 30.

It does seem like Adobe didn't want to put the hours in to support both bit architectures in their SDK. I can sympathize that it's probably hair pulling work trying to constantly satisfy Apple requirements. It's almost as if they make them just to keep it tough for the Adobe staff lol. Hopefully enough pressure will have them reconsider the 32 bit support. I'll add my support to the thread you've linked.

[kheftel]

This is a little late, but I wanted to add just in case anyone else sees this:

Since adhoc builds are broken in AIR SDK 29.0.0.122, I tried building with AIR SDK 29.0.0.112 for adhoc testing. Building failed with I errors for all my ANEs saying they must be built with universal binaries. "ANElibname1.a, ANELibname2.a are required to have universal iOS libraries. Please contact the ANE developer(s) to get the same."

I forgot that this was solved back in AIR 16, where all ANEs had to support both 32- and 64-bit. I wasted a lot of time before I figured out how to use the file command on macOS terminal to figure out that all my ANEs have been universal binary for a long time.

I've gone back to AIR 28 (which also uses iOS 11 SDK) from the archived downloads page, and have been able to successfully build adhoc versions for testing. Now to add Assets.car and work towards a store submission, which as far as I understand I have to use AIR SDK 29.0.0.122 to build in order to avoid the "use of non-public API" bug.