Tutorial on publishing Flex/Air app for Mac App Store or just using Developer ID for general distribution

Hi. Has anyone succeeded in notarization using macOS 10.15 Catalina?

Doing the same, mojave succeeds but catalina fails.

When the app signature is confirmed with the spctl command, it is rejected.

spctl command displays "source=no usualble signature"

I just went through the process on Mac OSX 10.14.6, and the posts in this thread helped me a lot to get my app properly signed and notarized. The main obstacle that I did not resolve from these posts was correcting the symlinks in the app generated by adt. I had to manually go in and correct the linkages.

To help others who may be going through this, I detailed my whole experience from adt'ing through notarizing. This post is quite long, but it is kind of what I wish I could have seen in trying to fix my issues. I hope it is helpful to someone out there. If you have questions, ping me and I'll try to help (you'll see I'm no expert on bash scripts).

-jonathan

----------------------------------------------------------------------

My Steps for Building AIR app on Mac OS 10.14.6

I have been publishing my Flash/AIR app (called SimsUshare_v2) to Mac OSX since 2012. Recently, however, Apple required that the app not only be code signed, but also notarized, since in some upcoming release of Mac OS, they will require all apps to be notarized.

I basically followed the steps I found in other articles, but they didn’t quite get me there. Here are three central articles I used:

1. Notarizing the app, very useful: “How to notarize your software on macOS”
2. Codesigning and notarizing Mac AIR apps, specifically: “Tutorial on publishing Flex/Air app for Mac App Store or just using Developer ID for general distribution”, particularly the post marked “Correct Answer” by re-cycle. Of course the success is due to several people who helped him or her, but it’s easiest to identify the last person who put it all together.
3. Codesigning and notarizing in general: “How to codesign and notarise your app for macOS 10.14 and higher”

In this post I will detail all the steps I used to get my app successfully codesigned and notarized. I am not going to go into how I got the certificates from my developer account, that should be clear from other places. I went into the process with my private key (myCertificate.p12), my password, and the latest AIR 32 build (as of September, 2019).

Compiling the App

I use adt to build the captive runtime as follows:

../AdobeAIRSDK/AdobeAIRSDK-32/bin/adt -package -storetype pkcs12 -keystore myCertificate.p12 -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp -target bundle "SimsUshare_v2.app" SUSFreeWinMac-app.xml -C . SUSFreeWinMac.swf libs/ examples/ icons/ piccache/ assets/

I am prompted for my certificate password, which I entered. This builds the SimsUshare_v2.app in the same folder.

The Start of Codesign woes

The original codesign statement I used to use did not have the parameters that were needed now to codesign and notarize the app, namely stuff about the hardened runtime.

codesign -f -v --options runtime -s "Developer ID Application: Equipment Simulations LLC" --entitlements "$APP_DIR/entitlements.plist" "$APP_DIR/SimsUshare_v2.app"

You’ll see from this statement I also added an entitlements.plist file which was suggested by the #2 article above (re-cycle). I am including that file with this post so you can see it directly. I did not try the build after getting it working to see if I truly need the entitlements.plist file, though. BTW, the $APP_DIR is from my build (bash) script (below) and merely points to the folder in which I have the app.

When I tried to follow the steps in article #2 after making my build script, I kept getting this error from codesign

SimsUshare_v2.app: bundle format is ambiguous (could be app or framework)

In subcomponent: /Users/jonathankaye/Dropbox/SimsUshare Mac Stuff/SimsUshare 2.8.6/SimsUshare_v2.app/Contents/Frameworks/Adobe AIR.framework

After reviewing a lot of the posts in the article #2 from above, I saw I had to remove certain parts of the app (like WebKit) and codesign the pieces directly. I was trying to do it once with the codesign --deep parameter. However, Apple’s codesigning documentation (which actually was useful, albeit very long) said that it is best to sign each part individually rather than to rely on --deep. This documentation also clued me into the real culprit, because it mentions “symlinks” under the error for ambiguous bundle format.

