Failure when delivering .ipa- ITMS-90338: Non-public API usage

[everseen83]

Problem Description

• Air SDK : 50.2.3.7, 50.2.3.8
• Upload Tool : Transporter (1.2.5)

After updating the Air SDK and uploading the .ipa, I received the following email from Apple.

ITMS-90338: Non-public API usage - The app contains one or more corrupted binaries. Rebuild the app and resubmit.. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

Any help in resolving this problem would be appreciated.

Known Workarounds

Downgrade to Air SDK to 50.2.3.6

[ajwfrost]

Hi

Do they give a list of "private Apple APIs" there? it mentioned there may be a list above this?

FYI there was no update at all in any of the iOS code between 50.2.3.6 and 50.2.3.7/50.2.3.8 - the only differences would likely come from the fact that we switched over to using the LLVM linker rather than the Apple one. But it may also be related to how the applications are packaged with reference to the Apple SDKs ..

Can you please confirm:

• did you build on Windows or on macOS?
• if on macOS, did you use the "-platformsdk" option when building?

thanks

[everseen83]

Hi :)

• Do they give a list of "private Apple APIs" there? it mentioned there may be a list above this?
  : No. I think that's a little weird, too.

• Did you build on Windows or on macOS?
  : macOS (Sonoma 14.0)

• if on macOS, did you use the "-platformsdk" option when building?
  : Yes. We built and submitted iPhoneOS 16.4 and 17.0 versions, but issues occurred in both versions.

[ajwfrost]

Okay thanks, this could be a pain...

Would you be able to try something please? If you open up a terminal window and cd to the folder where you have your AIR SDK installed, then do:

cd lib/aot/bin/ld64
mv ld64 ld64_llvm
ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld-classic ld64

Then if you build your IPA file again, and submit it, I would be interested in the result...
(this just backs up our original linker to the 'ld64_llvm' name, and then creates a link from an 'ld64' file to the Apple linker that you should have from Xcode 15...)

