This blog is predominantly about programming old computer hardware, with a focus on using modern tools but as little as possible between our logic and the underlying system. That’s not always talking directly to the hardware—usually we’ll make heavy use of BIOSes or onboard ROM routines—but it is to use the simplest constructs that we can to meet our needs.
It’s time to apply this philosophy to a more modern system. I had some practical problems to solve when I began investigating this, but in the end this has turned into another Bumbershoot Software project where I try to do as much as possible while relying on as little as possible and with as few compromises as possible.
Background
Apple has used fairly sophisticated metadata formats for their executables throughout their history. Classic Mac OS bundled applications into carefully formatted resource forks, and both OS X (now macOS) and iOS use precisely-structured directories to represent much of any given application. In addition to the executable binary, there are separate files representing graphical resources and usually some kind of declarative representation of much or even all of the user interface. These technologies have changed over the past 20 years but for the most part the core logic has remained unchanged.
My goal for this article and its followups is to strip away as much of the automatic frameworks in macOS and iOS applications as I can, so that one might treat developing for the Apple ecosystem in a way consistent with other operating systems.
Simplifying iOS
In some senses, our options on iOS are limited. Apple very aggressively polices its applications in its App Store and will prune anything that does not conform to its latest deprecation levels. That said, we still have have a lot of leeway. Most of the newer technologies that Apple has introduced over the life of the iPhone do not replace earlier APIs so much as wrap them. That means we don’t need to significantly change the APIs we use, because those are stable and generally available across all versions of iOS that the App Store would let us support.
The main intrusion Xcode makes into a notionally empty iOS project is two storyboards. Storyboards are an extension over their earlier Interface Builder system (“NIB” and “XIB”) which declaratively encode not only the UI on the various screens of an application but also represents transitions between them (segues). The underlying UI elements—UIViewController for individual screens, and UIView for the widgets within it. One of these storyboards is called LaunchScreen.storyboard and it controls the interim display while iOS itself is loading your application and preparing it to run. This is not really part of our logic, and this one doesn’t need to be stripped out. The other, however, is Main.storyboard, which is supposed to represent the entire workflow throughout the whole system, and this rapidly becomes an unwieldy nightmare. The article I linked there suggests breaking this down so that each storyboard is a single view controller, but why bother with this when iOS still permits working directly with View Controllers and Views?
Well, OK, there is an answer to that, which is that the level of single view controllers is a little inconvenient for doing visual design of a user interface. But for the purposes of this project, we’d like to remove all of the declarative UI and do everything (except the launch screen, which predates us starting anyway) programmatically.
Removing the main storyboard is easy—just delete it out of the project and remove the UIMainStoryboardFile key from your project’s Info.plist. Of course, that isn’t quite enough as it is; the main storyboard was responsible for actually setting up the app’s basic display and its first screen of UI. We’ll have have to do that part by hand. In our application delegate, we’ll need to extend the application:didFinishLaunchingWithOptions: callback with some code to set up the window and put the root view controller into place:
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
ViewController *rootViewController = [ViewController new];
[rootViewController loadView];
[rootViewController viewDidLoad];
[self.window setRootViewController:rootViewController];
[self.window makeKeyAndVisible];
It’s fairly common to build view controllers and composite views programmatically from scratch already, but in case you haven’t seen that before, here’s a whirlwind rundown of that:
- Create all your subviews, set translatesAutoresizingMaskIntoConstraints: to NO, and assemble your view hierarchy with addSubview: inside your view’s init function. (You don’t need to specifically override initWithFrame: nor initWithCoder:.)
- In the view controller’s loadView: method, assign a new instance of your core view to the self.view property.
- In the view controller’s viewDidLoad: method, set up any extra or cross-view gesture recognizers and actually activate the layout constraints. (If you aren’t working as close to the API as possible, the Masonry library provides some much-needed abstraction over AutoLayout’s systems of linear equations.)
Auto Layout was introduced in iOS 6, and any actually releasable iPhone app will thus at this point be guaranteed to support it. The auto-resizing mask is at this point just an embarrassing legacy of early OS X, and disabling it is just a bit of omnipresent boilerplate. With this, we’ve stripped away pretty much all the tooling around the raw code, and the UI will be built programmatically by the application as it runs.
On iOS, though, this doesn’t really buy you a whole lot beyond the ability to more easily use tools like Masonry and noticeably fewer merge conflicts thanks to a lack of storyboards. There’s not a whole lot of reason to actually do this on iOS.
Doing it on macOS is a little more exciting.
From iOS to macOS
Apple’s research and development of its user interface APIs is very clearly being spearheaded by iOS. Macs have gotten innovations from iOS in waves; the view controller paradigm supplemented OS X 10.0’s window controllers in 10.5 Leopard, Auto Layout was introduced in 10.7 Lion, and 10.10 Yosemite knitted these together more tightly. It’s a perennial fear amongst Mac users that Apple is planning to reduce the Macintosh to an iPad with a keyboard, but these API imports really just make development on the Mac more straightforward. The two main differences when writing Cocoa for Mac instead of iOS is that the classes and constants all start with NS instead of UI and there is an extra NSWindow and NSWindowController above the view controller level.
Oh, and storyboards aren’t used by default. because those are tied pretty strongly to a single-screen display that evolves over time as opposed to the desktop metaphor. Mac development continues to use the old “Interface Builder” APIs and represents the interfaces so designed as .nib files in the app bundle, or the equivalent XML-based .xib files when part of an Xcode project. (Storyboards are supported in macOS as of 10.10, but there’s very little call for them in a desktop application.)
That aside, the convergence between macOS and iOS is strong enough that the procedure for stripping down a macOS application is very similar to the iOS one. Put all your UI-building code in NSViewControllers and NSViews, set up your NSApplicationDelegate so that it builds your window, and you’re almost home free. There are two complications.
Building a Window From Scratch
The window’s lifecycle is split up a bit more in macOS.
- Create the window with [NSWindow windowWithContentViewController:] in the application delegate’s init method.
- In the delegate’s applicationWillFinishLaunching: handler, set your window’s contentView hander to the window’s contentViewController.view.
- In the delegate’s applicationDidFinishLaunching: handler, call [NSApp activateIgnoringOtherApps:YES] and then invoke makeKeyAndOrderFront: on your main window with the application delegate as the parameter.
Note that NSWindows did not get contentViewControllers until 10.10. If you want your application to run on older versions of macOS, you’ll need to create the window with the initWithContentRect:styleMask:backing:defer: initializer, and just create your main NSView just before assigning it to the window’s content view.
Dealing With the Menu Bar
Even if we wipe out all the windows from our Interface Builder files, we can’t actually get rid of the last one by default it. The project’s Info.plist will list an NSMainNibFile which specifies the initial state of the menu bar, and NSApplicationMain seems to insist on it being there. To get rid of that dependency, we need to replace NSApplicationMain and then build a menu bar ourselves at an appropriate time.
The first is pretty easy. Our new main function looks like this:
int main(int argc, const char **argv) {
@autoreleasepool {
NSApplication *application = [NSApplication sharedApplication];
AppDelegate *delegate = [AppDelegate new];
[application setDelegate:delegate];
[application run];
}
return EXIT_SUCCESS;
}
We will also need to set the “activation policy” that tells the rest of the OS how to deal with our windows, and in particular, that it should treat them as ordinary GUI application windows and not popunders or system alerts or whatever. We do this by adding this line to the applicationWillFinishLaunching: handler:
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
This handler is also the correct place to build our main menu. The most basic possible menu just has an application menu with a single option to quit out. Some straightforward code for building that looks like this:
NSMenu *menuBar, *appMenu;
NSMenuItem *appMenuItem, *quitMenuItem;
NSString *appName, *quitTitle;
menuBar = [NSMenu new];
appMenuItem = [NSMenuItem new];
[menuBar addItem:appMenuItem];
appMenu = [NSMenu new];
appName = [[NSProcessInfo processInfo] processName];
quitTitle = [@"Quit " stringByAppendingString:appName];
quitMenuItem = [[NSMenuItem alloc] initWithTitle:quitTitle
action:@selector(terminate:)
keyEquivalent:@"q"];
[appMenu addItem:quitMenuItem];
[appMenuItem setSubmenu:appMenu];
[NSApp setMainMenu:menuBar];
(If you aren’t familiar with Objective-C, lines like [foo bar] are invoking the method bar on the object foo and method arguments are introduced by colons. And yes, the default indentation styles are that when you do a method call that spans multiple lines like this that you make the colons line up with ragged edges on both left and right. Don’t look at me, I didn’t do it.)
With this in place we can now remove our reference to a “main NIB file” from our Info.plist. But we can do more than that.
The Punchline
Once we’ve stripped out MainMenu.nib and declined to use any other bundle resources, we have not merely removed files from our app bundle. We have removed the need for an app bundle at all. A Cocoa application that has been stripped down in this way can be run directly from the Terminal, and it will behave almost exactly like an X11 app does in a Unix terminal. The terminal’s control codes can be used to suspend, resume, or terminate the graphical application, and the application can output data to the Terminal’s standard output and error, which may be redirected as usual. Meanwhile, the application itself lives on the Dock and gets its own menu bar to switch to, and otherwise functions just like an ordinary application, albeit one that is using a Terminal-derived icon for its window.
That’s a fun trick to have, and that actually solves the problem I originally had (which was that I needed to pop up a dialog box inside a shell script, and AppleScript was not behaving as cleanly as I’d have liked it to). But this is all just dry theory and snippets, so far. Next time I will go through a worked example, and then we will see how many modern APIs we can abandon without having to compromise anything. Programming and API conveniences are nice, after all, but being able to actually run on older machines is nicer still.
References and Acknowledgements
Stack Overflow is full of people trying to do various parts of the techniques that I’ve presented here, though most of the answers may be summarized as “for the love of God, don’t do this thing.” Matt Gallagher’s Minimalist Cocoa Programming article from 2010 provided the most solid base for the rest of my development here, and where the procedures I have presented differ from his, they are to account for changes in the default macOS programming API, or to account for places where the minimalist approach doesn’t produce a fully well-behaved application when run from the Terminal. But that is no discredit to him—he could not see the future, and his goal was not my goal.
