How I Faked My Way into the Mac App Store, and How You Can Too

OK, “faked” may be a strong word, but I needed an eye-catching headline, because I have an important secret to share with all of you iOS developers out there. You know that computer you use to create awesome iOS apps? Yup, the Mac, that reliable workhorse of a computer you’ve loved since the 80s. It turns out, you can write apps for that thing too, and as of the past few years, doing so doesn’t suck as much as you might think.

Let’s cut right to the chase, if you’re an iOS developer, you probably think programming against AppKit sucks, and up until recently, I would have probably agreed. But the past few years have brought many of the iOS goodies you adore to the Mac, enough of them, that I contend it’s worth another look. This article discusses my experience creating my first “real” Mac app: AppLinX, including some suggestions, some gripes, and some helpful tools, all aimed at the skeptical iOS developer looking to maybe give it another go.

Go Small, Go Menubar

I’ll admit it right off the bat, when I say I shipped my first “real” Mac app, some might say I sort of cheated. Why? Because I opted to create a menubar app, rather than a full on, multi-window, dynamic frame beast of an app.

In all fairness, I made this decision purely because I had decided AppLinX made the most sense as a menubar app well before I started coding, but boy did it pay off in the longrun. On iOS, we’re used to dealing with one and only one window, the vast majority of the time. While view-based layouts can get quite complex, especially on iPad, the amount of extra overhead associated with supporting multiple resizable windows is a daunting prospect. By opting for a menubar app, I effectively turned my scary Mac app layout into a more iOS-like walk in the park, having to deal with only one window, of which I had complete sizing control.

If your first Mac app makes sense as a menubar app, save some of your precious brain cycles by taking that path, it’ll allow you to focus more on learning all the other aspects of Cocoa on the desktop. And, if you do decide to go this route, I highly recommend CCNStatusItem, a small library that will take the annoyance out of bootstrapping a menubar app.

Open Source Awesome

While I claimed earlier that the Mac is now a much more palatable development platform than it was even a few years ago, a good deal of the reason for this fact is the large amount of open source tools and frameworks that improve upon what Apple offers. Here’s a list of some of the projects I made use of in AppLinX, if you’re embarking on your first Mac app, these may save you some major time and aggravation:

• Rebel — A very comprehensive set of “fixes” for various AppKit components from the folks at Github. Too many individual components to list here, just trust me that you’ll want to use it if you’re writing a Mac app.
• AFNetworking — Yeah, obviously, it’s awesome on iOS and it works on OS X, a must have for any project that needs networking.
• GRNavigationController — “What place does a navigation controller have on OS X?” is what you may be asking yourself, but if you’re creating a menubar app, you may find this iOS UINavigationController analog useful.
• GBImageView — I’m a huge fan of SDWebImage for image caching on iOS. Unfortunately, as of this writing, it does not work on OS X. THis little library provides similar functionality for NSImageView (the Mac equivalent of UIImageView).
• MASPreferences — Ever notice how every good Mac app has a very standard preferences window? Well, turns out there’s a very strong convention from Apple on how to do this, and this library makes it super easy to implement via a handful of NSViewController subclasses.
• StartAtLoginController — Believe it or not, allowing your users to opt for starting your Mac app at login is a minor pain in the ass, involving a good deal of obnoxious boilerplate. This little library exposes this mechanism via a very simple to digest interface.

I’m typically more gunshy when it comes to adopting third-party code, but if you’re learning a new platform and want to get an MVP out quickly, pulling in some great libraries can both save you time and teach you about platform conventions.

NSCell: WTF?

Once you spend a few hours, or maybe even minutes, reading through AppKit framework reference material and noodling around, you’ll come across this bizarre abstraction called NSCell.

From the NSCell Class Reference:

The NSCell class provides a mechanism for displaying text or images in an NSView object without the overhead of a full NSView subclass. It’s used heavily by most of the NSControl classes to implement their internal workings.

I don’t have much in the way of advice on this thing other than to suggest you avoid it if at all possible. NSTableView used to require using it to configure cells, but now allows for view-based cells more akin to what you’ll find on iOS. Be aware that if you want to customize most controls, including NSButton, you’re in for a bag of hurt.

Where the hell is my layer?

iOS developers have been spoiled with layer-backed views since day one, but believe it or not, this is not the case on OS X. The fact that UIView is always backed by an instance of CALayer allows for easy bridging of things like animation directives and various styling, directly from the view to the layer. Try setting an NSView’s background color and you’ll quickly see what I mean (SPOILER ALERT: it can’t be done without accessing the layer directly). I mention this not to bitch about it, but to highlight the fact that if you want an NSView to be layer-backed in OS X, you need to set its wantsLayer property to YES before you access the layer.

A few words on appearance

On iOS, it’s pretty common to see UI that is quite stylized, making use of custom fonts, colors, iconogrophy, etc. In fact, I’d go as far as to say you’re at a distinct disadvantage if you don’t take the extra effort to pretty-up your app in a way that makes it feel unique. This is really not as much the case for OS X apps, as I’m sure is obvious to anyone that’s ever used a Mac for more than a few minutes.

What’s less obvious, especially to iOS developers, is that there is a rich set of framework code in place on OS X to make sure UI stays consistent, even in the face of user customization. Be very aware that users can change things like highlight color, system font size, and as of 10.10, menu style (dark or light). To keep your UI looking great at all times, have a read through the NSColor and NSFont headers for some of the standard value accessors you’ll want to use to have things auto-adjust to system changes.

Lastly, don’t think that just because you’re writing a Mac app, it has to be plain-jane boring. While it may be a bit less streamlined, Core Animation is present in all of its glory, and as of 10.10, mechanisms like UIVisualEffectView have made their way to OS X as well (see NSVisualEffectView and its cohorts).

Closing Thoughts

There’s so much more to say on this topic, but were I the reader, I’d probably be ready to be done at this point, so I’ll wrap it up. I hope I’ve at least peaked your interest and/or convinced you that the Mac as a development platform doesn’t suck as much as you might think. If I’ve succeeded, there’s definitely enough in this article to get you started, but I’d highly recommend also hitting the requisite reading/watching (Apple reference, past WWDC content, tutorials, books, etc.) With Apple slowly reaching feature parody between iOS and OS X, and technologies like iCloud, it’s never been a better time to sharpen your cross-platform knife.

If you feel like enjoying the fruits of my labor, do check out my app, AppLinX It’s all about creating, organizing, and using iTunes App Analytics links and if you’re an iOS developer trying to market your apps, it’s a must-have. Finally, if you think I’m full of crap on any of the content here, want to correct something, or just want to say hi, catch me on Twitter @nickbona or leave a comment.

Originally published at nickbona.com on August 24, 2015.