App Wrapper 3 [u]

Xojo makes developing Mac OS X apps very easy but getting those apps ready for distribution can be a daunting task. Apple has had the option for a while to not open applications from unknown developers using a security option that Apple calls Gatekeeper. Gatekeeper, in effect, restricts which apps a user can run on their computer. This theoretically helps protect users from installing malicious applications.

Gatekeeper has 3 settings: Mac App Store that allows only applications downloaded form the Mac App Store. Mac App Store and Identified Developers that allows Mac App Store and applications signed by certified Apple developers. Anywhere that allows any application to be launched. The default in Yosemite, is the 2nd option (Mac App Store and identified developers). Since Apple only recognizes its own developer certificates they have more control over the entire process.

To pass Gatekeeper you need to have a verified Apple Developer Account. Then use Keychain Assistant to request a certificate from Apple through the Apple Developer portal. Setting up this account costs $99 a year and it isn’t too difficult – Apple has some nice instructions for the novice developer to figure this out. However, signing your Xojo app isn’t the most straightforward thing to do, but we’ll get to that in a minute.

If you are trying to distribute your app on the Mac App Store you have to worry about a myriad of things that Xojo doesn’t automatically give you. The first is code signing your application. Other issues include Retina display settings and Retina image sizes, how you interact with the system via the App Sandbox, and if you are using iCloud or other Apple online services, Push Notifications or Game Center.

That’s a ton of stuff to figure out how to add on your own to your project. For several years we had our own postscript build that called a bunch of command line utilities that did the code signing, set the proper plist entries and so on. It was a pain to maintain and move to different projects for a variety of reasons – one of them being that finding out the cause of a script error wasn’t always straightforward!

AW Open

Enter App Wrapper from Ohanaaware. We’ve used App Wrapper 2 for a while and have been extremely happy with it. It takes the guess work out of configuring your Mac OS X distribution because the utility remembers the settings you’ve used for each application. This includes remembering which code signatures to use. Since we create apps for ourselves and for clients this is particularly useful.

App Wrapper 3 has five panels to choose from. The Report tab gives an overview of everything in the application along with reasons why it may be rejected from the Mac App Store. In the example below I’m showing ARGen, our ActiveRecord utility, that is NOT in the Mac App Store. If I did try to submit to the Mac App Store it would be rejected for three reasons: first, it uses the Sparkle framework, and the eSellerate libraries – both of which are rejected by Apple and are unnecessary in Mac App Store applications. The second reasons is that CubeSQL references QuickTime in the plugin (which is surprising since it’s a database plugin).

AW General

The General tab lets you set a number of variables needed by Apple. What’s the Category, minimum Mac OS X that can run the application. The copyright information. The version information, high resolution mode (Retina), which code signature to use, registering an Apple help file, and how the app should be packaged for you (to name the highlights). This is, by far, the panel you’ll need to pay close attention to.

One thing that was less than clear to me when setting up my app in App Wrapper 3 was the About Info credits. In version 2 there was checkbox to include this in the build. In version 3 it gets put into your application. The solution is to simply clear the text field but it’s not obvious. The default text is using my name and information. If I’m creating client builds I will now have to deliberately clear this out before I send to the client. Otherwise, there will be a Credits.rtf file in the Resources directory of the bundle.

For the Mac App Store the code signing certificate will automatically set the Packing for you. For non Mac App Store distribution you have the option of no packing, zip file, or Apple Installer. For us, we distribute via disk image (DMG) so we leave it to none.

The Capabilities panel is all about the App Sandbox and how the app interacts with it. There are a number of things with Sand Boxing that will make your development life a joy. All that fun stuff is beyond the scope of this review but if you’re going to submit to the Mac App Store you should really do some research!

The Info panel is all about setting up the info.plist properly for your app. The top list is what changes App Wrapper will add to the plist and the other sections are for Document Types, URL Aliases, and Uniform Type Identifiers. Some of these are set from Xojo and others are not.

AW Wrapping

The Other panel lets you clean up the application bundle. You can remove subversion remnants, DS_Store files, language files, and whether or not to clean up some of the architecture such as removing any old PowerPC code, or restricting it to Intel 32 bit or 64 bit. You even have the ability to fine tune the files and ignore them, delete them, delete them for the Mac App Store and so on.

To actually wrap your application you have two options. The first is to do it all manually. Drag your built executable on to App Wrapper 3, set it up all up, and simply hit the Wrap button in the upper right corner. You’ll want to do this manually a time or two to make sure there are no major errors.

The second, and probably preferable way, in my opinion, is to hit the Xojo Script button and drag the script file into the Finder and then into your project and put it under the build steps for Mac OS X (supposedly you can go direct from the App Wrapper to the Xojo IDE but I couldn’t get this work). Then it’s just a matter of hitting build in the Xojo IDE. The application is built and the script will use the executable and run App Wrapper in the background. Voila! You have a code signed application that’s ready for upload to it’s final destination (assuming no errors).

In App Wrapper 2 we used the command line option with our own Postbuild script. Version 3 doesn’t appear to allow this so we’ll have to modify our workflow a bit to use it but it doesn’t appear very onerous of a task (at this point). The benefits of using App Wrapper far outweigh the chore of setting it up.

Once your application is wrapped there are a couple of options for testing. The first is to test the application with Quarantine or RB App Checker Lite. Quarantine lets you start an application as if it was downloaded from the internet. This is handy because applications built on your machine are automatically considered ‘safe’. RB App Checker Lite from Rainer Brockerhoff lets you verify the certificate and check the entitlement settings before submitting it to the Mac App Store. Both of these tests are useful.

App Wrapper 3 has three purchase options. First is the 30-day Single User “Pay As You Go” option for $9.99 that runs for 30 days but can no longer be used at the end of the 30 days. The 1-Year Single User plan costs $20. The 1-Year Small Team plan costs $199.99 and lets App Wrapper be used by up to 10 developers. Both the Single User and Small Team options have free upgrades for a year after purchase and allow you to use the application even after the time period is up (no usage expiration).

The Pay As You Go option seems very odd. For a mere $20 you can get the Single User plan and can use it forever. I see no advantage in the Pay As You Go option and, to me, is more of a software rental plan.

[Update:] The 1-Year Single User plan is normally $49.99 but is $29.99 until the end of November.  Sorry for the error.

If you haven’t already checked out App Wrapper I recommend that you do. It is by far the easiest way to get your app ready for Gatekeeper and the Mac App Store. Without it, you may spend a lot of time figuring it out on your own. From experience I can say that Apple’s documentation assumes you’re using xCode so figuring it out for Xojo makes it that much harder.  Ohanaware has already done it for you!

For more information on App Wrapper 3 please visit

Review: RB Package Maker

In part one of our Mac App Store Utilities review we talked about AppWrapper from Ohanaware.  In this review we’ll review RB Package Maker Studio from blueColin Software.

RB Package Maker does many of the same things that AppWrapper does.  Like any two applications that accomplish the same thing it handles things a little differently.

Start RB Package Maker Studio.  It’s simple interface is designed around getting your app into the Mac App Store.  The first option you have is to select your Certificate used for code signing.  There are four tabs:  Basic, Resource Files, Sandboxing, and Override Info PLIST.

In the Basics tab, start by dragging, or selecting, your Real Studio built application.  RB Package Maker then parses the available information and puts in what information it can.  The other file you have to provide to the utility is the icns file containing your high resolution icons for the Mac App Store. In the info.plist settings are you need to provide the Application Category for the MAS and the version you’re submitting (this might require some clean up and the utility will flag it if it’s wrong).

In the Resources tab you can set up your help folder and have the utility index it for you.  An interesting twist in this is that you can tell the utility to NOT copy files with certain extensions.  This is handy if you are using subversion or other source code management systems that like to include hidden files.  In the Resources tab you can also specify additional files you want to placed in your bundle.

The Sandboxing tab is kind of…odd.  It lets you check off which Entitlements your application is going to be using.  However, you turn all of that on in the area above the tab control.  It seems kind of an odd choice and I guess the other oddity is that the listbox containing the entitlements looks to be enabled.  Anyway, once you’ve click on the Sandbox Main Switch above the tab control all the controls in this tab become active.

