Apple’s press release announcing the company’s annual developer conference featured an illustration of a robot head (🤖) bursting with code symbols, emoji, and Apple iconography.

All last week, attendees saw this motif in slides and signage throughout McEnery Convention Center, with variations featuring heads of monkeys (🐵), aliens (👽), skulls (💀), and other Animoji characters.

Looking back, it’s obvious now that the #WWDC19 graphics, with their neon sign motif, were a cheeky hint at the (then rumored) Dark Mode announced in iOS 13. Though we must admit the nod to SF Symbols and the new UIImage(system Name:) APIs (arguably the real dark horse of the conference) completely went over our heads.

Beyond presenting a compelling case for several 🤯-based additions to Unicode’s recommended emoji ZWJ sequences, these banners reinforced a central theme of the conference: “Write code. Blow minds.” Apple’s slogan was accurate but ambiguous; it wasn’t us that was writing code, but Apple. We were the ones getting our #mindsblown .

The problem with having your mind blown is that you can’t think straight.

Now that we’re safely removed from the Reality Distortion Field™ (some of us recovering from #dubdubflu 🤒, perhaps), let’s take a moment to process the announcements from last week as a whole, and consider what they mean for next week, next month, next year, and the years to come.

SwiftUI, Swift, and Open Source

SwiftUI is the most exciting announcement from Apple since unveiling the Swift language itself five years prior.

That said, for a language being developed in the open with a rigorous process for vetting proposed changes, many of us in the community thought Swift was immune from surprise announcements at WWDC. For better or for worse, we were wrong.

At the Platforms State of the Union, few of us in the audience recognized the SwiftUI code. It looked like the Swift we know and love, but it had a bunch of new adornments and seemed to play fast and loose with our understanding of syntax rules.

import Swift UI struct Content : View { @State var model = … var body : some View { … } }

Even if you ardently followed the Swift Forums and knew about the proposals for property wrappers, implicit returns for single-line expressions, and opaque result types… you still might struggle to make sense of everything you saw.

Apple’s language

The SwiftUI announcement serves a reminder that Swift is Apple’s language.

Fortunately, this arrangement has worked out pretty well so far — thanks in large part to good faith efforts from Apple engineers to communicate openly and take their responsibility as stewards of the language seriously. Case in point: within hours of the Keynote, Swift’s project leader, Ted Kremenek, posted a message outlining the situation, and proposals for the new features were submitted for review the same day (though one might wonder what that means in practice). Also, to their credit, the rest of the Core Team has done an outstanding job communicating with attendees at labs and answering questions on social media.

What happened at WWDC this year underscores a central tension between open community-driven contributions and the closed product-driven development within Apple. There’s already an active discussion about how this dynamic can and should play out for SwiftUI and Combine.

Ultimately, it’s up to Apple to decide whether these technologies will be incorporated into the Swift open source project. However, I’m optimistic that they’ll make the right choice in due course.

SwiftUI, Catalyst, and the Long-Term Viability of Apple Platforms

I don’t think it’s an exaggeration to say that Apple’s announcements of Catalyst and SwiftUI this year saved macOS from becoming obsolete as a platform.

With AppKit’s increasing irrelevance in the era of UIKit, few businesses have been able to justify investment into native macOS apps. As a result, the macOS ecosystem has languished, becoming a shadow of its glory days of the delicious generation.

At WWDC, Apple laid out a clear path forward for developers:

If you’re working on an existing iOS app , focus on making the most of the new features on iOS 13, like Dark Mode support and Sign In with Apple ID.

, focus on making the most of the new features on iOS 13, like Dark Mode support and Sign In with Apple ID. If you have an iPad app , consider adding support for macOS Catalina by way of Catalyst.

, consider adding support for macOS Catalina by way of Catalyst. If you’re creating your n+1 th app , weigh the potential benefit of adopting SwiftUI against the costs and risks associated with developing with new technologies (this calculation will change over time).

, weigh the potential benefit of adopting SwiftUI against the costs and risks associated with developing with new technologies (this calculation will change over time). If you’re looking to break into app development, or want to experiment, start a new Xcode project, check the box next to SwiftUI, and have a blast! There’s never been a better time to try everything out.

That’s essentially the decision tree Apple would have us follow.

As others have eloquently opined, SwiftUI marks an important transition for Apple as a company from the NeXT era to the Swift era. By way of historical analogy:

Swift is the new Objective-C



SwiftUI is the new Cocoa



Catalyst is the new Carbon



However, something’s missing from this narrative of how we got from Macintosh OS to Mac OS X.

What about Java(Script)?

Everyone knows Java was deprecated in Mac OS X 10.4.

What this section presupposes is… maybe it didn’t?

The transition from C to Objective-C may seem inevitable today, but at the time, there was a real possibility that Objective-C would be replaced by a more popular language — namely, Java.

The situation in 2019 bears a striking resemblance to what happened in 1999.

With web technologies only becoming more capable and convenient over time, can you really blame them for going with a “hybrid solution” — especially one that promises to target every platform with a single code base?

We must remember that the purpose of software is to solve problems. Consumers only care about which technologies we decide to use insofar as it provides a better solution, more quickly, at a lower price.

Yes, there are plenty of examples of cross-platform or web-based technologies that look and feel janky and out of place on the Mac or an iPhone. But there are plenty of instances where the results are good (or at least “good enough”).

Don’t let perfect be the enemy of good.

Or, put another way:

1 GB of RAM for an Electron app isn’t great, but it’s still better than the 0 GB of RAM for a native app that never ships.

With Apple’s endorsement of declarative programming with SwiftUI, now’s a great time to see how other communities are solving similar problems. For starters, check out React, Elm, Flutter, Android Jetpack Compose, and (our personal favorite) Shoes.rb.

Thinking outside the App Store

On the heels of Catalyst’s official debut, Twitter announced plans to port its iPad app to the Mac.

Apple’s exciting new technology empowers Twitter to easily bring our entire 1.5 million line code base from iOS to the Mac, allowing ongoing full feature parity with our iPad app, and enhanced with the macOS experience that will make Twitter feel right at home on your Mac. @TwitterSupport

In fact, you don’t need to wait for macOS Catalina — you can experience Twitter as a native desktop app today! The latest version of Chrome lets you install progressive web apps (PWAs), like Twitter, as native desktop apps.

Go ahead and try it for yourself: open https://twitter.com/ in Chrome, click the ⠇ icon on the far right side of your address bar and select “Install Twitter”.

Android has a similar feature that generates and installs a native app from a web app manifest — all without ever leaving the browser. Meanwhile, the Google Play Store has started to become more browser-like itself; with instant apps and games, that can be launched immediately, without installing the full payload.

And lest you think this is just a Google thing, Apple has also (quietly) improved its own support of PWAs over the years. iOS 12.2, in particular, was a huge step forward, addressing some of the most pressing shortcomings on the platform. And the first iOS 13 beta promises to be even better for PWAs (though you’d never know it based on this year’s conference sessions).

We’re not quite there yet, but with forthcoming support for Web App Manifest in WebKit, we’re getting really close.

When the iPhone first debuted in 2007, the intent was for 3rd-party developers to distribute software through web apps. The strong distinction between native and web apps is a product of history, not an immutable truth about software. When you think about the future of “apps”, you have to wonder if this distinction will still make sense in 5 or 10 years. Aside from ubiquitous high-speed wireless internet, there’s nothing particularly futuristic about downloading a 50MB payload from the App Store.

I think Apple has a real chance at checking JavaScript hegemony with Swift and SwiftUI. Imagine a version of SwiftUI that could — in addition to targeting AppKit and UIKit — render HTML to web clients. Take the very proposal for function builders itself, which is at the heart of SwiftUI’s DSL: div { if use Chapter Titles { h1 ( "1. Loomings." ) } p { "Call me Ishmael. Some years ago" } p { "There is now your insular city" } } On its own, as a DSL for writing HTML (say, as a replacement for Stencil or Leaf)… that’s not particularly compelling. But what if there was a web framework that could automatically generate and serve Web Assembly to be executed on the client and manage data flow transparently via XHR, web sockets, or WebRTC? Something like Phoenix channels or Meteor, perhaps? If someone built that, I think you’d have a solid case for Swift on the Server.

Apple, Politics, and the Global Economy

Apple’s transition from the NeXT era to the Swift era goes beyond technical changes within the company.

The day after delivering the WWDC Keynote, Tim Cook sat down for an interview with CBS News, in which he defended Apple against allegations of monopolistic behavior. A month prior, the U.S. Supreme Court issued a decision in Apple Inc. v. Pepper affirming that consumers were “direct purchasers” of apps from the App Store, and could sue Apple for antitrust practices. All of this at a time when there’s growing political momentum in the U.S. to break up big tech companies like Google, Amazon, Facebook, and Apple.

In case you were wondering what prompted developer feedback email you got from Apple or that “App Store Principles and Practices” thing they posted ahead of the conference…

Meanwhile, slowing iPhone sales in the U.S. and Europe, difficulty entering emerging markets in China and India, and the threat of a prolonged U.S. / China trade war loom large over Apple’s future.

For the past decade, the App Store has shielded many of us from the complexities of doing business with the promise of being able to build an app and carve out a livelihood. To the extent that this was ever true, we may soon have to confront some deeply held assumptions about our industry.

This is all to say that there’s a big world outside the Apple ecosystem.

I don’t doubt that SwiftUI is the future of macOS and iOS development. I’m thrilled that Apple is embracing a declarative UI paradigm on its platforms, and couldn’t be more excited for functional reactive ideas to spread to millions of new developers as a result.

I just worry that fixating on SwiftUI will come at the expense of solving more important problems.

Mind the Enthusiasm Gap

At the time of writing, SwiftUI has been public for what… like a week? And yet, if you haven’t spent every waking hour playing with SwiftUI, you might have the impression that you’re already too late.

Before you drop everything to catch up on session videos or start to feel bad for “falling behind,” remember that we’ve been here before.

The Swift programming language took a long time to become viable for app development. Years. Today, Swift 5 is barely recognizable from what we first saw in 2014.

All of those developers who rushed to learn it when it first came out (myself included) how many of us look back on all of that code churn fondly? How many teams would have been better off holding onto their Objective-C code bases for a few more years instead of deciding to rewrite everything from scratch at the first chance?

By all means, try out Xcode 11 on the latest macOS Catalina beta to appreciate the full extent of its live canvas. It’s insanely great!

But don’t feel beholden to it. Don’t upend your work for the sake of staying ahead of the curve. There are plenty of other things that you can focus on now that will have a more immediate impact on your users and your own career.

Silver Bullets and Universal Truths

SwiftUI solves some of the most visible problems facing Apple platforms, but they aren’t the most important or the most difficult ones — not by a long shot.

Taking care of yourself — sleeping enough, eating right, exercising regularly — will do more to improve your productivity than any language or framework out there. Your ability to communicate and collaborate with others will always be a better predictor of success than your choice of technology stack. Your relationships with others are the most significant factors of success and happiness in life.

Apple’s annual release cycle affords us all an opportunity each June to reflect on how far we’ve come and where we want to go from here — both individually and as a community.

Don’t be afraid to think different.