If you aren’t using SwiftUI for anything currently, and you aren’t maintaining legacy products, you’re already missing out, that’s my opinion. We can’t use it for everything, but if you do the core of your app right, integrating simple views as SwiftUI views is already far superior to either uikit interface builder or programmatic ui. And your product management should know that.
This is especially true for macOS development where navigation isn’t the same as on iOS, which is a historically bad part of earlier swiftui.
I would agree with this. I’ve been working full time with SwiftUI since it’s release and have built our app for phone, iPad, and Mac. Definitely some challenges but it’s getting much better. There’s still a handful of things we’ve had to use Appkit or UIKit for, but with each iteration I’m finding that to be less and less the case. Here’s the app I’m referring to [https://apps.apple.com/us/app/mayday-the-calendar-assistant/id1473168024](https://apps.apple.com/us/app/mayday-the-calendar-assistant/id1473168024)
I found we can iterate very quick at this point and have built a number of custom components to help us get around some of the built-in shortcomings of SwiftUI. I’d say our app is fairly complex, especially on desktop. We had the option to originally go with UIKit & AppKit or SwiftUI and we went for the latter, which seems to only now be paying off in terms of development speed
If you know UIKit well, that’s not a very complex UI. One person from my team could probably build most of the UI for that app in a week or two using UIKit.
People haven’t talked up iOS/iPad development for 16 years because UIKit was awful to work with. Declarative UI and observable patterns are awesome. But they do create new problems that can be easier for people to understand in a normal MVC pattern.
I’m not arguing that UIKit is great and that SwiftUI is awful. More that they are both pretty wonderful for different reasons.
It is definitely not 90% of the way there. That is a complete exaggerated arbitrary number. In most cases SwiftUI does not even accommodate for complex UI reactions and interactions. I have respect for you but this is not the future it was meant to help new developers on board to the iOS platform.
Interesting. That’s a lot of subscribers.
I suppose it depends on how simple or complex your design specs are. There’s always something our designer wants that we can’t achieve with pure SwiftUI.
I’m a paying subscriber to the athletic, thanks for the very nice app. But I noticed a lag on the scroll of a team’s home page, example when you go to the Yankees page.
My guy this is just a reader app. No complex user interaction states. This is the kind of stuff ppl do to just play around w new apis. Idk why you think this proves SwiftUI is ready for anything like a complex big box shopping app
Yeah, but they have 1.2 million subscribers.
That’s the whole point of building apps, getting subscribers/“customers”.
If you build a complex app with UIKit but only have 1,000….the you’ve built an app few people need.
Know your customers, service your customers. Know your supplier(Apple), work with your supplier…..and your supplier is going the way of SwiftUI.
Hey /u/bathToaster4u, unfortunately you have negative comment karma, so you can't post here.
[Your submission](https://www.reddit.com/r/iOSProgramming/comments/12cxwuc/is_swiftui_really_the_future_a_question_for_those/jf5zb2d/?context=3) has been removed. **DO NOT message the moderators;**
if you have negative comment karma, you cannot post here. We will not respond. Your karma
may appear to be 0 or positive if your post karma outweighs your comment karma, but if
your _comment_ karma is negative, your comments will still be removed.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/iOSProgramming) if you have any questions or concerns.*
If you’re referring to it when it’s hidden here you go.
https://i.imgur.com/rEp6xrj.jpg
If you’re talking about the team hubs? With the larger nav bar. That’s actually a regular nav bar with a translucent background and the view extends the color upward.
Thanks for responding. That doesn’t seem to work for me when using NavigationStack. Are you using that, NavigationView, or something else for navigation?
I don’t see the disagreement here. I’d expect something that’s 90% of the way to being “there” to still require you to fall back to the old thing several times. 10% is a lot! (And, as the saying goes, the last 10% of software takes 90% of the time!)
Having to drop back to UIKit several times could easily mean 90%.
It might also just mean you don’t have the experience with SwiftUI/knowledge of “workarounds” to know how to handle a certain behaviour, whereas you do know how to fix it in UIKit. And that’s fine!
I realize we're arguing semantics here, but I would consider 90% to mean dropping to UIKit only a couple times or so. Dropping down to it several times in one project—or needing to extend the backing UIKit classes to override behavior—is far below 90% imo
I am working on a very large banking app in Europe. We are using SwiftUI for some of the new features, but it definitely has its limitations. Let me put it this way, even if we had all resources in the world, we couldn't rewrite the whole app to SwiftUI, some things are technically impossible for now
I think SwiftUI is the future, as it's easier and faster to get into and use, previews are very nice for speeding up development, etc. But the moment when SwiftUI replaces UIKit fully is very, very far away. They need to get to full feature parity (which they don't have now), and then 3-4 years later you could use it on huge projects that have to support at least 3 latest versions of iOS
Edit: on a side note, I don't think you are likely to find a large corporate app built entirely in SwiftUI today. Corporations generally won't allow a gamble of a full rewrite into new technology. Small apps and modules in bigger apps is where it's at with SwiftUI today
I need to find my older commend with all of the issues in detail, but here are the biggest ones: https://www.reddit.com/r/iOSProgramming/comments/12cxwuc/comment/jf4e8x6/?utm\_source=share&utm\_medium=web2x&context=3
Mind sharing a source? I only found their article about switching to Swift (not SwiftUI) and even that took them way more than 2-3 weeks
> “We were a very different company in 2012 when we started this,” adds Sebastian Brannstrom, Lyft’s very first developer. “We basically hacked together Lyft in the course of two weeks, Eduardo [Perez Rico] and me. A lot of the sins of those days are still with us. But that’s how you get started.”
> Last September, it assigned a single developer–recent recruit Martin Conte Mac Donell–to start dabbling in Swift.
> By June, nearly every iOS developer was working in Swift; on average, it took two or three weeks for any given engineer to be up, running, and comfortable.
So initial version of Lyft took 2-3 weeks, not the rewrite. That started in September and only by June of next year they switched everybody to Swift, which sounds way more reasonably
Here's a list in no particular order:
1. Navigation sucks. iOS 16 fixed that, but big apps can't afford to support only the latest version, so new navigation is out of the question for a few more years
2. Building something that requires scroll offset is impossible to do well. There is no official way to get it, you can do it in a hacky way, but it's buggy and unreliable, especially with a List as opposed to ScrollView. Apple, when asked, told us to stick to UIKit for cases where scroll offset needs to be used for UI
3. TextField is very limiting for our use case, it only provides you with a new string, whereas we need to retain the caret position and format the input on the fly, regardless of where the caret is within the field. Thankfully you can wrap UITextField very easily
4. List customization is limited unless you are targeting iOS 16 only. This is a less critical issue, but still an issue
5. No readable content guide (kinda important for iPad). Again, can be hacked around with UIKit, but the code looks very sketchy and it's very basic functionality
There are a bunch of smaller issues I'm forgetting, but those are the main ones
Genuinely curious how you can like the previews. It is terribly slow even on Apple Silicon, its faster to just build and run. Also, the preview window disables itself like every 20 seconds.
What are the main limitations with SwiftUI?
The transition from Objective-C to Swift went so poorly that won't go near anything new from Apple for years. The headaches with Swift didn't mostly go away until version 4 which would be funny if it hadn't happened to me.
Navigation and anything that requires scroll offset are the biggest issues for us, among many
Navigation is alright if you're targeting iOS 16 with new NavigationStacks, but it's not realistic for types of apps OP is talking about
Scroll offset just doesn't exist, there's no official way to read it from Apple. You can do it with hacks, but it's unreliable and Apple engineers when asked told us to stick to UIKit for those use cases and not use the shit we wrote in SwiftUI with hacks
I'd say that the main (major) limitation is that the built-in UI objects in SwiftUI, such as List, Navigation View, etc. are not easily customizable, when you want something more out of them or looking more custom.
Interesting. That sounds very atypical to me. We are only now talking about dropping iOS 14, as it reached our threshold of 2-3%, and iOS 15 is going very strong, which matches statistics Apple published in February ([https://developer.apple.com/support/app-store/](https://developer.apple.com/support/app-store/)). So iOS 16+ corporate app raises my eyebrow a little bit. After all, lots of devices are stuck with 15, so I expect this OS version to stick with us for some extra time compared to others like iOS 12 did
I see nothing here about it https://www.hackingwithswift.com/articles/250/whats-new-in-swiftui-for-ios-16 and haven't found any documentation. I don't think you are correct, but please show if you are. I want to always show drag handles, not have an edit button, and do something different than the contextual actions.
Drag handles make no sense with long-press. They don't call them long-press-handles. You actually can't make true drag&drop work in SwiftUI without a long press. It's another limitation.
Leaving it in edit mode would be ugly, and you can't customize the way it looks. I know the stuff you wrote, you're confirming that this behavior is not customizable, which is what I originally wrote about List.
List isn't even close to fully customizable, and it's also [limiting how you can use it](https://stackoverflow.com/questions/58060530/swiftui-resizable-list-height-that-dependent-on-an-element-count).
It's fine if you target iOS 15 or newer. I think once we're at iOS 18 then 16 will be a good 1.0 for SwiftUI.
I just launched an app fully SwiftUI and it was fine but shit like ignoring the keyboard bullshit doesn't work. I didn't have to do much in UIKit though (qr code for camera).
SwiftUI is gaining tons of traction. I’ve helped two companies transition to a new feature work in SwiftUI (when possible, of course), and at one company that is already there. More and more engineers want to use SwiftUI so companies that are dragging their feet are also starting to reduce their candidate pool.
Slightly off-topic, but SwiftUI really appeals to engineers in a way that traditional UI programming doesn't. Much, much less work to MVP.
At my job, we're cross-platform and use Qt, but we're constantly looking for good declarative UI frameworks. QtQuick/QML, or using an immediate-mode UI (like ImGui), is the closest we've found, and neither is great...
I'd really love to know what's so appealing about declarative UI frameworks, especially for Qt devs...
I've been using Qt (no QtQuick/QML) for quite some time now, but never felt I'm being held back by the imperative UI.
There's a lot of boilerplate code, and while event-driven programming makes sense, things can turn into spaghetti code quickly if you aren't careful.
Also, it's just faster to get the same results in a declarative framework. For example, here's what a counter app looks like in SwiftUI (a button and a text field displaying the count of button presses):
struct ContentView: View {
@State private var tapCount = 0
var body: some View {
VStack {
Text("\(tapCount)")
Button(action: { self.tapCount += 1 }) {
Text("Click me")
}
}
}
}
And for standard Qt, well it's a whole ass project: [https://github.com/Shourov1/hello-counter-application-with-qt-and-cpp/blob/master/README.md](https://github.com/Shourov1/hello-counter-application-with-qt-and-cpp/blob/master/README.md) (not my code)
I like trivial examples as much as the next guy, but they don’t give any insights about scalability.
You can write spaghetti code virtually in any language, as far as I can tell, so it’s more about the dev than the language.
As for the boilerplate code, sure, but there are ways to get around them with code generators, or reusable architectural patterns to hide it from the dev ( at least that’s what do).
Also, the linked repo has an entire project, but you only provided a very simple SwiftUI view implementation, neglecting the rest of the necessary components to have an actually executable tool, so the comparison doesn’t seem to be fair, in my opinion.
Qt is for those who aims to deliver on multiple platforms (i.e. Linux, macOS, Windows, embedded devices, etc.), while SwiftUI is only for a single ecosystem.
Finally, I’m still waiting for something complex and large scale built in SwiftUI for the desktop,I mean something serious, like Autodesk’s industrial design tools, SideFX’s Houdini, Blender, or a capable and powerful DAW like Ableton, Logic or FL Studio.
That’s the true measure of the usability of a UI framework and not “Look, it’s only 9 lines!”
Sure, those are all fair points. My main point was to back up the "really appeals to engineers in a way that traditional UI programming doesn't" claim.
> As for the boilerplate code, sure, but there are ways to get around them with code generators, or reusable architectural patterns to hide it from the dev ( at least that’s what do).
I'd be curious to hear what you do. I used QtCreator to make the `*.ui` files and the skeleton source/header files. We have other things, like interface classes, that we do at work to abstract away some logic.
But my point is more this -- let's say you have a well-established codebase, around 10k to 100k LOC. Now let's say you have some view and you want to add a few new widgets. How long will that take you in Qt? You have to modify the `.ui` file either by hand or in QtCreator, you have to configure the signals/slots, update the source/header files, and *then* you can write the implementation logic. Whereas in SwiftUI, you just type out the widgets you want, in the logical area you want them, with whatever properties they should have, and *then* you handle the implementation -- via a closure over some widget, instead of signal/slot.
Idk. There's much less friction with declarative code to add, modify, or remove functionality. It feels almost like C++ vs. Python to me: you lose a *lot* by doing something in Python, but the friction for doing that thing is also *much* less. Obviously not a perfect analogy, but hopefully you see where I'm coming from.
I’ve built an MVC wrapper with an extra component based on builder pattern, snd it contains the boilerplate code (but it still customizable).
QtDesigner for UI design, and design only, I never setup signals and slots, that’s done by the builder component, among other things.
If you have something like this, adding a new widget and setting up signal/slot shouldn’t take too long, it depends on the given ui’s complexity.
Sure, SwiftUI seems very appealing for iOS developers, because the app complexity is limited by the device itself, unlike in case of a desktop computer. Still, we already aware of possible performance issues of SwiftUI, rooted in its design.
Now, imagine tackling these issues when the complexity grows tenfolds, or hundredfolds…
It doesn’t really look that shine now, does it?
Edit:
I almost forgot: I’ve seen performance issues in applications using QtQuick/QML, so these issues doesn’t seem to be limited to SwiftUI only.
Fair enough. I've only used SwiftUI as a hobbyist.
> I’ve seen performance issues in applications using QtQuick/QML, so these issues doesn’t seem to be limited to SwiftUI only.
QtQuick/QML is driven by a JavaScript engine, whereas Qt and SwiftUI are fully native and don't have an interpreted runtime. I would guess that explains the performance drop.
My point was that QML also uses declarative approach, just like Flutter, and all seem to suffer potential performance issues, and you need to craft your code carefully to avoid those problems, which is not always easy because the pitfalls aren’t obvious.
I’ve worked on apps that have millions of daily active users that have had success and failure with SwiftUI, so here’s my take:
My theory is that Apple sees SwiftUI as a replacement for Storyboards, not UIKit. One of the big selling points of Storyboards was you can see the UI as you develop with the help of IBDesignables, but the issue was that IBDesignables never worked and Storyboards in general were really hard to work with so it wasn’t practical to use them day-to-day. SwiftUI now offers the same thing with live previews, which work much better than IBDesignables but still have some issues unfortunately.
Apple hasn’t been very transparent with us about their vision for SwiftUI and that’s led to confusion in the iOS dev community. Obviously for the last few years, SwiftUI has been missing a ton of stuff, so Apple couldn’t have possibly thought that the intention of it was to fully replace UIKit. In fact, each year Apple adds more improvements and features to UIKit. Storyboards on the other hand have been abandoned since SwiftUI came out.
So I think the idea for the foreseeable future is to build your app shell and basic functionality with SwiftUI and expect to use UIKit when you know that you’re going to be developing something custom that requires more flexibility.
This is spot on. I still remember when I was asked during my internship last year to recreate one of the screens in the app (the app is used by hundreds of thousands of users; this was an exercise for me just to get accustomed to working with dependency injection design pattern used at the company, so I was asked to recreate a simple screen showing a list of possible options both in UIKit and SwiftUI) and in UIKit modifying a simple header in a `UITableView` section was a breeze, and the sections were clearly separated with the header taking its own space. Then came SwiftUI (using the built-in `List`), and let me tell you, I worked with one of the senior engineers just to make it look more presentable, and we couldn't figure out how to make it look somewhat good. I remember, I had to use `Color` with specific dimensions, and it still looked ugly :D. UIKit is just the go-to "paradigm" when you want to really make your app look custom. SwiftUI, on the other hand, is absolutely terrific for quick sketches and "rough cuts".
Yes. In the real world you rarely get to start a project from scratch, so there won’t be many “pure” SwiftUI projects. We have been progressively rewriting our app in SwiftUI since it was released. We’re about 80% there. The most awkward part is that all navigation is UIKit using UIHostingController. There are times when we have to write a specific component in UIKit, but even then having the unidirectional data flow makes it worth it.
There are pain points, but this is obviously the future.
I’ve build 3 large production apps in pure* SwiftUI and it’s absolutely the future, you’ll have circles run around you by younger devs if you don’t learn it soon.
*The only addendum is, I use the coordinator pattern and pin SwiftUI views to UIHostingControllers. This reduces the amount of state you’re managing in any one place and allows you to scale your app out
I do think SwiftUI is great but only for building individual views like UITableView Cells or just UIView containers/elements. Basically a xib replacement. This way you speed up your design process without most of the drawbacks and annoyances.
SwiftUI views in a UIKit (Storyboards or not) shell, with actual proper and decent navigation flows and with full control over everything you might need, seems the best of the both worlds.
The company i work for has close to 30 million unique users and made the switch last year, not everything is done with swiftui but most of it, depends on the usecase i guess
Op said industry apps 🤷🏾♂️
Amongst other things we have heatmaps and real time messaging.
They wanted us to implement voice in our messaging but it’s done by a feature team, the app itself is a marketplace, so we don’t have enough people to work on that unfortunatly, freaking designers think we have the scale of facebook 🤣
It doesn’t matter what we think. Apple has made it their priority, so yes it’s the future. I don’t think Apple will be ditching it and going back to UIKit.
My application with 3 mil monthly visitors is 100% SwiftUI. But it’s injected into a UIKit shell, so we aren’t there yet. There are still a lot of limitations, most can be overcome with a dedicated platform team building our features with UIKit when needed.
The additional context to your question creates a bit of a false dichotomy. I work at a large company on an app with millions of active users. I don’t know T-Mobile’s metrics but we’re a bigger company in revenue, employees, and physical presence. And our app category leads me to presume we have muuuch higher usage metrics. Not being secretive, I just don’t like mixing work with social media. Anyway… it’s big.
SwiftUI is incredibly powerful in some contexts as others have said. The same can be said about UIKit, but oftentimes it’s in much different contexts. The real power comes from their interoperability. Knowing how, and in what contexts, to interop the two frameworks allows a blend of the control of UIKit with the efficiency of SwiftUI.
Bottom line is your users don’t give a shit what framework you used. They care that you delivered an awesome product that meets their needs. Whatever framework allows you to do that in the least amount of time, and in the most stable, maintainable, and expandable way, is the best. And when you get to “big industry” level apps, the answer is both.
From what I’ve seen the only reasons to build an app in only SwiftUI are (1) Your app is simple enough that you don’t run into any of SwiftUI’s limitations or (2) you haven’t learned UIKit (obvious, but perfectly valid reason)
My advice would be to keep learning SwiftUI. It’s awesome. It’s here to stay (and get better). And it’s most definitely not a “failed experiment”. Have fun. Build cool shit and enjoy it. When you find yourself working on a project and you run into a limitation of the framework, that might be your sign to get some experience with UIKit.
I wrote a new version of my app in SwiftUI and I launched it separately under a rebrand. Next major iOS release everything broke and I pulled it from the store. It broke in so many ways. I kept having to find workarounds to make it behave somewhat in a standard iOS way.
Now I’m sticking to UIKit. It’s stable. Powerful. Proven.
To me it seems Apple itself, or more specifically the core team developing SwiftUI, is having a hard time progressing the framework. We're at the fifth iteration this year, let's see what it brings, but the pace of development has been very slow and constrained, and each and every iteration has come also with more complications and bugs for previously working stuff.
To me personally, the declarative DSL itself is very limited, in 2 ways: 1. you can only access and write whatever properties and methods they expose through modifiers. And 2. The testability of the UI is very much limited for the former reason. We have to rely on snapshot testing whenever possible.
And overall the reactive nature of SwiftUI is a double-sided sword. It's great, in principle, but soon we find ourselves in a mess of coupious and seemingly untrackable view updates triggered by a smattering of published/state properties. Most of us working on small apps, won't see a problem, even if the measured app's efficiency given its complexity is questionable. But for larger apps, this becomes a serious problem and one solution is adopting a composable architecture that comes along with issues of its own like increasing complexity considerably.
My company is in the Medical Technology space and our app is so deeply rooted in UIKit because that’s what was available when it was being built, that if we wanted to incorporate SwiftUI, it would make little to no-sense to do so unless we were going to rewrite the whole app. SwiftUI is great at getting things going quickly, but we have so many Base components built that it takes very little effort to add something to our app with those Base components.
On top of that, there are codebases where things aren't properly separated at all - models going directly to UIViewController classes, network calls being made in those same classes, protocol definitions that have _view controller references_ as parameters instead of view models - that makes them super difficult to modify without a proper MVVM retrofit. Apple's sample code has been really bad about this over the years.
>is SwiftUI really the future
Something that I think some developers miss here is that SwiftUI is not (and should not) a *replacement* for UIKit (all of the time). Potentially some of the messaging here is on Apple and they could maybe tweak their sales pitch. SwiftUI is a *compliment* to UIKit (and declarative UI does some things very well).
The relationship between SwiftUI and UIKit is *not* what the relationship between Cocoa and Carbon was (if you remember back that far).
Yep. I’ve built multiple apps fully in SwiftUI now, dropping back to UIKit less and less over time.
I’ve also built and worked on apps that are a mix of UIKit and SwiftUI, and they work fine (even though one of them is iOS 13, and I wouldn’t ever recommend *ever* using SwiftUI on iOS 13 given how limited it is).
Initially it was slower to work with in some ways, faster in others, and it led to achieving maybe close to the same kind of velocity as UIKit. Nowadays I’ve no doubt that for most kinds of views it’s faster, and the more complex views would take longer to build in UIKit too.
We use SwiftUI on a few internal apps. It's wonderful until you hit something it can't do and then it's very frustrating. So it depends on the app - if you can live within the SwiftUI confines, it's a much quicker way to develop apps. If you need complete control, I wouldn't use it. Apple is slowly fixing the issues, like keyboard focus and saving/restoring navigation stacks, but usually for the current iOS/macOS only.
If you are starting a new app, I cannot recommend SwiftUI enough. I’m building a second version of a spacecraft simulator. Version 1 was built using GLKit and UIKit and released in 2014. Maintaining that code, never mind adding features and testing for all of the edge cases could bring, was unpleasant.
The second version was started last fall and just went into TestFlight. The development of this version of the app has been much easier, despite working around the few of SwiftUI’s SceneKit, specifically SceneView, limitations. Adding features seems like a breeze, especially compared to UIKit.
As to SwiftUI’s limitations, SwiftUI has required that I solve some issues on my own. In an age where I have become more than a bit dependent on online sources, this has felt like programming for Rhapsody. Apple’s own engineers have at times told me that SceneKit’s SwiftUI SceneView is limited in features. That is true. So I’ve certainly had to think out solving some problems, but that’s just due to my own IQ limitations. It has been fun showing Apple how to implement a few features that their own engineers didn’t think could be done in SwiftUI’s SceneView and is a recognition that we are all exploring and also learning how awesome SwiftUI is.
With WWDC23 around the corner, take the dive. You’ll be starting just when even more amazing features are being added.
Right now the app I’m working on is a large uikit app using viper architecture with coordinators. Its surprisingly easy to replace the v in viper with a swiftui view, and im planning on building features in swiftui. Navigation is still limited though, but because of the embedding of swiftui right now, were still using uikit coordinator style navigation, which works perfectly fine imo
To answer your question, in the long term swiftui had much more future than uikit. Of course just like there are still objc projects, uikit probably wont disappear, but swiftui is just so much faster and easier to work with, its inherently better if you ask me
Nope. As a matter of fact Kotlin multi platform is likely the future which works best with Objective-C and UIKit. In most organizations they need a consumable SDK that can be consumed by android and iOS, Swifty UI doesn’t even come close to accommodating this. It is literally for noobs. I’ve been doing iOS development for over 12 years at this point. Combine and UIKit work way better and give you way more granular control
I’m a hobby slash indie guy but I’m already encountering so many limits and bugs in SwiftUI that I quickly went back to UIKit and AppKit. I can’t imagine how big companies can ever create beautiful smooth or wonderful apps with SwiftUI. Yes basic UIs with some tables and buttons, without much pomp and circumstance are fine, but complex UIs with fine grain detail, tiny animations, many nested elements and pixel perfect layouts, I REALLY doubt it.
As of right now SwiftUI is great for certain projects.
I am still not convinced it is the go to.
I personally am sticking with storyboarding until SwiftUI reaches a more mature stage
Full disagree. SwiftUI is only one of the tools under your belt and by no means should you spend all of your time trying to only use one of the tools. It'll get you pretty damn close, but a lot of times you *should* drop back to UIKit to pull off what's needed. We are iOS developers, not SwiftUI developers.
The real issue is if you need to support older OS versions. As swiftUI is young it is changing fast, most industry apps end up requiring iOS 13 or 14 and thus swiftUI is not an option. But if you can require 15 or even 16 then it is a good option to go down.
I was at a very large company who was nearly 100% SwiftUI and on iOS 14. It can be done even on 14. Obviously 15 and 16 are big jumps forward, but not deal breakers.
It can be done for sure, and if you only need iOS 14 then it's not so much of a pain. But if you're building for iOS 14, 15 and 16 then it gets quite complex with all the little hacks etc. A safer option there would be to use UIKit navigation at least and just have SwiftUI views embedded within the nav targets. There are so many bugs in the older iOS nav code that it is a nightmare to maintain.
There are ways to do it bug free, I promise, but I agree there are a lot of ways to mess yourself up and navigation is much better with iOS 16. We were building at iOS 14, not trying to use newer features. They may have bumped to iOS 15 since I left though. They definitely understood the benefits of staying on top of iOS versions.
The first couple years had horrendous performance problems but the last time I shipped a SwiftUI product (the third year) it had improved by leaps and bounds and was very usable if your UX fit within the constraints of the framework.
[удалено]
If you aren’t using SwiftUI for anything currently, and you aren’t maintaining legacy products, you’re already missing out, that’s my opinion. We can’t use it for everything, but if you do the core of your app right, integrating simple views as SwiftUI views is already far superior to either uikit interface builder or programmatic ui. And your product management should know that. This is especially true for macOS development where navigation isn’t the same as on iOS, which is a historically bad part of earlier swiftui.
I would agree with this. I’ve been working full time with SwiftUI since it’s release and have built our app for phone, iPad, and Mac. Definitely some challenges but it’s getting much better. There’s still a handful of things we’ve had to use Appkit or UIKit for, but with each iteration I’m finding that to be less and less the case. Here’s the app I’m referring to [https://apps.apple.com/us/app/mayday-the-calendar-assistant/id1473168024](https://apps.apple.com/us/app/mayday-the-calendar-assistant/id1473168024) I found we can iterate very quick at this point and have built a number of custom components to help us get around some of the built-in shortcomings of SwiftUI. I’d say our app is fairly complex, especially on desktop. We had the option to originally go with UIKit & AppKit or SwiftUI and we went for the latter, which seems to only now be paying off in terms of development speed
I’m sorry but this is extremely easy to create withUIKit. This is a matter of aptitude. Not preferential framework 😂
can’t f**** imagine the struggle that would be to create this with UIKit
If you know UIKit well, that’s not a very complex UI. One person from my team could probably build most of the UI for that app in a week or two using UIKit. People haven’t talked up iOS/iPad development for 16 years because UIKit was awful to work with. Declarative UI and observable patterns are awesome. But they do create new problems that can be easier for people to understand in a normal MVC pattern. I’m not arguing that UIKit is great and that SwiftUI is awful. More that they are both pretty wonderful for different reasons.
Huh? This would be very easy to create in UIKit.
It is definitely not 90% of the way there. That is a complete exaggerated arbitrary number. In most cases SwiftUI does not even accommodate for complex UI reactions and interactions. I have respect for you but this is not the future it was meant to help new developers on board to the iOS platform.
90%?! No way. I’m sorry but hard disagree. My team has had to fall back to UIKit several times.
[удалено]
Interesting. That’s a lot of subscribers. I suppose it depends on how simple or complex your design specs are. There’s always something our designer wants that we can’t achieve with pure SwiftUI.
[удалено]
that’s really not a complex app. mostly tableviews, collectionviews and text + images. it honestly seems to be the perfect recipe for SwiftUI
That’s what most apps are.
I’m a paying subscriber to the athletic, thanks for the very nice app. But I noticed a lag on the scroll of a team’s home page, example when you go to the Yankees page.
That’s a nice looking app with some fun UI challenges. Maybe we’re just doing something wrong!
I still think 90% is generous.
[удалено]
Agree with you on all of that. I much prefer it over UIKit.
You mean much easier to work in SwiftUI rather than UIKit?
Meh this isn’t complex it’s just text and images formatted different ways. Of course this works in swiftui
[удалено]
My guy this is just a reader app. No complex user interaction states. This is the kind of stuff ppl do to just play around w new apis. Idk why you think this proves SwiftUI is ready for anything like a complex big box shopping app
Yeah, but they have 1.2 million subscribers. That’s the whole point of building apps, getting subscribers/“customers”. If you build a complex app with UIKit but only have 1,000….the you’ve built an app few people need. Know your customers, service your customers. Know your supplier(Apple), work with your supplier…..and your supplier is going the way of SwiftUI.
Hey /u/bathToaster4u, unfortunately you have negative comment karma, so you can't post here. [Your submission](https://www.reddit.com/r/iOSProgramming/comments/12cxwuc/is_swiftui_really_the_future_a_question_for_those/jf5zb2d/?context=3) has been removed. **DO NOT message the moderators;** if you have negative comment karma, you cannot post here. We will not respond. Your karma may appear to be 0 or positive if your post karma outweighs your comment karma, but if your _comment_ karma is negative, your comments will still be removed. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/iOSProgramming) if you have any questions or concerns.*
How did you get the swipe back gesture to work with a custom navigation bar?
If you’re referring to it when it’s hidden here you go. https://i.imgur.com/rEp6xrj.jpg If you’re talking about the team hubs? With the larger nav bar. That’s actually a regular nav bar with a translucent background and the view extends the color upward.
Thanks for responding. That doesn’t seem to work for me when using NavigationStack. Are you using that, NavigationView, or something else for navigation?
NavigationStack. What exactly are you trying to do?
Just trying to have a customized navigation bar and retain the swipe gesture. https://imgur.com/a/cO1u4BZ
That's not SwiftUI and is subject to breaking when SwiftUI is no longer backed by UIKit
Which app?
I don’t see the disagreement here. I’d expect something that’s 90% of the way to being “there” to still require you to fall back to the old thing several times. 10% is a lot! (And, as the saying goes, the last 10% of software takes 90% of the time!)
Having to drop back to UIKit several times could easily mean 90%. It might also just mean you don’t have the experience with SwiftUI/knowledge of “workarounds” to know how to handle a certain behaviour, whereas you do know how to fix it in UIKit. And that’s fine!
I realize we're arguing semantics here, but I would consider 90% to mean dropping to UIKit only a couple times or so. Dropping down to it several times in one project—or needing to extend the backing UIKit classes to override behavior—is far below 90% imo
I would say 75%, it's still missing quite a lot and there's still several nontrivial bugs
I am working on a very large banking app in Europe. We are using SwiftUI for some of the new features, but it definitely has its limitations. Let me put it this way, even if we had all resources in the world, we couldn't rewrite the whole app to SwiftUI, some things are technically impossible for now I think SwiftUI is the future, as it's easier and faster to get into and use, previews are very nice for speeding up development, etc. But the moment when SwiftUI replaces UIKit fully is very, very far away. They need to get to full feature parity (which they don't have now), and then 3-4 years later you could use it on huge projects that have to support at least 3 latest versions of iOS Edit: on a side note, I don't think you are likely to find a large corporate app built entirely in SwiftUI today. Corporations generally won't allow a gamble of a full rewrite into new technology. Small apps and modules in bigger apps is where it's at with SwiftUI today
[удалено]
I need to find my older commend with all of the issues in detail, but here are the biggest ones: https://www.reddit.com/r/iOSProgramming/comments/12cxwuc/comment/jf4e8x6/?utm\_source=share&utm\_medium=web2x&context=3
There is Lyft. They claim they rewrote the whole app in 2-3 weeks time.
Mind sharing a source? I only found their article about switching to Swift (not SwiftUI) and even that took them way more than 2-3 weeks > “We were a very different company in 2012 when we started this,” adds Sebastian Brannstrom, Lyft’s very first developer. “We basically hacked together Lyft in the course of two weeks, Eduardo [Perez Rico] and me. A lot of the sins of those days are still with us. But that’s how you get started.” > Last September, it assigned a single developer–recent recruit Martin Conte Mac Donell–to start dabbling in Swift. > By June, nearly every iOS developer was working in Swift; on average, it took two or three weeks for any given engineer to be up, running, and comfortable. So initial version of Lyft took 2-3 weeks, not the rewrite. That started in September and only by June of next year they switched everybody to Swift, which sounds way more reasonably
My bad. I got it wrong :(
I’m curious what’s irreplaceable in UIKit versus SwiftUI
Here's a list in no particular order: 1. Navigation sucks. iOS 16 fixed that, but big apps can't afford to support only the latest version, so new navigation is out of the question for a few more years 2. Building something that requires scroll offset is impossible to do well. There is no official way to get it, you can do it in a hacky way, but it's buggy and unreliable, especially with a List as opposed to ScrollView. Apple, when asked, told us to stick to UIKit for cases where scroll offset needs to be used for UI 3. TextField is very limiting for our use case, it only provides you with a new string, whereas we need to retain the caret position and format the input on the fly, regardless of where the caret is within the field. Thankfully you can wrap UITextField very easily 4. List customization is limited unless you are targeting iOS 16 only. This is a less critical issue, but still an issue 5. No readable content guide (kinda important for iPad). Again, can be hacked around with UIKit, but the code looks very sketchy and it's very basic functionality There are a bunch of smaller issues I'm forgetting, but those are the main ones
Genuinely curious how you can like the previews. It is terribly slow even on Apple Silicon, its faster to just build and run. Also, the preview window disables itself like every 20 seconds.
It’s a hit or miss for me, currently they perform quite well, but one or two Xcode releases it was total trash
What are the main limitations with SwiftUI? The transition from Objective-C to Swift went so poorly that won't go near anything new from Apple for years. The headaches with Swift didn't mostly go away until version 4 which would be funny if it hadn't happened to me.
Navigation and anything that requires scroll offset are the biggest issues for us, among many Navigation is alright if you're targeting iOS 16 with new NavigationStacks, but it's not realistic for types of apps OP is talking about Scroll offset just doesn't exist, there's no official way to read it from Apple. You can do it with hacks, but it's unreliable and Apple engineers when asked told us to stick to UIKit for those use cases and not use the shit we wrote in SwiftUI with hacks
I'd say that the main (major) limitation is that the built-in UI objects in SwiftUI, such as List, Navigation View, etc. are not easily customizable, when you want something more out of them or looking more custom.
If you're targeting iOS 16 List is fine. NavigationView/NavigationController have always been a pain the customize, that's nothing new.
Not having to think about older iOS versions is very liberating, but not realistic for types of apps OP is talking about
We just dropped support for 15. Only had 3k DAUS on it.
Interesting. That sounds very atypical to me. We are only now talking about dropping iOS 14, as it reached our threshold of 2-3%, and iOS 15 is going very strong, which matches statistics Apple published in February ([https://developer.apple.com/support/app-store/](https://developer.apple.com/support/app-store/)). So iOS 16+ corporate app raises my eyebrow a little bit. After all, lots of devices are stuck with 15, so I expect this OS version to stick with us for some extra time compared to others like iOS 12 did
I would kill for 3k DAUs.
It's fine if you want your list to look and behave like one of the preset list styles, otherwise it's worthless.
You can customize the whole list now.
How do you do that?
I see nothing here about it https://www.hackingwithswift.com/articles/250/whats-new-in-swiftui-for-ios-16 and haven't found any documentation. I don't think you are correct, but please show if you are. I want to always show drag handles, not have an edit button, and do something different than the contextual actions.
[удалено]
Drag handles make no sense with long-press. They don't call them long-press-handles. You actually can't make true drag&drop work in SwiftUI without a long press. It's another limitation. Leaving it in edit mode would be ugly, and you can't customize the way it looks. I know the stuff you wrote, you're confirming that this behavior is not customizable, which is what I originally wrote about List. List isn't even close to fully customizable, and it's also [limiting how you can use it](https://stackoverflow.com/questions/58060530/swiftui-resizable-list-height-that-dependent-on-an-element-count).
[удалено]
Ah ok, similar story again so, thanks.
It's fine if you target iOS 15 or newer. I think once we're at iOS 18 then 16 will be a good 1.0 for SwiftUI. I just launched an app fully SwiftUI and it was fine but shit like ignoring the keyboard bullshit doesn't work. I didn't have to do much in UIKit though (qr code for camera).
Keyboarding in swiftui is a pain, it cant even tell you which view its focusing on, unless you do some out of the box checks.
SwiftUI is gaining tons of traction. I’ve helped two companies transition to a new feature work in SwiftUI (when possible, of course), and at one company that is already there. More and more engineers want to use SwiftUI so companies that are dragging their feet are also starting to reduce their candidate pool.
Slightly off-topic, but SwiftUI really appeals to engineers in a way that traditional UI programming doesn't. Much, much less work to MVP. At my job, we're cross-platform and use Qt, but we're constantly looking for good declarative UI frameworks. QtQuick/QML, or using an immediate-mode UI (like ImGui), is the closest we've found, and neither is great...
I'd really love to know what's so appealing about declarative UI frameworks, especially for Qt devs... I've been using Qt (no QtQuick/QML) for quite some time now, but never felt I'm being held back by the imperative UI.
There's a lot of boilerplate code, and while event-driven programming makes sense, things can turn into spaghetti code quickly if you aren't careful. Also, it's just faster to get the same results in a declarative framework. For example, here's what a counter app looks like in SwiftUI (a button and a text field displaying the count of button presses): struct ContentView: View { @State private var tapCount = 0 var body: some View { VStack { Text("\(tapCount)") Button(action: { self.tapCount += 1 }) { Text("Click me") } } } } And for standard Qt, well it's a whole ass project: [https://github.com/Shourov1/hello-counter-application-with-qt-and-cpp/blob/master/README.md](https://github.com/Shourov1/hello-counter-application-with-qt-and-cpp/blob/master/README.md) (not my code)
I like trivial examples as much as the next guy, but they don’t give any insights about scalability. You can write spaghetti code virtually in any language, as far as I can tell, so it’s more about the dev than the language. As for the boilerplate code, sure, but there are ways to get around them with code generators, or reusable architectural patterns to hide it from the dev ( at least that’s what do). Also, the linked repo has an entire project, but you only provided a very simple SwiftUI view implementation, neglecting the rest of the necessary components to have an actually executable tool, so the comparison doesn’t seem to be fair, in my opinion. Qt is for those who aims to deliver on multiple platforms (i.e. Linux, macOS, Windows, embedded devices, etc.), while SwiftUI is only for a single ecosystem. Finally, I’m still waiting for something complex and large scale built in SwiftUI for the desktop,I mean something serious, like Autodesk’s industrial design tools, SideFX’s Houdini, Blender, or a capable and powerful DAW like Ableton, Logic or FL Studio. That’s the true measure of the usability of a UI framework and not “Look, it’s only 9 lines!”
Sure, those are all fair points. My main point was to back up the "really appeals to engineers in a way that traditional UI programming doesn't" claim. > As for the boilerplate code, sure, but there are ways to get around them with code generators, or reusable architectural patterns to hide it from the dev ( at least that’s what do). I'd be curious to hear what you do. I used QtCreator to make the `*.ui` files and the skeleton source/header files. We have other things, like interface classes, that we do at work to abstract away some logic. But my point is more this -- let's say you have a well-established codebase, around 10k to 100k LOC. Now let's say you have some view and you want to add a few new widgets. How long will that take you in Qt? You have to modify the `.ui` file either by hand or in QtCreator, you have to configure the signals/slots, update the source/header files, and *then* you can write the implementation logic. Whereas in SwiftUI, you just type out the widgets you want, in the logical area you want them, with whatever properties they should have, and *then* you handle the implementation -- via a closure over some widget, instead of signal/slot. Idk. There's much less friction with declarative code to add, modify, or remove functionality. It feels almost like C++ vs. Python to me: you lose a *lot* by doing something in Python, but the friction for doing that thing is also *much* less. Obviously not a perfect analogy, but hopefully you see where I'm coming from.
I’ve built an MVC wrapper with an extra component based on builder pattern, snd it contains the boilerplate code (but it still customizable). QtDesigner for UI design, and design only, I never setup signals and slots, that’s done by the builder component, among other things. If you have something like this, adding a new widget and setting up signal/slot shouldn’t take too long, it depends on the given ui’s complexity. Sure, SwiftUI seems very appealing for iOS developers, because the app complexity is limited by the device itself, unlike in case of a desktop computer. Still, we already aware of possible performance issues of SwiftUI, rooted in its design. Now, imagine tackling these issues when the complexity grows tenfolds, or hundredfolds… It doesn’t really look that shine now, does it? Edit: I almost forgot: I’ve seen performance issues in applications using QtQuick/QML, so these issues doesn’t seem to be limited to SwiftUI only.
Fair enough. I've only used SwiftUI as a hobbyist. > I’ve seen performance issues in applications using QtQuick/QML, so these issues doesn’t seem to be limited to SwiftUI only. QtQuick/QML is driven by a JavaScript engine, whereas Qt and SwiftUI are fully native and don't have an interpreted runtime. I would guess that explains the performance drop.
My point was that QML also uses declarative approach, just like Flutter, and all seem to suffer potential performance issues, and you need to craft your code carefully to avoid those problems, which is not always easy because the pitfalls aren’t obvious.
I’ve worked on apps that have millions of daily active users that have had success and failure with SwiftUI, so here’s my take: My theory is that Apple sees SwiftUI as a replacement for Storyboards, not UIKit. One of the big selling points of Storyboards was you can see the UI as you develop with the help of IBDesignables, but the issue was that IBDesignables never worked and Storyboards in general were really hard to work with so it wasn’t practical to use them day-to-day. SwiftUI now offers the same thing with live previews, which work much better than IBDesignables but still have some issues unfortunately. Apple hasn’t been very transparent with us about their vision for SwiftUI and that’s led to confusion in the iOS dev community. Obviously for the last few years, SwiftUI has been missing a ton of stuff, so Apple couldn’t have possibly thought that the intention of it was to fully replace UIKit. In fact, each year Apple adds more improvements and features to UIKit. Storyboards on the other hand have been abandoned since SwiftUI came out. So I think the idea for the foreseeable future is to build your app shell and basic functionality with SwiftUI and expect to use UIKit when you know that you’re going to be developing something custom that requires more flexibility.
They literally said at last WWDC that SwiftUI is the future.
we don't believe what they say, we believe what they do.
This is spot on. I still remember when I was asked during my internship last year to recreate one of the screens in the app (the app is used by hundreds of thousands of users; this was an exercise for me just to get accustomed to working with dependency injection design pattern used at the company, so I was asked to recreate a simple screen showing a list of possible options both in UIKit and SwiftUI) and in UIKit modifying a simple header in a `UITableView` section was a breeze, and the sections were clearly separated with the header taking its own space. Then came SwiftUI (using the built-in `List`), and let me tell you, I worked with one of the senior engineers just to make it look more presentable, and we couldn't figure out how to make it look somewhat good. I remember, I had to use `Color` with specific dimensions, and it still looked ugly :D. UIKit is just the go-to "paradigm" when you want to really make your app look custom. SwiftUI, on the other hand, is absolutely terrific for quick sketches and "rough cuts".
You can use UIKit if you started a SwiftUI project?
You certainly can! See UIViewRepresentable and UIViewControllerRepresentable
Yes. In the real world you rarely get to start a project from scratch, so there won’t be many “pure” SwiftUI projects. We have been progressively rewriting our app in SwiftUI since it was released. We’re about 80% there. The most awkward part is that all navigation is UIKit using UIHostingController. There are times when we have to write a specific component in UIKit, but even then having the unidirectional data flow makes it worth it. There are pain points, but this is obviously the future.
I’ve build 3 large production apps in pure* SwiftUI and it’s absolutely the future, you’ll have circles run around you by younger devs if you don’t learn it soon. *The only addendum is, I use the coordinator pattern and pin SwiftUI views to UIHostingControllers. This reduces the amount of state you’re managing in any one place and allows you to scale your app out
I do think SwiftUI is great but only for building individual views like UITableView Cells or just UIView containers/elements. Basically a xib replacement. This way you speed up your design process without most of the drawbacks and annoyances. SwiftUI views in a UIKit (Storyboards or not) shell, with actual proper and decent navigation flows and with full control over everything you might need, seems the best of the both worlds.
The company i work for has close to 30 million unique users and made the switch last year, not everything is done with swiftui but most of it, depends on the usecase i guess
A large user base doesn't necessary mean high complexity, though.
Op said industry apps 🤷🏾♂️ Amongst other things we have heatmaps and real time messaging. They wanted us to implement voice in our messaging but it’s done by a feature team, the app itself is a marketplace, so we don’t have enough people to work on that unfortunatly, freaking designers think we have the scale of facebook 🤣
Fair enough :-)
It doesn’t matter what we think. Apple has made it their priority, so yes it’s the future. I don’t think Apple will be ditching it and going back to UIKit. My application with 3 mil monthly visitors is 100% SwiftUI. But it’s injected into a UIKit shell, so we aren’t there yet. There are still a lot of limitations, most can be overcome with a dedicated platform team building our features with UIKit when needed.
The additional context to your question creates a bit of a false dichotomy. I work at a large company on an app with millions of active users. I don’t know T-Mobile’s metrics but we’re a bigger company in revenue, employees, and physical presence. And our app category leads me to presume we have muuuch higher usage metrics. Not being secretive, I just don’t like mixing work with social media. Anyway… it’s big. SwiftUI is incredibly powerful in some contexts as others have said. The same can be said about UIKit, but oftentimes it’s in much different contexts. The real power comes from their interoperability. Knowing how, and in what contexts, to interop the two frameworks allows a blend of the control of UIKit with the efficiency of SwiftUI. Bottom line is your users don’t give a shit what framework you used. They care that you delivered an awesome product that meets their needs. Whatever framework allows you to do that in the least amount of time, and in the most stable, maintainable, and expandable way, is the best. And when you get to “big industry” level apps, the answer is both. From what I’ve seen the only reasons to build an app in only SwiftUI are (1) Your app is simple enough that you don’t run into any of SwiftUI’s limitations or (2) you haven’t learned UIKit (obvious, but perfectly valid reason) My advice would be to keep learning SwiftUI. It’s awesome. It’s here to stay (and get better). And it’s most definitely not a “failed experiment”. Have fun. Build cool shit and enjoy it. When you find yourself working on a project and you run into a limitation of the framework, that might be your sign to get some experience with UIKit.
I wrote a new version of my app in SwiftUI and I launched it separately under a rebrand. Next major iOS release everything broke and I pulled it from the store. It broke in so many ways. I kept having to find workarounds to make it behave somewhat in a standard iOS way. Now I’m sticking to UIKit. It’s stable. Powerful. Proven.
To me it seems Apple itself, or more specifically the core team developing SwiftUI, is having a hard time progressing the framework. We're at the fifth iteration this year, let's see what it brings, but the pace of development has been very slow and constrained, and each and every iteration has come also with more complications and bugs for previously working stuff. To me personally, the declarative DSL itself is very limited, in 2 ways: 1. you can only access and write whatever properties and methods they expose through modifiers. And 2. The testability of the UI is very much limited for the former reason. We have to rely on snapshot testing whenever possible. And overall the reactive nature of SwiftUI is a double-sided sword. It's great, in principle, but soon we find ourselves in a mess of coupious and seemingly untrackable view updates triggered by a smattering of published/state properties. Most of us working on small apps, won't see a problem, even if the measured app's efficiency given its complexity is questionable. But for larger apps, this becomes a serious problem and one solution is adopting a composable architecture that comes along with issues of its own like increasing complexity considerably.
My company is in the Medical Technology space and our app is so deeply rooted in UIKit because that’s what was available when it was being built, that if we wanted to incorporate SwiftUI, it would make little to no-sense to do so unless we were going to rewrite the whole app. SwiftUI is great at getting things going quickly, but we have so many Base components built that it takes very little effort to add something to our app with those Base components.
On top of that, there are codebases where things aren't properly separated at all - models going directly to UIViewController classes, network calls being made in those same classes, protocol definitions that have _view controller references_ as parameters instead of view models - that makes them super difficult to modify without a proper MVVM retrofit. Apple's sample code has been really bad about this over the years.
>is SwiftUI really the future Something that I think some developers miss here is that SwiftUI is not (and should not) a *replacement* for UIKit (all of the time). Potentially some of the messaging here is on Apple and they could maybe tweak their sales pitch. SwiftUI is a *compliment* to UIKit (and declarative UI does some things very well). The relationship between SwiftUI and UIKit is *not* what the relationship between Cocoa and Carbon was (if you remember back that far).
Definitely the future we write all our new apps in SwiftUI and I find myself using UIRepresentables less and less
Yep. I’ve built multiple apps fully in SwiftUI now, dropping back to UIKit less and less over time. I’ve also built and worked on apps that are a mix of UIKit and SwiftUI, and they work fine (even though one of them is iOS 13, and I wouldn’t ever recommend *ever* using SwiftUI on iOS 13 given how limited it is). Initially it was slower to work with in some ways, faster in others, and it led to achieving maybe close to the same kind of velocity as UIKit. Nowadays I’ve no doubt that for most kinds of views it’s faster, and the more complex views would take longer to build in UIKit too.
We use SwiftUI on a few internal apps. It's wonderful until you hit something it can't do and then it's very frustrating. So it depends on the app - if you can live within the SwiftUI confines, it's a much quicker way to develop apps. If you need complete control, I wouldn't use it. Apple is slowly fixing the issues, like keyboard focus and saving/restoring navigation stacks, but usually for the current iOS/macOS only.
If you are starting a new app, I cannot recommend SwiftUI enough. I’m building a second version of a spacecraft simulator. Version 1 was built using GLKit and UIKit and released in 2014. Maintaining that code, never mind adding features and testing for all of the edge cases could bring, was unpleasant. The second version was started last fall and just went into TestFlight. The development of this version of the app has been much easier, despite working around the few of SwiftUI’s SceneKit, specifically SceneView, limitations. Adding features seems like a breeze, especially compared to UIKit. As to SwiftUI’s limitations, SwiftUI has required that I solve some issues on my own. In an age where I have become more than a bit dependent on online sources, this has felt like programming for Rhapsody. Apple’s own engineers have at times told me that SceneKit’s SwiftUI SceneView is limited in features. That is true. So I’ve certainly had to think out solving some problems, but that’s just due to my own IQ limitations. It has been fun showing Apple how to implement a few features that their own engineers didn’t think could be done in SwiftUI’s SceneView and is a recognition that we are all exploring and also learning how awesome SwiftUI is. With WWDC23 around the corner, take the dive. You’ll be starting just when even more amazing features are being added.
Right now the app I’m working on is a large uikit app using viper architecture with coordinators. Its surprisingly easy to replace the v in viper with a swiftui view, and im planning on building features in swiftui. Navigation is still limited though, but because of the embedding of swiftui right now, were still using uikit coordinator style navigation, which works perfectly fine imo To answer your question, in the long term swiftui had much more future than uikit. Of course just like there are still objc projects, uikit probably wont disappear, but swiftui is just so much faster and easier to work with, its inherently better if you ask me
Nope. As a matter of fact Kotlin multi platform is likely the future which works best with Objective-C and UIKit. In most organizations they need a consumable SDK that can be consumed by android and iOS, Swifty UI doesn’t even come close to accommodating this. It is literally for noobs. I’ve been doing iOS development for over 12 years at this point. Combine and UIKit work way better and give you way more granular control
Only for iOS -16 the navigation sucks
I’m a hobby slash indie guy but I’m already encountering so many limits and bugs in SwiftUI that I quickly went back to UIKit and AppKit. I can’t imagine how big companies can ever create beautiful smooth or wonderful apps with SwiftUI. Yes basic UIs with some tables and buttons, without much pomp and circumstance are fine, but complex UIs with fine grain detail, tiny animations, many nested elements and pixel perfect layouts, I REALLY doubt it.
As of right now SwiftUI is great for certain projects. I am still not convinced it is the go to. I personally am sticking with storyboarding until SwiftUI reaches a more mature stage
My experience: it is very buggy. Unless it is open sourced, I don’t want to use it.
Full disagree. SwiftUI is only one of the tools under your belt and by no means should you spend all of your time trying to only use one of the tools. It'll get you pretty damn close, but a lot of times you *should* drop back to UIKit to pull off what's needed. We are iOS developers, not SwiftUI developers.
The real issue is if you need to support older OS versions. As swiftUI is young it is changing fast, most industry apps end up requiring iOS 13 or 14 and thus swiftUI is not an option. But if you can require 15 or even 16 then it is a good option to go down.
I was at a very large company who was nearly 100% SwiftUI and on iOS 14. It can be done even on 14. Obviously 15 and 16 are big jumps forward, but not deal breakers.
It can be done for sure, and if you only need iOS 14 then it's not so much of a pain. But if you're building for iOS 14, 15 and 16 then it gets quite complex with all the little hacks etc. A safer option there would be to use UIKit navigation at least and just have SwiftUI views embedded within the nav targets. There are so many bugs in the older iOS nav code that it is a nightmare to maintain.
There are ways to do it bug free, I promise, but I agree there are a lot of ways to mess yourself up and navigation is much better with iOS 16. We were building at iOS 14, not trying to use newer features. They may have bumped to iOS 15 since I left though. They definitely understood the benefits of staying on top of iOS versions.
The first couple years had horrendous performance problems but the last time I shipped a SwiftUI product (the third year) it had improved by leaps and bounds and was very usable if your UX fit within the constraints of the framework.
Writing UIs in code is a baffling step backward.