iOS Undefined symbols architecture with latest update

[marcanw]

Compiling from Animate (AIR 50.2.3.1) on Windows for iOS get this error since I updated GooglePlayServices:

[mrfrasier]

@ajwfrost sadly I can't scroll far enough up to see the first lines, but all the others are warnings. The final lines are as such:

[marchbold]

@marchbold Ok, so if I update the Firebase ANE, it will solve the issue, right?

Yes, update com.google.firebase.core

[ajwfrost]

@mrfrasier you can hopefully enable the ADT debug log - or simpler, just launch the AIR SDK Manager and go to the "troubleshooting" tab. Then if you re-run it, the log should appear in that pane, or in the c:\users\marcus\adt.log file..

[mrfrasier]

@ajwfrost thanks for that. Going step by step I've managed to isolate it to the Firebase ANE causing the trouble (somehow I can run the PushNotifications-FCM ANE without it), so this may be a @marchbold issue specific to the ANE.

In any case, here's the actual error that kills things:

ld64: error: undefined symbol: _APMUserDataFieldEmailAddress
>>> referenced by E:\\tmp\\0870d453-7e84-49fd-b942-93791733fa84\FirebaseAnalytics.framework\FirebaseAnalytics(FIRAnalytics.o):(symbol +[FIRAnalytics initiateOnDeviceConversionMeasurementWithEmailAddress:]+0x5c)
>>> referenced by E:\\tmp\\0870d453-7e84-49fd-b942-93791733fa84\FirebaseAnalytics.framework\FirebaseAnalytics(FIRAnalytics.o):(symbol +[FIRAnalytics initiateOnDeviceConversionMeasurementWithEmailAddress:]+0x58)

After that is a bunch of warnings as you saw before.

[marchbold]

@mrfrasier the com.distriqt.Firebase ANE is not a requirement for FCM in the com.distriqt.PushNotifications extension. We have kept these extensions independent so you don't need to purchase both.

Can you log this issue in the Firebase repo and we'll look into it.

[marcanw]

@marcanw @Michoko92 can you please try downloading the folder from the below link, this should replace the lib\aot\bin\ld64 folder in your AIR SDK. This contains a new build of the linker, using LLVM's rather than Apple's source - it's worked in our internal testing but it would be good to know if this also runs and builds/links for your apps..

https://transfer.harman.com/link/BxsZukLF5pKkU6XKAzcVO6

thanks

Hi @ajwfrost There is a new 50.2.3.7 release. Do we have to download the folder again for this new version?

[ajwfrost]

@marcanw yes, sorry, we did the 50.2.3.7 version just with Android updates, so if you're using it for iOS you'd need to update the linker again -> new download link is https://transfer.harman.com/link/Brh2YO2NAELPL99TZbgimo

We'll be pushing out 50.2.4.1 shortly that has these plus the other updates needed on iOS for the latest Xcode/SDKs..

[idanasher]

Trying to compile my app on mac for the first time using animate.

I am getting this Launch-Screen related issue:

[marchbold]

@idanasher Not sure that is related to this issue. Try opening a new discussion in the AIR forum: https://github.com/airsdk/Adobe-Runtime-Support/discussions/new/choose

[marcanw]

@marchbold & @ajwfrost Just to let you know I updated all my ANE's and the last AIR (50.2.3.8) and all my problems are gone. Thanks for the great job :-)

[idanasher]

@marchbold & @ajwfrost Just to let you know I updated all my ANE's and the last AIR (50.2.3.8) and all my problems are gone. Thanks for the great job :-)

on a mac \ pc ?

[marcanw]

PC

[idanasher]

Hearing the news, I am back on my pc trying to compile my ios app with 50.2.3.8.

first, Do I still need to include the 'Framework' folder on my app root like I have always did ?

