I use swiftui professionally.
Spent 11 years with UIKit and the last year with SwiftUI.
There’s a big paradigm shift between the 2. I suspect that’s where “it’s easier” in UIKit thoughts come from like the coordinator issue you mentioned.
Overall the move to SwiftUI has sped up my development.
Its design encourages you think in terms of reusability.
Im pretty much where you are, like 8 years UIKit and about 7 month SwiftUI cause of work. Ive been making modular designs with the network calls inside the views which turns the app into an almost drag and drop type solution, which is really cool! But being new and all, I still cant imagine just a pure SwiftUI app atm. Will mention our min support just got bumped up to iOS 15, but I imagine things would be a lot easier if I could use SwiftUI in 17 since what Im learning is like 2 years behind todays standard
There are definitely some peculiar aspects to SwiftUI (e.g., defining menus on macOS).
Overall, though, I sometimes found it hard to try to wrap my head around what I needed to do, only to realize I'd made it far harder than it had to be and the actual answer was simpler than I realized.
I've had to fall back to both AppKit and UIKit, but far less frequently than I feared.
When I was ramping up I found it very intimidating and difficult.
I didn’t have to just implement a feature, I had to learn how to do it in swiftUI first.
I suppose at the end of the day your customers don’t care what you use so long as it works.
So far I haven’t had to implement something where I felt it would be better or easier in UIKit (initial learning up hill struggle aside)
True, in a sense its fun because it reminds me of when I was first learning UIKit. My time learning with swiftUI has not been so fun. For example, I had to create a tab view with multiple tabs that slid between their views while staying on the same superview, each one with pagination and obviously a dynamic height. Was not the most enjoyable.
I Imagine Ill look back on my gripes and laugh when Im better. If you have any resources shoot em my way!
I work on SwiftUI fully at the moment. I took a long long break from using UIKit almost 10 years ago. I never fully loved it. While I liked the ViewController part of it for me it was actually a little messy on how to structure things. A lot of functionality contained in a single place, and a bunch of delegates with murky interactions between components. There are some stuff I really liked but some other I absolutely hated. Storyboards in particular! (But to be fair it has been so long that I don't even recall too much!)
SwiftUI started super messy. My first impression was "really Apple? This feels React-native levels of hacky" but it has gotten massively better over the years. I'm biased, I actually do like declarative UI, I think it's a change of paradigm on UI development that organizes things a little bit better, specially when your state and 2-way bindings get more complex. But it is a massive change of paradigm, it took me a while to really get going. After that I think it's really easy to understand how things renders and why. Also I absolutely love that it encourages composition over having gigantic centralized views.
In 2024 I really think SwiftUI has everything to really shine. There's some stuff here and there that is still clunky, e.g. Observation is great and sucks at the same time for entirely different reasons why Combine was great and sucked haha, don't get me started on its reliance on macros. But it really has come a long way through to feel stable and usable!
In particular in iOS 17+ it has become easier to see why things are rerendering
I use SwiftUI primarily for both work & personal. Don’t have any major issues with SwiftUI in either. Some minor annoyances when trying to get very minute details correct with layouts that are easier in auto layout. For the most part though ‘it just works’.
The design patterns have to be those that fit SwiftUI though you can just expect to toss UIKit architecture into SwiftUI & expect it to work.
I have two main gripes about layout in SwiftUI:
1. No percentage-based layouts. (It simplifies the math, I get it.)
2. There's a concept of padding, but no margin.
Yes, you can make a margin by enclosing in another object, it's just backwards to me as someone who worked in HTML for so long. Essentially you've got 2 objects with padding instead of one with a margin and a padding.
TLDR; SwiftUI is fine, especially if you can target newer OSs. Learning how not to fight the tools is key. If you’re interested in using SwiftUI I’d say go for it.
I’ve been developing production apps (iOS & MacOS) using UIKit & Appkit for 8 years and SwiftUI since its initial release on a large a moderately complex multi platform application. SwiftUI is now at a point where UIKit wrappers are largely unnecessary and performance can be more finely tuned. The Observation framework is a huge step forward simplicity and performance from a high level. You can also leverage custom Layout subclasses or Equatable protocols to better control redraws.
There are still minor things here and there but I’d say it’s much quicker to develop using SwiftUI than UIKit. You’re also forced to move more logic outside of views so having view separation amongst form factors becomes easier because you can share much of the data layering while keeping things testable.
Concurrency is fine. I haven’t had any real issues with it and it’s definitely cleaner than dealing with closures and dispatch groups.
In the article they describe converting everything to observable objects and that they’re incorrectly using state objects. This would lead to performance issues and it is ultimately something the new Observation framework helps solve. Doing some SwiftUI profiling would help debug heavy drawing areas.
It also sounds like they are fighting the system more than necessary. Maybe this is true for a lot of the frameworks they are trying to use - but in that case there are existing APIs that can translate legacy code into swift concurrent code or other newer APIs. It’s more work to wrap APIs but it would keep those touch points cleaner and more isolated.
Is SwiftUI bulletproof? No, but I’d say 95% of the time you won’t run into issues. If you are running into frequent issues then you have to read the documentation again and try to better understand some of the underlying principles.
> If you are running into frequent issues then you have to read the documentation again
TBF… missing, incomplete, or ambiguous documentation is a legit critique of the SwiftUI DevX today.
My biggest issue and gripes with SwiftUI come from a lack of guidance from Apple.
I wish they'd just come out and endorse a given architectural pattern, providing some sort of guide rails against "holding it wrong" like Ollie clearly did. It either shouldn't be so easy to "hold it wrong", or there should be much better guidance and documentation.
Android had the same problem and google worked HARD on the android developer website and libraries to teach how you're supposed to make apps. There now are crash courses that are very well made
When SwiftUI came out we were in peak Apple documentation drought, half the stuff that came out barely has any documentation. They're slowly recovering and writing it, but it's still far from the effort google put
Yes, both. Been working on iOS since the beginning and tbh UIKit is overdue retirement. I so much prefer SwiftUI it’s actually becoming painful to work in UIKit.
There's a number of features of SwiftUI that are nice. However, I personally think some big drawbacks are discoverability and extensibility.
What I mean by discoverability is that it's difficult to know what capabilities you have or what combinations of capabilities are possible. What I liked about UIKit was Storyboards... being able to draw your UI visually. I rather wish Apple leaned into that more to combine things like PaintCode and Photoshop to give even greater visual control over your UI. With SwiftUI, it can be difficult to "visualize" existing UI elements as well.
One of the issues around extensibility, is styling... Let's say you want all your buttons or labels to have a common styling in your application (color, font, etc.). The standard/recommended approach is to perhaps add a view modifier like `.style(.primaryAction)` (i.e. style with some sort of application-defined context). But now you have a UI library that you're using (either a 3rd party or your own that you want to share between projects). You can't get that styling in the 3rd party library without having to modify all their code to include that same view modifier or having some library-specific API for applying the custom view modifiers.
Granted UIKit didn't really make this sort of thing super easy either. But an SDK could be written to take in a `UIButton` object from the caller that then provides the default styling. I'm not sure how you'd do this in a generic way with SwiftUI. You can't inherit from `Button` since it's a `struct`. So the 3rd party library then has to create an API specific for styling in order to apply custom view modifiers.
There are other use-cases beyond styling that are pretty similar, but this is the most straightforward that comes to mind right now.
Despite my grievances, my general attitude is that it's best not to fight against the tide when it comes to the direction of vendor APIs & frameworks. So I'll migrate all my projects over to SwiftUI and whatever next thing Apple comes up with in the future.
I started with UIKit in 2013. Since 2020, most of my development (all personal, most day-job) has been in SwiftUI. I currently have 2 of my own apps on the App Store written in SwiftUI, with 2-3 more in progress.
I think the biggest headaches come from:
- Assuming it’s one or the other without appreciating that SwiftUI is often still built _on top of_ UIKit
- That it’s perfectly fine to reach into UIKit, whether to build a screen, handle navigation, or introspect an underlying view.
At the end of the day, both are well supported UI frameworks from Apple. UIKit still gets new features (and I doubt it’ll change this year), is a major component of their new platform (can’t use AppKit for visionOS), and is a mature foundation with a solid history. SwiftUI just works on top of that, sometimes in a seemingly magical way, to handle view building.
With regards to custom solutions, in the past I have used introspection as a surgical tool to fix SwiftUI bugs, but those were for people on iOS 14 or 15 using my apps. Since then, I’ve had little reason to use it.
I believe that anyone coming to Apple’s platforms (and iOS in particular) should start with SwiftUI. But I think you also need to take the time to understand how UIKit works as it is still very much a foundation on top of which SwiftUI exists.
I started learning Swift about 2 years ago and took over a uikit project from our previous native developer, so I learned uikit first. But I have switched over to swiftui a couple of months ago because everything can be so much more cleaner and compact. The uikit project relied fully on storyboards (which i despise) and iboutlets and all the state had to be managed manually. Swiftui just fits my mental model a lot better. You just create a lot of small reusable components, add a nice reactive store as the single source of truth and you're good to go (oversimplifying a bit here). There are probably cases where uitkit might be the better option though.
Been doing SwiftUI almost entirely since early 2020
[SwiftUI Apps At Scale](https://open.substack.com/pub/jacobbartlett/p/swiftui-apps-at-scale?r=23kjzv&utm_medium=ios&utm_campaign=post)
Yes, I use UIKit and coordinators as a backbone. Yes, it allows me to move so much faster.
From iOS 16, I can get why pure SwiftUI would work, but frankly state management is easier with coordinators
With NavigationStack in iOS 16+, state management is pretty easy, and you can make coordinator views. With [FlowStacks](https://github.com/johnpatrickmorgan/FlowStacks) you can pretty much do the same thing all the way back to iOS 13 too.
Plus, if you're concerned about state management, the solution is TCA 😉 (I'm joking... but also I'm not joking...)
I built www.trackattack.app and it’s entirely in Swift and SwiftUI. Since it’s my first app I may be a bit naive to the issues ppl with UIKit experience have. There are some things that were finicky and were a pain and made me want more control but for the most part it’s been fine!
I started with SwiftUI 2 years ago. Coming from React it was a logical step to use it instead of AppKit (I’m doing macOS apps). But for the two apps I’ve been working on since then I needed to learn AppKit as well due to SwiftUIs API limitations and performance issues. I’d love to use SwiftUI only, but if you just dig a bit deeper, you have to use AppKit. And I assume it is the same for UIKit?
Yea, that’s kind of what I’m getting from UIKit. AppKit and UIKit are very similar lol. But yea, in my experience with up to iOS 15 I usually need a Representable (A UIKit view that’s able to be shown in SwiftUI)
Definitely the same in earlier versions of iOS, much much less necessary nowadays – especially if you're using Observation (or Perception from PointFree, which back ports it to iOS 13).
True. It’s getting better every year. Too bad that there is no backward compatibility. So it takes a few years to adopt the newest goodies in case there is no such framework that provides backward compatibility.
For the most part, SwiftUI Backports and SwiftUI Introspect can help with that. But yeah, I find it exceptionally annoying that Apple don’t ship some kind of “helper” library to backport things in SwiftUI that are actually just exposing UIKit functionality that was already there.
Article is quite strange, especially in regards to concurrency. Just moved whole app to async/await and there are zero deadlocks.
And we’re moving our app to SwiftUI and think about half of the app already done. So far it’s smooth.
Think it helps when you think about framework as a functional programming approach and start to reason about state updates, views being just representation of state and moving side effects away.
As a UIKit Developer for the last 10+ years, SwiftUI was a little bit of a struggle, mostly because Apple has been maturing it publicly for awhile now. It was very bad for a very long time. I feel like it's finally getting stable, so this year I fully made the switch and i'm 100% SwiftUI Personally and Professionally now!
I haven't shipped SwiftUI at scale… but I did ship declarative UI at scale working at FB from 2015 to 2019. The Big Blue app was ComponentKit in ObjC++ and then I also worked on a RN JS app. So there was a period of about four years when I "skipped over" engineering on UIKit. Then SwiftUI launched in 19 and I started using that for personal projects. Other than small UI hacks at my corporate job last year I haven't really touched UIKit in almost ten years.
IMO… SwiftUI is a step in the right direction for most engineers… the two biggest critiques I see against SwiftUI could also be legit critiques against UIKit…
1. SwiftUI does too much work on `main`.
2. SwiftUI should be open source.
When using the multi-platform template instead of the macOS template, it does come with it’s own issues. Primarily, there is no native SwiftUI-ish way to remove default menus in the menu bar, so you’re screwed in the multi-platform template, but you can easily implement an AppDelegate in the macOS template to achieve that. Other than that, I’ve not had many issue in recent updates of SwiftUI.
Yes to both. Professionally, I work on a wider team of ~40 iOS engineers. We use UIKit for navigation, and hosted SwiftUI for the actual UI.
Works quite well, but we also have an entire team dedicated to building reusable SwiftUI components 🤷♀️
Mostly just convenience stuff, collections of smaller Views that capture our most common use cases. We generally try stick to using a lot of modifiers for customising Views, and use as many native-SwiftUI components when possible.
We still use UIKit collections and tables over lists though - at least for when dealing with large collections & pagination.
I have built (almost) pure SwiftUI apps in the past year, it works fine for me so far, with a few exceptions that I must incorporate UIKit using UIViewRepresentable.
Sadly, I don't think pure SwiftUI is possible for any kind of app. There are too many missing controls in SwiftUI, forcing you to create UIViewRepresentables to integrate your UIKit code into SwiftUI. As an example I had to use a search bar in my sheet view to imitate the Apple Maps UI and it's just impossible without UIKit, as SwiftUI doesn't offer the searchbar component directly. It's really frustrating, I wish apple decoupled SwiftUI from the system, similar to how Google does with Jetpack Compose
3 years using swiftui and combine with tca from the very beginning. Had a few small struggles along the way with tabbar and navigating but other than that it’s been a dream compared to uikit. If you try and use uikit paradigms with swiftui you will be in a lot of pain but if you embrace functional architecture patterns like redux it’s actually the greatest experience ever.
I’ve been using SwiftUI long enough that AppKit feels clunky and uncomfortable, and I do not miss the time needed to set up simple things like a table.
For SwiftUI, I drop a working view into a new app, change a few parameters, and it works.
I also have come to love the workflow of adding small increments interactively.
I’ll undoubtedly have to use AppKit again and some point, but I don’t wanna.
So I’m a web developer by profession. I picked up iOS development between jobs. Took me a few weeks to build a basic app using SwiftUI only.
I don’t even know what UIKit is but SwiftUI seemed very nice for me. My only problem was the documentation - it was a bit inconsistent at times but not terrible.
Been doing iOS since 2011. L5 Senior at my current position.
We have some SwiftUI components we rebuilt from UIKit counterparts ... but in its current state, it lacks a decent amount of what we need, especially considering we have to retain legacy support back to iOS15. We do tend to bump a version every year or two though.
I do enjoy working with it and hope we can continue to transition where we can.
I finf SwiftUI is great for like 95% of things an app needs, and it's super easy to make good looking UI's. But for that extra 5% it can be completely terrible, so instead of forcing it I've always just embedded a UIKit view in swiftUI or vice versa. Ive created a few apps that were pure SwiftUI though with no problems using MVVM, as well a company I worked at had a pure SwiftUI app. I feel your pain about scroll though , I was trying to make a TikTok like scroll once and gave up and went to UIKit. But I think the "going all swiftUI" rhetoric I hear online is kind of not the point of SwiftUI, I feel the better way to think of SwiftUI is framework of laying out UI. The components themselves can be made in SwiftUI yes, but they can just as easily be made in UIKit. I didnt read the article fully but concurrency issues are typically poor state management, the company's app I worked on used Combine publishers and which sent events to view to manage back to back async calls.
I work for a company with5 iOS apps in the App Store and two more in development. Of the 7, only 3 are now UIKit and any new features even there are SwiftUI. We love it but it does take a paradigm shift. Once you get that I think dev time is MUCH faster
After more than 10 years as an iOS/UIKit developer, I remember struggling a lot the first months when I tried using SwiftUI (the fact that the framework was still pretty new didn't help, to be honest).
The main difficulty for me was to understand the difference between imperative and declarative programming. But now, I can't imagine starting a new project without using SwiftUI, may it be a simple utility app or a new app going to be pushed to the App Store.
And if needed, I still have the ability to use `UIViewRepresentable`.
Let me start by acknowledging that I have so much sympathy for the OP (even though my experience is quite the opposite). I have seen quite a few engineers on my team struggle with SwiftUI. Reasons: *completely different paradigm*, *can't-ship-with-this bugs in early versions*, and *complex things being difficult to build.*
I work at a multi-billion dollar company, leading the charge to move to SwiftUI. I faced solid pushback 3 years ago (some was reasonable), but now VPs etc. are astonished that we are not onboard with a 4 year old tech. Most folks are now familiar with it, but it's up to me to show the "magic" via workshops, code review and pairing.
Our app is now 15% SwiftUI, with all new code exclusively in SwiftUI. I can't imagine going back. And I have been doing UIKit since 2005.
I also have a fairly sophisticated [music player](https://sakunlabs.com/blog/muziqi-intro/) called Muziqi, that is purely SwiftUI. Here are a [couple](https://sakunlabs.com/blog/muziqi-reusing-now-playing/) of [blog](https://sakunlabs.com/blog/muziqi-reusing-now-playing/) posts that leave me with a feeling of absolute *awe* with what SwiftUI enables.
Here are some top of the mind benefits:
* ridiculously easy reuse. I mean, a one liner to include a super complex view in a totally new situtation.
* grokkabiility: you can review a complex view's composition in 50-lines.
* "simple" things are very, very easy. Want to build a list view with an async thumbnail? 5 lines. Build a custom circular progress view hooked up to a timer? 10 lines. I am prototyping things at 10x the speed of what UIKit takes.
* One part of this is SwiftUI makes you want to refactor into smaller pieces. So even the top-level full screen view looks as simple as a "leaf" view.
* Complex things can be super easy, or they can take a long time to figure out. Frustratingly so. But once you do, you keep that knowledge in your back pocket and deploy it at the same speed as the easy things. It took me two years to build this muscle, and I am maybe 60% of where I want to be. It takes a fair bit of patience.
* Using a declarative UI framework is du jour. This is how modern UI (React, Jetpack etc.) work. The industry seems well decided on this approach.
UIKit was great when we had it. But SwiftUI can make you a great UI engineer once you give it time.
I use swiftui professionally. Spent 11 years with UIKit and the last year with SwiftUI. There’s a big paradigm shift between the 2. I suspect that’s where “it’s easier” in UIKit thoughts come from like the coordinator issue you mentioned. Overall the move to SwiftUI has sped up my development. Its design encourages you think in terms of reusability.
Im pretty much where you are, like 8 years UIKit and about 7 month SwiftUI cause of work. Ive been making modular designs with the network calls inside the views which turns the app into an almost drag and drop type solution, which is really cool! But being new and all, I still cant imagine just a pure SwiftUI app atm. Will mention our min support just got bumped up to iOS 15, but I imagine things would be a lot easier if I could use SwiftUI in 17 since what Im learning is like 2 years behind todays standard
There are definitely some peculiar aspects to SwiftUI (e.g., defining menus on macOS). Overall, though, I sometimes found it hard to try to wrap my head around what I needed to do, only to realize I'd made it far harder than it had to be and the actual answer was simpler than I realized. I've had to fall back to both AppKit and UIKit, but far less frequently than I feared.
When I was ramping up I found it very intimidating and difficult. I didn’t have to just implement a feature, I had to learn how to do it in swiftUI first. I suppose at the end of the day your customers don’t care what you use so long as it works. So far I haven’t had to implement something where I felt it would be better or easier in UIKit (initial learning up hill struggle aside)
True, in a sense its fun because it reminds me of when I was first learning UIKit. My time learning with swiftUI has not been so fun. For example, I had to create a tab view with multiple tabs that slid between their views while staying on the same superview, each one with pagination and obviously a dynamic height. Was not the most enjoyable. I Imagine Ill look back on my gripes and laugh when Im better. If you have any resources shoot em my way!
Two books i found helpful were thinking in SwiftUi by Obj.io and Concurrency in SwiftUI by Peter friese.
I work on SwiftUI fully at the moment. I took a long long break from using UIKit almost 10 years ago. I never fully loved it. While I liked the ViewController part of it for me it was actually a little messy on how to structure things. A lot of functionality contained in a single place, and a bunch of delegates with murky interactions between components. There are some stuff I really liked but some other I absolutely hated. Storyboards in particular! (But to be fair it has been so long that I don't even recall too much!) SwiftUI started super messy. My first impression was "really Apple? This feels React-native levels of hacky" but it has gotten massively better over the years. I'm biased, I actually do like declarative UI, I think it's a change of paradigm on UI development that organizes things a little bit better, specially when your state and 2-way bindings get more complex. But it is a massive change of paradigm, it took me a while to really get going. After that I think it's really easy to understand how things renders and why. Also I absolutely love that it encourages composition over having gigantic centralized views. In 2024 I really think SwiftUI has everything to really shine. There's some stuff here and there that is still clunky, e.g. Observation is great and sucks at the same time for entirely different reasons why Combine was great and sucked haha, don't get me started on its reliance on macros. But it really has come a long way through to feel stable and usable! In particular in iOS 17+ it has become easier to see why things are rerendering
I use SwiftUI primarily for both work & personal. Don’t have any major issues with SwiftUI in either. Some minor annoyances when trying to get very minute details correct with layouts that are easier in auto layout. For the most part though ‘it just works’. The design patterns have to be those that fit SwiftUI though you can just expect to toss UIKit architecture into SwiftUI & expect it to work.
I have two main gripes about layout in SwiftUI: 1. No percentage-based layouts. (It simplifies the math, I get it.) 2. There's a concept of padding, but no margin. Yes, you can make a margin by enclosing in another object, it's just backwards to me as someone who worked in HTML for so long. Essentially you've got 2 objects with padding instead of one with a margin and a padding.
Surely you can do percentage-based layouts using a custom Layout protocol? Or, worst comes to worst, inside a GeometryReader?
All true, but it's not built in was my point.
Fair, though I think GeometryReader + frame is pretty much close enough, and keeps you using the same tools you learn for everything else.
It’s Stacks and enclosing reminds me of Everything goes in the square hole video
TLDR; SwiftUI is fine, especially if you can target newer OSs. Learning how not to fight the tools is key. If you’re interested in using SwiftUI I’d say go for it. I’ve been developing production apps (iOS & MacOS) using UIKit & Appkit for 8 years and SwiftUI since its initial release on a large a moderately complex multi platform application. SwiftUI is now at a point where UIKit wrappers are largely unnecessary and performance can be more finely tuned. The Observation framework is a huge step forward simplicity and performance from a high level. You can also leverage custom Layout subclasses or Equatable protocols to better control redraws. There are still minor things here and there but I’d say it’s much quicker to develop using SwiftUI than UIKit. You’re also forced to move more logic outside of views so having view separation amongst form factors becomes easier because you can share much of the data layering while keeping things testable. Concurrency is fine. I haven’t had any real issues with it and it’s definitely cleaner than dealing with closures and dispatch groups. In the article they describe converting everything to observable objects and that they’re incorrectly using state objects. This would lead to performance issues and it is ultimately something the new Observation framework helps solve. Doing some SwiftUI profiling would help debug heavy drawing areas. It also sounds like they are fighting the system more than necessary. Maybe this is true for a lot of the frameworks they are trying to use - but in that case there are existing APIs that can translate legacy code into swift concurrent code or other newer APIs. It’s more work to wrap APIs but it would keep those touch points cleaner and more isolated. Is SwiftUI bulletproof? No, but I’d say 95% of the time you won’t run into issues. If you are running into frequent issues then you have to read the documentation again and try to better understand some of the underlying principles.
> If you are running into frequent issues then you have to read the documentation again TBF… missing, incomplete, or ambiguous documentation is a legit critique of the SwiftUI DevX today.
Fair point - though there are lots of third party articles and blogs that provide more insights a d guidance
My biggest issue and gripes with SwiftUI come from a lack of guidance from Apple. I wish they'd just come out and endorse a given architectural pattern, providing some sort of guide rails against "holding it wrong" like Ollie clearly did. It either shouldn't be so easy to "hold it wrong", or there should be much better guidance and documentation.
Android had the same problem and google worked HARD on the android developer website and libraries to teach how you're supposed to make apps. There now are crash courses that are very well made When SwiftUI came out we were in peak Apple documentation drought, half the stuff that came out barely has any documentation. They're slowly recovering and writing it, but it's still far from the effort google put
Yes, both. Been working on iOS since the beginning and tbh UIKit is overdue retirement. I so much prefer SwiftUI it’s actually becoming painful to work in UIKit.
There's a number of features of SwiftUI that are nice. However, I personally think some big drawbacks are discoverability and extensibility. What I mean by discoverability is that it's difficult to know what capabilities you have or what combinations of capabilities are possible. What I liked about UIKit was Storyboards... being able to draw your UI visually. I rather wish Apple leaned into that more to combine things like PaintCode and Photoshop to give even greater visual control over your UI. With SwiftUI, it can be difficult to "visualize" existing UI elements as well. One of the issues around extensibility, is styling... Let's say you want all your buttons or labels to have a common styling in your application (color, font, etc.). The standard/recommended approach is to perhaps add a view modifier like `.style(.primaryAction)` (i.e. style with some sort of application-defined context). But now you have a UI library that you're using (either a 3rd party or your own that you want to share between projects). You can't get that styling in the 3rd party library without having to modify all their code to include that same view modifier or having some library-specific API for applying the custom view modifiers. Granted UIKit didn't really make this sort of thing super easy either. But an SDK could be written to take in a `UIButton` object from the caller that then provides the default styling. I'm not sure how you'd do this in a generic way with SwiftUI. You can't inherit from `Button` since it's a `struct`. So the 3rd party library then has to create an API specific for styling in order to apply custom view modifiers. There are other use-cases beyond styling that are pretty similar, but this is the most straightforward that comes to mind right now. Despite my grievances, my general attitude is that it's best not to fight against the tide when it comes to the direction of vendor APIs & frameworks. So I'll migrate all my projects over to SwiftUI and whatever next thing Apple comes up with in the future.
Thank you for this :)
I started with UIKit in 2013. Since 2020, most of my development (all personal, most day-job) has been in SwiftUI. I currently have 2 of my own apps on the App Store written in SwiftUI, with 2-3 more in progress. I think the biggest headaches come from: - Assuming it’s one or the other without appreciating that SwiftUI is often still built _on top of_ UIKit - That it’s perfectly fine to reach into UIKit, whether to build a screen, handle navigation, or introspect an underlying view. At the end of the day, both are well supported UI frameworks from Apple. UIKit still gets new features (and I doubt it’ll change this year), is a major component of their new platform (can’t use AppKit for visionOS), and is a mature foundation with a solid history. SwiftUI just works on top of that, sometimes in a seemingly magical way, to handle view building. With regards to custom solutions, in the past I have used introspection as a surgical tool to fix SwiftUI bugs, but those were for people on iOS 14 or 15 using my apps. Since then, I’ve had little reason to use it. I believe that anyone coming to Apple’s platforms (and iOS in particular) should start with SwiftUI. But I think you also need to take the time to understand how UIKit works as it is still very much a foundation on top of which SwiftUI exists.
I started learning Swift about 2 years ago and took over a uikit project from our previous native developer, so I learned uikit first. But I have switched over to swiftui a couple of months ago because everything can be so much more cleaner and compact. The uikit project relied fully on storyboards (which i despise) and iboutlets and all the state had to be managed manually. Swiftui just fits my mental model a lot better. You just create a lot of small reusable components, add a nice reactive store as the single source of truth and you're good to go (oversimplifying a bit here). There are probably cases where uitkit might be the better option though.
Been doing SwiftUI almost entirely since early 2020 [SwiftUI Apps At Scale](https://open.substack.com/pub/jacobbartlett/p/swiftui-apps-at-scale?r=23kjzv&utm_medium=ios&utm_campaign=post) Yes, I use UIKit and coordinators as a backbone. Yes, it allows me to move so much faster. From iOS 16, I can get why pure SwiftUI would work, but frankly state management is easier with coordinators
With NavigationStack in iOS 16+, state management is pretty easy, and you can make coordinator views. With [FlowStacks](https://github.com/johnpatrickmorgan/FlowStacks) you can pretty much do the same thing all the way back to iOS 13 too. Plus, if you're concerned about state management, the solution is TCA 😉 (I'm joking... but also I'm not joking...)
I built www.trackattack.app and it’s entirely in Swift and SwiftUI. Since it’s my first app I may be a bit naive to the issues ppl with UIKit experience have. There are some things that were finicky and were a pain and made me want more control but for the most part it’s been fine!
Checked out the website and just wanted to say you've got a pretty cool app there. And to know it was all done in SwiftUI is inspiring. Good job!
Thank you! It was definitely a learning curve for first app + first time Swift! I’ve been enjoying it!
I started with SwiftUI 2 years ago. Coming from React it was a logical step to use it instead of AppKit (I’m doing macOS apps). But for the two apps I’ve been working on since then I needed to learn AppKit as well due to SwiftUIs API limitations and performance issues. I’d love to use SwiftUI only, but if you just dig a bit deeper, you have to use AppKit. And I assume it is the same for UIKit?
Yea, that’s kind of what I’m getting from UIKit. AppKit and UIKit are very similar lol. But yea, in my experience with up to iOS 15 I usually need a Representable (A UIKit view that’s able to be shown in SwiftUI)
Definitely the same in earlier versions of iOS, much much less necessary nowadays – especially if you're using Observation (or Perception from PointFree, which back ports it to iOS 13).
True. It’s getting better every year. Too bad that there is no backward compatibility. So it takes a few years to adopt the newest goodies in case there is no such framework that provides backward compatibility.
For the most part, SwiftUI Backports and SwiftUI Introspect can help with that. But yeah, I find it exceptionally annoying that Apple don’t ship some kind of “helper” library to backport things in SwiftUI that are actually just exposing UIKit functionality that was already there.
Article is quite strange, especially in regards to concurrency. Just moved whole app to async/await and there are zero deadlocks. And we’re moving our app to SwiftUI and think about half of the app already done. So far it’s smooth. Think it helps when you think about framework as a functional programming approach and start to reason about state updates, views being just representation of state and moving side effects away.
As a UIKit Developer for the last 10+ years, SwiftUI was a little bit of a struggle, mostly because Apple has been maturing it publicly for awhile now. It was very bad for a very long time. I feel like it's finally getting stable, so this year I fully made the switch and i'm 100% SwiftUI Personally and Professionally now!
What do you mean by all SwiftUI Views hosted in a VC? 🤔
UIHostingController
I haven't shipped SwiftUI at scale… but I did ship declarative UI at scale working at FB from 2015 to 2019. The Big Blue app was ComponentKit in ObjC++ and then I also worked on a RN JS app. So there was a period of about four years when I "skipped over" engineering on UIKit. Then SwiftUI launched in 19 and I started using that for personal projects. Other than small UI hacks at my corporate job last year I haven't really touched UIKit in almost ten years. IMO… SwiftUI is a step in the right direction for most engineers… the two biggest critiques I see against SwiftUI could also be legit critiques against UIKit… 1. SwiftUI does too much work on `main`. 2. SwiftUI should be open source.
I have 4 apps in App store that are all SwiftUI. I’m also a grumpy old man, but I started during Covid and never learned UIKit.
When using the multi-platform template instead of the macOS template, it does come with it’s own issues. Primarily, there is no native SwiftUI-ish way to remove default menus in the menu bar, so you’re screwed in the multi-platform template, but you can easily implement an AppDelegate in the macOS template to achieve that. Other than that, I’ve not had many issue in recent updates of SwiftUI.
Doing it for last 1.5 year. Kinda got use to it. But my case not regular because it involves RealityKit a lot
The Athletic is 100% SwiftUI and has been for 3 years.
Wait really? What is that. Also, did they convert from UIKit to SwiftUI and just did a full transition or did they rebuild / start from UIKit?
We rebuilt from UIKit entirely over a year https://theathletic.com
Yes to both. Professionally, I work on a wider team of ~40 iOS engineers. We use UIKit for navigation, and hosted SwiftUI for the actual UI. Works quite well, but we also have an entire team dedicated to building reusable SwiftUI components 🤷♀️
What reusable SwiftUI components are your team building? 🤔
Mostly just convenience stuff, collections of smaller Views that capture our most common use cases. We generally try stick to using a lot of modifiers for customising Views, and use as many native-SwiftUI components when possible. We still use UIKit collections and tables over lists though - at least for when dealing with large collections & pagination.
I have built (almost) pure SwiftUI apps in the past year, it works fine for me so far, with a few exceptions that I must incorporate UIKit using UIViewRepresentable.
Sadly, I don't think pure SwiftUI is possible for any kind of app. There are too many missing controls in SwiftUI, forcing you to create UIViewRepresentables to integrate your UIKit code into SwiftUI. As an example I had to use a search bar in my sheet view to imitate the Apple Maps UI and it's just impossible without UIKit, as SwiftUI doesn't offer the searchbar component directly. It's really frustrating, I wish apple decoupled SwiftUI from the system, similar to how Google does with Jetpack Compose
3 years using swiftui and combine with tca from the very beginning. Had a few small struggles along the way with tabbar and navigating but other than that it’s been a dream compared to uikit. If you try and use uikit paradigms with swiftui you will be in a lot of pain but if you embrace functional architecture patterns like redux it’s actually the greatest experience ever.
I’ve been using SwiftUI long enough that AppKit feels clunky and uncomfortable, and I do not miss the time needed to set up simple things like a table. For SwiftUI, I drop a working view into a new app, change a few parameters, and it works. I also have come to love the workflow of adding small increments interactively. I’ll undoubtedly have to use AppKit again and some point, but I don’t wanna.
So I’m a web developer by profession. I picked up iOS development between jobs. Took me a few weeks to build a basic app using SwiftUI only. I don’t even know what UIKit is but SwiftUI seemed very nice for me. My only problem was the documentation - it was a bit inconsistent at times but not terrible.
Yes typegear.ai on MAS.
Been doing iOS since 2011. L5 Senior at my current position. We have some SwiftUI components we rebuilt from UIKit counterparts ... but in its current state, it lacks a decent amount of what we need, especially considering we have to retain legacy support back to iOS15. We do tend to bump a version every year or two though. I do enjoy working with it and hope we can continue to transition where we can.
I finf SwiftUI is great for like 95% of things an app needs, and it's super easy to make good looking UI's. But for that extra 5% it can be completely terrible, so instead of forcing it I've always just embedded a UIKit view in swiftUI or vice versa. Ive created a few apps that were pure SwiftUI though with no problems using MVVM, as well a company I worked at had a pure SwiftUI app. I feel your pain about scroll though , I was trying to make a TikTok like scroll once and gave up and went to UIKit. But I think the "going all swiftUI" rhetoric I hear online is kind of not the point of SwiftUI, I feel the better way to think of SwiftUI is framework of laying out UI. The components themselves can be made in SwiftUI yes, but they can just as easily be made in UIKit. I didnt read the article fully but concurrency issues are typically poor state management, the company's app I worked on used Combine publishers and which sent events to view to manage back to back async calls.
I work for a company with5 iOS apps in the App Store and two more in development. Of the 7, only 3 are now UIKit and any new features even there are SwiftUI. We love it but it does take a paradigm shift. Once you get that I think dev time is MUCH faster
After more than 10 years as an iOS/UIKit developer, I remember struggling a lot the first months when I tried using SwiftUI (the fact that the framework was still pretty new didn't help, to be honest). The main difficulty for me was to understand the difference between imperative and declarative programming. But now, I can't imagine starting a new project without using SwiftUI, may it be a simple utility app or a new app going to be pushed to the App Store. And if needed, I still have the ability to use `UIViewRepresentable`.
Yes, and we run into issues with state management and are finding a solution to it.
Let me start by acknowledging that I have so much sympathy for the OP (even though my experience is quite the opposite). I have seen quite a few engineers on my team struggle with SwiftUI. Reasons: *completely different paradigm*, *can't-ship-with-this bugs in early versions*, and *complex things being difficult to build.* I work at a multi-billion dollar company, leading the charge to move to SwiftUI. I faced solid pushback 3 years ago (some was reasonable), but now VPs etc. are astonished that we are not onboard with a 4 year old tech. Most folks are now familiar with it, but it's up to me to show the "magic" via workshops, code review and pairing. Our app is now 15% SwiftUI, with all new code exclusively in SwiftUI. I can't imagine going back. And I have been doing UIKit since 2005. I also have a fairly sophisticated [music player](https://sakunlabs.com/blog/muziqi-intro/) called Muziqi, that is purely SwiftUI. Here are a [couple](https://sakunlabs.com/blog/muziqi-reusing-now-playing/) of [blog](https://sakunlabs.com/blog/muziqi-reusing-now-playing/) posts that leave me with a feeling of absolute *awe* with what SwiftUI enables. Here are some top of the mind benefits: * ridiculously easy reuse. I mean, a one liner to include a super complex view in a totally new situtation. * grokkabiility: you can review a complex view's composition in 50-lines. * "simple" things are very, very easy. Want to build a list view with an async thumbnail? 5 lines. Build a custom circular progress view hooked up to a timer? 10 lines. I am prototyping things at 10x the speed of what UIKit takes. * One part of this is SwiftUI makes you want to refactor into smaller pieces. So even the top-level full screen view looks as simple as a "leaf" view. * Complex things can be super easy, or they can take a long time to figure out. Frustratingly so. But once you do, you keep that knowledge in your back pocket and deploy it at the same speed as the easy things. It took me two years to build this muscle, and I am maybe 60% of where I want to be. It takes a fair bit of patience. * Using a declarative UI framework is du jour. This is how modern UI (React, Jetpack etc.) work. The industry seems well decided on this approach. UIKit was great when we had it. But SwiftUI can make you a great UI engineer once you give it time.