Why You Can’t Use Async/Await
Or not. Apple listened to us, for once, and async/await, actors, and other structured concurrency features have been back-ported and are now available for iOS 13 and 14 and other earlier macOS and tvOS platforms.
For more read my latest article: Apple Listened: You No Longer Need To Wait For Async.
The following is relevant only for historical purposes.
With Actors and Async/Await, Apple has finally brought modern, asynchronous concurrency support to the Swift language. The syntax and concepts are powerful, clean, and elegant.
But Async/Await and Actors both suffer from a single, minor, almost insignificant issue… we can’t use them in our code.
I’ve written about this problem again and again in regard to SwiftUI, another one of the great new paradigms that Apple’s made available to developers. Or, at least, made available to some developers.
Let me explain.
The UIStackView problem
It was WWDC 2015, and I remember watching the introduction of
UIStackView and starting to 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?!
The iOS Developer’s Catch-22
If you’re a professional corporate or enterprise iOS developer, then you know the problem as well as I do. After all, it’s extremely 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