Where Did SwiftUI Leave You Hanging?
This is a call to join the topic-of-the-month for the Swift Blog Carnival!
[…]
What do you LOVE about SwiftUI? What boggles your mind about it?
.sheetis STILL not animatable (a feature since the first OSX release)[…]
Toolbar item placement is completely broken.
[…]
.searchableis a complete mess that shouldn’t be a thing at all[…]
Due to a conflict between
List’s aggressive view destruction on scroll, and the way.taskworks, the millisecond a view that calls an API to load and parse a short string disappears, that already parsed string gets de-assigned. Once that particular list item appears again, it has to perform the extremely expensive API call and parsing again. Instead of just saving a 10-character string to memory. […] This leads to funny bugs, such as scrolling too fast through a list that’s made up of only text making the whole Mac freeze up and crash
SwiftUI is just too incomplete, inflexible and inextensible. It’s also great and that’s what makes this so frustrating.
[…]
Developers used to get Sherlocked when Apple would copy a third party apps features into the OS or packed apps. Now we get road blocked where only Apple can make use of a feature leaving us on the outside left trying to explain to users why Apples app has feature X,Y and Z and we don’t.
[…]
In a framework built on containers and modifiers just don’t go too deep into those containers or things may just break. Often this means your UI simply stops rendering on the screen. You may think you’re not doing anything wrong and then boom your code just doesn’t work.
[…]
Over the years we’ve all seen frameworks offering to create apps with no code or allowing you to write in your favorite language and run on all platforms. There were demos showing it working. None of those ever seem to pan out. They always come up short or perhaps they allow you to shoehorn in some native code to do something the framework authors don’t provide. If this sounds familiar this is what Apple is offering with SwiftUI. Looks impressive in canned demos, often falls short but you can just drop back to your old coding ways to fill in the blanks. I’ve always viewed this as a bunch of incomplete hacks. Now this is Apple standard practice.
[…]
I want SwiftUI to be so much more than it is currently. I want to make real Mac apps with it. I don’t want an iPad app in a Mac wrapper.
I encountered the following limitations with SwiftUI:
- Limited rich text editing experience.
- The file exporter returns a folder URL when exporting to PDF.
- SwiftUI lets you save documents in unwanted export file formats in Mac apps.
Despite this simplicity, the first implementation of that list was shockingly badly-behaved. It was:
- Extremely slow (scrolling would cause multi-second freezes!)
- Visually broken in multiple ways (you’ll see)
[…]
This was honestly very entertaining code to write! I think it’s especially fascinating how it’s essentially imperative code, expressed through declarative modifiers. It’s an absolute mess to read, because on top of that mismatch between behavior and expression, respecting view tree constraints forced an unnatural order for everything. Glorious, and dismal.
[…]
And at the same time, it’s a maddening amount of work for such a basic user interface.
Recently, I have seen multiple posts on Mastodon suggesting that SwiftUI is a failure, that nobody is using it, and that Apple should have focused on improving or replacing AppKit and UIKit instead of wasting everyone's time with SwiftUI. While I have great respect for some of the people saying these things, I disagree. I love using SwiftUI, I think a large number of developers are using it, and I want to explain what I find so great about it.
[…]
The reactive aspect of SwiftUI feels like magic! It allows me to have something like a stored setting with a default value, connected to a menu item with a checkmark, a toggle in a settings window, a button in the toolbar, and a switch on the main interface. SwiftUI keeps these all in sync without any effort on my part.
[…]
The AI proponents argue that if AI is writing all this verbose code, then there is no need for the more concise SwiftUI. While I have started using AI to write some code, I still review every line and the more the AI writes, the harder this becomes and the more likely it is that there will be un-detected bugs.
[…]
I don't want to imply that I think SwiftUI is perfect. I have struggled with various aspects of it, and I have had to find workarounds for some things that I want to do. Partly, this is due to the buggy nature of Apple software at the moment, but as someone who primarily works with Mac apps, I am feeling the pain of the lack of attention to the Mac. Again, this is not a SwiftUI problem, but a general Apple problem.
After shipping three small apps with
SwiftUI(and actively working on the fourth), I’ve come to a simple conclusion:SwiftUIis great for narrowly scoped small apps.[…]
Getting from zero to a working app that doesn’t look like a mess was incredibly fast - which helped with staying motivated. For me at least, being able to see interactive progress is part of what drove me to build apps, and
SwiftUImakes that feedback loop a lot quicker (and since I struggle with staying motivated, that’s a big win).[…]
Handling routing in
SwiftUIis easier with a router and anenumof all main navigation destinations, that can easily be navigated to from anywhere.And if you add a new screen or flow without handling it, the code won’t compile, so the compiler makes sure that nothing gets missed.
[…]
SwiftUIdidn’t make me a better developer or remove complexity from app development. But it removed enough friction that I started shipping ideas again.
I still maintain my personal opinion which is, it’s ok that there’s some expectation to dip back to UIKit / AppKit, but yeah, Apple needs to stop shouting “SwiftUI all the way!” at us when it can really only do anywhere from 40%-70% of the way.
[…]
We love SwiftUI. It’s awesome, fast and simple. The allure of highly legible, nearly-natural-language interface writing is strong. But we don’t have to let our love and hopes for SwiftUI limit us: It’s one tool in a big box. It’s ok to use the ol’ WKWebView here and there.
SwiftUI shipped in 2019, seven years ago. At WWDC 2022, Apple put up this infamous claim during the State of the Union[…] Here we are in 2026, right before another WWDC, four years and four major release cycles after that claim. How well does it hold today? In my opinion, we’re not even close. Modern SwiftUI can do a lot. But it’s still riddled with inexplicable bugs and weird limitations that prevent developers from building truly great experiences. Or at least, experiences that match system behavior.
[…]
Example 1: On iOS, SwiftUI can’t autofocus a text field in an appearing sheet to bring up the keyboard in the same animation.
[…]
Example 2: On macOS, drag & drop is essentially impossible to get right. Seven years in, we’re on the third major iteration of drag & drop in SwiftUI. […] Yet you still can’t have it all at once: reorder inside and drag out of the same view, plus drop validation when items may not be accepted, plus defining which drop operation (copy / move / link) a destination would cause. Let’s not dare to think of allowing Option to toggle between “move” and “copy”.
[…]
I believe Apple should tap into this invaluable resource of skilled developers with affection for its platforms and open-source SwiftUI. Sounds crazy. But is it? Swift has been open-source for years now, to great success. Let’s explore the thought, shall we?
This is not the only call for open source SwiftUI I’ve seen so I’m not trying to pick on it.
But my understanding is that SwiftUI cannot become open source. It touches too many private APIs. Even on platforms like macOS it’s no longer really a wrapper for AppKit, and it’s reaching deeper and deeper into private frameworks.
Previously:
2 Comments RSS · Twitter · Mastodon
There already is an open source SwiftUI. It's called Flutter.
Looks like the usual "SwiftUI is great BUT..."
> It allows me to have something like a stored setting with a default value, connected to a menu item with a checkmark, a toggle in a settings window, a button in the toolbar, and a switch on the main interface.
I only use this in one app but I'm pretty sure um.. NSUserDefaultsController can do this. The copyright in the header file goes all the back to 2002!!! We've had 'magic' for a long time.
Anyone still cucked to SlopUI would be floored to learn about Interface Builder + Cocoa Bindings. It's 80% of what they rave about, but more stable and performant.
> Apple needs to stop shouting “SwiftUI all the way!”
The same goes for inexperienced developers who proudly dotted their resumés and profiles with "#SwiftUI" for 8 years now. You gaslit one another and pushed a bad tech.
