Java and Mac OS X

Trying to deploy my JavaFX application on Mac has been incredibly frustrating. But this is no accident. In fact, it is a direct result of Apple’s software philosophy. Specifically, Apple wants a couple of things: 1) to have 100% iron-fisted control of the whole Apple-branded technology stack and 2) to shift 100% of the pain of software problems from users to developers. You can’t argue that their philosophy has been successful in some sense—just check their stock price.

On the other hand, they have chosen to make life much more difficult for developers than necessary—especially Java developers. I’ll give a few concrete examples.

One of the most egregious examples of Apple’s software philosophy is how their products handle errors. The general idea seems to be to hide any remotely scary-sounding error message from the user. Back in the day, Windows was infamous for its “blue screen of death” (BSoD), an iconic example of the frightening error message. Now you tend to get more friendly, but still tech-arcane error messages on Windows. At least the user (or a developer) can do a quick web search for an error message and usually find the cause and/or solution. By contrast, Mac OS X tries to either hide the error and pretend like nothing happened (even if it means, your application appears to hang for no reason), or worse, give an outright lie as the message. For example, an application that is “improperly” digitally signed may generate a message saying that the application file is corrupted, and the user should try downloading it again. Heaven forbid we mention anything that might disturb the user like an untrusted cryptographic signature.

Signing an application with a well-known, trusted authority using a standard process is not enough for a Mac application. Instead, with the new Gatekeeper features, you need to sign your application using Apple’s process and Apple’s certificate, which they will happily sell you for $99 (no concern for the small-time developer who might not want to shell out $99 for a hobby project). If your application doesn’t jump through all of Apple’s hoops, the user might get anything from silent failure to an indication of a corrupted file.

Oracle is not blameless either. They should have made it a priority a long time ago to streamline deployment of rich client applications on any supported platform. The Java Web Start user experience is a travesty. Due to security issues, vendors like Apple and Mozilla have gone out of their way to make it difficult to run any Java applications. The result is a terrible user experience for launching Java-based applications, especially on Mac OS X. Worse yet, recent “bug fix” updates to Java 7 actually break some Web Start applications in the name of security.

But all is not lost. Enter JWrapper, a free and awesome solution for deploying Java apps as native applications on Windows, Mac, and Linux. Like other commercial solutions, JWrapper builds native installers that work regardless of any JRE being present. Unlike other solutions, JWrapper doesn’t cost thousands of dollars… in fact, the basic version (with a JWrapper logo) is free, and the paid license is only a few hundred dollars. Rock on!

I still had some trouble working out a few deployment kinks. In particular, I had to include a magical JVM option “-Djavafx.macosx.embedded=true” to get JavaFX to run properly and consistently in a Java 7 + Mac environment. But the build process is relatively simple, and now my application runs on a Mac with a good installation user experience. You plug in the code certificate files and it signs your application both in the standard process and the Mac signature process. I highly recommend JWrapper for developers of Java GUI applications.

This entry was posted in Uncategorized.
Bookmark the permalink.