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.

[OMA2k]

Flashmonkey500​ : You CAN test even if you can't use ad-hoc. After uploading to iTunes Connect, you can use the "TestFlight" tab to setup that version as a test version, then download it into your iOS device using the TestFlight app (official Apple app). Once your testing is done, you can submit that same version of the IPA without reuploading, from iTunes Connect.

witekgolden​ : You have to remove the whole <Entitlements></Entitlements> block so ad-hoc mode works again. If you want to test in TestFlight, then you have to restore that block back in its place.

[Flashneverdies]

Thanks, good to know about the Testflight method

[Flipline]

Don't use the "beta-reports-active" key in your XML if you're planning to use adhoc, that's the whole reason why the newest AIR SDK is broken for adhoc -- Adobe is accidentally automatically adding it to every build for some reason.

[OMA2k]

Flipline​ : If the latest AIR adds the entitlements block even if you don't add it yourself, does it work if you explicitly add an entitlements block with the opposite values? (i.e: with "beta-reports-active" set to false instead of true). Does it still override the values you specify?

[JulianDMG]

No, it doesn't override the value you specify but setting beta-reports-active to false won't fix the issue because the entitlement itself (regardless of being true or false) is not supported in Ad Hoc provisioning profiles, so you will get an error when trying to install the app.

[OMA2k]

I see. Thank you for your reply, JulianDMG​

In that case, is there an issue created in Adobe's Bug Tracker to let them know there is a bug in AIR 29.0.0.122 which makes it wrongly add an "Entitlements" block when compiling as ad-hoc?

[Flashneverdies]

I always search 'download air sdk' and this is the page I got it from:

Download Adobe AIR SDK

I can confirm my steps above worked for the Apple review.

- the icons need to be in a folder called 'icons'

- I only put those 8 icons in the folder

[Shahbaz Pothiawala]

Hi. I am following this thread since that time I was getting error IOPSCopyPowerSourceInfo. I am now using AIR SDK 29 from the Adobe website along with Assets.car file packaged with the app. However, I now get the following error email from Apple saying :

Missing Info.plist key - This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSLocationAlwaysUsageDescription key with a string value explaining to the user how the app uses this data.

Missing Info.plist key - This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSLocationWhenInUseUsageDescription key with a string value explaining to the user how the app uses this data.

On searching, I found that ios apps require permissions to be set in XML that would also reflect in info.plist file.

However, my app does not require any location permission! Is it the new sdk that needs location permission? If so, why? and how do I solve this error?

[Flashneverdies]

Hi, I've just had the same problem! Just when I thought I'd got it nailed, now this new bug!

[Shahbaz Pothiawala]

I think I got some solution to my own problem. Adding the below code in the app descriptor xml might work, as doing so my app just passed the initial phase and is now under review by apple. hope this works.

<InfoAdditions>

      <![CDATA[<key>NSLocationAlwaysUsageDescription</key><string>Required by Adobe SDK</string><key>NSLocationWhenInUseUsageDescription</key><string>Required by Adobe SDK</string><key>UIPrerenderedIcon</key><true/><key>UIDeviceFamily</key><array><string>1</string><string>2</string></array>]]>

    </InfoAdditions>

[hhhhhhhhhhhhhh5]

Got the same error from Apple. Thank you foofook85423902 for sharing the hack!

[cybobear]

Will try this when I need to submit again. We don't need to be worried about privacy here do we? I mean, adobe isn't grabbing location data from our users behind our back is it? That would be terrible.

[peter_nicolai_123]

This could be an Apple thing too - we submitted a build with the new v29 sdk and it got approved, then another that didn't because of this. Nothing changed between the two builds that would have affected anything to do with location permissions. Since it's impossible to submit builds with any other version of the SDK now, it's hard to really verify if this is about an SDK change, appstore review policy change or both, but it must be at least in part due to appstore review policy.

[cybobear]

This is confusing to me, so you are saying that with v29 some of your apps are approved and some are not with this same error?

So this wasn't fixed in v29 sdk then? It seems adobe said it was in the bug tracker here: https://tracker.adobe.com/#/view/AIR-4198623.

It looks like v29 is a official release and not a beta right?

[peter_nicolai_123]

No, I was talking about the location permission string. Apple accepted our latest build, but we had to add the location permission strings described above. Since we're not doing anything that's going to ask for this, and don't see these popups ever in testing, it's not a big deal given the ask-as-you-go permissions model to just add them to satisfy Apple (for the moment anyway).

[cybobear]

Thanks for clarifying. It does seem odd that adobe closed the tracker for this exact bug, and you're saying it's actually not fixed and you need to use the InfoAdditions hack.

Do you see any reason for suspicion for privacy issues for our users that adobe may actually be using location information within the SDK itself?

[peter_nicolai_123]

The tracker link you posted is about the original issue with private APIs, this is different.

If I had to guess, I'd say Apple is just getting pickier about code included in the exe that's referencing APIs like this, even if that code is never called. As far as privacy issues, Adobe couldn't be sneakily looking at location info because if they did, either users would see a popup asking for the permission, or if the permission string didn't exist the app would crash. Just in case, the permission string we included assures users that clicking "Don't allow" is fine and that our app doesn't use or ask for these permissions, but they're unlikely to ever see it.

[cybobear]

I see. I assume there is a new tracker bug for this issue then.

Is it still the case that all air apps require full network access? I remember this was something to do with the captive runtime but now it's always included in the builds. A little paranoid with privacy issues with all that's going on in the news. Be nice to see an official statement from adobe regarding the SDK and privacy.

[marchbold]

Same thing happened to us, we had a build approved and released early this week and then an update yesterday with only minor changes triggered the location usage description errors.

We just added them to our info additions and review passed, so definitely appears to be another Apple requirement change here.

[Flashneverdies]

Thanks foofook - Apple passed my app already with your handy hack. You're the hero of the day!

[OMA2k]

Hello foofook.

Could you please explain what does this code you posted exactly do? What are those "Required by Adobe SDK" strings for?

<key>NSLocationAlwaysUsageDescription</key><string>Required by Adobe SDK</string><key>NSLocationWhenInUseUsageDescription</key><string>Required by Adobe SDK</string>

Thank you!

[Colin Holgate]

In iOS you have to give the user a reason why you want a particular feature to be active in the background. Here's an article about it:

Requesting Always Authorization | Apple Developer Documentation

I think that "Required by Adobe SDK" wouldn't mean much to people, and although Apple's automatic checking will be happy, a reviewer might question whether the phrase is good enough. If your app is using location features, something like "Required for app GPS feature", would be better. If the alert is coming up for all AIR apps, regardless of whether they use location services, that's something Adobe ought to fix.

[rewb0rn]

Hey Colin if I understand correctly, the description must be included because Air binds the API for geolocation, which Apple recognizes now. But if your app doesn't trigger it, the description will never be shown to the user, i.e. they will never be asked to give this permission. Or did you make a different observation?

[Colin Holgate]

Hopefully you're right, and reviewers will never see the message. If you do use location services, the message could be better than just saying Adobe needs it that way.

[eckhoff_randy]

More info about the ad-hoc not working... I seem to be getting a similar issue working with enterprise certificate and mobile provision file. Trying to debug on the device directly i get the api internal error or application verification failed errors. If I bundle the app for enterprise distribution, when I download, it downloads, installs but won't run on the iphone. the error message says the file couldn't be downloaded. I'm guessing this is the same issue. This is with AIR 29 122.

If i revert back to AIR 29 112, same exact build works like it always has with no issues.