SwiftUI and the UIStackView Problem

Or how Apple is making a major mistake with SwiftUI…

Michael Long
Jun 13 · 6 min read

I remember watching the introduction of UIStackView during WWDC 2015 and feeling myself get excited. I watched the Mysteries of Auto Layout sessions and got even more excited.

Finally, you could focus on writing code and creating interfaces without having to spend half your time wiring up AutoLayout constraints. It would even automatically manage showing and hiding views — with animations! You could finally have a computer do the things that computers are good at and let it manage my layouts for me!

Finally, you could…wait. What? Only supported in iOS 9?!

My hopes, so high, came crashing back to earth.

The iOS Developer’s Catch-22

If you’re a professional iOS developer, then you know the problem as well as I do. After all, it’s rare that an application can be written to only support the current version of iOS.

Not every customer will immediately upgrade to the latest and greatest version of iOS. And in fact, not every customer can upgrade to the latest and greatest version. Their phones simply aren’t supported.

It’s true, as mentioned during the keynote, that 85% of today’s base is on iOS 12. But the operative phrase in that sentence was “today’s base”. It didn’t happen immediately. It took time. Almost nine months, in fact.

So, if you’re lucky, your shop does “current minus one”, which means that you write your code to support the current version of iOS, minus one. In the case of UIStackView, that would have been iOS 9 and iOS 8.

Unfortunately, at the time we were doing “current minus two”, which meant that we had to support iOS 9, iOS 8, and iOS 7. Heck, we were still supporting iOS 6!

And that based on that metric it would be two whole long years before I could even think about using my cool new set of tools.

And you see where this is going, don’t you?

Introducing SwiftUI

At WWDC 19, Apple introduced SwiftUI and I’m sure that more than one developer’s jaw dropped open in shock and awe. At least, I know mine did.

To quote Apple, “SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift.”

SwiftUI uses a declarative syntax so you can simply state what your user interface should do.

SwiftUI was also said to save developers time by providing automatic interface layout, automatic support for Dark Mode, automatic support for Accessibility, automatic right-to-left language support and internationalization. Pretty much automatic everything.

SwiftUI even has native frameworks for Apple Watch, tvOS, and macOS apps, so the methodologies and even much of the code you write can be cross-platform.

And much, much more. I was drooling so badly that I had to run and grab a towel during Apple’s State of the Union presentation.

And then once again the fine print hit me. Supported in iOS 13.

UIStackView’ed once more.

The problem

I mean, I understand the problem. SwiftUI is heavily based on features only supported in the Swift 5.1 language and runtime. Domain-Specific-Languages, Opaque return types. Property wrappers.

It’s also heavily dependent on Combine, Apple’s new reactive framework that’s also only available on iOS 13.

Plus other new features added to iOS 13, like SF Symbols.

I mean, I understand the problem…

…which doesn’t mean that I like it. Or that I believe it should stand.

The competition

Apple has introduced a new paradigm for Swift developer’s on iOS. SwiftUI promises to take developers further and faster than ever before.

If only they could use those tools.

Worse is the fact that, in many ways, Apple is well and truly behind the eight ball on this one.

Many developers have dropped iOS-specific development in favor of cross-platform tools like React Native.

In the declarative framework world, Google announced Jetpack Compose, their own backwards-compatible framework for quickly creating and developing Android applications in Kotlin.

Others, including quite a few Android developers, have embraced Flutter,

Flutter is Google’s other declarative framework that lets developers create apps for both Android and iOS. Google is even promising support for desktop and web applications.

I’ve used Flutter, and while I think SwiftUI has eliminated many of Flutter’s warts and filed away the rough edges, the fact remains that I can use it today. I can write and support iOS 12 apps today.

Heck, Flutter supports iOS 8. That’s right. iOS 8. Today.

Pretty Woman

Remember the scene from the movie classic Pretty Woman, where the heroine is shown a box full of dazzling jewelry…and then, as she reaches for it, the box is snapped shut?

It feels like that.

Apple’s shown us a wonderful set of shiny new tools…and then snapped the box closed.

Backwards Compatibility

Look, I know supporting SwiftUI on iOS 12 might be difficult. That supporting iOS 11 might even be impossible. That there might be some things it might not be able to do or support.

Fine. I get it. But what’s the alternative?

Wait another year, or two, until enough developers can sunset their existing code and finally migrate to SwiftUI? Give Google yet another year to improve and consolidate Flutter and its growing cross-platform success story?

And in the process reinforce the idea that apparently only Google has the technological know-how and expertise required to support previous versions of iOS? On a platform not even their own?

Or hope in vain that some small subset of developers will decide to go for broke and completely trash all of their existing code and completely rewrite their current apps in SwiftUI?

All of this while giving the rest of Apple developers enough time to become depressed and disillusioned over all of the cool things they’ll be able to do… eventually?

Yes, I — personally — could probably begin writing a new app with SwiftUI today, with plans to ship it in the fall.

At work, however? My team probably won’t be able to even start using SwiftUI until late next year.

How about yours? In 2020? The year after that in 2021? Even later???

Completion Block

Given the above, I think that Apple should step up and figure out some way to let iOS developers into the promised land.

Create a way to let us use and integrate SwiftUI and Combine in our existing applications. To let us start writing new apps using those tools, while at the same time continuing to support the users who’ve yet to upgrade to the latest and greatest phones and operating systems.

During the keynote (and during almost every session), one phrase was repeated over and over, again and again. “And that’s [Combine | SwiftUI | Xcode 11]. We can’t wait to see what you do with it!”

Sadly, Apple may have to do just that: Wait.

Because even though SwiftUI has the potential to turbocharge developers, and give them power to create the apps of the future…

That’s exactly where many of those apps are destined to remain.

In the future.


What about you? Agree? Disagree? Can’t wait to use SwiftUI? Switching to Flutter?

I’d really like to know, so drop me a line in the comments below.

And in the meantime?

Hey, at least we can finally use UIStackViews…

Better Programming

Advice for programmers.

Michael Long

Written by

Michael Long (RxSwifty) is a Senior Lead iOS engineer at CRi Solutions, a leader in cutting edge iOS, Android, and mobile corporate and financial applications.

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade