Is Gatekeeper the writing on the wall?

I just updated one of my Macs to Mountain Lion so that I have a test machine for my software. As expected none of my software worked out of the box. When I tried opening PDF OCR X, it came up with a message saying that the application was damaged and should be dragged to the trash.

It turned out that the problem was that I hadn’t signed the application with my Apple Developer Key, and Mountain Lion is set up by default to disallow applications from running if they aren’t signed by a valid developer key (that you can only get with a paid membership to the Mac Developer program). There are workarounds (described in this support article), but this still happened to be a road block for a lot of people.

Luckily I have a Mac Developer membership and a key. It only took me an afternoon to sit down and figure out how to sign all of my code and upload an updated version. However this looks like it may be writing on the wall. In the security settings pertaining to this “Gatekeeper” feature, there are 3 options:

  1. Allow Only Applications downloaded from the Mac App Store
  2. Allow Only applications by identified developers (i.e. they pay to be in the developer program)
  3. Allow all programs

The default is #2 (allow only identified programs). If you try to select #3 it pops up with a warning message to discourage you from this choosing this option.

So probably most people will continue to operate with setting #2. Is this just the beginning though? Can we look forward to future releases of OS X having a default of #1 – or worse, not having an option at all? My experience with developing Mac software has been one of keeping up with the moving goal posts.

When I first started developing Mac Apps all you had to do was put your app on the Apple download site (it was free) and people would find you. Then apple came out with the App store and placed many restrictions on the applications – and of course took their 30% cut. I chose not to add my applications to the App store because of the large cut that apple took – and because it would have been a significant amount of work to make them comply with the app store guide lines (I use Java). When Java finally reached the point where it could be bundled into an app (and thus be accepted into the App store), I contemplated adding my application. but alas my choice was taken away as the goal posts moved again: Sandboxing.

Now applications must comply with Apple’s new sandboxing model which basically locks applications inside a sealed box. It cannot interact with the rest of the file system. Since my application is a utility that is meant to allow users to batch convert large numbers of files, it simply cannot be done using the Sandbox model.

Users should be concerned too. If they have purchased an application from the App store and then accidentally click “Update” to update to the latest version, they may have features taken away, never to be returned. This happened on my iPad when I accidentally updated my Kindle App. The old version contained a button to “buy books” that took me directly to the kindle store. However, apple since placed a regulation saying that Kindle couldn’t link to their website directly from the app (because Apple wanted a piece of all sales), so the link had to disappear.

In order to markets to function, consumers must have confidence in the market. Apple has proven time and time again that it will move the goal posts as far as it can get away with – so there can be no confidence that purchases I make today from a 3rd party developer in the Mac App store will not be taken away from me at a later date.

I, personally, will not be purchasing any software from the Mac App Store for this reason. I will purchase directly from the vendor if that is possible. If it is not possible, I will find an alternative. (Of course there are some things for which there is no alternative – e.g. Apple Software).

JavaFX Has Finally Arrived

JavaFX 2.1/2.2 finally gives me the tools that I need to build the applications that I want to build. This release provides 2 missing pieces that make all the difference:

  1. Scene Builder – Finally a good graphical GUI tool for Java. This makes building GUIs almost as easy as Apple’s Interface Builder.
  2. JavaFXPackager Native Bundles – Now you can instantly build native application bundles for Mac, Windows, and Linux.

The only question is whether these features are too late to the party to make a difference. Sun dropped the ball with desktop Java a long time ago. It survived the past 10 years almost entirely on the backs of JavaEE (i.e. web/server programming) and, more recently, Android. Desktop application developers have been fending for themselves for the most part.

Now we have the tools that we need to make some serious applications. The upcoming release of JDK 1.7 will also finally enable Java developers to get their applications into the Mac App store. Currently the bundle size for an application is quite large (over 50 megs for my hello world application test), because it needs to contain the entire Java Runtime Environment, but this should improve over time as we get better at compressing and splicing the JRE to suite specific purposes).

I downloaded Netbeans 7.2, JavaFX Scene Builder, and JavaFX 2.1 (included with JDK 1.7.0u6) to try to build a simple web browser application. This proved to be super easy, and it gives me a lot of faith in the power of technologies such as FXML (an XML format for representing user interfaces). Some key points that impressed me during my short test:

  1. Netbeans now has an option to create a Swing-wrapped JavaFX project. This was previously a real pain, since JavaFX has lots of cool toys, but wouldn’t give you a full desktop experience. E.g. You still needed swing to get menus at the top of the screen for Mac. Swing still does a lot of things well, so if you wanted to use JavaFX, you would generally need to rig up the Swing FX Panel yourself. Having this as a default option for a project is nice. No more messing around.

  2. Using a controller for the FXML file makes it very easy to achieve full separation of the view and logic. The @FXML annotation also makes it incredibly easy to reference elements of the FXML UI from the controller. Attaching events for controls was quite simple.

In order to truly be successful, JavaFX still needs to get a mobile presence. It currently doesn’t run on Android or iPhone (despite demonstrations to the contrary at previous JavaOne conferences). If they can somehow port it to these platforms, I think it will really take off.