Weekly Sponsor: Mandrill
Mandrill is a scalable, reliable, and secure email infrastructure service trusted by more than 300,000 customers. It’s easy to set up and integrate with existing apps. And it’s really fast, too. With servers all over the world, Mandrill can deliver your email in milliseconds. Detailed delivery reports, advanced analytics, and a friendly interface mean your entire team—from developers to marketers—can easily monitor and evaluate email performance.
I’ve used Mandrill extensively as a front-end dev and found it really easy to understand. It’s great when you can hop into a really powerful system as a first-time user and start being productive immediately.
Beyond Objective-C, Beyond Swift
I had been writing software for less than a year when Apple introduced Automated Reference Counting (ARC) in iOS 4. Even in that short span of months I had struggled often enough with manual memory management (retain/release) that I immediately grasped the significance of ARC. I’ll never forget the figure that accompanied the transition guide documentation:
It perfectly illustrated the benefits of ARC. ARC didn’t make code shorter through syntax niceties or compacted expressions. It obliterated whole swaths of code throughout a project. An entire layer of error-prone state management was reduced to an almost invisible implementation detail.
ARC seemed too good to be true. Granted, to this day there are still some areas where memory management requires finessing, but for the most part it is quite close to magic — especially for anyone who remembers what it was like to write iOS software before ARC.
Progress is Offensive
During the first few years after the ARC introduction, mastery of old-fashioned manual reference counting was a point of pride among seasoned developers. Using ARC was somehow not “real” Objective-C programming. The kids these days and their ARC. That attitude is one that I don’t encounter much anymore. By the time Apple transitioned OS X to ARC, the stigma had all but disappeared.
Advances in software development are offensive to the practitioners of the technologies made obsolete. The new technology seems childishly simple in comparison to the complexity of what it replaces. At the risk of overgeneralizing, I think this reaction is natural. When you’re passionate about your work, you tend to fall in love with its idiosyncrasies, even those that might actually be burdensome.
Software development advances via abstraction. Best practices from lower levels of infrastructure are codified, automated, and optimized for common scenarios. It’s this abstraction and simplification that is the source of offense for the champions of older ways of working. When it’s done right, a new technology automatically handles tasks which previously required significant planning and effort. No one wants to see their expertise made obsolete — until they realize that the new layer of abstraction they thought was childishly simple is actually the building blocks for new complex things they’d never have been able to build with the old tools.
That’s what I want from an Objective-C replacement, but it isn’t what we get from Swift.
A Feeling of Disappointment
Some people are huge fans of Swift already. Others are ambivalent, doubtful, or outright opposed. I would place myself among those in the ambivalent group. I haven’t been able to articulate my thoughts and feelings yet. I think I can now.
There’s a lot to like about Swift. I especially love enums, string handling, the Playground REPL. Swift has clearly been designed with thoughtfulness and care. But nevertheless I can’t shake a feeling of disappointment. The best way I can sum it up is:
Swift solves problems that I don’t really have, and the problems I care about most Swift doesn’t solve.
Let’s use Apple’s Swift landing page as the canonical reference for the reason Swift was made. Here are the Swift features that Apple lists first (not including features that Objective-C had already, more or less, like automatic memory management):
Inferred types – Inferred types make code cleaner and less prone to mistakes.
Modules – Modules eliminate headers and provide namespaces.
Closures & Functions – Closures are unified with function pointers.
Tuples – Tuples and multiple return values.
Generics – That’s all it says. Just “Generics.” It’s implied that the usefulness of generics speaks for itself.
Structs – Structs that support methods, extensions, protocols.
Functional Programming Patterns - For example,
mapandfilter.
These are all demonstrable improvements over Objective-C. Let’s set aside the tired debates about the merits of generics, inferred types, functional programming patterns, etc. and agree that yes, Swift is better at many things than Objective-C.
So why am I disappointed? My disappointment with Swift is because all the items in the list above are only iterative improvements. None of them address the biggest challenges I face as a developer. To explain why, let me first describe the way I work. Then I’ll return back to Swift.
How I Work: Coding in the Air
I build all my software in a manner I call coding in the air. It began as a fruitful working relationship with Jamin Guy, my colleague at Streamweaver and Riposte. We would sit in Jamin’s living room and discuss architecture at length. Sometimes sessions would last for five or six hours. Neither of us would be touching a keyboard. We’d build up and tear down APIs in our minds, rattling off class names, property lists and method signatures over and over, each time a little different. Our mouths were sore from repeating the same words. Gradually the right patterns revealed themselves.
At the end of these sessions, the implementations were so clear in our minds that the actual work of writing software was not much more than typing.
It takes enormous amounts of concentration to build software in this way, but it’s worth it — especially if you have the benefit of a like-minded partner. Other than an uninterrupted block of time, there’s virtually no cost to coding in the air. As soon as an idea doesn’t work, it vanishes. There’s no code to rewrite or files to delete.
Coding in the air shifts your focus away from implementation details and onto architecture. It’s architecture that is the hardest and most important part of any project. It’s the part that takes the most time to implement — and the most time to reimplement should you paint yourself into a corner with a bad assumption early on. Coding in the air reduces the risk that you’ll need to reimplement something.
Implementation is the Bottleneck
When at last the time comes to fire up Xcode, the implementations are fairly clear in my mind. But this is where my problems really begin. Every project I’ve worked on involves rewriting the same kinds of implementations, but this code isn’t re-usable. Things like:
Databases & Persistence – Frameworks like FMDB or Core Data are reusable, but not the classes that actually make use of those frameworks. Classes have to be written that insert, update, and fetch project-specific objects into and out of those frameworks. Other classes have to be written to provide caches of those objects for uniquing and performance. If you want your table views to delay pending changes until after scrolling has completed, you’ll need to use something other than an NSFetchedResultsController to manage the pending changes. Layer upon layer of model controllers, for lack of a more graceful term, are required to serve as the “goo” between what your app does and where its data is housed. Let’s not even mention dealing with multi-threaded database access, migrations, and merging.
JSON & RESTful APIs – Networking tools like NSURLSession or AFNetworking are reusable, but not the classes that make use of them. Data must be converted to dictionaries, and dictionaries converted to objects. Each step in that pipeline is rife with potential errors that need to be safely caught, responded-to, and propagated back up to the top level of the application. The same complexities exist in the opposite direction, for outbound requests that send local data to a remote API.
Triggers & Responses – Events that trigger responses have to be wired up. KVO, when done correctly, involves a non-trivial amount of boiler plate. Notifications have to be posted, with the correct user information. Observations of those notifications have to be written wherever needed. If you make a mistake with KVO or notifications, you might get a crash. Many times things just won’t work, and no amount of linting will warn you. Your best hope is to set up integration tests with UI Automation and hope that your app design doesn’t break them too often. ReactiveCocoa is a daring third-party approach to simplifying some of these implementation issues.
UI Layout – Whether you use springs & struts or AutoLayout, either way you still have to explicitly instruct your view classes how they should arrange themselves. Long hours are spent writing and correcting the math behind these arrangements, especially now when there are so many devices to account for. Nothing just works. It’s all dependent upon minutely detailed instructions. It feels like instructing a blindfolded person how to assemble a model plane. Every app is a new plane.
These are just some of the time-consuming tasks we all face when writing Objective-C applications. They take a long time to do well, and involve a great deal of repetitious, brute-force work. These tasks deplete limited resources. Developer time is the biggest expense subtracted against a startup’s bottom line. It’s also mentally and physically taxing. It’s hard to stay focused on the core problem that matters most: building something that users love.
Back to Swift
Swift doesn’t reduce the time and energy it costs to implement the boilerplate goo that comprises our applications. Even factoring out the learning curve (which is steep), Swift merely shifts the locus of debugging from runtime into compile time. It solves some common implementation mistakes with Objective-C, but it doesn’t make whole applications faster to implement. Saying Swift makes programming easier is like saying that iOS 8 extensions make it easier to use an iPad the way that Federico Viticci does — more straightforward, perhaps, but as a workflow it’s just as complex.
The net result will be this: Objective-C developers will spend the next several years transitioning to the new syntax and assumptions in Swift. When that transition is finished we will likely still be where we left off in 2014. We’ll still be spending long hours writing boring, buggy, non-reusable implementations of persistence, networking, trigger/response, and layout code.
What I Want
On a continuum from the abacus to punch cards to Objective-C, Swift is only an iterative improvement upon Objective-C. Perhaps someday Swift will serve as the underlying language behind the kinds of solutions I’d like to see. Regardless of how it happens, here’s some of the things that I want:
Automated Persistence – I don’t want to have to think about how to implement persistence ever again. I just want to toss a model object into a bucket and trust that it will be stored, cached, merged, and uniqued. I should be focused on describing the properties and relationships between objects, and the way I want them to be grouped. Everything else should be an invisible implementation detail.
Automated RESTful APIs – Once I’ve instructed my application how to map an API response to a model object, the networking and JSON conversion code should be handled behind the scenes without any effort from me. I want to focus solely on how those items should be presented to the user.
Expressive Triggers & Responses – I want to describe the responses to events and triggers in a syntax that derives from the intent of the response. I don’t care how those linkages are implemented, only that they’re implemented in ways that won’t break through common refactoring mistakes.
WYSIWYG UI Editing – I don’t care what the math is behind a view hierarchy. Just like Disney keyframe animators handing off pencil sketches to armies of interns, I want to manually position some example views in Xcode, for a handful of edge cases, and let Xcode handle all the implementation decisions. That would truly be worthy of the name AutoLayout.
I want whatever comes after Objective-C to obviate whole layers of architecture the same way that ARC made memory management a concern of the past. I understand that what I’m asking for is more than just a programming language. But that’s because the biggest obstacles holding back Objective-C development can’t be solved by a language alone. We need a new paradigm.
The iPhone 6 Plus Makes Designing Apps for Physical Comfort More Difficult — and More Important — Than Ever
Several months ago I wrote a post about the ingredients that make an app feel comfortable. This post is more applicable now than ever.
I’ve spent only a few days with an iPhone 6 Plus and it’s clear that the designs of many popular iOS apps are inappropriate for a display this large. It may be a huge phone, but the iPhone 6 Plus is still a phone. You should be able to comfortably perform common actions in your favorite apps with just one thumb.
I absolutely love the huge display. Five and a half diagonal inches are better for many things: web browsing, reading RSS, watching movies, and more. It’s misguided to suggest that the size of the display is what needs to change. The problems are caused by the misuse of interface elements that were designed to fit constraints imposed by smaller displays.
Cancel and Accept – Modal screens presented via navigation controllers are particularly frustrating. The most important buttons on many screens are also the most difficult to reach. I can’t cancel or accept a new tweet, or dismiss a web browser, etc. The back button is by far the most difficult to reach, which wouldn’t be as big of a deal if it wasn’t for the next issue:
Going Back – The native iOS screen edge gesture (for popping a screen off a navigation controller stack) is unwieldy. Sometimes it’s practically impossible to use. In some apps, when going back I have to deliberately bring all scrolling to a halt so I don’t accidentally trigger another scroll event thereby canceling the back gesture. This is something I spent an inordinate amount of time on in Unread1.
These are just two of many problems the new devices have introduced. My experience is with a 6 Plus, but I have long fingers. From what I have read, people with small or average sized hands have similar complaints about the iPhone 6 (non-plus).
Solutions to these design problems are waiting to be found, but they will not be obvious. What I know for sure is: we can do better.
-
There’s a heuristic in Unread that favors vertical scrolling over horizontal panning. I don’t remember the exact ratio (It wasn’t 50/50. I tried many ratios until it felt right). Most of the time you’re just trying to scroll through a list of stuff. But when a dismissal is determined to be the user’s likely intention, the dismissal pan gesture overrides all other panning gestures. The result is buttery, responsive navigation. ↩
Iterate 74: Designing for iPhone 6 and Apple Watch, with Kawano, Sinclair, and Wiskus
I was a guest on last week’s episode of the Iterate podcast. There was so much to talk about after Apple’s announcements. My biggest concern: I’m worried that many apps won’t figure out how to feel physically comfortable on iPhone 6 and 6 Plus. My biggest point of excitement: I can’t wait to see what people do with the Apple Watch, especially for customers who can’t use their iPhones while they work.
Good Design is a Process, iPhones 6 Edition
From John Gruber’s review of the iPhones 6 (emphasis added):
My understanding, talking to people at the event last week, is that Apple’s industrial design team mocked up prototypes of every single size between 4.0 and 6.0 inches, in tenths-of-an-inch increments, and from those 20 sizes selected the two that best hit the sweet spots for “regular iPhone” and “ginormous iPhone”.
Two takeaways with regards to my post yesterday about healthy design processes:
It’s sweet spots — plural. It’s never been more obvious that Apple’s design team can produce two different products that are equally faithful interpretations of unchanging principles. Both the 6 and the 6 Plus are unmistakably iPhones.
Tenths-of-an-inch increments. Not even Apple waltzes through a problem confident in their first or second draft. Someone said: let’s make every fucking size between four and six inches and try them all, and the team followed along. That’s the only way they could know for sure which sizes work best.