Review: AppWrapper

Ever since Apple opened the Mac App Store (MAS), Real Studio developers have been wanting tools to help them get their apps ready for it. The first step was CodeSigning your application but more recently the MAS requires new applications be sandboxed.

Sandboxing is Apple’s new security requirements that is really good for end users since it promises to keep malicious code from compromising your application and thus your computer and they do this by cutting off access to most parts of the operating system, including the Open and Save dialogs!

That makes most applications quite useless so the developer has to tell the operating system exactly what sorts of access it’s going to do. This includes Open and Save Dialogs, but also includes access to many of the standard folders like Downloads, Pictures, Music, Movies, etc. and even whether or not your application will be using iCloud services and even hardware like the printer or a USB or Bluetooth device. Since you’ve told the operating system what you’re going to be doing, the operating system can then grant your application Temporary Entitlements.

You could do all these settings yourself if you had a strong knowledge of command line programming and, in fact, we did Code Signing from an IDE script for a while. But as things became more complicated with the MAS our script wasn’t good enough any more. So we needed a new solution.

Thankfully a number of third party utilities have arrived to help make your life easier when dealing with the Mac App Store.

In part one, we’ll be reviewing AppWrapper from Ohanaware and in part two, we’ll review RB Package Maker Studio from blueColin Software.

AppWrapper is a simple drag and drop utility that has a number of options that you might find very useful. You start by compiling your application in Real Studio like you normally would. Then you drag the application on to the utility where upon you’ll be presented with a whole host of options that you may, or may not need, for your application.

You start with the basic Property List tab where you set the Mac App Store Category for your application. You set the copyright info, the application version and give it a high resolution icon file. The icon Real Studio creates (at least in Real Studio 2011 R4.3) is too small for use with the MAS so you have to overwrite the Real Studio icon with a higher resolution.

In one of the more interesting options in AppWrapper is that you can use a pre made About Window, with credits in your application. This requires that you add some code to your application and recompile. The About Window is something that people spend little time on so this might be a good, quick, solution for you. However, if you are creating cross-platform applications this will be of little use to you.

If you have a Help files, you can attempt to make them Apple compatible and have them indexed before putting them into the bundle of your application.

Document handling can be kind of a pain with the UTI’s. AppWrapper does a nice job of scanning the application giving you a number of options to properly create your UTI’s.

The Resources tab lets you choose which resource items you want included in your application. I’m a little confused on why you would want this, though, since to get them in the Resources bundle to begin with you’d have to specifically put it there anyway. Though I could see some situations where you need to remove a few things from the MAS build (like eSellerate libraries) that you aren’t controlling via Build Steps or other IDE scripting.

 

Finally, the Package tab is where code signing and sandboxing rules are setup. You’ll need a Certificate from Apple to do these things and, if you’re like us, you are doing this for multiple clients, it’s possible to choose which certificate to use. In the Packages tab you enable the Sandboxing rules and tell the OS all the things that your application will do with it. This is also where you’ll tell the OS what Apple Events you might be using with other applications.

Finally, there are several options when “Wrapping” your application. If you are building for the Mac App Store you have to create an Apple Package (really an installer), but you might want to test your application with all the rules enabled, or you might simply want to create a zip file to send to your beta testers.

 

When you’ve got all that done, you click the Wrap button to start the process. You’re presented with a nice listing of all the things the utility is doing. The green check marks indicate things that went well but the red lines indicate things that you might need to fix before submitting your application to Apple. And that’s it! Your application is wrapped using the rules you setup.

 

All in all AppWrapper is a nice utility and I can recommend it for use. Ohanaware has been using Real Studio for many years and is using it for their own applications.

There are few items that I wish were a little better. For one, I’d love to be able to invoke AppWrapper from an IDE script. The fact that I have to stop working in the IDE and then drag and drop the app onto the utility seems like an unnecessary task though not exceptionally burdensome. What can I say? I’m a lazy programmer, but, to be honest, I’ve submitted to the Mac App Store, for myself and clients, up to 10 applications in a single day.

My other nitpick complaint is that the Ohanaware website doesn’t have a support forum or dedicated help area for AppWrapper. While I think the utility is simple enough to learn, it’s still dealing with a topic that is a bit scary for many Real Studio Developers and some might want to be handheld throughout the process. In that same light, while AppWrapper comes with a help file it’s a little light on details and what the consequences are of each type of selection.

 

AppWrapper costs $50 and is available at http://www.ohanaware.com/appwrapper. It’s also part of the OmegaBundle http://www.omegabundle.com/ where it is part of the overall package of products for $399.

Long Live Cocoa (or is sandboxing killing carbon?)

Real Software posted an article on changes to the Mac App Store.  Starting in November apps submitted to the Mac App Store must be sandboxed.  This is a huge change and currently, according to Real Software, the carbon implementations to accomplish sandboxing are broken.

More information the Apple sandboxing can be found at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/ApplicationSandboxing/ApplicationSandboxing.html and I highly recommend you read it.

At the very bottom is a caveats section: apps can’t send AppleEvents from the sandboxed app (though they can receive them).  This seems rather extreme.  If your Mac app can’t send AppleEvents does this mean that Apple is killing AppleScript?  I doubt it, but it does seem to limit the usefulness of the service and I suspect that there will be a workaround.

Apps cannot work with non-bundled projects that reference other files.  Does this mean that services like Kagi and eSellerate will no longer work?

So what does this mean for a vast majority of Real Studio developers?  Not much really – unless you happen to be selling your apps in the Mac App Store.  For you, the changes are important and you’ll need to start compiling for Cocoa.  Cocoa is much improved in Real Studio 2011 R2 than any previous Real Studio release but unfortunately it still not complete.

So the bottom-line is that if you are developing Mac apps and hope to put it in the Mac App Store then you’d better start testing your builds in Cocoa.  While your app may not ship using Cocoa yet, Real Software needs the feedback on what’s not perfect so they can fix it.

It’s a good idea to start using Cocoa now because in November you’ll need it.  Long Live Cocoa!