And it would then also be ideal if you were able to send us both IPA files so that we can compare the outputs of the LLVM-based linker (that you'd used originally) and the 'classic' LD64 linker from Apple. Let me know if you need an upload link sent over..

thanks

[everseen83]

cd lib/aot/bin/ld64
mv ld64 ld64_llvm
ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld-classic ld64

(with 50.2.3.8 + Xcode15)

When I built using the above method, there were no issues on submission!

[ajwfrost]

That's kind of good to hear, but implies we have an issue with the LLVM linker that Apple are spotting..
Would it be okay to send us the IPA files (failing and working)?
Upload link is; https://transfer.harman.com/requests/kFLnAjTqIjR9EsGJEJgOBo

thanks

[everseen83]

Okay, I sent the file via your link.

[ajwfrost]

Thanks .. there's quite a few differences between those executables! In terms of symbols.. the ld64-based one has loads of extra symbols in there! And that's the one generated by Apple, so I'm a little surprised that the llvm-based one is being rejected.

The Apple message seemed to suggest there could be one of two things wrong:

1. Corrupted binaries (by which I would assume it means that the binary wouldn't actually run..?)
2. Private API usage (or some symbols being included that may make them think this is the case)

Presumably (1) is something that can be eliminated by just running the IPA manually, can I check that this does actually work for you?

Which may mean it's down to (2), although given the symbols that we can see there, I don't know what they may be finding that's "private" -> is there a way to ask them for more information on this?

We'll do a bit more digging here to see if we can minimize the differences in output between the linkers, but without knowing exactly what we're aiming for, it may be tricky!

thanks

[everseen83]

Presumably (1) is something that can be eliminated by just running the IPA manually, can I check that this does actually work for you?

: Sure. I installed IPA(failing version) directly from a USB connection to my device and had no problems running it.

Which may mean it's down to (2), although given the symbols that we can see there, I don't know what they may be finding that's "private" -> is there a way to ask them for more information on this?

: I'm not sure, but I'll give it a try.

[OneHalf3544c]

I have same problem Air SDK : 50.2.3.7
Build on Windows

[pipa-studios]

cd lib/aot/bin/ld64
mv ld64 ld64_llvm
ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld-classic ld64

(with 50.2.3.8 + Xcode15)

When I built using the above method, there were no issues on submission!

same here.. tks guys :)

[yvant]

Same issue with Air sdk 50.2.3.8 on Windows

[ajwfrost]

Okay so we'll have to switch ADT on macOS so that it tries using ld-classic as the preference. Something is obviously up with the output of these LLVM builds, we'll see if we can work that out in order to get Windows-built binaries to be acceptable to Apple...

[ajwfrost]

Some good news (finally!) -> Apple have updated their open source code which means we can start looking at building this for Windows....
https://github.com/apple-oss-distributions/ld64/tree/ld64-907

From experience, I don't think this is going to be a quick task, so we'll go with the short term fix to make the binaries build with ld-classic on macOS, and then get this released as soon as possible...

thanks

[idanasher]

Thanks a lot @ajwfrost

so just make sure I got it right: this issue (Non-public API usage) can't be solved now and we need to wait for the upcoming release ?

and compiling on a mac also has this issue ?

[ajwfrost]

@idanasher if you're distributing through the App Store, then yes it seems we have this problem - on our Windows build we don't really have a workaround, unless your binary doesn't need any Xcode 14 based frameworks, in which case we should be able to get things working with the earlier ld64 executable that Adobe created.

On macOS, we are switching back to using the Apple-deployed linker, so for 50.2.3.x you can apply the workaround in the SDK to link ld64 to the ld-classic binary from Xcode 15, see above (#2911 (comment))

50.2.4.1 is coming out shortly which automatically uses ld-classic on macOS. For a proper solution for Windows though, yes it's going to take a bit of time to get the Apple ld64 version working..

thanks

[idanasher]

Thanks Andrew.

on my mac, with AIR 50.2.3.8. have not implemented the above workaround yet,
and when trying to upload production version via transporter I get:

Should I perform the workaround or maybe it is another issue I have ?

I use all latest ane's from distriqt.
Transporter version 1.2.5
Xcode version 14.3
mac-mini Ventura 13.2.1

[ajwfrost]

Are you using the latest Animate for this by any chance? We've found an issue with their 2024 update which is screwing up the code signatures... can you check your adt.log file (or run the AIR SDK Manager with "Troubleshooting" tab..)

thanks

[idanasher]

Yes, im using Adobe Animate 2024.
Should I try install 2023 version ?

[ajwfrost]

Ah okay .. so the workaround hopefully is to open the Keychain Access app (not the passwords thing!), select the "login" keychain on the left and "My Certificates" tab, and then File -> "Import items..." - then browse for and import the certificate file that you used for signing within Animate (presumably a .p12 file). It should ask for your certificate's store password, but once that's done, it should appear in that list with a '>' character to indicate it's got the private key in the keychain store.

Basically - Animate 2024 switched to a later JRE which means our internal codesigning doesn't work, we then use the 'native' codesign app on the macOS machine, and despite you giving it a .p12 file, it needs to have the certificate present with the local keychain in order to sign it. Once you've done the import, you may then see a request for your login password so that Animate/ADT can access your keychain store to use this to sign the IPA.

Convoluted, sorry! We are looking at how we can work around this better...

[ajwfrost]

... and I've just checked this on Windows. Animate 2024 has broken the iOS signing there, for the same reason.
At least for this one, we get an understandable error message back:

[idanasher]

Hi @ajwfrost

on my mac, I have removed Animate 24 and installed Animate 23.0.
After that I did get the "right" error of "Non-public API usage" as expected.

then I followed and implemented your terminal commands:

and after that when im trying to compile I get this one:

[ajwfrost]

Hmm.. it's definitely "ell dee sixtyfour" rather than a one or an "i" character? Worth checking what you get from a terminal with that - and did you copy/paste in the path to ld-classic from the instructions, or did you find it on the local machine? It assumes you have Xcode 15 installed in a normal path..

Try from a terminal:

ls -la /Users/edanasher/Downloads/AIR_SDK/AIRSDK_50_2_3_8/lib/aot/bin/ld64/ld64

Or of course, update to 50.2.4.1 where this should be resolved...

thanks

[idanasher]

Answering your questions:

• I have copy from instructions.
• I have Xcode 14.3 (so maybe this is the reason that the paths are different)

I am now downloading 50.2.4.1 and I will try with it now. (and let you know)

Btw, How can I be notified when a new air version is released ?

Thanks

[ajwfrost]

Ah - so with Xcode 14.3 it's enough to link to "ld" rather than "ld-classic"
With 50.2.4.1 we look for "ld-classic" and if we don't find it, drop back to "ld"..
Short term, with 50.2.3.x, if you change your link command to remove the -classic bit near the end, it should then work.

How can I be notified when a new air version is released ?

If you go to https://github.com/airsdk/Adobe-Runtime-Support/discussions, there's a pinned post at the top left "AIR SDK Announcements", where we put a new message each time we release. But the simplest thing is to get hold of the AIR SDK Manager which will check for updates when it's opened...