The symlink mention reminded me I had seen this post and comment from Juergen saying to examine the symlinks and the application needs to be in a certain structure. Honestly I didn’t quote understand what that structure was from Juergen’s comment, but I was able to find this somewhere else based on Dass’ comment that made it clearer:

I used this example to clean up the SimsUshare_v2.app structure to have the correct symlinks, which I then put into my codesign script, below. FWIW, here is my diagram of the app (‘…’ is whatever is in there, -> are symlinks):

To make these changes, I added the fixes to my script for codesigning (I did hardcode the 2.8.6 into the APP_DIR variable which I will replace with VERSION at some later time, also I could make the script with a parameter for VERSION to make it more general).

You will see in the script that in addition to the symlink fixing, I also added some a command I had found to remove extended attributes (which Apple labels as “detritus”, if you don’t do that step), and I also put in checks to see that the app, once codesigned, passes two tests – one to verify the codesign, and the second to see if Gatekeeper will accept it. Of course I removed my passwords from the script, for posting. At the bottom of the script I put the complete output I received.

You’ll see I commented out a line (line 11) about copying icons, I did not have a problem with icons AFAIK but that copy statement was from a different article that had problems with AIR 31 and icons.

From the last few lines you can see my app was now properly codesigned and it passes Gatekeeper’s test. On to the notarization!

For this, I followed article #1 that I had listed at the top. That article was very clear, so here are my instructions that made it work:

1. I made a DMG using DropDMG, which is a great app, BTW, for making DMG’s really simply. Well worth the cost!
2. Now I had to upload the DMG to Apple’s servers:

xcrun altool --type osx --file SimsUshare_v2.dmg --primary-bundle-id com.simsushare.SUSMobileDesktop --notarize-app --username u@eqsim.com

1. Before doing this, I had to go through the Developer portal to create an app-specific password, which I was prompted for, and entered.
2. I received the following response after 5 minutes (of course I blanked out the actual UUID [the notarize ID] received):

No errors uploading 'SimsUshare_v2.dmg'.

RequestUUID = 1xxxxxxxx-xxxx-xxxxx-xxxx-xxxxx1f1

1. I put the notarize ID into the next command:

xcrun altool --notarization-info 1xxxxxxxx-xxxx-xxxxx-xxxx-xxxxx1f1 --username u@eqsim.com

1. After it asked for the app-specific password, I received (I removed my password below!)

No errors getting notarization info.

Date: 2019-09-25 13:43:51 +0000

       Hash: bd86076feaxxxxxxxxxxxxxxxxxxx5ac2bc631bc7

RequestUUID: 1xxxxxxxx-xxxx-xxxxx-xxxx-xxxxx1f1

     Status: in progress

To query the status (from https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow#3087720😞

xcrun altool --notarization-info 1xxxxxxxx-xxxx-xxxxx-xxxx-xxxxx1f1 -u u@eqsim.com -p <my password!> --output-format xml

1. I did check the status using the command it stated, but about 4-5 minutes later, I checked it and received the approval notice, like this:

1. Yay! Last step was to staple the output, or something:

xcrun stapler staple -v SimsUshare_v2.dmg

1. Which after a little bit came back with a long response that ended with

…

The staple and validate action worked!

1. As the article #1 I mentioned says: Congratulations ... your app has now been codesigned and notarized
2. After you installed the app (from the .dmg) you can double check if everything is working:

spctl -a -v </Path/to/your.app>

1. After your app has been successfully notarized, you will also receive a mail from Apple:

Dear Sir,

Your Mac software (bundle identifier ) has been notarized. You can now export this software and distribute it directly to users.

For details on exporting a notarized app, visit Xcode Help.

Best Regards,

Apple Developer Relations

Just in case anyone still has trouble with this for hosting your installer other than on the Mac App Store, here is my bash script that creates a .pkg installer for MacOS and it downloads without any warnings from any browser (tested with Safari, Chrome, Firefox and Brave), and it installs without warnings, and the installed app launches without warnings.

It also fixes the icons that as of AIR 31 are still wrong for MacOS, and it updates Info.plist with version. This app package contains 10 ANEs as well.

# !/bin/bash

VERSION=$1

USAGE="Usage: build.sh app_version_string (n.n.n)"

if [ "$VERSION" == "" ]; then

    echo "app_version_string is required"

    echo ${USAGE}

    exit 1

fi

INFO_PLIST="$APP_DIR/out/your-app.app/Contents/Info.plist"

cd $APP_DIR

# copy icons file over the one built by AIR which is still packaged incorrectly as of AIR SDK 31

cp -f ./packaging/Icon.icns ./out/your-app.app/Contents/Resources/Icon.icns

rm -f "./out/your-app.app/Contents/Frameworks/Adobe AIR.framework/Versions/1.0/Resources/WebKit.dylib"

rm -f "./out/your-app.app/Contents/Frameworks/Adobe AIR.framework/Versions/1.0/Resources/Adobe AIR.vch"

/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString ${VERSION}" "${INFO_PLIST}"

/usr/libexec/PlistBuddy -c "Set :CFBundleGetInfoString ${VERSION}, © 2018 Your Company, Inc. All rights reserved." "${INFO_PLIST}"

/usr/libexec/PlistBuddy -c "Add :LSApplicationCategoryType string public.app-category.business " "${INFO_PLIST}"

codesign -f -v -s "Developer ID Application: Your Company, Inc. (YOUR_TEAM_ID)" "./out/your-app.app/Contents/Frameworks/Adobe AIR.framework/Versions/1.0/Adobe AIR_64"

codesign -f -v -s "Developer ID Application: Your Company, Inc. (YOUR_TEAM_ID)" "./out/your-app.app/Contents/Frameworks/Adobe AIR.framework/Versions/1.0/Adobe AIR"

codesign -f -v -s "Developer ID Application: Your Company, Inc. (YOUR_TEAM_ID)" "./out/your-app.app/Contents/Frameworks/Adobe AIR.framework"

codesign -f -v -s "Developer ID Application: Your Company, Inc. (YOUR_TEAM_ID)" "./out/your-app.app"

productbuild --component ./out/your-app.app /Applications "./packaging/mac/your-app.pkg"  --sign "Developer ID Installer: Your Company, Inc. (YOUR_TEAM_ID)" --identifier "your-app" --version "${VERSION}"

I am trying to code sign my air for mac app (sdk 23/24) and have researched and found several threads, none of which appear to work. This is for general distribution, not for the Mac Store. I have tried the following:

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/Adobe\ AIR.vch

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/adobecp.plugin

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/adobecp.vch

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/AdobeCP15.plugin

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/WebKit.dylib

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/Flash\ Player.plugin

rm -rf APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/AdobeCP15.plugin

which all seems to work, followed by:

codesign -f -v -s “Developer ID Application: Developer" APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/Current/Adobe\ AIR_64\ Helper

codesign -f -v -s “Developer ID Application: Developer" APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/Current/Adobe\ AIR_64

codesign -f -v -s “Developer ID Application: Developer" APP.app/Contents/Frameworks/Adobe\ AIR.framework/Versions/Current/Adobe\ AIR

codesign -f -v -s “Developer ID Application: Developer" APP.app/Contents/MacOS/App

codesign -f -v -s “Developer ID Application: Developer" APP.app

which all seems to work, indicating each step is signed.

If I start the signed App.app directly (double click) it opens and runs no problems. However if I put it into a dmg, take the dmg and put it on a server, download back onto the same computer, mount the dmg and try to run App.app, it says it is damaged and should be put in the trash. I have done this several times.

On the signed App.app, when I run spctl -a App.app, I get: App.app: nested code is modified or invalid.

I have also tried the above without the initial rm commands, leaving the bundle intact prior to signing, and just using the 5 codesign commands - get the same results: nested code is modified or invalid. Note that I first compile the app using a self signed certificate, then apply the above to the resultant app.

Any help appreciated, I must be missing a step somewhere?

I am having some real annoying issues that I think is related to codesigning. The icon just bounces in the dock, then quits. This is what my os x system tells me.

10/13/15 1:34:29.815 PM CoreServicesUIAgent[18086]: Error -60005 creating authorization

10/13/15 1:34:35.885 PM lsd[441]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

10/13/15 1:35:08.718 PM com.apple.backupd[792]: Bulk setting Spotlight attributes failed.

10/13/15 1:36:26.211 PM lsd[441]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

10/13/15 1:36:26.240 PM CoreServicesUIAgent[18086]: Error -60005 creating authorization

10/13/15 1:36:37.946 PM CoreServicesUIAgent[18086]: Cannot load Interface Builder file '/System/Library/Frameworks/AppKit.framework/Resources/English.lproj/NSAlertPanel.nib'

10/13/15 1:36:37.946 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.oneshot.0x10000016.TrafikteoriLaerer[18110]) Service exited due to signal: Killed: 9