second: i have successfully compiled the app (and then re-signed it on my mac with the resign script but when trying to upload the app via mac transporter I get those rejects:

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/

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBAEMKit.framework/FBAEMKit' contains bitcode.

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit' contains bitcode.

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBSDKCoreKit_Basics.framework/FBSDKCoreKit_Basics' contains bitcode.

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBSDKGamingServicesKit.framework/FBSDKGamingServicesKit' contains bitcode.

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBSDKLoginKit.framework/FBSDKLoginKit' contains bitcode.

ITMS-90482: Invalid Executable - The executable 'rummy_world.app/Frameworks/FBSDKShareKit.framework/FBSDKShareKit' contains bitcode.

[ajwfrost]

Hi @idanasher - it seems like there are (sometimes?) some problems with the LLVM linker outputting a format that Apple are rejecting. We've got a couple of binaries from someone else to do a side-by-side comparison, one linked using our LLVM-based linker from the latest AIR SDK, the other one using the 'classic' LD64 linker from Apple.

The bitcode thing is a new one though, and may also be a useful clue, so we'll see if we can at least eliminate that.

Just to check, when they talk about "the private Apple APIs listed above", did you see any APIs listed?

thanks

[marchbold]

@idanasher Have you updated the Facebook ANE? Looks like you may be using an older version that still contains bitcode.

Edit: Yes you still need to include the Frameworks folder to correctly package the required dynamic frameworks.

[idanasher]

@ajwfrost Regarding

Just to check, when they talk about "the private Apple APIs listed above", did you see any APIs listed?

No, i did not get any more information on this. and thank you for your response Andrew

@marchbold i have used Facebook ane version 16.01 and i am now getting the latest version16.0.101. Do you recommend any more specific ane's latest versions to update ?
Thanks a lot Michael

[ this is what i use now: Core.VERSION== 7.2.0 Starling.VERSION==2.5.1 NetworkInfo VERSION = 4.0.12 Application.VERSION==6.11.0 Facebook.instance.version==16.0.1 Branch.VERSION ===5.0.067 Adverts.VERSION== 14.0.3 InAppBilling.version ==14.4.1

]

[marchbold]

I suggest updating them all. Particularly InAppBilling and the Core ANE. Also 16.0.103 is the latest release of the Facebook ANE not 16.0.101

[idanasher]

i have replaced all ane's to the latest version and still getting the same 'ITMS-90482: Invalid Executable Contain bitcode ' issues

[marchbold]

@idanasher Did you update the frameworks?

[idanasher]

Nope I have not updated it in a long time

Where do I het it from ? Thanks a lot

On Thu, Nov 16, 2023, 12:12 Michael @.***> wrote:

@idanasher https://github.com/idanasher Did you update the frameworks?

— Reply to this email directly, view it on GitHub https://github.com/distriqt/ANE-GooglePlayServices/issues/28#issuecomment-1814147286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6PMHOUG4AMJWKMZJNF4UTYEXRJTAVCNFSM6AAAAAA2DB6ANOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGE2DOMRYGY . You are receiving this because you were mentioned.Message ID: @.***>

[yvant]

second: i have successfully compiled the app (and then re-signed it on my mac with the resign script but when trying to upload the app via mac transporter I get those rejects:

I also build my ipa on Windows and didn't hear about that resigning script. Where can I find it?

[marchbold]

@idanasher it's in the repo alongside the extensions. You must always update all associated assets and frameworks when updating an extension.

@yvant You shouldn't need the resign script anymore, AIR has corrected the issue that required this

[yvant]

Ok thanks for the info. I had a "Non-public API usage" error and I thought it could be related. I've seen a thread with a similar bug, I'll just follow that other one.

[ajwfrost]

@yvant yes for an issue with binaries being rejected by Apple for "Non-public API usage", please refer to: https://github.com/airsdk/Adobe-Runtime-Support/issues/2911

Essentially, we had switched to using the LLVM mach-o linker in order to support the new object file formats that are used by Xcode 14, but these are producing output that - while it runs fine - are for some reason unacceptable to Apple. So for the short term we'll need to switch back to using the Apple linker, which is fine on macOS (as it exists!) but on Windows the latest linker Apple have published is based on Xcode 13 so we'd end up with the same issues as found in the original problem report above.

Actually - breaking news - Apple have just updated their open source drops! https://github.com/apple-oss-distributions/ld64/tree/ld64-907

So we'll get working on that ....

[marcanw]

HI @ajwfrost Any idea about the timing on this Apple rejection? Did you think about asking a grace period to Apple? Does it necessarily occur on each IPA build with AIR 50.2.4.1 on Windows?

[marchbold]

@marcanw Is that related to this issue?

[ajwfrost]

Hmm.. define "this issue" ..! Originally this was about the objc_msgSend symbols not being worked out by the Adobe-build Apple linker. We've kind of resolved that by switching to the LLVM macho linker, but that then has this issue where Apple are rejecting the binaries that are then created.

The binaries appear to work.. I don't know whether anyone has tried to challenge Apple on this, given that their message says that the app uses some non-public APIs as listed below, but then fails to list anything. It's very possible their response would just be to suggest using their own linker rather than LLVM... so our expectation is that the best approach is to use the Apple linker itself.

There's then the problem that when we use the Apple linker from Xcode 15 (on mac) it doesn't work if you link against the 'stub' files we generate. So we're now using the linker from Xcode 14 (ld-classic) when compiling on a mac, and the LLVM macho linker when compiling on Windows. We end up with binaries that both run fine, but only the mac-built ones are accepted into the App Store.

I'm hoping that we can build the Apple linker for Windows (which would be the Xcode 14 one), and then I think we may also need to do away with the 'stubs' folder and have people use the iPhoneOS SDK directly, so that the correct set-up of symbols between different frameworks on different iOS versions works properly, and so that the macOS builds can then use the latest/Xcode 15 linker..

[marchbold]

Ah thanks for the update, wasn't aware there was a rejection occurring with the update, hence my confusion :)

[Mintonist]

Hm... I use AIR 50.2.4.1 on Windows and my apps have been approved some days ago.

[mrfrasier]

Hm... I use AIR 50.2.4.1 on Windows and my apps have been approved some days ago.

Are you sure your submission was built with 50.2.4.1? Numerous folks (myself included) have gotten rejections with that exact version. If so, it may end up coming down to what APIs (libraries) your app actually accesses, which is interesting.

[Mintonist]

Sorry I use AIR 50.2.3.8 but I check the same version of ld64 binaries (\lib\aot\bin\ld64) with AIR 50.2.4.1 May be ld64 is not a problem?

And I see this issue was commented while AIR 50.2.3.8 was the latest.

I don't want use AIR 50.2.4.1 because of IOS version restriction (11->12)

[mrfrasier]

@ajwfrost For the Windows LLVM issue, since there is no ETA, is there a simple method to export the project to Mac for building? We've been hoping to push a fix to a build last updated in October :/

[marcanw]

@ajwfrost or if you have a better view on the timing because I'm really stuck... Thx

[ajwfrost]

@mrfrasier we can work on something for that, it should be something we can work around... @marcanw do you have any mac that you could use for linking? anything that supports Xcode 14 would be fine..

I'm thinking that if you're using Windows as the primary development machine, we could have a set-up where you also have a mac that runs a bit like a Jenkins node, i.e. a client machine that is triggered to build the software by a "master" server. But with a very specific/limited case, to make it a little simpler..

thanks

[mrfrasier]

@ajwfrost sounds good. I don't have an active mac anymore (I mean, I guess I could dust off my old macbook), but I use a VirtualBox instance to submit apps to the store. Hopefully that should suffice

[marcanw]

HI @ajwfrost I tried building on Windows with the latest AIR version 50.2.4.3, and I was able to publish successfully. I'm not sure if this success is due to the latest AIR version, or if I was never affected by the "ITMS-90482: Invalid Executable" issue from the start. Do you have any idea? Thx

[ajwfrost]

Thanks @marcanw - when you say "publish", do you mean it's been accepted for the App Store? We appear to have two separate issues with the Windows linking:

1. when using symbols that are present across different frameworks dynamically, depending on the iOS version, it typically leads to a crash-on-startup when running on an older device
2. when publishing for the App Store, Apple seem to mark the binary as containing private APIs and block it as an invalid/corrupt executable

@mrfrasier I'm quite impressed you managed to get macOS running within a VirtualBox instance! does that have a reasonably recent version on it, e.g. with Xcode 14 or later?

thanks

[mrfrasier]

@ajwfrost I took a look and it seems my VM is running Catalina and xcode 11.3.1 -- though the app store says the latest is 15.2 but doesn't give the option to update.

It says there's a system update available, so I'll try that

[marcanw]

@ajwfrost I guess I wasn't concerned by 2. I was able to publish on App Store two times

[Mintonist]

when using symbols that are present across different frameworks dynamically, depending on the iOS version, it typically leads to a crash-on-startup when running on an older device

@ajwfrost where you discuss this problem and what status for this now? It is very important for my projects! Thanks!

[mrfrasier]

when using symbols that are present across different frameworks dynamically, depending on the iOS version, it typically leads to a crash-on-startup when running on an older device

@ajwfrost where you discuss this problem and what status for this now? It is very important for my projects! Thanks!

Pushing this back to the forefront. I haven't been able to publish to iOS < 16 since last year. I still have a lot of users asking me about this regularly. @ajwfrost do we have an update on that front? We got an updated SDK that should work, but then the issues with not being able to submit to the app store arose. What is the current method for getting our apps out there?