iOS Undefined symbols architecture with latest update #28
Comments
|
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. |
|
Which extensions are you using that is causing this error btw? |
I reverted back. |
|
|
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 would use the older versions of the androidx libs as well if you are trying to keep the same versions on android |
|
Hello @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) |
|
I just bought a Mac Mini 2023 for iOS build packaging, but an alternative option would be nice. |
|
Well, there's some more information about the cause of all this, from the LLVM project: 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!) |
|
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... |
|
@Ender22 I also found that the latest update of Firebase does not compile and previous crush app on launch on iOS 12.5.5. |
|
@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. |
|
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. |
|
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... |
|
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. |
|
Have tested it on XCode 13.4.1 and it seems to package fine, yay. Thanks guys |
|
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? |
|
@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 |
|
Yes, I'm using APM. Hmm okay, looking at my lock file has left me a bit confused. I use the following extensions:
From the lock file, it looks like com.google.firebase.core is used in: 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? |
|
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. |
|
@marchbold I have two questions:
Thank you for your response. |
|
|
Can someone please post here once the issue is solved and ANEs are ready for development on Windows. |
|
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. |
|
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. 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 |
|
Hi, 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/ |
|
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 |
|
Thank you @ajwfrost , this is excellent news! Keep up the amazing work, you and your team are really appreciated. 🙏 |
|
PC |
|
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:
|
|
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 |
|
@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 |
|
@ajwfrost Regarding
No, i did not get any more information on this. @marchbold [ this is what i use now: ] |
|
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 |
|
i have replaced all ane's to the latest version and still getting the same 'ITMS-90482: Invalid Executable Contain bitcode ' issues |
|
@idanasher Did you update the frameworks? |
|
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
<#28 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6PMHOUG4AMJWKMZJNF4UTYEXRJTAVCNFSM6AAAAAA2DB6ANOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGE2DOMRYGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I also build my ipa on Windows and didn't hear about that resigning script. Where can I find it? |
|
@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 |
|
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. |
|
@yvant yes for an issue with binaries being rejected by Apple for "Non-public API usage", please refer to: 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 .... |
|
HI @ajwfrost |
|
@marcanw Is that related to this issue? |
|
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.. |
|
Ah thanks for the update, wasn't aware there was a rejection occurring with the update, hence my confusion :) |
|
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. |
|
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 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) |
|
@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 :/ |
|
@ajwfrost or if you have a better view on the timing because I'm really stuck... |
|
@mrfrasier we can work on something for that, it should be something we can work around... 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 |
|
@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 |
|
HI @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:
@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 |
|
@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 |
|
@ajwfrost |
@ajwfrost where you discuss this problem and what status for this now? |
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? |
Compiling from Animate (AIR 50.2.3.1) on Windows for iOS get this error since I updated GooglePlayServices:
The text was updated successfully, but these errors were encountered: