...and they shall know me by my speling errors.

Danno Ferrin (aka shemnon) on stuff that matters to him.

Getting Your Java 8 App in the Mac App Store

Good news everyone!

Professor Farnsworth

You can now put your Java 8 applications onto the mac app store. How do I know? Because I put a little hackathon app I wrote on the Mac App Store. The better news is that Oracle is working on making this very simple with the JavaFX packager. You can get some of the early bits in the open source repo for OpenJFX here (building and using open source code is left as an exercise for the reader).

If you don’t want to wait for the code to get an official release and you are comfortable doing stuff by hand then here are the steps you will need to follow.

Prepare your Environment

First you will need to be signed up as part of the Mac Develoer program at [developer.apple.com]. For this tutorial I will presume your name is Alice Duke, that your Team ID is JJJJJJJJJJ and that the app you are shipping is titled AwesomeJavaApp. You will of course need to change these to real values.

Download your signing keys if you haven’t done so already (here’s how). You will need both the Mac App Distribution and Mac Installer Distribution, and they should automatically be placed in your keychain under the names 3rd Party Mac Developer Application: Alice Duke (JJJJJJJJJJ) and 3rd Party Mac Developer Installer: Alice Duke (JJJJJJJJJJ).

You will also need an entitlements file. Read all about them at the Mac Developer Library. You will have to turn on the app-sandbox entitlement as well as any of the other entitlements you will be using. Be sure to keep track of what entitlements you grand and why they are needed. Apple will be asking you to justify every one of them.

Prepare the Application

Next, create your Mac .app bundle the normal way you are doing with the javafxpackager, Ant, Maven, or Gradle build. Make sure this app works as it is what we will be bundling up.

Next, you will need to copy the info.plist from the existing JDK or JRE into the embedded JRE in your app. It should be either at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist or /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist, but it is likely to be the first one. Copy this file to AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Info.plist.

cp /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Info.plist

Now we need to strip a library. The Mac App Store doesn’t accept apps that even mention the deprecated Quicktime API, so we will need to remove the media capabilities tom JavaFX. If your app uses the JavaFX media apis you are out of luck for the time being. There is a bug to fix this in a future release.

The good news is that the Java 8 license lets us fix the problem, at least when it comes to JavaFX. Remove the file libjfxmedia.dylib.

rm AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Home/jre/lib/libjfxmedia.dylib

Sign the Application

Signing the app (in may different places) is next. Apple loves their cryptographic hashes.

First, you may need to make the JDK in the app bundle writeable. The codesign program won’t sign read-only binaries. chmod -R +w AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk should do the trick.

You need to sign all jars, dylibs, and executable files in the bundle (with one exception). Enumerating them is left as an exercise to the reader. Any decent build tool can do it for you. You will need to sign it with both the identity you have and the entitlements you want

codesign -f -s "3rd Party Mac Developer Application: Alice Duke" --entitlements <your_entitlements_file> <the_libary_jar_or_executable>

There is one caveat. Don’t sign the main excitable of the app bundle. It is in Contents/MacOS and has the name of your application, for example it would be AwesomeJavaApp.app/Contents/MacOS/AwesomeJavaApp. We will get that signed another way.

Another quirk is that you can give different entitlements to each file. In the javafxpackger we sign with an entitlements file that contains only the app-sandbox and inherit entitlements, so they inherit all the entitlements from the main application.

Next, you will want to sign the Java directory itself. Actually you need to sign all plugins and frameworks in your app, but the overwhelming majority of java apps will only have one plugin: Java.

codesign -f --deep -s "3rd Party Mac Developer Application: Alice Duke" --entitlements <your_entitlements_file> AwesomeJavaApp.app/PlugIns/jdk1.8.0.jdk

Finally, we can sign the application itself. Yes, we can actually shave the yak at this point.

codesign -f --deep -s "3rd Party Mac Developer Application: Alice Duke" --entitlements <your_entitlements_file> AwesomeJavaApp.app

You may or may not need all of the flags I’ve show with codesign, as I have not exhaustively tested them in all the possibly combinations. You may not need the --deep flag, but adding it will not get you out of signing all the interior jars and libraries. You may not need the -f flag but it insures that your signature will be the only one. Finally, you may want to add a --verbose=4 flag to see all the gory details. Or not.

Packaging for Install

I bet you thought you were done? Now we need to create an installer package to send to the app store. Use the productbuld too to generate the need file

productbuild --component AwesomeJavaApp.app /Applications -s "3rd Party Mac Developer Installer: Alice Duke" AwesomeJavaApp.pkg

Note that you are signing this with the second key you downloaded: the one for installers.

If you feel the need you can test the install:

sudo installer -store -pkg AwesomeJavaApp.pkg

Now you can load it into the Mac App store using the Application Loader tool. You will first need to go to iTunes Connect and set things up. But we have now left the Java specific part of the assembly so there are many other blog posts out there by more qualified and experienced Mac App Store developers.

Last Words

There are many other potholes that you could run into. Two I hit were not having a 512x512@2x icon, and another was a dispute about copyright on an icon. I changed the icon rather than wade through the appeals process to prove that the icon was in the public domain.

I plan on keeping this post up to date with any changes or corrections, so feel free to bookmark this page.