Thoughts on SwiftUI
Cocoa, Mac, SwiftUI, iOS
0 comments
Like everyone, I was shocked by Apple’s surprise reveal of SwiftUI at WWDC last week. We’ve heard rumors of some kind of declarative, multi-platform framework coming sometime in the future, but I don’t think anyone expected we’d see it so soon. This seems like a huge change, a beginning of a completely new chapter for app developers on Apple platforms. I’ve watched most of the session videos about SwiftUI and I’m incredibly excited and eager to start using it in practice.
Here are some first impressions and thoughts about SwiftUI after reading about it and playing with it for a few days:
Difficulty:
Prepare to feel like you’ve just started learning Mac/iOS programming… This is a completely new thing which works in a completely new way, and it’s hard to switch your brain to a new mode. You will be thinking “How the hell do I do X” every step of the way. And it’s ok, because even ignoring the paradigm change, this is just a completely new API, we don’t know the names of all the classes and methods by heart and it will take time before we’re somewhat familiar with them.
We’ll need to figure this thing out together - over the next months there will be thousands of blog posts, tutorials, books, screencasts and conference talks. People sharing tips, techniques and best practices. This will make it much easier to learn how to use these new APIs and how to do it well. (Some crazy people have already started last week!)
Things I’ve had the most trouble with so far:
- layout, whenever it goes beyond the simple horizontal or vertical flow - how to put this thing in that place or make sure it has such size - things that would be trivial with AutoLayout, here I often don’t even know where to start
- bindings - which kind of property to use and how, where to use the ‘$’, how to make sure the UI gets notified of a given change (or even how to get the thing to compile at all)
- arrangement of modifiers - in what order I should put them if I want to apply several different effects
Project state:
This is definitely a beta thing at the moment. Some things just don’t work yet, the compiler is often extremely unhelpful, showing very cryptic error messages or showing them in a wrong place, and the reference documentation is incomplete. Autocomplete only works about half of the time. This will hopefully get better by September, although I suspect it won’t be completely perfect by then.
Also not every feature from the native frameworks that we might need is exposed in the new API, and that’s kind of by design - that’s why we have NSViewRepresentable and UIViewRepresentable. Hopefully more and more shared and platform-specific things will get added in future versions (and hopefully we won’t have to wait until June 2020 to see anything new).
Potential:
We’ll only know for sure once we start using SwiftUI in real, full size apps, but judging by what we’ve heard so far, the potential for saving us work, speeding up development and eliminating bugs is huge. I can’t wait to see how much faster I will be able to build things once I get up to speed, and how much less boring boilerplate code will I need to write. This should also make it much easier for people new to Apple’s platforms, or programming in general, to learn how to build apps. I can already imagine workshop events a la Rails Girls that get people from zero to a working app in the space of one day or a weekend.
Migration plan:
I’m not working on any client projects at the moment, so I’m actually in the comfortable position that I can consider moving most of my projects to SwiftUI in near future. I have the iOS version of Banner Hunter to write, which I’m terribly procrastinating on, and this seems like a perfect thing to try out building a full SwiftUI app on - it’s going to be a new app, so there’s no old UI code to migrate and existing users to support. And this will be a very simple UI, mostly a walkthrough and a status screen. This might actually help me get around to doing this much sooner.
The story is different on the Mac side, because Mac users update their devices much slower - it’s fairly normal to be running macOS two major versions back. So I probably won’t be touching the Mac version’s UI for now (and there’s nothing new to add there anyway).
I also have the old Repertuary.pl app for Polish cinema listings that I’ve built 9 years ago. There are still parts of it written in ObjC, my custom framework I’ve abandoned long ago, and even ASIHTTPRequest… and I’m really tempted to rewrite and rebuild it with SwiftUI. It’s making very little money and doesn’t even have a potential to make more, because it has a limited target market by design, but because I’ve never really treated it seriously, it has been a kind of playground for me many times to try out new APIs. So it could serve that role again - even if just as a learning experience.
Finally, I still have that ongoing watchOS experiment, where I didn’t really get to the part of building the app UI with WatchKit yet. And I’m kind of considering still building it once with old WatchKit, and then again with SwiftUI to have a comparison of how these two approaches work in practice.
The future:
I know a lot of people (including me) were worried that this WWDC, with the long expected public launch of the Marzipan framework aka Catalyst, would be a kind of death sentence for AppKit and “real” native Mac apps - that UIKit, the framework which was initially designed only for iOS, only for devices with touch screens and no keyboards or mice, would be branded as the future of app development for macOS and all Apple platforms. And that since the Mac has a completely different model of interaction, this would make the Mac worse by forcing it to adopt UIs that wouldn’t work well there - that we’d get another Windows 8.
What happened last week has completely changed the game. Turns out, the future is not an 11-year-old framework designed for touchscreen devices - it’s a brand new framework designed for all kinds of devices (even the ones we haven’t seen yet). A framework that acknowledges and emphasizes each platform’s uniqueness, what things work well and not well on each, what kind of UI and interaction works best for each. Instead of trying to make one UI work on all platforms, it creates different, customized UIs for each platform from similar code (check out the Picker example from the talk).
But as it was said in the “SwiftUI On All Devices” talk, it’s not “Write once, run anywhere”, it’s “Learn once, apply anywhere”. Each app version should be looked at separately to make sure the design is just right on each platform - but SwiftUI will make that much, much easier than before, because it will be mostly the same code, just arranged in different ways. (This talk should be a required watching if you’re building apps for more than one Apple platform.)
AppKit and Mac apps:
Long term, I imagine the way it’s going to work is that SwiftUI (and possibly some related new frameworks) will gradually take over more and more parts of the underlying platform UI frameworks, to the point where they eventually just disappear. We’ll be writing a single codebase with SwiftUI and it will render differently on each platform, with some customizations required for each platform, but it’s possible that we’ll need less and less of those going forward, as the framework will get smarter.
In the meantime, I wouldn’t be surprised if this change actually makes people more interested in building AppKit apps - meaning apps that render AppKit controls, as opposed to Catalyst apps rendering UIKit controls; apps that are written mostly in SwiftUI with some AppKit additions for things that are missing, and that feel more native on average than UIKit apps will.
AppKit had this reputation in recent years of something very hard to learn even for an experienced iOS developer, and that was partly because of its age, but partly just due to the complete lack of up to date learning materials. Once the Mac/iOS developer community gets familiar with SwiftUI and builds some knowledge base around it, it should be much easier to switch between platforms, because you will use the same SwiftUI building blocks on each for the most part.
So hopefully in the end this will all mean more Mac apps, and Mac apps that don’t feel out of place on macOS and don’t try to change it into something it’s not. If so, I’m definitely looking forward to that.