[has a workaround] ANE packaging with library (.a file) compiled with Xcode 14 is failing

[heitara]

I'm bundling an ANE file which is using a library (OBJ-C native code). Everything was working fine while I was compining the native code with xcode 13+. Once I've updated to Xcode 14 the packaging is failing for me.

The error that I'm seeing is:

Error: Apple App Store allows only universal applications. "lib.....a" is not a universal binary. Please change build settings in Xcode project to "Standard Architecture" to create universal library/framework.

AIR SDK - 33.1.1.929 The problem affects packaging with following arguments:

/Development/flex/flex4.6AIR33.1.1.929/bin/adt -package -storetype pkcs12 -keystore /Development/flex/certificates/anes_cert.p12 -storepass ****** -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp -target ane ANE.ane ../build/extension.xml -swc swc/ANE.swc -platform Android-ARM -platformoptions ../build/android_platform_options.xml -C android/ . -platform Android-ARM64 -platformoptions ../build/android_platform_options64.xml -C android64/ . -platform iPhone-ARM -platformoptions ../build/ios_platform_options.xml -C ios/ . -platform default -C default/ .

I can provide the binary(lib.a) that causes the problem.

Steps to Reproduce

Start from arbitrary ANE that has iOS code. Try to package it if the native code is compiled using xcode 14.

Known Workarounds

Downgrade to Xcode 13. binaries.zip The attached .zip file contains the binary that works and the one that doesn't.

[marchbold]

I think Xcode 14 has increased the minimum ios version to 11. Have you set the sdkversion in your platform xml to be 11?

[mayainle]

I had the same issue. I changed the minimum ios version to 11 in my platform xml and it worked.

[ajwfrost]

When you say "minimum ios version", I don't think that's what ADT is looking at. That may be required for the linker options but to get ADT to allow a non-universal binary, it would need to have a line in the platform xml options such as:

<sdkVersion>11.0.0</sdkVersion> 

[mayainle]

Yes @ajwfrost that worked for me. I had on my Mac version xcode 14 running and there everything worked fine after the change of the skdVersion in platform xml, on the other Mac there was still xcode 13 and it failed with the same exception but after I updated that one to xcode 14 too everything is fine. So I would say this can be closed.

[ajwfrost]

Thanks @mayainle

@heitara are you okay with this now, with that sdkVersion definition?

I'm wondering whether we should follow Apple in completely dropping support for the pre-11 iOS versions, and the 32-bit binaries.. which we'll likely have to do anyway given that we may need to switch to xcode 14 too soon. Then we can take this condition out of ADT which will avoid a bit of confusion...

[marchbold]

We are starting to experience libs that will need Xcode 14 and have held back some updates to extensions, so we would encourage an update soon. While we have been running a minimum iOS 12 for a while now I think this will likely affect a good number of developers, so we should have some strategy in place for people to support older devices/ios versions.

Perhaps an LTS version of the AIR SDK prior to this change?

[ajwfrost]

Yes good idea.. I'm thinking that the 50.0 version may be superseded fairly quickly as there are other API and namespace changes we want to make soon, so we could have that as our last one that still supports iOS 9 built with the older toolchain/SDK and then move to iOS 11 + Xcode 14 for AIR 50.1 and beyond.. and we could still update 50.0.x.x as/when needed with bug fixes.

[heitara]

I've set it to version to 12 <sdkVersion>12.0.0</sdkVersion> Here is the full ios_platform_options.xml:

<platform xmlns="http://ns.adobe.com/air/extension/19.0" >
    <copyright>Lancelotmobile Ltd. 2022 (o)</copyright>
    <sdkVersion>12.0.0</sdkVersion>
    <linkerOptions>
	<option>-ios_version_min 12.0</option>
	<option>-w</option>
        <option>-framework AVFoundation</option>
        <option>-framework AudioToolbox</option>
        <option>-framework MediaPlayer</option>
        <option>-framework CoreMedia</option>
        <option>-framework CoreGraphics</option>
        <option>-framework AssetsLibrary</option>
        <option>-framework QuartzCore</option>
        <option>-framework ImageIO</option>
        <option>-framework CoreImage</option>
        <option>-framework Photos</option>
        <option>-framework PhotosUI</option>
        <option>-framework MobileCoreServices</option>
        <option>-framework AssetsLibrary</option>
        <option>-framework QuartzCore</option>
        <option>-framework MessageUI</option>
        <option>-framework MapKit</option>
        <option>-framework Foundation</option>
        <option>-framework StoreKit</option>
        <option>-framework AVKit</option>
    </linkerOptions>
</platform>

I still get the same error. My Xcode version is Version 14.0.1 (14A400). I'm using AIR - 33.1.1.929

[ajwfrost]

Okay thanks @heitara - there's some very weird code in here, looking at it in more detail. It's taking the sdkVersion string and then converting it to a number with some weird - and wrong - logic, which means that you would need to have 12.0 rather than 12.0.0. Anything with three numeric segments is ignored (!) and actually anything with two digits might also be handled wrongly... so 12.0 is what you should put, but perhaps try 1.11 and it may still work... (!!)

Anyway -> we'll update it so it works properly with one, two or three (or four) number-segments, but for now hopefully it works if you just use 11.0 or later..

thanks

[heitara]

Wow! 12.0 works!

I won't close the issue until we have a proper fix. But this workaround is a good thing!

[ajwfrost]

Great, thanks for confirming, we'll get this actual code updated/fixed and put into a release. cheers

[marchbold]

iOS versions are traditionally only 2 digits so 12.0 makes sense, 12.0.0 would be invalid.

[heitara]

I believe they try to follow that, but I'm not quite sure if it is valid for all previous versions and whether it would be for all future versions. Better to make the tool smart.

[marchbold]

Yeah iOS is versioned with 3 but the SDK has always been 2 as far as I'm aware.

[marchbold]

Definitely agree to make it smart, but just pointing out this is the convention apple has followed

[heitara]

This is what I see in Xcode. @marchbold I think you are right about their convention.

If we can throw an error when validating the XML this should work as well. Once there is this issue in github, I believe anyone who faces it will find the solution easier. Should I close it or you will do it, once there is anything implemented?

[ajwfrost]

FYI we've already changed the code in ADT that looks at this sdkVersion value. TBH it's only trying to work out if it's 11.x or higher, so currently we don't care about how many sections it may have! so the method is a bit simpler now (and more correct). We'll close this issue once we've released that in the next 50.0.x.x version..