SwiftUI: Will It Be Ready With Only a Month to Go?
Is SwiftUI a risk and am I willing to bet my project on it?
And while there is excitement in the iOS/Swift community over what Apple is promising, it doesn’t necessarily mean everyone is going to take the plunge.
I doubt anyone is jumping to rewrite their production app in SwiftUI, unless that was already in the works. But, to me, there are two categories of developers that are currently asking the same question.
The first is the devs who already have a project underway and, depending on how far along and how distant or near the release date is, they’re wondering about starting a POC, at least.
The other category is devs starting from scratch who may also have a variable release timeframe, and, of course, want their app to start off on the latest and greatest.
The question they are both asking, however, is this: “is SwiftUI a risk and am I willing to bet my project on that?”
Let’s break it down then, shall we?
The benefits were immediately recognizable
Though I missed the live stream of WWDC, I imagine the reaction I had watching the recording was similar to most folk’s live reaction.
This was going to change native iOS (really Apple) UI building.
What was being shown were promises that things were changing, specifically for things that took the same monotonous steps over and over or just seemed overly complex for such small payouts in our code.
They were being reduced to mere lines, with built-in guides, and a slew of UI considerations for free (automatic styling guide parameters, automatic dark theme considerations, accessibility and localization features, etc.).
We could even begin to imagine how much time could be saved by natively writing our UI’s this way (Paul Hudson even demonstrates that in a great video comparison).
And even what I just said feels freeing: natively writing. No one can look at SwiftUI and not come up with some benefit, including the following points.
We love it because we’re so over IB/SB
Interface Builder had growing pains, being an early solution for a quickly evolving market.
Storyboards was the bridge between connecting the old way to realized needs in UI construction. Still, there was this weird gap between what needed to be done in GUI, in code, or coded into a field in the GUI.
And while auto-layout and constraints prepared us for years of growing (and morphing) screen sizes, they took a lot to master.
StackViews seemed to be a helpful tool (and that’s why they’re at the core of SwiftUI), but it was a retro-fit feature.
Now, a Single-View Application project set to SwiftUI doesn’t even come with
Main.Storyboard. It’s an official stand-alone UI solution. That, in itself, makes every SwiftUI project I start up feel modern.
Previews is everything (when it works)
If time equals money, then previews is the biggest value to developers that Xcode 11 provides. Changes almost immediately appear without the need to hit
Even better, I can preview subviews, too, meaning I don’t need to go through a workflow just to see and test out a deeply nested subview. We devs know, we hit
Run over and over again until we get it right.
Calculate the time saved. Take the average build/navigation time it takes to test out a view, currently, and multiply that by the average number of times you hit
Run in a day.
For real, give your best estimate and do the math. Go ahead, I’ll wait.
Swift Is now whole
There’s something special about being able to write your UI in Swift now. It’s truly like a marriage; your code and your UI are now one. That’s an extremely sappy way of looking at it, I’ll admit, but it’s a wonderful thing.
Yes, there are frameworks for Swift to be reactive. Yes, you could be a UIkit master and build your UI in code (though you’ll still need a storyboard).
But yet, they still could end up relying on native code/plugins when they hit a functionality limitation. It works, but it’s just not the same.
In case you haven’t figured it out by now, I really do like Swift. It’s an exciting language with a dedicated and fun community. SwiftUI feels like a gift, because now, when I’m building an app, I can stay in a Swift world from top to bottom.
The beta is buggy
It’s true. SwiftUI is pretty buggy. I’ve had errors for no good reason, errors show up lines away from where the error actually is, my UI becomes twisted and ugly only to be fixed on a re-run, and on and on.
And I’m not alone. Some folks would go so far as to call it an alpha.
It’s incredibly frustrating because it’s at a point where it takes away from some of the benefits. Granted, it’s a beta product. Even the past Xcode betas, they were incredibly buggy up until gold and then they somehow they managed to be magically fine.
But, this is not an IDE tool that I can also just work around as long as my code is fine. This is my code.
I’ve run across a number of deprecated items.
Modal are gone and replaced,
identified(by: ) was changed,
relativeSize is removed, and more.
I figured a few things would change over the betas, but some of these are how an entire feature is presented.
And it’s not always straight-forward that something has changed. Something as little as changing
TextField’s init wasn’t immediately obvious and was considered to be a “great catch” on the developer forums.
With the number of edits still being made, it makes you wonder if there’ll still be changes soon after the release.
This becomes doubly frustrating when you’re trying to actually learn or get support for SwiftUI. Already a number of tutorials and videos I’ve referred to are outdated.
Again, I know it’s a beta, but it really doesn’t make releasing an app with SwiftUI much sense anytime soon after it’s release.
It’s not the first
Those desiring to build UI’s through code have already had options for years now. As I mentioned before, they are add-ons and frameworks built on top of the native resources, but, to many, that’s still more than good enough.
It’s even worth having to fill in the gaps in native Swift and linking it to the framework of choice. So, in a sense, SwiftUI is up against experienced, mature, and already adopted competition.
And it’s still not cross-OS
This is an obvious point, but, in a time where we have pretty viable cross-OS options, it’s worth considering. Especially if your app really doesn’t have too many native or OS-specific dependencies and you’re wanting to hit both the iOS and Android markets.
People would love to see Swift become cross-OS properly, but even something like SwiftUI would most definitely still be Apple-specific.
If you’re looking to release on both platforms and don’t want to write two native apps — the answer really is that you don’t need to and that removes SwiftUI from the equation.
But this doesn’t take into consideration that SwiftUI is for more than phones and tablets. If we’re looking to write cross-platform apps in the Apple-sphere, it’s an entirely different story.
The Outlook Ahead — Ugly nor Pretty
State of apps in general
There’s speculation (even here on Medium) on whether “there’s an app for that” is a thing anymore. Do we really still need apps?
I can think of at least three immediate responses to that:
- Apps looking to take advantage of hardware optimizations (ARKit and Core ML anyone?).
- Apps looking beyond just the iPhone (iPadOS being a killer reason).
- Apps that want to have pretty awesome UX beyond what a mobile site can offer.
So in essence, apps are nowhere near extinction. If anything, trending platforms and hardware capabilities will really dictate the trajectory and scale of apps moving forward.
Decoding iPhone sales
It’s no secret Apple did not get the response they hoped for last year with the XS’s and XR. And their sales have definitely suffered a bit.
This doesn’t necessarily mean people are leaving iOS though. It just means that, now that Apple has set the financial bar high, adoption of newer devices is going to be more carefully thought-about by the average consumer.
Most people around me in the past year have asked how they can get a cheap iPhone 7 or 8 because they just can’t afford to take the plunge. They have no need for Portrait mode, Face ID, OLED screens, or even ML optimized hardware (especially because they don’t even know what that means).
They need an iPhone, any iPhone. Why? Because they’re used to it, like Apple, and/or have average needs.
Over-generalization, I get it. But these are true comments from folks around me. Personally, my wife and I got XR’s after squeezing the life out of our 6's.
What Should You Do?
All things considered, every project is unique (or a clone of a unique app) just as every developer is (unique, not the clone part).
Would I be developing an app using SwiftUI for release in 2019? It depends, really, on complexity and how willing I have to be to maintain that app.
What we’re really addressing here is whether or not to be an early adopter. It’s a 21st-century conundrum. And, as with anything, being an early adopter of something carries risk (Galaxy Fold? Too soon?).
For me, personally, I’m just excited about SwiftUI and want to eat it all up. I’m content just learning for the moment and seeing where it all heads, but with the intent on using it for a future release.
As for my section header question, it’s not one I can answer for you. It’s more for you to ponder.
As a matter of fact, I would love to hear feedback from you, the community! Are you taking the plunge? If not next month, then soon after? Or have you already looked elsewhere?