WWDC 2019 - SwiftUI
SwiftUI. When I heard the name I had very mixed feelings. It reminded me of the time I fought UI layouts in code. A horrible, dark time I do not want to remember. Back in the day I mad a happy dance for weeks when I discovered Borland C++ Builder and its interface tool. Transitioning to Mac OS and Xcode I missed it a bit and Interface Builder took a really long time before I considered it usable. So when Apple announced SwiftUI I was very sceptical. Playing around with it in the Xcode 11 beta I have to admit I could not have been more wrong. This might actually be a real game changer.
Let us first talk a little bit about application development in teams, specifically a client application for a server application. There are usually three large parts for an application like this:
- UI
- API integration
- business logic
We could surely break it down a little better, but let us just go with those three parts for now. Let us assume we are building an iOS application to fetch data from our server to display the latest news.
The API is pretty straight forward - fetch a JSON object, maybe pass a token in a header field to authenticate, handle some common errors,... pretty straight forward Swift you do not even need a third party library for anymore to make it simple and maintainable.
The business logic might be some transformation, maybe image resizing because the server team is lazy and does not want to do it or some random lookups and references to previously fetched data.
Now what happens when two engineers work on the same piece of code? Likely a merge conflict when bringing both changes into the master branch of the project. But it is also very likely that the conflicts can easily be resolved - in the end it is "just Swift", right?
But what happens when you have merge conflicts in your xib / nib? For those who never were in this situation: you are in a world of pain, undo the merge and go on a vacation hoping someone else took care of it when you come back. Maybe you consider switching jobs if this is not the case.
Xib files are basically XML. A lot of XML, even for very simple UIs. And it is nearly impossible to programatically resolve merge conflicts, you are forced into Xcode and Interface Builder to figure out which changes were made and how to resolve them. There are lots of neat work arounds, but in the end - it sucks.
Fast forward to SwiftUI. Just watch this video if you have not yet. It is a pretty good introduction with some nice examples of a lot of the features you will likely love.
The code is stupidly simple. It is Swift. They even built a list with UITableViewDelegates and UITableViewDataSource! This part alone makes me want to use an Xcode beta software all day long. Going a step further you can now inject test data and get a live preview. You read that right, a full preview of how your UI will look like with some data you can freely define. In Swift! And you can even do some sane positioning and layout changes without messing with constraints! And those two things were only the first 8 minutes.
Obviously not everything will be beautiful, nice and cozy. There will be a transition period, you will have to learn a new framework and I would take a bet that Xcode will break in 10 minute intervals after the release just for the sake of breaking. (Remember Swift v1 to v3 and code completion crashing?)
I took the time to create some test UI in Xcode and do some modifications in various branches. It is actually possible to see and resolve merge conflicts, but the more complex UIs and applications will get, the harder it will be. In the end writing a UI in code was never a pleasant or good idea, but it was a working solution.
Now I might make it sound like this is a totally new, unheard of concept, but it is not. Technically you can already maintain a UI in code. You could for decades. Technically. You do not really want to do this, especially when you have a team working on it. The chances that everyone is comfortable with it are pretty small. And to address one comment I know I will read: No, this does not speak to the quality of the engineers, not everyone thinks that using a steady hand and a magnetic needle is the right way to code, Mr. Elitist Snob.
SwiftUI might also make it feasible to develop a Swift application without Xcode. For all the AppCode or vim lovers this might be an actual game changer. And who knows, maybe Apple takes the chance and brings us Xcode for iOS next year. I would really appreciate that.
I am excited about Xcode 11 and SwiftUI, as excited as I was not in a very long time when it came to developing UIs and graphical applications. Let us see where this will lead us, but a unified way to write UIs across all platforms is surely welcome, appreciated and necessary if development for platforms other than iPhones and iPads should gain popularity.