Context: I’ve been working with iOS full time since a few years before Swift came out.
A few startups ago we built our app using SwiftUI 1.0. At that time, while 90% of it was fantastic, 10% was either unworkable or extremely unreliable, causing for some maddening bugs. The documentation was laughable so for these reasons I chose to do the app for a subsequent startup in UIKit.
Fast forward to my most recent company; decided to give SwiftUI another shot (targeting iOS 14 & SwiftUI 2). I am 100% glad we did. It’s been pretty incredible; we’ve built a reasonably complex banking app at a pace not possible with UIKit. The animations in particular are crazy good to work with; we’ve got some very complex animated flows that would have taken weeks and thousands of lines with UIKit… with SwiftUI it was about 5 days.
It’s definitely not without its downsides; documentation is still slim at best, but there’s plenty of blogs and resources (https://swiftui-lab.com/ is the most helpful IMO) available now. There are also still some maddening bugs that appear in production and take a day or two of head scratching only to discover it’s a bug in the framework (most recently; using #available causes code to crash on the platform it’s protecting against lol), but there are always workarounds. Still, time wasted on these has been vastly outweighed by the weeks / months of time saved.
Finally, you can always use UIKit as an escape hatch through UIViewRepresentable.
iOS 15 is at 85% adoption, so we plan to drop support for 14 somewhat soon, which will give us an even more robust framework as well as async await APIs. Not feasible for most companies I know, but even supporting 14+ Will be pretty reasonable when iOS 16 drops in September.
Do you mind explaining exactly what animations would take that much work? I’m struggling to see how animations could ever take as long as estimated for UIKit
Here's a part of the flow I'm talking about; for context it's a debit card that rewards users with stock as they use it. The entire flow is SwiftUI (though the top of the pack ripping is PNG sequences so we did cheat a bit).
The parent said “animated flows” and mentioned a banking app, so I’m betting a multi-page form with lots of transitions between a lot of different state combinations.
Again, just guessing, but I would imagine that it’s managing that state and animating it in a sane way which requires LOTS of code, less so the animations themselves.
I'm targeting iOS 14+ for most projects and planning to drop when iOS 16 drops as well. Thankfully async/await was back-ported to iOS 13 (can't live without it!)
You could write an opposite article featuring people using SwiftUI that have never touched UIKit or iOS code before and it would be nothing but glowing praise.
That's kinda like my story. Covid started and I wanted to learn something new so I started with Swift/SwiftUI. 2 years later I've been doing tons of crazy custom stuff in my portfolio tracker app https://stocketa.com (not launched yet) - I kept a thread with my progress since the first day I started my journey: https://twitter.com/Stammy/status/1527288954935922688 (scroll up).
> You could write an opposite article featuring people using SwiftUI that have never touched UIKit or iOS code before and it would be nothing but glowing praise.
How can one properly evaluate it with no point of comparison?
If you've never tasted chocolate, then vanilla might seem like the greatest flavor ever.
The point of comparison is that it has given people the ability to develop their own iOS apps from scratch, when previously they could not as UIKit was too daunting and the tools were not as advanced (live preview with swiftui/etc).
It's quite a bit different experience working on an app by yourself and working on an app that has several hundred thousand lines of code that 10+ people are working on simultaneously. I've worked with a bunch of people that are complaining in this and the problems you face are quite a bit different.
I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit.
A couple of reasons:
1) The documentation for SwiftUI, when I started (about two years ago) was awful. I was shocked at how bad it was. I believe that it has since improved.
2) I knew of no major apps (even Apple ones) that had been done with it.
I already knew that UIKit was up to the task, and held my nose, while I set things up. It's working out extremely well, but (of course) I'd like to rewrite the whole thing (a sure sign that I'm approaching ship).
I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I'm able to release fairly basic Apple apps in UIKit, in just hours, so speed of development isn't compelling.
What is compelling, is the ability to design a reactive system for a complex app (like the one I'm writing now). AppKit has allowed this for some time, and it's possible to force UIKit to do it (but it isn't really designed for that).
I really wish that SwiftUI had been a bit more mature, when I started this system, but I would have also needed to rewrite the two server SDKs I use, anyway. It wouldn't have worked, no matter how hard I bang my heels together.
But I'm looking forward to it.
One thing that I've learned, is that it's really OK to wait for things to mature. Companies always screech about how we need to jump on the bandwagon, but that's all hype. I have taken OpenDoc courses at Apple DU. I also busted my ass, getting my app ready for Copland. I have scars from Apple hype.
I did take a big chance, by jumping directly into Swift, but that has turned out to be a good decision.
I’ve been dabbling in SwiftUI in an existing UIKit app from time to time for a while now and have similar feelings. Even if you get past the lack of docs, SwiftUI is missing just enough bits and pieces to make it a pain. I can usually get things about 90% to where they’re supposed to be, and then I rewrite it in UIKit because that’s the only way to get the fine details right without convoluted hackery. Lack of backwards compatibility doesn’t help here — several times something I’ve needed has only been available for iOS 14/15+.
I think it has massive potential regardless, but yes it’s going to need some time to fully bake (much as UIKit did).
It’s too bad that Cocoa Bindings never found their way from AppKit into UIKit. I understand their exclusion was likely due to CPU power limitations early on, but that hasn’t been a problem for many years at this point.
Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them.
I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfortune to work in.
> better off cutting with the grain of the underlying platform's abstractions
That's a great little turn-of-phrase that I plan on stealing in the future. Apple's APIs will absolutely reward you for taking the time to step back, figure out how Apple wants you to use them, and try your hardest to use them in that way.
An example from the olden days of iOS development: many of the apps I worked on went out of their way to avoid subclassing UIView, filling their view controllers with layout and interface updates that would have made much more sense in a view. If only they had read all the docs for UIView would they know that doing something like subclassing a button and tweaking a few methods would have done exactly what they wanted with a minimal amount of work.
i've been developping for 20 years, and 10 years on iOS as a freelance.
I've seen all the horrors, and i can now safely claim that all the problems i've seen on iOS development come from not designing the model layer properly in their MVC app. Because most developers start by coding UIs and later end up wondering where to put that business logic and make it reusable.
And now every time i see another pattern that claim to facilitate refreshing the UI upon model change ( and vice versa), i know it's going to be a failure.
I apologize to the people who bought into this pattern but what was anyone thinking? Just reading through how it was supposed to be done set off so many red flags I never even considered it. There is so much useless abstraction it makes no sense.
UIKit isnt even deeply MVC. Its purely C. The Controller is the god object by design, but also because the first 10 years of iOS tutorials never took the time to even split out a single View. So that became the gateway for everyone learning the platform, and is what they imitated.
Its not much better today overall, but is usually not an issue within companies themselves.
> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the platform differs, and yes you are not going to avoid the UIViewController when doing it on iOS. But you are still doing MVVM even if your V is actually a UIViewController.
I use MVVM almost exclusively now, and I usually do it in a cross-platform framework (Xamarin/MAUI). The codebase is portable across both iOS and Android with no re-architecting of the high-level architecture pattern.
I liked the "cut with the grain" comment, someone made earlier.
The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers.
It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless.
I use the Storyboard Editor a lot. It is not my favorite editor, but it allows me to work incredibly quickly, and to make a really reflowable UI.
I know that the app I'm working on now, is larger than any I've seen from SwiftUI (around 40 screens, and communicating with three servers in realtime, using a couple of SDKs). I am able to make it all work.
I feel as if MVVM would make the parts of the app that link the UI to the servers a lot more graceful (it's a nasty state engine, right now -ick). I feel as if this kind of app is the kind of thing they had in mind, with SwiftUI.
I do know that it's really important to derive subclasses, and extend ObjC classes, when using UIKit/AppKit/WatchKit, and I feel sorry for folks that avoid inheritance like the plague. It must be a fair bit of work. Looks like SwiftUI doesn't really need that at all, but I haven't spent enough time with it, yet, to know for sure.
I have no doubt that I'll end up mastering it. I'm a quick study. I've spent 35 years, surfing the tech wave.
> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I agree with everything you've said but this. I've worked on 3 very large app, one which is 85% using mvvm, the two others were still in experimentation phases with it and I am not sure where they've ended up. It's been a joy. The app is designed in a very reactive way and the data flow paths are very clearly defined and easy to follow.
Don't get me wrong the other two apps were heavily MVC with a lot of delegation and that was fine. I could easily switch back to an architecture like that but it's very possible and quite easy to switch over to an mvvm pattern.
I have heard many state that. It has not been my experience.
It may be because I want a "pure" MVVM, and it has to be sort of "impure" to work with UIKit apps. In that case, it just adds more code. I'm a "the best code I write, is the code I don't write" kind of guy.
I think that most of the smaller Apple apps are now SwiftUI (and Catalyst).
But the app I'm writing is a good deal more complex than most of the utility apps, and I seriously doubt that the complex apps are SwiftUI. I would not be surprised if many of them are still ObjC.
SwiftUI has been a game changer for me as a solo dev. Sure - you have to make tradeoffs like backwards compatibility, and some strange things are missing/don't work. But - it's been a force multiplier. You can break apart complex views into components by copy/pasting its body into a new `View` struct. It's so much simpler than ripping apart a storyboard into a XIB or fighting with layout constraints. The simplicity lets you try things and fail fast without too much of an investment in design complexity.
I find that I can deliver features and iterate much faster and that makes up for the time I spend fixing edge case bugs or bridging to UIKit when I need an unsupported feature.
Another solo dev, and I can second your sentiment.
I would like to add that I found SwiftUI to be extremely robust against developer mistakes. Things either work, or they give error messages. It's rare that a view is subtly broken.
I hear you, even though I've chosen to just deal with fighting the layout constraints. For what it's worth, I just use a zillion nested UIStackViews when I'm in "try things and fail fast" mode and it tends to work okay for just seeing if the overall thing works like I want. Then I go back and do more precise design work fiddling with spacing, alignment, compression pressure, etc.
My team has two green field apps that we started a few weeks ago. The leads on the iOS team and Android team both spent a week evaluating the new UI systems in each platform, SwiftUI and Jetpack Compose.
The conclusion was that Apple made a huge mistake tying it the iOS version and effectively limiting updates and it's real world use for years at a time.
Both leads liked the design paradigms, but we are only going to use Jetpack Compose since it's made of multiple libraries that are all backwards compatible with our minimum supported version. iOS will stick to UIKit since it works and is backwards compatible
> The conclusion was that Apple made a huge mistake tying it the iOS version and effectively limiting updates and it's real world use for years at a time.
Exactly this. SwiftUI on iOS 13.x is practically unusable for anything above simple implementations, with some fairly major bugs that weren't fixed until iOS 14-15. Bugs aside, the lack of StateObject in SwiftUI (iOS) 13.x makes it a non-starter.
Yeah iOS is one thing as you can generally wait it out as Apple is pretty aggressive about upgrades there but on macOS I think this limitation has really killed it's viability, people just don't update their desktop OS.
Not to mention that Apple just orphaned a shitload of perfectly viable computers (first-gen Retina iMacs, for example).
I was also baffled to find that TestFlight can't be installed on pre-Monterey Macs. I mean... WTF? That makes no sense. Sure, we can pass DMGs around, but my company is new to Macs and standardizing our QA team on TestFlight on all devices would've been simple.
[Edit: Everyone read ChrisMarshallNY's comment, it's a less terse and more eloquent version of this :)]
My humble belief is that once one understands the inner workings of UIKit, Swift UI is about half of the interactivity of UIKit (read interactivity not as animations or formatting, but actual user controls and inferences from intended actions).
I had requirements to fully understand UITextView, then TextKit and NSLayout, then new ways to interact with text that I have no earthly idea how I would build my interactions in SwiftUI.
In SwiftUI, you get a lot of bang for your buck, but if you want to build something truly remarkable, you need to get your hands dirty and codify your opinions with UIKit.
> “Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?” Adam Kaump
I've been working on an app that's mostly SwiftUI for about a year now. It feels magical when it works, but I don't think I've saved time vs. using UIKit at this point due to all of the workarounds that I've needed to find.
Particularly, SwiftUI List views are still loosely supported, and in some cases broken. Unfortunately for devs, lists are the cornerstone of many apps.
For example, it's very difficult to get the content offset of list. You cannot put multiple buttons in a list row without breaking their tap targets. You can't change the background color of a grouped list without changing it globally (and it's very difficult to customize many SwiftUI components, like the navigation bar). It's difficult to control the spacing between sections in grouped lists. I could go on.
Developers are stuck in a hard place right now. If you're starting an iOS app today, do you go with UIKit (and accept that your code will soon be considered legacy by Apple and many engineers?) Or do you go with SwiftUI, and accept that many things will be broken or impossible to make right?
IMO SwiftUI feels limited b.c. it breaks itself away from the UIKit world: React succeeded because it is the DOM with all of raw HTML & CSS, a thin abstraction with official escape hatches. Mixing imperative and declarative code is natural and more abstractions can be built.
Instead, SwiftUI adopted a whole new set of primitives that doesn’t mix. Accessing the underlying UIView is discouraged, and wrapping up UIKit in SwiftUI feels like a legacy feature. IMO SwiftUI should have been a thin wrapper on UIKit.
There are official escape hatches in SwiftUI to let you leverage UIKit. As someone actively working on a slow migration from UIKit to SwiftUI (where possible), it doesn't feel discouraging to wrap a UIKit view to use it in SwiftUI if necessary.
That’s more of a compatibility solution than an escape hatch. An official SwiftUI escape hatch should have access to the underlying imperative object, call methods on it, etc… Unfortunately the underlying ‘things’ in SwiftUI is implementation detail, inspecting the view hierarchy and finding the UIViews that implement a SwiftUI view is a hack.
Readit News
A few startups ago we built our app using SwiftUI 1.0. At that time, while 90% of it was fantastic, 10% was either unworkable or extremely unreliable, causing for some maddening bugs. The documentation was laughable so for these reasons I chose to do the app for a subsequent startup in UIKit.
Fast forward to my most recent company; decided to give SwiftUI another shot (targeting iOS 14 & SwiftUI 2). I am 100% glad we did. It’s been pretty incredible; we’ve built a reasonably complex banking app at a pace not possible with UIKit. The animations in particular are crazy good to work with; we’ve got some very complex animated flows that would have taken weeks and thousands of lines with UIKit… with SwiftUI it was about 5 days.
It’s definitely not without its downsides; documentation is still slim at best, but there’s plenty of blogs and resources (https://swiftui-lab.com/ is the most helpful IMO) available now. There are also still some maddening bugs that appear in production and take a day or two of head scratching only to discover it’s a bug in the framework (most recently; using #available causes code to crash on the platform it’s protecting against lol), but there are always workarounds. Still, time wasted on these has been vastly outweighed by the weeks / months of time saved.
Finally, you can always use UIKit as an escape hatch through UIViewRepresentable.
iOS 15 is at 85% adoption, so we plan to drop support for 14 somewhat soon, which will give us an even more robust framework as well as async await APIs. Not feasible for most companies I know, but even supporting 14+ Will be pretty reasonable when iOS 16 drops in September.
https://streamable.com/56pha0
(shameless plug; check us out at https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
Again, just guessing, but I would imagine that it’s managing that state and animating it in a sane way which requires LOTS of code, less so the animations themselves.
Animations are so often an ill-advised, interaction-slowing pain in the ass for users that I'm curious about beneficial and non-annoying use cases.
That's kinda like my story. Covid started and I wanted to learn something new so I started with Swift/SwiftUI. 2 years later I've been doing tons of crazy custom stuff in my portfolio tracker app https://stocketa.com (not launched yet) - I kept a thread with my progress since the first day I started my journey: https://twitter.com/Stammy/status/1527288954935922688 (scroll up).
This was last june but I wrote about my experience with SwiftUI at the time: https://paulstamatiou.com/getting-started-with-swiftui/
How can one properly evaluate it with no point of comparison?
If you've never tasted chocolate, then vanilla might seem like the greatest flavor ever.
Your app looks sharp though I like it.
A couple of reasons:
1) The documentation for SwiftUI, when I started (about two years ago) was awful. I was shocked at how bad it was. I believe that it has since improved.
2) I knew of no major apps (even Apple ones) that had been done with it.
I already knew that UIKit was up to the task, and held my nose, while I set things up. It's working out extremely well, but (of course) I'd like to rewrite the whole thing (a sure sign that I'm approaching ship).
I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I'm able to release fairly basic Apple apps in UIKit, in just hours, so speed of development isn't compelling.
What is compelling, is the ability to design a reactive system for a complex app (like the one I'm writing now). AppKit has allowed this for some time, and it's possible to force UIKit to do it (but it isn't really designed for that).
I really wish that SwiftUI had been a bit more mature, when I started this system, but I would have also needed to rewrite the two server SDKs I use, anyway. It wouldn't have worked, no matter how hard I bang my heels together.
But I'm looking forward to it.
One thing that I've learned, is that it's really OK to wait for things to mature. Companies always screech about how we need to jump on the bandwagon, but that's all hype. I have taken OpenDoc courses at Apple DU. I also busted my ass, getting my app ready for Copland. I have scars from Apple hype.
I did take a big chance, by jumping directly into Swift, but that has turned out to be a good decision.
I think it has massive potential regardless, but yes it’s going to need some time to fully bake (much as UIKit did).
It’s too bad that Cocoa Bindings never found their way from AppKit into UIKit. I understand their exclusion was likely due to CPU power limitations early on, but that hasn’t been a problem for many years at this point.
I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfortune to work in.
That's a great little turn-of-phrase that I plan on stealing in the future. Apple's APIs will absolutely reward you for taking the time to step back, figure out how Apple wants you to use them, and try your hardest to use them in that way.
An example from the olden days of iOS development: many of the apps I worked on went out of their way to avoid subclassing UIView, filling their view controllers with layout and interface updates that would have made much more sense in a view. If only they had read all the docs for UIView would they know that doing something like subclassing a button and tweaking a few methods would have done exactly what they wanted with a minimal amount of work.
I've seen all the horrors, and i can now safely claim that all the problems i've seen on iOS development come from not designing the model layer properly in their MVC app. Because most developers start by coding UIs and later end up wondering where to put that business logic and make it reusable.
And now every time i see another pattern that claim to facilitate refreshing the UI upon model change ( and vice versa), i know it's going to be a failure.
Its not much better today overall, but is usually not an issue within companies themselves.
< Takes out a foil blanket. Hands you a flask. >
https://github.com/uber/RIBs
I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the platform differs, and yes you are not going to avoid the UIViewController when doing it on iOS. But you are still doing MVVM even if your V is actually a UIViewController.
I use MVVM almost exclusively now, and I usually do it in a cross-platform framework (Xamarin/MAUI). The codebase is portable across both iOS and Android with no re-architecting of the high-level architecture pattern.
The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers.
It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless.
I use the Storyboard Editor a lot. It is not my favorite editor, but it allows me to work incredibly quickly, and to make a really reflowable UI.
I know that the app I'm working on now, is larger than any I've seen from SwiftUI (around 40 screens, and communicating with three servers in realtime, using a couple of SDKs). I am able to make it all work.
I feel as if MVVM would make the parts of the app that link the UI to the servers a lot more graceful (it's a nasty state engine, right now -ick). I feel as if this kind of app is the kind of thing they had in mind, with SwiftUI.
I do know that it's really important to derive subclasses, and extend ObjC classes, when using UIKit/AppKit/WatchKit, and I feel sorry for folks that avoid inheritance like the plague. It must be a fair bit of work. Looks like SwiftUI doesn't really need that at all, but I haven't spent enough time with it, yet, to know for sure.
I have no doubt that I'll end up mastering it. I'm a quick study. I've spent 35 years, surfing the tech wave.
I agree with everything you've said but this. I've worked on 3 very large app, one which is 85% using mvvm, the two others were still in experimentation phases with it and I am not sure where they've ended up. It's been a joy. The app is designed in a very reactive way and the data flow paths are very clearly defined and easy to follow.
Don't get me wrong the other two apps were heavily MVC with a lot of delegation and that was fine. I could easily switch back to an architecture like that but it's very possible and quite easy to switch over to an mvvm pattern.
It may be because I want a "pure" MVVM, and it has to be sort of "impure" to work with UIKit apps. In that case, it just adds more code. I'm a "the best code I write, is the code I don't write" kind of guy.
Probably not ‘major’ as in ‘complex’, but I believed the Apple Pay sheet is now Swift UI
But the app I'm writing is a good deal more complex than most of the utility apps, and I seriously doubt that the complex apps are SwiftUI. I would not be surprised if many of them are still ObjC.
I find that I can deliver features and iterate much faster and that makes up for the time I spend fixing edge case bugs or bridging to UIKit when I need an unsupported feature.
I would like to add that I found SwiftUI to be extremely robust against developer mistakes. Things either work, or they give error messages. It's rare that a view is subtly broken.
The conclusion was that Apple made a huge mistake tying it the iOS version and effectively limiting updates and it's real world use for years at a time.
Both leads liked the design paradigms, but we are only going to use Jetpack Compose since it's made of multiple libraries that are all backwards compatible with our minimum supported version. iOS will stick to UIKit since it works and is backwards compatible
Exactly this. SwiftUI on iOS 13.x is practically unusable for anything above simple implementations, with some fairly major bugs that weren't fixed until iOS 14-15. Bugs aside, the lack of StateObject in SwiftUI (iOS) 13.x makes it a non-starter.
I was also baffled to find that TestFlight can't be installed on pre-Monterey Macs. I mean... WTF? That makes no sense. Sure, we can pass DMGs around, but my company is new to Macs and standardizing our QA team on TestFlight on all devices would've been simple.
My humble belief is that once one understands the inner workings of UIKit, Swift UI is about half of the interactivity of UIKit (read interactivity not as animations or formatting, but actual user controls and inferences from intended actions).
I had requirements to fully understand UITextView, then TextKit and NSLayout, then new ways to interact with text that I have no earthly idea how I would build my interactions in SwiftUI.
In SwiftUI, you get a lot of bang for your buck, but if you want to build something truly remarkable, you need to get your hands dirty and codify your opinions with UIKit.
I've been working on an app that's mostly SwiftUI for about a year now. It feels magical when it works, but I don't think I've saved time vs. using UIKit at this point due to all of the workarounds that I've needed to find.
Particularly, SwiftUI List views are still loosely supported, and in some cases broken. Unfortunately for devs, lists are the cornerstone of many apps.
For example, it's very difficult to get the content offset of list. You cannot put multiple buttons in a list row without breaking their tap targets. You can't change the background color of a grouped list without changing it globally (and it's very difficult to customize many SwiftUI components, like the navigation bar). It's difficult to control the spacing between sections in grouped lists. I could go on.
Developers are stuck in a hard place right now. If you're starting an iOS app today, do you go with UIKit (and accept that your code will soon be considered legacy by Apple and many engineers?) Or do you go with SwiftUI, and accept that many things will be broken or impossible to make right?
Instead, SwiftUI adopted a whole new set of primitives that doesn’t mix. Accessing the underlying UIView is discouraged, and wrapping up UIKit in SwiftUI feels like a legacy feature. IMO SwiftUI should have been a thin wrapper on UIKit.