Thanks to @tonystech for the clear explanation of the problems and solutions to this issue. I want to add some further insight and suggestions to this process of packaging an AIR app for macOS. Overview To summarize, the suggested flow for packaging an AIR app for macOS is: 1. Package the AIR app using a temporary self-signed certificate. This will build the actual app bundle. 2. Enhance the app bundle so that it meets the base requirements for a first-class desktop application. 3. Code sign the completed app bundle. The app is now ready to run. 4. [Bonus] Create a presentable dmg or pkg if delivering to the Mac App Store. The app is now ready to distribute. Part 1 is necessary because it avoids the cryptic packaging errors AIR encounters when using non self-signed certs, and the app has to be code signed again manually later. Part 2 is necessary because AIR adt packager is not capable of producing an acceptable app. Parts 3 and 4 are necessary because of security and presentation to end-user. Steps Here are the steps I go through when crafting an AIR app for macOS. Step 1 - Build and package the application with adt using temporary certificate @tonystech covered this very well in his post above, apologies for the redundant information. Create a temporary self-signed certificate in p12 format using the adt binary included with the AIR sdk. The adt syntax is: adt -certificate -cn <name> ( -ou <org-unit> )? ( -o <org-name> )? ( -c <country> )? ( -validityPeriod <years> )? 2048-RSA <pfx-file> <password> Example usage: adt -certificate -cn SelfSign -ou Dev -o Dev -c US 2048-RSA temporaryCertificate.p12 temppass Run your standard compile and build process using the IDE of your choice, pointing to the temporary certificate created above. Step 2 - Replace icons AIR does not package high resolution application icons. These icons must be independently created, packaged, and placed in the application bundle. Documentation on high resolution icons is available from Apple in their High Resolution Guidelines for OS X document: Optimizing for High Resolution Once your complete high resolution icon set is crafted, use the tiffutil command to create a final Icons.icns file. Replace the icons that AIR created with this new high resolution file by replacing the file in your application bundle at Contents/Resources/Icon.icns. Step 3 - Remove DRM and Disallowed Libraries Delete the following files located in your app bundle in /Contents/Frameworks/Adobe AIR.framework/Resources: Adobe AIR.vch adobecp.plugin adobecp.vch AdobeCP15.plugin (reference: https://helpx.adobe.com/flash-player/kb/posting-air-app-mac-app.html) If distributing through Mac App Store, the plist in the Flash Player.plugin package must be deleted. path/to/bundle.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/Flash\ Player.plugin/Contents/Info.plist. Step 4 - Add Missing keys to Info.plist In bundle.app/Contents edit the Info.plist file to add any necessary keys. Typically you will want to add a CFBundleVersion key as AIR does not do this. You must also add an LSApplicationCategoryType key for distribution through the Mac App Store. Reference on LSApplicationCategoryType keys: https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/TP40009250-SW8 Step 5 - Set Permissions In Terminal, perform: chmod -R 777 bundle.app/ Reference: http://pigsels.com/2012/04/air-app-store-publishing-guide/ Step 5 - Create Entitlements plist should be created to set permissions and capabilities for your app. This is beyond the scope of this guide, see Apple's dev site for this. Sample entitlements file: <?xml version="1.0" encoding="utf-8"?> <plist version="1.0">     <dict>         <key>com.apple.security.app-sandbox</key>         <true/>         <key>com.apple.security.inherit</key>         <true/>         <key>com.apple.security.network.client</key>         <true/>         <key>com.apple.security.network.server</key>         <true/>     </dict> </plist> Step 6 - Code sign The specific Apple developer program derived certificate to use for code sign will depend upon delivery target. For distribution outside of the Apple App Store, a Developer ID Application type of certificate is needed. For distribution via the Mac App Store, a Mac App Distribution type of certificate is needed. Using the proper certificate is key! Using an improper certificate will appear to work, but the gatekeeper validation will fail. A good reference: https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html The exact common name string of the certificate to use will be listed in the proper certificate shown in the Keychain Access utility app. Developer ID certificates are named starting with "Developer ID." Mac App Distribution and Mac App Installer certificates are named starting with "3rd Party Mac Developer." See Table 14-2 from the above link for details. A deep code sign can be performed with a single command from the Terminal. Example of typical code sign: codesign -f --deep -s "Developer ID Application: YOUR COMPANY (X6UWRFHA)" /path/to/YourApp.app --entitlements pathToYour/entitlements.plist Step 7 - Verify code sign In Terminal: spctl -a -t exec -vv YourApp.app Verification must pass. If it does not, the app may be blocked from running on the end user machine. Step 8 - Create a release dmg [optional] Creation of this is beyond the scope of this outline. An excellent and comprehensive video tutorial on crafting a release dmg is available at http://computers.tutsplus.com/tutorials/how-to-create-a-retina-ready-dmg-based-app-installer--cms-21653 Step 9 - Mac App Store package creation [optional] For onboarding into the Mac App Store, you'll need to create a .pkg: productbuild --component /path/to/bundle.app /Applications --sign "3rd Party Mac Developer Installer: YOU COMPANY (X6UWKFTNN)" bundle.pkg You should now be done and ready to ship! ... View more

Thanks Colin, I appreciate it greatly. I don't have the iOS 10 SDK setup, but need to evaluate using AIR 22 for next iOS project. ... View more

The steps refer to a "textcodesign" command, which I can't find. If changed to codesign, it still fails because of unsigned or sign-mismatched embedded executables, such as Adobe AIR, Adobe AIR_64, Adobe AIR_64 Helper, ExtendedAppEntryTemplate64. Changing the bundle identifier to com.adobe.AIR1 results in the following submission error: ERROR ITMS-90334: "Bundle identifier mismatch. The executable at Adobe AIR in MyApp.app/Contents/Frameworks/Adobe AIR.framework has been signed with identifier 'com.adobe.AIR1' which does not match the bundle identifier 'com.adobe.AIR'." I've come up with my own approach as to which files to delete, which to sign, and when to use entitlements, but it's all guesswork. I've spent two entire days of work trying to get it right. ... View more

App thinning may be a bad practice for those who care about security. This post contains some fascinating insights and opinions about app thinning: https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitcode-f35cd8fbfcc5 ... View more

The issue as described is still a flaw in the latest AIR 21 beta. versionLabel flat out fails to work for desktop. Hand editing the plist file in the application bundle is the workaround to manually address this. There are so many things that need hand editing after publishing an application bundle anyhow (proper deep code sign, removal of unused DRM libraries, adding in high resolution application icons, adding proper entitlements for compliance with sandboxing requirements) that this isn't a big problem, just a confusing inconvenience. ... View more

I tried using the freshplanet KeyboardSize ANE from https://github.com/freshplanet/ANE-KeyboardSize but it was hard crashing the app when run on device when the getKeyboardHeight() method was called. I assume you're using the same ANE. If there is a different or updated ANE, please let me know. ... View more

The skin for the target TextInput instance is spark.skins.mobile.StageTextInputSkin. ... View more

The problem occurs in AIR 19.0.0.241, AIR 20.0.0.233, and AIR21.0.0.128 overlaid on Adobe Flex 4.6.0, on both iOS 9.2.1 and Android 6.0.1. These are the listener methods I've tried. Only one (marked) works: // This works, but can't capture key codes: _myTextInputInstance.addEventListener(TextOperationEvent.CHANGE, onTextInputChange); // These three attempts fail: _myTextInputInstance.addEventListener(KeyboardEvent.KEY_DOWN, onTextInputKeyDown); NativeApplication.nativeApplication.addEventListener(KeyboardEvent.KEY_DOWN,onNativeApplicationKeyDown); this.stage.addEventListener(KeyboardEvent.KEY_DOWN, onStageKeyDown); ... View more

Thank you Roshan for your detailed steps. I am no longer experiencing the problem after removing the certificate, then adding it back. I did not follow every step verbatim. For your information, here's what I did: 1. Completely remove the certificate using Keychain Access. 2. Added the certificate back to the keychain simply by opening Xcode > Preferences, then refreshing my account. The missing certificate gets added back to the keychain. 3. Examining the newly added certificate in Keychain Access > Access Control shows that the item is set to "Allow all applications to access this item" as it was before. I set this to the "Confirm before allowing access" setting. 4. I packaged the IPA using the previously exported external p12 certificate. Since the certificate has not changed, this should work. 5. During the packaging process, I did get a prompt to access the certificate in my keychain from codesign. I selected "Always Allow" 6. codesign --verify -vvvv payload/<YourAPP>.app reports valid on disk satisfies its Designated Requirement 7. Application Loader process allows ipa to evaluate, upload, and process, no errors! For the first time, I am able to get my AIR app packaged using AIR 20 and Xcode 7.2 & iOS 9.2. ... View more

This workaround is listed in the fixed issues section of the release notes, but I can't get it to work. I continue to get an invalid signature on the resultant ipa. In Keychain Access, I've set the Access Control to "Allow all applications to access this item" for all private key children of pertinent certificates. The certificates in question pass validation. I then perform another adt packaging. Performing a spctl check on the ipa reports "rejected source=no usable signature" ... View more

This is still occurring with AIR 20.0.0.233. ... View more

I highly recommend using IntelliJ IDEA for AIR development. It is faster and less buggy than Flash Builder, and has a broader feature set. It is in active development with frequent releases. There is a free trial version. You need to full/standard (non-community) edition to code with ActionScript. As hferreira pointed out, there are several alternatives. I agree it would be nice to have a new 64-bit Flash Builder not tied to an outdated Java install. Flash Builder went downhill when it stopped supporting Flex GUI design view. ... View more

Now that you've received your initiation scars, welcome to the club! Issue originally reported in thread Flex 4.6 AIR 19 iOS 9 ADT package fail: library not found for -ISystem.B I strongly recommend using Xcode 6.4 until Adobe fixes the problem with a new, robust AIR release. ... View more

The "fix" listed here feels like a real hack. I continue to get anomalous compiling errors using the iOS SDK included with Xcode 7.x. I've given up on this hack and wish I could revoke the "answered" status of this post. Workaround: I strongly recommend compiling against the SDK included with Xcode 6.4. It's obscured, but you can download older versions of Xcode from the Apple Developer site. Some links listed at ios - How to download Xcode 4 / 5 / 6 / 7 and get the DMG file? - Stack Overflow You can have two versions of Xcode installed at the same time, just segregate them by name or folder placement. You may also have to run the xcode-select command to mark which version is the active one you are targeting. Terminal psuedocommand: sudo xcode-select -switch /Applications/PathToTargetXcode.app Adobe AIR seems like it needs a lot of work to compile against the up-to-date iOS 9.1 SDK. We eagerly await a new version of AIR that is capable. ... View more

Thanks so much Roshan. Copying the file from Xcode 7 (current release version) to the Flex + AIR SDK and renaming it did the trick. I can now debug on device as well as package release builds. The resulting ld64 is 0.5 MB smaller than the AIR version and doesn't include the Adobe patch modifications, but it is working. Hopefully this will be addressed as an updated ld64 in a future update to AIR. ... View more

Xcode 7 has changed the enclosed library file format from .dylib to .tbd. This may be part of the issue. How do I link against .tbd files in Xcode 7? | Apple Developer Forums The old dylibs seem to still be around in /usr/lib, but I lack the savvy to know how to link to them with AIR. ... View more

Compiling with iOS SDK 8.4 also works. iOS SDK 9.0 remains problematic. ... View more

Workaround: Use an earlier iOS SDK, such as 8.1. I have a separate iOS 8.1 SDK folder that I saved out, and use as the SDK source for the compile. It gives no problems. This remains a serious open bug with the current release version of AIR 19.0.0.190 and the current beta version of AIR 19.0.0.193 for legacy compiler Flex projects targeting iOS 9 SDK. I haven't yet tested it against a pure ActionScript ASC 2 project, so the problem may be present there as well. I would like to get my AIR project compiled with the iOS 9 SDK as it is headed to the App Store in just a couple of weeks. The Simulator warning I posted above has gone away after a run of Xcode and a reboot. Possibly a vestigial issue with a fresh Xcode install. ... View more

This issue seems to be an old bug that has resurfaced, tied to the old Adobe Flex compiler, Java, and Xcode: Compilation failed while executing : ld64 For the record, I'm on OS X 10.10.5, with Java 1.8.0_25. Error occurs in both IntelliJ IDEA 15 and Flash Builder 4.7. ... View more