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:

[marchbold]

Looks like we need to get Harman to update the stubs packaged with the AIR SDK again. I'll look into it.

In the meantime either use macOS to package your app or revert to the previous version.

[marchbold]

Which extensions are you using that is causing this error btw?

[marcanw]

Looks like we need to get Harman to update the stubs packaged with the AIR SDK again. I'll look into it.

In the meantime either use macOS to package your app or revert to the previous version.

I reverted back. Can I update the other ane?

[marcanw]

Which extensions are you using that is causing this error btw? I would say Inapp-Billing, according to the errors in the screen of the original post.

[marchbold]

I believe that is actually the core google firebase dependency in the error, so likely one of the extensions that depend on that.

The others you listed should be okay to update for ios, as long as you aren't using the FCM variant of push notifications.

[marcanw]

I believe that is actually the core google firebase dependency in the error, so likely one of the extensions that depend on that.

The others you listed should be okay to update for ios, as long as you aren't using the FCM variant of push notifications.

I use the FCM version. So I better avoid to update till there is a solution. I ,just updated AndroidSupport. Is it fine?

[marchbold]

I would use the older versions of the androidx libs as well if you are trying to keep the same versions on android

[marcanw]

Hello @marchbold Do you know when I will have a solution for this?

[marchbold]

Hi, I have been discussing potential solutions for this with the Harman team. The main issue is that the Apple opensource compiler for iOS apps that AIR uses hasn't been updated by Apple in a while and has fallen behind the features available in Xcode. So AIR is facing an issue with packaging iOS apps on Windows that use recent features in iOS or libraries that have been packaged with the latest build tools.

As there seems to be developers who don't want to or can't use macOS, I was wondering what you all would think of a hosted packaging solution for developers on Windows where a host provided by Harman would package your application for iOS and provide the ipa as an alternative. There would obviously be a cost involved (potentially part of the AIR license), but this would allow you to continue developing iOS applications on Windows.

Would love to hear your thoughts on this idea?

(Note this doesn't affect developers using macOS for iOS development)

[sjabberwocky]

I just bought a Mac Mini 2023 for iOS build packaging, but an alternative option would be nice.

[ajwfrost]

Well, there's some more information about the cause of all this, from the LLVM project: https://github.com/llvm/llvm-project/issues/56034

I'd just looked at the symbols exported by a framework with/without this flag, and there are zero differences other than those symbols being there! But of course, within the executable code, these symbols will be called in order to call each of the selectors...

So, it may feasibly be possible to build the "latest" Apple linker on Windows, and merge in the changes that LLVM have made, and then have this support these newly built libraries. But building the Apple linker on Windows was proving to be very complex already..

The alternative option -> providing a service whereby ADT would upload the object files to an online service, backed by a macOS computer that just does the linking -> might actually be simpler! but perhaps not quicker. And scalability may be an issue (and service availability, given how often our macs reboot themselves!)

[Ender22]

I'm a bit confused because I am packaging on mac with intelliJ but the latest com.google.firebase.core.ane ANE version is also giving me the same errors.

Does the latest require an update to XCode or something? I'm using a bit of an older xcode...

[sjabberwocky]

@Ender22 I also found that the latest update of Firebase does not compile and previous crush app on launch on iOS 12.5.5.

[marchbold]

@Ender22 Yes you need to update the compiler on macOS, easiest done by updating Xcode.

@sjabberwocky I'll follow up on the crash in the Firebase repo.

[Ender22]

Is it possible to update the compiler without updating xcode? I had a lot of trouble packaging on mac before, and right now it's in a 'if it isn't broke don't fix it' state.

I've downloaded xcode13 but can't install it without updating MacOS first. Could I like, just replace the path to the compiler to the new xcode13 one maybe?

If it doesn't work like that and would be a big hassle then I'll just bite the bullet and update the OS and xcode, but thought I'd ask first.

[ajwfrost]

We've tried things like that before (there's a Developer/Toolchains folder in Xcode, iirc) and it worked to a certain extent but there may then be other issues you find with the compiler features, expected header files, and all sorts... it can get messy. So it could be worth trying, but there may be challenges... Apple tend to expect everyone updates all the time to the latest of everything...

[Ender22]

Understood, @marchbold what is the lowest xcode version that works with this ane? Apparently, my Mac is too old to install Ventura, so the best I can do is Monterey which only supports XCode 13.4 it seems. Also curious if I don't update this one ANE, which other ANE's are expected to fail because of it? I'm using a bunch of ANE's and not quite sure which one is dependant on firebase.

[Ender22]

Have tested it on XCode 13.4.1 and it seems to package fine, yay. Thanks guys

[Ender22]

Wait crap no. It doesn't compile on XCode 13.4.1, I tested the wrong ane version. So I'll need to buy a new Mac for this. Can I go back to the question of what other ANE's are expected to fail if I use the older com.google.firebase.core? Maybe it affects some functionality I don't actually use?

