The Right Way to Create an iCloud-enabled Mac App in Xcode

A few months ago, I decided I wanted to try exploring the Mac App Store ecosystem as a developer. I’ve been writing little Objective-C apps for myself for awhile, and I decided I wanted to see what it was like from the other side. So I wrote this little app called Airplane Setting. It was a stupid simple little app that made it easy to turn off your radios with a single action. I wrote the app and paid my $99 admission fee. And after a month of back and fourth with Apple and a couple of rejections for what I consider to be dubious reasons as best (especially seeing as how I could point out existing apps in the store that broke the “rule” they said my app was breaking, but whatever, their store, their rules…), my little App was finally approved for sale. It did moderately well, passing 1,000 downloads with virtually no advertising from me. I had big dreams for this little app. Plugins, global hotkey support, localization, Applescript support, and more potential functionality. But all that was dashed by “Entitlements” and Apple’s requirement that all apps must be sandboxed. Look, in theory, the idea of sandboxing an app is not bad. The problem here is Apple’s all-or-nothing approach to sandboxing. The selection of entitlements are just so limited as to be nearly useless for anyone creating a unique, new or complex app - especially one that requires hardware access. Your choice is either to sandbox your app, choosing from the available selection of entitlements, or not sandbox it and not be in the Mac App Store at all starting in March. There’s no reason to only provide such a limited subset of functionality that a developer must choose from. Would it not be better to provide us a wider set of entitlements and allow us to justify our reasons for needing them when we submit our app? The reason Apple gives for requiring sandboxing is to prevent “rogue apps” from destabilizing the system. But when you consider that the App Store itself is curated, this requirement makes even less sense. If Apple is curating the store, how does a “rogue app” end up in the App Store? I’m a huge Apple fangirl. I have almost all Apple hardware in my house, from my iMac to my Macbook Pros, to my iPad and iPhone and my wife’s iPod Touch. I had AppleTVs before they were cool (and there’s one on every one of my TVs now). I love Apple. But as an developer … I [expletive] hate Apple for this “innovation” that crippled my once-promising little app. So, at this point, my options are: Leave Airplane Setting in the App Store. Doing so will mean no further updates so I’ll likely cease development. Remove Airplane Setting from the App Store and start distributing it exclusively from the website. My original intent with Airplane Setting was to explore what it was like to be an App Store developer. I guess … now I know what it’s like to be an App Store developer, and living in constant fear of Apple as a sword of damocles hanging over your head.