If you are unsure what each area does, RB Package Maker has an interesting build in help system.  Select the entitlement in the list and a more detailed description of what that entitlement does is presented to you including any other properties that it might be mutually exclusive to.

In the Override Info PLIST tab you have the ability to add your own information to the applications PLIST file.

To make your package you must be in the Basics Tab and then select the Make & Sign Package at the lower right corner of the window.  A new window is presented where you have a couple of options including Force Code Signing anything else in your bundle that might already be signed (Monkeybread Plugins, for example, are signed by them).  You also have the option to leave it as an application or make a package.

You have the ability to see what the command line commands will be by checking the See Bash Commands button.  This is an interesting option as you might be able to include this in your IDE script later on.

To sign and make your package, click on the Sign Application button.  The utility then creates your application and you get to see the Bash commands happening and the resulting messages from the Apple utilities.  Then it’s up to you close the window when you’re done.

RB Package Maker comes with extensive online help which includes a 25 page PDF file.  In addition they have a number of videos showing you how to use the utility as well as an extensive Q & A area on their website.  The Q & A entries go into some of the reasons why some things are the way they are.  If you like a lot of background information their website is chock full of additional information.

All in all, this utility does what it does very well and I’ve used it extensively for a couple of months.  It’s not without some flaws though.  While it’s not very hard to create an icns file using Apple’s Icon Composer application, this seems a little unnecessary step as you can make an icns file from any image object.

I really wish the utility would remember more of the settings between runs.  I find it annoying that if I’m creating the same package I have to setup the same information, Certificate, icon file, Application Category over and over again.  This is ripe for errors to occur.

As with App Wrapper I would love the ability to add this to my IDE script so I didn’t have to switch applications.  If either utility added this it would rank very high on my recommended apps list.

RB Package Maker Studio is $29.95 and is available at

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 It’s also part of the OmegaBundle where it is part of the overall package of products for $399.

Mac App Store

The Mac App Store, so far, has been pretty good for sales of Task Timer.  We have been running double of normal sales of the previous version.  Technically, version 5 was out before it was approved in the Mac App Store so that’s even more proof that the Mac App Store is doing well for us.  So from that aspect we are very happy with what we’ve seen from a sales standpoint from the Mac App Store.

What’s not very good is the amount of time it takes to get an application – even an application update – approved (or rejected) in the store.  We’ve been lucky that the few bugs that have been reported aren’t affecting everyone and aren’t critical.  We submitted our update on January 12th and didn’t receive a rejection until January 28th.  That’s 12 business days!

The rejection was from not linking properly to the HXRuntime library.  The problem and fix is documented on REAL Software’s blog.  What’s worse is that REAL Studio applications don’t even use this library so this is a false-positive result from some automated test that Apple implemented between our first second submissions.

I realize that we’re not generating a ton of sales from Task Timer so we’re not even a blip in Apples sales figures, but 12 days is an eternity when a customer has a problem.  They won’t complain to Apple, they’ll complain to me.  At the best I can offer customers to update outside of the Mac App Store but that’s a half-assed solution, in my opinion.  At worst, I’ll lose customers for life because I’m ‘unresponsive’ or write ‘crappy’ software.  I predict most people will be relatively forgiving but I think it depends on the cost of the software and what it does.

We are not the first and only developers to face this problem.  Panic, makers of the popular Transmit, had a similar issue that was thankfully taken care of quickly.  One has to wonder if a public blog post from a very popular developer didn’t speed things up a bit, but the point is that the process has a flaw.

I can’t believe that Apple is oblivious to this problem.  The wait times for app approval is just too long.

I’m not sure what the solution is.  All I know is that the current situation is not good for smaller, independent developers like me.  Wasn’t the Mac App Store supposed to be a boon for us?

Anyway, I’m not really all that angry.  I expect that approval times will get better as time goes on.  I would also expect that the automation tools they’re using internally will be available to developers for testing purposes (before submission) or, at the very least, some sort of automated testing submission process that, if not instantaneous, is light years faster than it is now.

What say you?