Jan 3 2020 11:50 PM
Whenever Apple introduces a new technology for developers, there’s always the question: “Can I use this thing right now for my projects?”. The answer many times ends up being the good, old, and boring “it depends”, but more often than not it leans toward “probably better to wait for a few OS versions”.
With SwiftUI, it’s the same. While there are some brave developers using it to create production apps - especially on the Apple Watch - most developers seem to agree that it’s kind of like using Swift when it first came out.
I’ve been asked the question many times, and I tend to agree that going all-in on SwiftUI right now for an app you plan on publishing to the App Store is a little bit risky. The technology is very new, it has quite a few rough edges, and is bound to change significantly in the coming months/years.
But at the same time, just like I found it important for me to learn Swift when it was first introduced - even though my main projects were all still on Objective-C - I also find it important for every iOS developer to at least familiarize themselves with SwiftUI.
The question then is: given I don’t want to publish anything to my users that’s done with SwiftUI since I still have to support iOS 12 and I don’t want to risk getting something so new into production, how do I go about having enough experience with it to feel comfortable with the technology?
That type of comfort to me only comes when I create something “for real”. That’s how the unofficial WWDC app for macOS was born - it was an app I made to learn Swift. Following tutorials and making little test projects is great to learn the basics, but there’s a level of knowledge you can only get when you really get your hands dirty with the technology and start creating things with it.
I found a way to become comfortable with SwiftUI that I would like to share here since I think it might be useful to many developers. We often have our own internal tools that we built ourselves and use for different reasons. I have quite a few of them.
One example is the app that’s used to create content for ChibiStudio. It’s a Mac app that I and my illustrator use when creating the packs that are available and sold in the app. ChibiStudio also includes a “Learn” tab with content published by us, which is served as a static JSON file generated by another little app I made. I have another one that I use to test push notifications, one to generate JWT tokens for testing and quite a few others.
If you don’t have the habit of creating your own internal tools to make your job easier, I highly recommend it. They don’t have to be perfect, they just have to fulfill your own needs, and you should make them with no expectation that you’re ever going to make them available to anyone else.
So the trick I found for myself to get comfortable with SwiftUI was to start making all of my internal tools using the technology, instead of using AppKit or UIKit which I’m already familiar with. This not only makes me more comfortable with SwiftUI, but it also turns the task of developing and maintaining these tools more fun, since I’m learning while making them.
It’s also a completely safe way to do it since these tools are never meant to ship to “regular users”, so I can afford to have some weird UI glitches here and there and not have a perfectly designed app. Of course, nothing beats actually releasing something to real users in the App Store, but this is the closest I could get without actually doing it, and because I’m doing it, I feel like when the time comes to adopt SwiftUI for user-facing projects, I’m going to be ready for it.
So yes, you can, in fact, start using SwiftUI today.