So today, out of nowhere, Xcode 4 finally landed as an official release. After seemingly forever in beta, and me quipping more than once about it’s similarity to Duke Nukem Forever, Apple finally pulled the trigger and released it. But something changed. Xcode now has a price. And that has left me, as both a Mac user and a Mac developer, with a lot of questions. It’s either $4.99 if you’re not a registered, paid Apple developer, or free if you are a registered, paid Apple developer (with all its $99 per year price tag glory). Supposedly there’s some crazy accounting reason that they have to charge for it. This, of course, leaves open the possibility that Xcode will soon be free again once OS X 10.7 arrives. But, it also leaves open the possibility that Xcode will no longer be distributed with OS X and will always have a price tag. It may not even stay $4.99. It may be $49.99 or $499.99. There are additional questions, too. Does this mean that Apple is still distributing Xcode as a bundle with GNU GCC? Because there are things (such as MacPorts) that rely on the underlying foundation provided by the developer bundle that don’t actually use Xcode. Before, those were completely free. Now, they cost $4.99 unless they have split the underlying compiler from the IDE. And if they are still distributing it with GCC, that leads to all kinds of crazy interesting licensing questions. But I think the worst part is that there is now a barrier to entry, however low, to being a developer on a platform that is already a minority in market share. I can’t understand how Apple potentially believes that it is good and right to trade short term profits for long term growth in the number of potential developers. For the future of the Mac platform, I sure hope this isn’t their line of reasoning. So, let me tell you a little story. My first dabbling in programming came courtesy of QuickBASIC back in the MS-DOS and Windows 3.1 days. This was the late 80s or early 90s, so I would have been 10 or 11 at the time. I stumbled across the Qbasic environment included with MS-DOS by accident and found Nibbles. And, after playing it, I discovered that I could change things by making changes to the strange text presented on the screen. I could change colors and speeds. But it would be a couple of years before I really understood what I was doing. When Windows 95 came out (and along with it, Visual Basic 4), I talked my parents into getting me a copy. I don’t remember how much it cost but it was probably a lot because it was one of the few Christmas presents I got that year. But boy did I run with it. I’ve periodically felt guilty over that expense because I didn’t actually make anything really useful with it, but it was instrumental in furthering my education. Now I could do things on my computer far beyond what poor ol’ Qbasic was capable of. So I wrote lots of silly little programs. I put together a “family newsletter” one year that was installed and ran as a piece of software. I was pretty proud of that. I even wrote some software for my high school as part of a software development and AP Computer Science courses. Eventually, I would move on to other things. Other versions of Visual Basic, Java, C, a brief foray into LISP and Forth-based languages for programming MUDs, and eventually web programming. First in Perl, then in PHP. I even landed my first paying programming job while still in high school, writing applications for a local transit contractor. At first, these were Visual Basic applications. But by the time I left (August of 2000) everything was going to the web and so were we. But I can trace everything - my entire career, and my consuming passion for software engineering - back to Qbasic and Nibbles. A silly little game about a block snake, and a free development environment included with the operating system. Had I not stumbled on Qbasic and Nibbles, there’s a chance I would never have been a developer. This is not about $4.99. I spend more on coffee in a week than that. My worry is about that 11 year old kid out there somewhere who may never get the opportunity to stumble across Xcode or the sample applications in /Developer and realize the raw power they possess. This is an area where Apple, a company with billions in cash on hand, should be happy to show a loss. It would be to the benefit of their platform, both now and in the future. One of the great benefits of the Mac platform has been it’s low barriers of entry to developers. Sure, one could argue that the hardware is more expensive (and I could counter-argue that, for the quality of the equipment you are getting a bargain), but the development tools have always been freely available online and included with the machine. You could dabble in programming to your heart’s content. Sure, if you want to put something in the app store(s), you had to pay for admission, but there was nothing stopping you from getting all the way to that point, or even distributing your creations on your own. But this new trend of charging for the development tools - even if it is a paltry sum - sends, to me, a worrying signal about the course Apple intends to tread. They’ve now moved the gate from the last step to the first step. It’s a course that Microsoft, as above, once tread. Microsoft? They now give away a version of Visual Studio for free.

Over the weekend, I was having some hard drive issues. While I think I fixed the issues, I’ve been keeping a close eye on my console (Console.app) to look for any hints that the issues are more major than those that can be repaired by Disk Utility. However, while watching my console, I noticed something: there are a LOT of spammy Mac apps out there! Most Mac/Objective-C developers are aware of the NSLog() function, which, while in an Xcode environment, outputs data to the Xcode console. It’s usually one of the first things a new developer learns about and it’s very useful for debugging. What many developers may not realize is that NSLog() continues to output data to the system logs even when the app is not being run from within Xcode. As a result, the console fills up with messages that don’t mean a whole lot to people looking at the console. Now, I don’t want to come across as saying you should never use NSLog() outside of Xcode. There are times when outputting debug data to the console is fine. But some of the things I see are people echoing objects into the log or short text strings that are obviously method names. These aren’t helpful to people looking at the console and, arguably, aren’t helpful to a developer once an app is in the wild. Once your app is in the wild, data in the logs should indicate error conditions in your app. NSLog() is fine for debugging in Xcode, but you should be careful to remove them when you’re done. A good question I ask myself before leaving an NSLog() in place is, “if a user filed a support request with this data, would it help me fix their problem?” Most of the time, the answer is no. So before releasing an app, do a quick search in your project for all uses of NSLog() and evaluate whether they are really needed.