Has anyone experienced this or have an idea what this could be?

Hi, I found this post really helpful and have now finally got my app in the osx app store (Garden Planner ) as well as having a gatekeeper friendly version on my site.

I thought I'd share my steps in case it helps anyone.

first up I create the swf and then create the app on my mac with adt

the adt command looks like this AdobeAIRSDK/bin/adt -package -keystore mycert.p12 -storetype pkcs12 -target bundle gardenPlanner.app gardenPlanner-app.xml gardenPlanner.swf

then to create a version for download from my site that gatekeeper is happy with I just code sign the frameworks

codesign -f -s "Developer ID Application: your name (XXXXXXX64)" "gardenPlanner.app/Contents/Frameworks/Adobe AIR.framework"

then sign the app

codesign -f -s "Developer ID Application: your name (XXXXXXX64)" gardenPlanner.app

then product build

productbuild --component gardenPlanner.app /Applications --sign "Developer ID Installer: your name (XXXXXXX64)" gardenPlanner.pkg

and that seems to work. Note you dont have to change the icons or delete stuff from the framework - its probably good practice to at least put in higher res icons, but you dont have to and I wanted to show the minimal steps.

This is the best post on this issue I could find in the Adobe Forums, kudos DMcQ!

That being said, I concur with the other commenters. There are still way too many loose and outdated suggestions. Adobe sorely needs to step up and produce something comprehensive, something far better and more up-to-date than the Post Adobe AIR app to Mac app store page. AIR developers need two detailed documents with explicit environment/SDK version details:

1) Packaging an OS X Adobe AIR app for independent distribution

2) Packaging an OS X Adobe AIR app for Mac App Store distribution

I am struggling to properly codesign my OS X AIR app for independent distribution and have not yet succeeded in creating an app bundle that passes a clean circa OS X 10.9.5 v2 certificate Gatekeeper test: spctl -a -t exec -vv Foo.app.

This returns one of the following, depending one what approach I take:

- rejected

- nested code is modified or invalid

- a sealed resource is missing or invalid

Just some of the many questions and concerns I have regarding some provided suggestions in this manual re-packaging and codesign process:

- Doesn't removing contents of the bundle after it is built invalidate the included resources and jeopardize subsequent codesigning?

- Performing a brute force chmod -R 777 MyApp.app  seems to set the executable bit on enclosed items willy-nilly which seems counterproductive.

- What exact enclosed items need to be codesigned (directories, plugins, binaries), and in what order?

- What about non-App Store distributed applications that need to rely on WebKit?

- What about sandboxing entitlements?

- If entitlements need to be created, provide examples on typical AIR application entitlements and how to craft the file.

- Should the codesign --preserve-metadata option be used, and if so, with what parameters?

- Doesn't AIR 15 [latest beta] support the large icon sizes in the application descriptor and obviate the need to manually edit the icns file?

The official doc page on Mac App Store submission was updated just over two months ago given some recent changes needed in recent SDKs:

http://helpx.adobe.com/flash-player/kb/posting-air-app-mac-app.html

It should be current, though I think I see a typo in one of the commandline calls that mentions 'textcodesign' when it should just be 'codesign'