OS X for iOS Developers: Why You Should Be Building Desktop Applications
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Xcode. Interface Builder. Objective-C. Swift. These core tools power your iOS development tasks. Many developers, however, never consider how easily these skills transfer to the desktop. OS X development is based around the same tools and the same languages, with a large API overlap. This write-up explores what it takes to start building OS X apps from an iOS background.
Moving from UIKit to App Kit
If you can build an iOS app in Xcode using Objective-C or Swift and Interface Builder, you know pretty much everything you need to create OS X apps. Whether you're working with strings, dates, notifications, constraints, or dictionaries, the APIs are essentially identical between platforms.
The biggest difference lies in interfaces. OS X uses the AppKit framework, which supplies all the windows, buttons, menus, and views you need to build your user experience. AppKit expects mice, keyboard, and trackpad input. iOS leverages UIKit, a newer touch-based system created for smaller screens and the less precise input that finger touches entail.
While AppKit focuses on menus, windows, pop-up elements, and multitudes of buttons, checkboxes, and text fields, UIKit specializes in folding interfaces down to their essentials. It uses a bare minimum of control types to establish interaction intent. Navigation stacks compress apps to single interaction scenes. So while you may develop similar application semantics for both platforms, how you express those underlying semantics can look and feel quite different between desktop and mobile platforms.
Why Bother with OS X?
Many iOS developers discount OS X. The market is smaller, customer discovery is more difficult, and the app store less well integrated. Signing up for official distribution certificates costs an additional $99 per year, and expected revenue is almost always going to be far less than you can earn via the iOS App Store. If you want to bypass the App Store—and many developers do, because of sandboxing and other restrictions—you have to set up your own rights system and storefronts. So why develop for OS X? Compelling reasons remain.
OS X development offers a great way to expand your app beyond the phone. Whether you're connecting files through iCloud, playing games together in the game center, or offering services with Bonjour, an OS X client enables you to expand your brand and add value.
You might also explore OS X-only development. The market may be limited, but it's still a terrific ecosystem, whether you work inside the App Store or use developer signing outside it. You can build utilities to enhance people's workdays or create games to add some fun to their lives. Nothing says development has to start and end in the mobile world; you already have most of the skills you need to build OS X apps.
API Differences
Long-established video games occasionally sneak in a retro-styled level reminiscent of an older title in the series. In many ways, moving from iOS to OS X feels a lot like that. All the skills you've developed apply, but API specifics can feel slightly off or outdated.
To be fair, developing for OS X doesn't mean jumping into the past. The desktop is a lively, modern, and evolving target. Yosemite offers many new OS X features, just as 8.x added new iOS features. Moving from U
Kicking the Tires
One way to convince yourself that you already know how to develop OS X apps is to write one yourself. All you need is Xcode. In the following steps, you build a working application that interactively matches text using regular expressions:
Create a new project. Choose File > New > Project and select OS X > Application > Cocoa Application. For simplicity, leave the Create Document-Based Application and Use Storyboards options unchecked. Xcode builds a working app skeleton. As with iOS templates, you can immediately run the app, which defaults to the single window in Figure 1.
Figure 1 Xcode's default project skeleton creates a single window app.
- Simplify the window. For this simple example, the app needs only a minimal interface. Select the window and open the Attributes inspector. Disable the Resize, Close, and Minimize checkboxes to ensure that you have a fixed-sized window that won't disappear.
Add a text view and populate it. Use the Xcode object library to drag a text view onto your window. Then select View > Bordered Scroll View > Clip View > Text View in the Interface Builder document outline, as in Figure 2.
Figure 2 Text views are embedded into clip views and bordered scroll views. Navigate down the Interface Builder document outline to select them.
Next, open the Attributes inspector. Fetch a few paragraphs of lorem ipsum–style filler text. Paste the paragraphs into the text view content field in the inspector, as in Figure 3. Then scroll down the inspector pane and disable the Editable Behavior checkbox. Don't worry about the font or text size.
Figure 3 Use the Attributes inspector to populate the text view with text.
Establish a text view outlet. While holding down Control, drag from the text view in the outline to the application delegate's header file to create an outlet for the text view (see Figure 4). Name it textView.
Figure 4 Control-drag to add outlets to the header file.
Add a text field and build another outlet. Next, drag in a text field and control-drag to the delegate header to build a text field outlet. Name it textField. After this step, the app delegate interface looks like this:
@interface AppDelegate : NSObject <NSApplicationDelegate> @property (unsafe_unretained) IBOutlet NSTextView *textView; @property (weak) IBOutlet NSTextField *textField; @end
Set the text field's delegate. Select the new text field and control-drag to the App Delegate object in the Xcode (see Figure 5). Select delegate from the pop-up to assign the app delegate as the text field's delegate. This action allows the app delegate to respond to changes typed into the text field.
Figure 5 Control-drag to set the app delegate as the text field's delegate.
Add code and run. Finish the app by updating the app delegate implementation to the following code:
@implementation AppDelegate { NSString *lorem; } - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { lorem = _textView.string; NSAttributedString *outputString = [[NSAttributedString alloc] initWithString:lorem attributes:@{NSFontAttributeName : [NSFont fontWithName:@"Georgia" size:18.0]}]; [_textView.textStorage setAttributedString:outputString]; } - (void) controlTextDidChange: (NSNotification *) notification { if (notification.object != _textField) return; NSMutableAttributedString *outputString = [[NSMutableAttributedString alloc] initWithString:lorem attributes:@{NSFontAttributeName : [NSFont fontWithName:@"Georgia" size:18.0]}]; [_textView.textStorage setAttributedString:outputString]; NSString *sourceString = _textField.stringValue; sourceString = [sourceString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]]; NSError *error; NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:sourceString options:0 error:&error]; if (!regex) return; [regex enumerateMatchesInString:lorem options:0 range:NSMakeRange(0, lorem.length) usingBlock:^(NSTextCheckingResult *match, NSMatchingFlags flags, BOOL *stop) { NSRange range = match.range; BOOL abut = (range.location + range.length) >= lorem.length; if (!abut) { [outputString addAttribute:NSForegroundColorAttributeName value:[NSColor greenColor] range:range]; [outputString addAttribute:NSUnderlineStyleAttributeName value:@(NSUnderlineStyleThick) range:range]; } }]; [_textView.textStorage setAttributedString:outputString]; } @end
)
)
)
)
){kind=link}
Each time the user updates the text field, these methods treat that text as a regular expression and mark out matching occurrences in the text view. Figure 6 shows the running application.
)
Figure 6 The running application matches input expressions to the lorem ipsum text displayed in the text view. This particular search locates strings of three lower-case letters followed by an additional lowercase letter l. Matches are underlined and colored green.
This code is nearly identical to the code you'd build for iOS. Text storage, attributed strings, and regular-expression handling offer practical cross-platform solutions. The font uses NSFont instead of UIFont, but the call to create an 18-point instance is pretty much the same between platforms. Only the delegate method controlTextDidChange: is markedly different, as iOS uses a more formal UITextFieldDelegate protocol.
The steps used in Interface Builder should also feel familiar. The control-drags to create outlets and connect properties are equivalent to those used for iOS development. Yes, a few things (notably the stand-alone window and the embedded text view) feel different from iOS, but it's the similarities more than the differences that win.
IKit to AppKit does involve a learning curve. If you're prepared to elbow grease your way through web searches, you can easily get up and going with OS X dev.OS X has been around since 2001—longer, if you take the beta period into account, and even longer if you consider NeXTStep, its predecessor, as part of the evolution. Sample code, mailing list discussions, and how-to write-ups abound. Just about any challenge you run into can be solved with a mix of Google searches and peer support, whether on the Apple developer forums or on IRC. Freenode hosts a #macdev chatroom for OS X development issues.
Summary
OS X is a platform that's well worth investigating for many iOS developers. As the simple project in this write-up demonstrates, the distance between iOS and OS X is minimal. iOS skills readily transfer to OS X, and you can start building your own desktop projects in almost no time at all.
You'll find a working copy of this sample project at https://github.com/erica/useful-things in the informit folder.