Copy protection is not a feature of the Mac AppStore. Although copy protection is optional, it’s an obvious option for developers who want to see a return on their investment. Unfortunately this means one more step before submitting to the AppStore. Apps purchased through the AppStore come with a receipt included in their app bundle, and it’s the developer’s responsibility to verify that receipt. That means tackling some nasty topics like cryptography and code obfuscation.
Fortunately there’s Recigen. Recigen provides a two-step process for implementing receipt validation: (1) enter your app’s bundle identifier and version number to generate an obfuscated header file and (2) copy that header into your project and replace the NSApplicationMain method in main.m with CheckReceiptAndRun. That’s it—your app is copy protected. Then you need only generate a new obfuscated header (step 1) each time your app’s version number changes.
Sandboxing an app for distribution on the Mac App Store can be difficult, sometimes impossible, but at the very least tricky. Every temporary entitlement will be carefully reviewed by Apple before approval and must be justified. Your app will be rejected if
usage of temporary entitlements is not precise.
One discrepancy between Lion and Mountain Lion we recently came across has to do with Flash video in WebView’s. If you are developing an app that includes a WebView, chances are the user will want to watch video at some point. If this app is being developed in Mountain Lion, everything should work just fine under the standard set of entitlements found under the app summary tab—no need to breakout the plist editor.
If you’ve been building apps for some time, you won’t be able to sleep at night until you’ve checked your app on as many different devices (in the case of iOS apps) and firmware/operating systems as you can get your hands on. This can be difficult in building mobile apps by design (Apple makes it difficult to test on older firmware because they want everyone to move along to the latest iOS release), but easy to with desktop apps. You’ll find past and future releases of OS X (at least as far back as 10.7) available for download in the developer portal, which you can run as virtual instances using either Parallels or VMWare.
So now if you setup a Lion instance and run your app, you’ll notice you get a black rectangle where you should be seeing a YouTube video. This is because you need the com.apple.WebKit.PluginAgent temporary entitlement to run video in 10.7 under sandboxing. Open your __AppName__.entitlements file and add a new row and add an array type with key com.apple.security.temporary-exception.mach-lookup.global-name. The array needs only a single entry: com.apple.WebKit.PluginAgent. Compile and run on 10.7 and everything should work okay.
Sandboxing can be a pain, but it’s worth the effort if your app can fit in a sandbox, even if you plan to distribute outside the Mac AppStore. From what we’ve seen, Apple is paying attention to how people are making use of temporary entitlements and are adjusting the sandbox accordingly with each iteration of OS X.
My workflow has completely changed in the past couple of weeks since I started using SourceTree. I make a lot of micro-commits throughout the day and I like to use gitk to see exactly what it is I’m checking in (for those of you who can get by with using git diff in the shell, more power to you).
It was easy to start using SourceTree as just a replacement for the antiquated gitk, which never got along well with Mountain Lion. The terminal button let me do only as much as I was comfortable with in SourceTree, until one by one I replaced each git shell command with a button.
SourceTree is easy to use, works with both Git and Mercurial and, most importantly, it’s stable. Highly recommend.
And then… One day you call -addPersistentStoreWithType:configuration:URL:options:error: and it fails, with an incomprehensible error about not being able to upload (or sometimes download) a file named baseline.zip. Or else, some other equally incomprehensible error relating to undocumented internal classes like PFUbiquityImportScanOperation or PFUbiquitySwitchboardCacheWrapper. You’ve never heard of baseline.zip, and you weren’t attempting to upload or download anything. Your app doesn’t have access to iCloud at this point, but what’s worse, you also don’t have access to your local data store, and you have no recovery path for either problem. Worst of all, you did not actually do anything wrong, and there’s nothing you can do to fix it. Try again, and better luck next time.
Tom Harrington, iCloud: State of the Union
For those of you wondering why we haven’t integrated iCloud into any of our apps just yet.