The opportunity that SwiftUI presents for product builders
Over the last year or so I've taken a closer look at SwiftUI and I am really, really excited about it. If you love building products, you should be too. In this post I'll detail why this is so exciting, the work I've personally done already in SwiftUI, resources for learning and then the plans I have lined up.
Why is SwiftUI so exciting?
I'm a big fan of the Apple ecosystem. A long time ago I decided it was better to have a curated closed garden than an uncurated open one. The more control you have over how things get built, the better the output.
SwiftUI is the next step on Apple's quest to help developers build on their platform. Using a single codebase, you can build for iPhone, iPad, Mac, Watch and TV. This is unreal. The benefits of sharing large parts of core functionality between these platforms are huge. Not only will building multi-platform apps be quicker and easier, it will encourage developers to look at building these types of apps when they previously might not have considered it.
A great example of Apple doing this themselves is the Fitness+ app. It's on your phone, your TV and your watch. You open the app on the TV and it prompts you on your watch to log in. You select the workout, and during the workout you can see your health data (mainly heart rate) displayed in real time on the TV. When you're done, it's synced to your phone. The point is this is seamless between all the different platforms.
What makes SwiftUI even more exciting is that it is easy and quick to build apps. Once you've learned the basics (there are some great resources listed below) you can get productive in much less time that using Swift and UIKit (the previous option for developing apps). Some estimates put this time saving between 30% and 50% depending on what you are building. Again, this is unreal.
For someone who likes building products, this is the best news I've heard in a long time. I can build apps for five platforms, using a shared codebase, in 30% to 50% less time than before? Where do I sign up.
For everyone saying "but this is only for Apple, you exclude Android as a platform" - you're right. When doing an app in SwiftUI you are going native and you'd need another app for Android. We can have a long debate on native vs hybrid, but if you're going to build for an ecosystem, and you want to charge for it, Apple is where you should put your time and money.
The work I've done in SwiftUI
So far I've built a few apps as part of the courses I've taken, and then played around with new ideas for products. The main app I settled on was an app I have all the designs for and have already built in React Native - Fight A Bear. This is an app that allows you to create random, HIIT workouts and have you compete against yourself. It's currently backed by an API written in Go. I've written about the how and why of this app in Functional Fitness and Understanding the Human Body.
So why rewrite the app? The top reason is to learn SwiftUI - I think learning through project work is the best way to grasp a new skill or language. I also want to make a few changes: have all the workout generation happen on-device, have the workouts displayed in a better and more intuitive way, create a watch app that will also record your heart rate, have different versions of the workouts (timed and the current reps based), offer a desktop app to dive deeper into your workouts as well as to create new custom workouts, and to implement subscriptions.
I also want to move as much as I can away from having a backend at all. The current plan is to have a few serverless functions for sharing a workout and for notifying you of a friends workout. I'll probably do this using the serverless framework and Vue as a frontend (I'd recommend Vue Mastery if you're looking for resources on learning Vue). For more on my technical preference for building products read this.
Once I started work on the rewrite, the benefit of SwiftUI became really clear. I had every screen rebuilt (with dummy data) in 10 hours, including some improvements. I rewrote the workout generation logic, as well as created the new functionality of custom workouts, in 3 hours. I was able to add a great custom timer with animations in under 30 minutes. Flying.
There is still work to be done: moving the data into Core Data objects and having that synced to iCloud using CloudKit, the creation of accounts using Apple Sign In, subscriptions and a few pieces of other functionality. I'll then re-release on the app store and get to work on the Watch app and then the Mac app.
For perspective the iOS app should be done in another 8 hours, the Watch app in around 10 and the Mac app in another 10. This is an amazingly short timeline for building this type of product.
Resources for learning SwiftUI
I've found a few really good resources for learning SwiftUI, these are the ones I would strongly recommend:
DesignCode. Really detailed and easy to follow, great focus on design and making the apps look good. Also just released a mobile app and Mac app coming soon.
Hacking with Swift. An amazing repository of information on SwiftUI and Swift, as well as numerous books on all the platforms. This is where I am learning about Watch and Mac apps.
Blckbirds. Probably the most beneficial course for an end to end journey on SwiftUI development.
Plans for products using SwiftUI
The opportunity that SwiftUI provides has opened my mind up to the possibilities of what can be done, and at what cost (time and effort). Currently I have ideas around book reading and note taking, doing more with your health data (where is the Mac app for Fitness, Apple?!), getting new views on your finances (yay Open Banking) and creating apps as entry points for some API first products I am looking at.
In short, there is a lot I am keen to do with SwiftUI and Apple moving forward. If you are interested in building products for people, I'd strongly recommend taking some time and diving a bit deeper.