[marchbold]

@Ender22 The hidden costs of Apple development hey...

I would suggest if you are trying to maintain an older version that you use APM to install versions prior to this latest update. Don't just install a lower version of com.google.firebase.core but pull a version of all the extensions at a specific release. If you were using apm your lock file would have contained the details and you could just revert your version control to that version? Otherwise you can try just downloading the version from the github repositories

[Ender22]

Yes, I'm using APM.

Hmm okay, looking at my lock file has left me a bit confused. I use the following extensions:

• Application
• Application Rater
• Camera Roll Extended
• CameraUI
• Dialog
• Flurry
• Media Player
• Native WebView
• Network Info
• Notifications
• PDF Reader
• Push Notifications
• Scanner
• Share

From the lock file, it looks like com.google.firebase.core is used in: com.distriqt.playservices.CloudMessaging com.google.android.datatransport and those are part of google play services right?... and I don't really understand from my list of extensions which is using google play services, we don't try to do anything directly with that.

Additionally, since google play services aren't used on iOS, I guess nothing will stop working? I've done some tests today and all ANE's seem functional with the older firebase core.

Sorry, I'm a bit lost. Do you know offhand which one of my extensions is causing the firebase.core requirement, so I could roll back just that specific extension?

[marchbold]

Okay, so looks as though you could probably remove this extension for the ios build. It is required for Firebase services which is likely getting included as you are using Push Notifications which uses FCM on Android. We are working on getting platform dependant builds working with apm but it's only partially implemented so far.

Currently you could try either manually removing it, or setting up an alternative apm project config for ios and installing the APNS variant of the push notifications extension.

[marcanw]

@marchbold Due to this issue, I'm stuck with older ANEs.

I have two questions:

1. Are the latest versions of the ANEs required for Android 33?
2. As I understand it, the problem arises when building iOS on Windows, but this concerns an ANE that is only required for Android (referring to your last post). Perhaps I'm overlooking something. Could you clarify?

Thank you for your response.

[marchbold]

@marcanw

1. I believe the previous version of the majority of our extensions supported API 33. This latest update is to support the latest Google services (Firebase/Analytics/FCM etc) which included several bug fixes from Google.
2. com.google.firebase.core is required by iOS apps supporting Firebase services so not an Android only extension.

[idzdigital]

Can someone please post here once the issue is solved and ANEs are ready for development on Windows. Thanks

[Michoko92]

Michael pointed me to this thread, and the discussion about possibly dropping the iOS support on Windows. Honestly, this AIR feature is probably the most precious and unique to me, compared to other SDKs. Every time I check new SDKs or engines, the first thing I look for is how to build for iOS target. Until now, all the alternatives I saw can only build on an Apple machine. As an experienced Windows user, being able to build all platforms on my dev machine is a comfort only AIR offers, and it is invaluable.

I'm sure that, knowing Apple, maintaining iOS support must be a very challenging task. But honestly, this is something that could definitely be one of the strongest selling points for AIR once marketing is done more actively. Please tell me there is still hope.

PS: I suppose that having a remote building service would be OKish, and it would be better than nothing. But I think that if AIR drops Windows iOS building in a future version, I'll stop updating as long as I can.

[ajwfrost]

Hi

Thanks @Michoko92 for the input. The support for iOS on Windows is a tricky one, but we think we may have a route forwards for it. To link in another thread: the below is our tracking one for the 'undefined symbols' problem when building on Windows. https://github.com/airsdk/Adobe-Runtime-Support/issues/2299

We're investigating still - particularly the updates that may be coming along with Xcode 15 - but I would say that there is now some hope! We do now have some updated ld64 code from Apple which we hope supports the msgsend selector stubs, so will be looking into this now.

thanks

[MatseFR]

Hi, Michael pointed me to this thread as well. I do have an old mac mini, I updated it and it's now running Monterey and XCode 14.2

I'm not a mac user at all but after hours of hairpulling I finally managed to run ADT with the latest AIR SDK... only to get the same "Undefined symbols for architecture arm64" error, which is quite disappointing to be honest.

Do I need a mac that can run XCode 15 ?

Here is the command I used, do I miss something in there ?

adt -package -target ipa-app-store -provisioning-profile appstore.mobileprovision -storetype pkcs12 -keystore ios_dist.p12 -storepass xxxxx app.ipa application.xml -C icons/ios/ . -C bin . -extdir ane -platformsdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.2.sdk/

[ajwfrost]

Hi

Definitely don't update to Xcode 15.. the fact you're getting this on a mac is odd though .. possibly you could remove the "platformsdk" argument in case that's confusing things?

Is your mac mini an Intel one? And are the missing symbols all ones that have "objc_msgsend" in the name?

thanks

[Michoko92]

Thank you @ajwfrost , this is excellent news! Keep up the amazing work, you and your team are really appreciated. 🙏