WWDC 2019
I had the tremendous fortune to attend Apple’s Worldwide Developers Conference in San Jose this year, and by nearly all accounts this was the most important WWDC since at least 2014 (the year Swift was introduced).
The sheer magnitude of this year’s changes will take some time to absorb, and some of them will probably take a year or two to be felt acutely within KPCC. That said, I thought it would be useful to offer a brief recap of some of the more notable technologies announced this year.
First, Some Background…
Apple’s platforms have a variety of ways in which to create user interfaces.
For the Mac, the venerable framework known as AppKit provides the basis for building most user interface controls, labels, etc. You create these either in code or visually, using Xcode’s Interface Builder tool, and interact with them using myriad APIs. AppKit is powerful, but very old — it originated with NeXTStep in 1989 — and, as such, has a fair bit of technical debt and assorted cruft associated with it.
When the iPhone (and, later, the iPad) came out, Apple provided a new UI framework known as UIKit. UIKit borrows a great deal from AppKit, but features a whole new set of APIs designed with touch interaction in mind. It also integrates nearly two decades’ worth of institutional learning at Apple as to how best to design a UI framework.
AppKit and UIKit do share a number of similarities, but the underlying APIs differ greatly, as do many basic assumptions of how one interacts with a user interface — even things as fundamental as how colors and screen coordinates are specified. Writing an app for the iPhone or iPad and porting it to the Mac, or vice-versa, essentially means throwing out all UI code and starting from scratch.
That is, needless to say, less than ideal.
SwiftUI
At this year’s WWDC, Apple announced a whole new UI framework called SwiftUI, intended to serve as a basis for all of their platforms (macOS, iOS, watchOS, and tvOS).
This conceivably allows developers to define interfaces using the same framework — and much of the same code — no matter what platform they target, with platform-specific affordances being provided by SwiftUI as needed.
SwiftUI is notable for being a declarative UI framework. Rather than building views piece-by-piece over a period of steps and modifying it in runtime, you simply define what the view looks like once, tying state to variables that are then changed (and can be changed) during runtime. This promises to greatly reduce the number of potential states — and, by association, bugs — in one’s UI code.
It also rids us of Auto-Layout, which for all its promise did little to alleviate the overall complexity and burden of view layout code.
There’s great Xcode support for SwiftUI, too. Replacing Interface Builder (!) is a live preview mode that allows you to lay out your views, Playgrounds-style, in real time. At a glance you can even view how they look in a variety of contexts (different device sizes, languages, accessibility modes, etc) without having to even compile your app.
To say that SwiftUI is an enormous development in the Apple developer community is an understatement, and there isn’t a single aspect of UI/UX that it doesn’t touch. It has dominated discussion within the developer community since its announcement.
We at KPCC are unlikely to adopt SwiftUI in the near future for our iOS development efforts, though, as it does require the as-yet unreleased iOS 13 to function (our audience will take a while to upgrade), and it’s still a bit rough around the edges. In a couple of years, though, I foresee most apps moving to SwiftUI. Thankfully, it can be adopted gradually on a view-by-view basis.
Catalyst (UIKit on Mac)
In the year leading up to this WWDC, much of the buzz was on Catalyst (then known by the codename Marzipan), an implementation of UIKit for the Mac. While there were only the faintest rumblings about what would become SwiftUI, Catalyst has been Apple’s worst kept secret for some time now.
Catalyst allows apps created for iOS to be recompiled for use on the Mac, theoretically doing away with a lot of the same duplication of effort resolved by SwiftUI.
Initial implementations of Catalyst-based apps that shipped with macOS Mojave were not well-received by the Apple commentariat, but the improvements since last year have been significant. Creating a truly “Mac-like” experience that users expect still requires a fair bit of extra work (including delving into AppKit from time to time), though, and many apps will require a major overhaul to fit in.
Catalyst is in the odd position of essentially being deprecated by SwiftUI on the day it was launched, however. Apple has strongly implied that it is a stopgap to bring existing iOS codebases to the Mac, whereas new apps should adopt SwiftUI instead.
Swift Package Manager
One of the worst aspects of iOS development, for me, has been dealing with dependencies.
I dislike dependencies, and seek to minimize them as much as possible. Not only are they a source of risk for any project (what if they stop being maintained, or a security vulnerability is introduced?), the prototypical tools for managing them in the Apple ecosystem strike me as kludgy and overly-complicated.
Enter Swift Package Manager, Apple’s project for managing package dependencies. It has been in open development for years now, but until now has mainly been adopted for Swift use outside of the Xcode toolchain (by projects like Vapor, for example). You couldn’t use them for iOS or Mac apps.
Starting this fall, Xcode 11’s Swift Package Manager integration will allow developers to specify package dependencies, control update policies, and keep everything coordinated. All in a nice, Apple-supported way.
I’ve made a concerted effort to modularize our iOS project over the past year, so this promises to alleviate the massive headache I incur every time I have to deal with dependencies. I can’t wait to adopt it.
SiriKit & Shortcuts Improvements
Of particular interest to those creating audio-focused apps, SiriKit gained support for Media Intents this year, empowering developers to integrate Siri into their apps. It is now possible, for example, to make it so that users can ask their device for a certain program and have it play an episode.
Along the same lines, the addition of parameters in Shortcuts allows for a much richer voice interaction model.
Sign In with Apple
Anyone who downloads apps often has surely seen the ubiquitous social login buttons (“Sign In with Facebook” and “Sign In with Google” buttons in particular) contained within.
These buttons offer users a Faustian bargain: Skip the somewhat tedious email sign-in flow and, in exchange, offer up one’s usage patterns and behaviors to one of a handful of major advertising companies to do who-knows-what with them.
Apple’s business model doesn’t depend on such surveillance, however, and as part of their ongoing privacy push they’ve created an alternative to these buttons for use on all their platforms, the web, and even rival platforms such as Android.
Sign In with Apple offers the same convenience as Facebook and Google’s buttons, but does no tracking and provides transparency to the user as to what is being sent to developers before it is sent. It also allows users a single-use email at an app-specific relay email address for use with login, preventing the formulation of cross-product user profiles.
What’s more, starting with iOS 13 Apple is requiring all apps with sign-in functionality using other services to also support Sign In with Apple. I expect privacy-conscious users to make use of it.
Grab Bag
The above announcements are by no means all there was to WWDC 2019. Any of the items below would have been a headlining announcement in any normal year:
- iPadOS: iOS on the iPad has been (in some sense) forked, and Apple is now referring to it as iPadOS. This seems to be more of a last-minute marketing maneuver than a technical one — many of the presenters hadn’t even updated their slides to refer to it, and near as I can tell there isn’t any more deviation from normal iOS than there usually is. This may portend major changes to come, but for now it seems to be a mostly artificial distinction.
- Dark Mode: Following on the heels of macOS’ adoption of dark mode last year, iOS now gets API level support as well. Many apps have already implemented this functionality — it’s a crowd favorite, especially for apps that have a reading experience — but having an official path for supporting it in place is welcome.
- Multiple Windows on iPad: One of the big things holding the iPad back as a general purpose computing platform has been the lack of windowing support. In iOS 13, Apple provides API support for app windowing and affordances for managing those windows.
- Combine: A competitor to RxSwift, Combine is a declarative framework for managing asynchronous events over time.
A Big Year
This was, by most accounts, the biggest WWDC in half a decade. The ramifications for how we build software on Apple platforms cannot be overstated, with SwiftUI in particular presenting both change and opportunity for faster iteration and reduced development time.
