10 ms·

SwiftUI After 7 Years

• formvoltron 2mo ago
  Is the right way to develop mobile apps flutter? or Kotlin multiplatform plus native UIs?
  • rubymamis 2mo ago
    I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.
    • afidrya 2mo ago
      It's licensing is expensive though unless the app is opensource.
      • gen2brain 2mo ago
        I heard this repeated many times. You can create closed-source Qt apps without paying any money. You cannot statically link, though; you must obey the LGPL license; that is all. And yes, you cannot use commercial modules, but that is kinda expected.
    • preg_match 2mo ago
      Yes, Qt is mature and high-quality software. If you’re doing OSS, then Qt is truly a no brainer. The amount of C++ you have to write is truly minimal, and it’s not “raw” C++. There’s a lot of tooling and libraries. You can target web now too, and QML is legitimately good. If KDE can develop a high performance stable desktop, you can design whatever.
    • palata 2mo ago
      I have been involved in two non-trivial Qt mobile apps. Never again. I don't know what your experience is, and I mean no offence or anything, but the only people I have seen who were happy with Qt for mobile development were people who had never tried to do it with a modern language, like Kotlin. With Compose Multiplatform and Kotlin Multiplatform, you can write a cross-platform app in a modern language, and that is far better than C++.
  • danscan 2mo ago
    There is no right way :) SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery. Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.
    • rumori 2mo ago
      I’ve worked on some award winning apps in the past, our experience with SwiftUI is it makes it really easy to develop a basic average looking app. As soon as you need something non-standard, you have to drop down to UIKit and figure out how to play nice between the two, which is often non trivial and hard to estimate. You file radars, which at best will be fixed in the next OS release and rarely back ported if at all. In the end some of the more complicated apps just ditched SwiftUI altogether or applied a myriad of workarounds.
  • livinglist 2mo ago
    Define right, it’s hard to replicate the native UI especially Liquid Glass on iOS because it’s rendering everything using its own rendering engine, making it hard to feel right on iOS. I have also seen a lot of companies move away from flutter to either native or React Native.
    • lowbloodsugar 2mo ago
      Well we all love Liquid Glass. Most loved UX update in iPhone and macOS history. Massive dealbreaker for an app not to look like Liquid Glass. I definitely choose apps based on whether they look like proper Liquid Glass applications instead of the developer taking shortcuts and focusing on working features instead.
      • lelandfe 2mo ago
        You jest but yes, even as I do not love this new update, an application bucking Apple platform standards personally sours me pretty hard on it.
      • livinglist 2mo ago
        Well I’m a heavy Flutter user myself, and the app I built Hacki often gets reviews saying it doesn’t feel native on iOS. I personally don’t have anything against it and I think Flutter has the BEST developer experience compared to other mobile app dev toolkit/SDKs.
      • afavour 2mo ago
        I despise Liquid Glass too but for most users there’s a broad feeling of “it fits” vs doesn’t. And apps with Liquid Glass fit today’s iOS.
  • SV_BubbleTime 2mo ago
    Flutter has been a great success for us.
    • rumori 2mo ago
      Same here, but Liquid Glass has been a headache lately. Google really dropped the ball here, but to their credit it almost feels like Liquid Glass was an intentional move by Apple to cause as much friction for cross platform frameworks as possible.
  • krzyzanowskim 2mo ago
    Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.
  • randyrand 2mo ago
    I developed a complicated app in Flutter and it’s one of the best engineering decisions I made. Flutter is great.
  • ducktective 2mo ago
    I wonder what experts think of this other option: going fully native for one platform then vibe-porting it to others.
    • palata 2mo ago
      It's never "just working", you'll still have to debug the vibe-ported apps. And you won't be good at it if your devs don't actually know the target platform. All that to say, I don't think that vibe-porting will give you more than cross-platform. With cross-platform, at least your engineers understand the codebase.
  • palata 2mo ago
    What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework. For instance, I can write a KMP library and a "pure" Android or iOS app can pretend it is a "pure" Android/iOS library. That is, pure native apps, can integrate KMP libraries. They cannot integrate Flutter libraries. In other words, if I write a KMP library, I can ship it for multiple platforms and developers can use it in their Flutter project, or in their pure Android/Kotlin project, or in their pure iOS project.
  • frizlab 2mo ago
    Neither.
• rayiner 2mo ago
  The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is the company that shifted from Toolbox to Carbon to Cocoa and each step was better than the last. Could Apple build MacOS X and Cocoa today if they didn't already exist? Microsoft's two decades of failure to ship a true successor to Win32 suggests that Microsoft (at least, the operating system side of the company) died a long time ago. I wonder if we'll say the same thing about Apple 10 years hence.
  • skydhash 2mo ago
    I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS.
    • poly2it 2mo ago
      Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai: https://github.com/janestreet/bonsai https://github.com/janestreet/bonsai
      • mpweiher 2mo ago
        Not sure how you define "success" here. Is Bonsai used much outside of Jane Street?
      • 2mo ago
• Razengan 2mo ago
  I fell in love with SwiftUI the day it was announced, but as a solo dev I still haven't been able to make a full app with it yet, mostly because of the lack of documentation, and the gaps where you still need to drop down to AppKit/UIKit. I went through Visual Basic, .NET, WPF, Cocoa, and other random frameworks all professing to be the promised panacea for UI, but I think SwiftUI+SwiftData is the best environment ever.. IF only it could reach its full potential, i.e. do everything that Apple's "legacy" APIs can do. I even tried using SwiftUI for games: https://i.imgur.com/5aTWbft.mp4 https://i.imgur.com/5aTWbft.mp4 The biggest/worst hurdle in the "modern" dev experience is Apple's insistence on a yearly update cycle and the way they advertise those updates: You have to wait for the next WWDC and suffer through videos of uncanny-valley presenters, hoping to catch a glimpse of something that fixes the shit that was bothering you since the last WWDC. 3rd-party sites like hackingwithswift.com & swiftwithmajid.com provide invaluable info that Apple's own docs should. At least the Swift language has been getting more regular updates since it went open source. There's no way I'd dare to take on a full Apple-platform app project alone on my own, but I've started dabbling in it again thanks to AI: Codex even converted an old app I made in Visual Basic 900 years ago and had it running in SwiftUI within minutes! I've even tried to get AI to sift through the WWDC video transcripts so I won't have to waste my mortal lifespan on that.
  • steve1977 2mo ago
    > There's no way I'd dare to take on a full Apple-platform app project alone on my own And that's really sad, because earlier Mac OS X (and even OPENSTEP to a degree) was an Eldorado for boutique developers, not least due to frameworks like Cocoa and Objective-C (despite all the hate it seems to get). If you knew C, it was not hard to grasp Objective-C (at least it was much easier than say C++ and MFC on the Windows side of things).
    • Razengan 2mo ago
      That's actually why I jumped from Windows to Mac in the first place! My first Apple purchase was an iPad I got for my aunt, and I loved how streamlined yet powerful it was so I installed a VM on Windows to dabble in iOS development, and fell in love with the sheer consistency of macOS, iOS and their APIs. This was during the era when Microsoft was still figuring out whether to keep the Start Menu and replace the whole Windows UX with a tablet UI, so it was an easy jump. Almost never looked back, and whenever I do I'm glad I jumped. Then came Swift and I loved it, but then it took literal years to catch up with everything you could do in Objective-C with the Apple APIs. SwiftUI is having the same problem but for much longer :(
• migueldeicaza 2mo ago
  skills issue
  • mpweiher 2mo ago
    https://en.wikipedia.org/wiki/Poe's_law https://en.wikipedia.org/wiki/Poe's_law
    • migueldeicaza 2mo ago
      Let me rephrase, he is not the sharpest knife in the drawer. In my professional medical opinion, he is at high risk of being replaced by a year old low-end Chinese open source LLM.
  • migueldeicaza 2mo ago
    I joked, but reading the post is even more clear - man this poor dude. He is brute forcing his way through life and broadcasting it on YouTube. Dunno man, Xogot is made up of almost half a million lines of code. Of those 727 files use SwiftUI, and 65 use UIKit, 119 use AppKit (I did not count the overlap, so they are not mutually exclusive). Using GeometryReader makes it clear he is living in the past and the fact that he uses printChanges in this year without mentioning the dedicated SwiftUI instrument show a lack of curiosity on the space.
    • miffy900 2mo ago
      So in other words you have no response to any of the arguments in the link? just some silly ad-hominem attack on the author. right.
    • vintagedave 2mo ago
      > Using GeometryReader makes it clear he is living in the past He seems to phrase it as though he has to, that he falls back because nothing else works. What would you suggest instead? I'm only lightly familiar with both Cocoa and SwiftUI, but I have heard many nightmare stories about SwiftUI and Swift the language. I'm inclined to take his criticism seriously, and I think there's a big distinction between people who know a platform very deeply -- you are a strong expert almost everywhere you touch :) and it's clear from your comment SwiftUI works for you -- and normal developers who, you know, just want to learn a framework once and use it to get a job done. Living in the past is not necessarily bad; it's a good thing if what worked in the past worked well and still works today.
• cosmic_cheese 2mo ago
  I'm sure many will disagree, but I have doubts that pure declarative-reactive is the "right" shape for an all-purpose native UI framework. In my experience, Kotlin+Compose shares many of the same warts… its main redeeming quality is that it's better than Android Framework (most of the time), which is low bar to clear. These frameworks have a number of good ideas but they don't necessarily combine in a way that transcends high quality traditional imperative frameworks with declarative-reactive bits sprinkled throughout, at least for more complex apps. SwiftUI and its ilk work best for super simple tabs-and-flat-lists sorts of apps.
  • rumori 2mo ago
    I think open source is the right move here. The great thing about Flutter is you get the declarative UI to build a lot of standard screens easily but you can always drop down to lower levels, inspect the standard components, mix and match with your custom implementation. You can mix UKit and SwiftUI but there’s way more friction due to the closed nature of the SDK.
    • cosmic_cheese 2mo ago
      Perhaps. Certainly source visibility makes life easier as a dev who has to live with these frameworks on a daily basis. That said, I think frameworks should strive to have a wide and deep enough set of widgets that in most cases, devs won't need to resort to custom implementations to do what they need to. It also doesn't fix problems inherent to declarative UI, like readability breaking down easily and certain things that would be a cinch in an imperative framework being extremely awkward to implement.
    • norbert515 2mo ago
      Fully agree (been an early Flutter adopter!). It's always the right too for the right job, declarativness makes a lot of sense for most UIs. UIs are surprisingly more complicated than one might think, there is accessibility/ theming/ keyboard traversal etc., just declaring UI and letting the framework figure out the rest has held up pretty well. And because of the open source nature you can always drop down in layers, just a few weeks ago I made a very specific engine optimization, all while the application code on-top can stay declarative!
• sampton 2mo ago
  SwiftUI is gold compared to SwiftData.
  • emehex 2mo ago
    Agreed. SwiftData is terrible for anything more than like 2 "Models". I have a bunch of apps written with SwiftData and a bunch more with GRDB... I hate touching the SwiftData ones.
  • myko 2mo ago
    To be fair CoreData was always a footgun as well
  • wahnfrieden 2mo ago
    SQLiteData is the winner.
  • ardit33 2mo ago
    SwiftData is just a framework that you can choose to ignore and not use at all. Even CoreData. You can go straight to the source, and use some small layer on top of SQLite, and ignore that noise (most large apps just do that). But, SwiftUI is being pushed as the way to do UI, and as a replacement for UIKIt/the future of apple, where it is not even near feature parity with it. That's the most troubling part of it. I wished apple just made it as a Template Rendering framework, and integrated wit with UIKit, and just modernized UIKit a bit.
• the-golden-one 2mo ago
  A similar story to WPF.
  • tonyedgecombe 2mo ago
    WPF was abandoned at birth, it went years without any attention and then was superseded. Apple has at least been consistent on UI frameworks.
    • dgellow 2mo ago
      Sort of superseded. In practice WPF is still very often the best option in the complete mess that is window GUIs
      • masfuerte 2mo ago
        Yeah, I like WPF and I still use it for my own apps. In fact, my own software is the only thing keeping me on Windows now. I really should take a look at Avalonia and port my stuff over to Linux.
  • Razengan 2mo ago
    WPF was stamped out by lack of dogfooding = inability to inspire confidence, and then Microsoft spazzing out with that clusterfuck that was the Windows 8 "Metro" bullshit. Back when I wanted WPF to succeed, Microsoft was barely using it in any of their own apps. Apple has used SwiftUI in their OS more than MS/Windows did, and there's quite a few apps on the App Store that -seem- to be made with SwiftUI.
  • VCFundedGenYer 2mo ago
    I think you might have meant UWP. WPF is still around and have been spruced up as of late. UWP was the DOA Windows 8/8.1/10 app format that was super restrictive, strange to develop for, and non-portable. It's basically MS's equivalent of SwiftUI.
• ardit33 2mo ago
  SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder. It is a newbie trap. It is great at producing simple apps, or things that don't require intense scrolling, or anything with heavy animations and precise layouts, but when you do something smooth, it is not it. It feels more of a React Native competitor, than a true UIKit replacement. Also, almost everything that Apple has re-wrote with SwiftUI, came out worse as before (Settings, Spotlight, etc), and that doesn't help. With AI coding... SwiftUI lost its edge/advantage (easy to layout screens), as now you code less of that directly, and might as well just go fo the framework that allows the most flexibility and gives you the best results for your users. Apple really needs to either double down on it, and make it such that it has everything that UIKit has (match both features and performance), or just turn it into another optional framework, just as Interface Builder (.xib files) back in the day of Objective-C. Right now it heavily promotes it as a first class citizen, meanwhile the features are not even parity with UIKit. It is so misleading to newcomers to the platform. Ps. The other upsetting thing about SwiftUI, is that it has hurt the Swift language as well, as the team has had to introduce all kinds of hacks, or obscure features to the language in order to make it work, which made even the Swift language experience worse and more complicated than it should have been.
  • Razengan 2mo ago
    > With AI coding... SwiftUI lost its edge/advantage On the contrary, I think AI has made it EASIER to approach SwiftUI now, because AI makes up for SwiftUI's biggest weaknesses: the many ways of doing everything, Apple's wonky documentation and the need to know when to fall back to AppKit/UIKit.
    • ardit33 2mo ago
      Maybe for you. But SwiftUI promise was to make coding UI easier for the programmer similar to ReactN, but with AI coding that is not necessary anymore, you can go straight to UIKit which is most stable and feature complete. In car terms: UIKit - Manual Transmission - you control everything, but a bit of a chore SwiftUI - Slushbox Auto Transmission - easier to drive, sucks for performance UIKIT+AI Coding - Dual Clutch Transmission - both great performance, and easy to control/drive
• emehex 2mo ago
  > real, production-grade UI framework What does this even mean? There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade". The only people still complaining about SwiftUI 7 years later are the UIKit holdouts that never took the time to properly learn how to use it.
  • brailsafe 2mo ago
    > There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade" The first is a statement of quantity, the second is a statement of quality, dubiously supprted by the first. The Mac Settings app still lags between panes years after it was redesigned to look like iOS. I would think that if they had a viable way build a high quality and performant app with even relatively basic UI components (if they cared to do so) they'd do it for the 1 app that's deployed to every mac. SwiftUI does work in certain circumstances, and does work for allowing people to shit out their ideas faster, but it has struggled with the aspects described in the video. Some companies don't care either, and turnaround time is paramount, but in this discussion it's about quality compared to what came before.
    • saagarjha 2mo ago
      Settings lags not because of SwiftUI but because it renders all the panes out of process
      • brailsafe 2mo ago
        I think it's a little of both, but last time I tried making a performant NavigationView/NavigationSplitView/VStack like that, it chugged along compared to the same layout built with AppKit
• spacedcowboy 2mo ago
  Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit. Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux
  • jshier 2mo ago
    Apple will likely never drop Obj-C, but it's been a secondary language for years now. New frameworks are all written in Swift, Obj-C is only used for existing Obj-C codebases.
  • blltprfmnk 2mo ago
    There were a lot of people actively complaining about ObjC in the lead-up to the unveiling of Swift. In fact I recall one prominent blogger in the iOS community begging Apple just a few months earlier to consider replacing it. Unfortunately although Swift seemed promising at first, by the time Swift 3 rolled around a lot of people were actively frustrated and moved on from iOS development. Having actual experienced hands guiding that ship could have led to something great instead of the mess that is there today.
    • kccqzy 2mo ago
      Are you talking about the unveiling of Swift or SwiftUI? My recollection was that some people hated ObjC and wanted a more modern language. Apple gave them Swift. But I don’t recall people hating AppKit (maybe I wasn’t remembering correctly) and SwiftUI was basically Apple following the hipster trend.
      • blltprfmnk 2mo ago
        Just referring to Swift. Agree that SwiftUI was just jumping on a bandwagon and would say that the design of SwiftUI clearly strains the poor language design choices in Swift.
    • spacedcowboy 2mo ago
• emehex 2mo ago
  I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.
  • jshier 2mo ago
    Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API. Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.
    • andrekandre 2mo ago
      > If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API. apple/obj-c had bindings and automatic ui updates more than 20 years ago in appkit; apple could have added that capability to view controllers in ios a long time ago
  • CharlesW 2mo ago
    > I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is true. SwiftUI became "very good" as of iOS 26 (in part because the performance gap mostly evaporated) and continues to get better in iOS 27. Over and over, I see UIKit developers trying to do things "the UIKit way" in SwiftUI, and they'd rather write TFAs instead of considering that they may need to skill up and learn to write effective and idiomatic SwiftUI.
    • oefrha 2mo ago
      Now, if only that code you write for iOS 27 can also work on older versions of iOS, instead of having to maintain legacy code for old versions forever…
• happytoexplain 2mo ago
  Autolayout, while flawed like anything else, remains the pinnacle of UI across all platforms. SwiftUI is a laudable attempt to idiot-proof UI, but it sacrifices too much and ultimately fails.
  • frizlab 2mo ago
    I love Auto-Layout so much.
    • sunnybeetroot 2mo ago
      Make 320pt frame layouts great again /s
      • frizlab 2mo ago
        That’s the point of Auto-Layout, to be able to be responsive…
        • sunnybeetroot 2mo ago
          I edited the comment with /s to make it more obvious that I was joking
  • Klonoar 2mo ago
    Every time I have to structure UI anywhere else, I lament not having AutoLayout.
• sandoze 2mo ago
  This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help here but there are profile tools that tell you when and where things are updated. This isn’t black magic. Keep Views small, be careful how you hand around data. @environment is super cool but can have a cascade effect. This was greatly improved iOS 17+ and I wouldn’t support anything older than iOS 17. GeometryReader: Occasionally I’ll use this. It’s kind of a necessary evil when dealing with certain view complexity. It can also be a sign that you’re doing something wrong. API Stability and performance: Apple users upgrade. There’s no reason that you should be supporting iOS 17 at this point — even iOS 18 is roughly 2%% of our user base across several apps. I’ve been using SwiftUI without major performance issues but I also don’t early optimize. I profile and fix as needed. One of the early studios I worked for wrote all our games in UIKit as prototypes, when performance tanked we’d switch to the appropriate tools (eg. OpenGL) where it was necessary — like in the core game. I could go on but in the end just use the right tool for the job, if you’re not proficient in SwiftUI or it isn’t going to work for your cross platform project, you have a lot of other alternatives. For me though, it’s been amazing to work with. I stepped away from iOS programming for 3 - 4 years because I was burnt out using storyboards, dealing with massive view controllers, and all the boiler plate it’d take to get a view up and going in UIKit. SwiftUI roped me back in. * Quick addition edit: Cross platform for iOS, iPad, macOS has never been good. I’ve found recent updates have made things better to the point of tolerable and it’s nothing like when we had to post-fix an ~ipad to our Nibs — There has never been a ‘glory days’ of cross platform Apple UI libraries.
  • _s 2mo ago
    I was just thinking more or less along these lines - I haven't been in mobile apps for a few years now, but back then my impression was - SwiftUI is great for "surface level" UI, that has some basic data bindings - think a basic CRUD app, which needs some navigation, and the ability to scale across the smallest iPhone to the largest macOS screen, from touch gestures to mouse input. If you ask anything more of it, then you need to start branching off into specific libraries / tools / frameworks (UIKit, CoreAnimation etc) - which is much easier now too, but you'll always have a bad time if you try to mix the two in a single "view" / "frame". I'm not surprised that's still true today.
• zer0x4d 2mo ago
  SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return. This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug. I'm convinced no one (not even senior devs with 5 years of SwiftUI experience) understands how the ordering of modifiers works. It's just swap them until it does what you want it to. 2. The view lifecycles and code execution path seem random and hidden behind layers of "magic," making it incredibly difficult for developers to trace and debug issues. 3. It is practically impossible to set breakpoints for rendering and view construction, it's impossible to really figure out when re-renders happen and what drives them. I'm convinced SwiftUI apps are incredibly slow not because the SwiftUI implementation itself is slow, it's because, even Apple's own apps probably do a bunch of unnecessary re-renders and one no one seems to have any idea. This is unfortunately another design issue that can't be solved by just making SwiftUI more efficient. It requires simplification and tooling to help developers not footgun themselves. 4. Lots of issues start appearing later on in the development cycle because, for simple apps, bad SwiftUI design decisions and footguns have unnoticeable effects, until the apps gets more complex and things start breaking. Fixing these issues sometimes requires rewriting whole features or spending hours debugging. 5. There seems to be almost no documentation on Liquid Glass. It's laughable that after more than 1 year, Apple has simply refused to document or provide good examples for Liquid Glass, except for maybe couple pages that resemble the brain dump of an engineer that has never passed a writing class in college? 6. Stuff seems to be rapidly changing and breaking from version to version. It took days to make my app look and work the same in iOS 27 as it did on iOS 26, even though iOS 27 is supposed to be a minor bug fix release. We don't even use anything non-standard and don't do any hacks. This defeats the whole purpose of a simple UI framework that can be easily adopted to different platforms (this never used to happen with UIKit). 7. View debugger still has no SwiftUI equivalent. It used to make things so much simpler in UIKit when you could just see the view bounds, pick views apart and understand what's actually happening. SwiftUI has no equivalent other than `.background(.red)`. Terrible. I don't know how Apple can salvage this beyond just undoing some of these terrible design decisions and making it 1. super simple to work with, 2. stop relying on magic, making things more explicit, and 3. providing actual 1:1 UIKit feature parity.
• palata 2mo ago
  Maybe unrelated, but as an Android dev, a few years ago I wanted to look into SwiftUI. But now I feel like for most apps, I should be fine with Compose Multiplatform and Kotlin Multiplatform. I don't see the point of learning SwiftUI anymore.
  • frizlab 2mo ago
    Well you could do android apps using SwiftUI ¯\_(ツ)_/¯
    • palata 2mo ago
      But then I would have to endure the Apple developer experience...
      • frizlab 2mo ago
        To each his own, but I actually like it
        • palata 2mo ago
          Genuinely curious: do you have experience with other environments, or mostly Apple?
          • frizlab 2mo ago
            Excellent question. I have mostly used Apple tools, but have also tried (most notably) VSCode, android studio, zed, Eclipse, vim and Sublime Text. None of these convinced me, except Sublime which I still use for “non-Apple” projects (also non-android, obviously). I also like vim, but not for coding, just as a general text editor. I particularly hate VSCode, for some reason (the reason is not that it comes from M$ if you’re wondering; I’m not really sure why tbh, probably because it’s electron and feels particularly not native). I am aware of IntelliJ, but have never tried it. Given that android studio is based off this AFAIK, I’ll probably not really like it either, I guess? idk
• peheje 2mo ago
  Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic. The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed. My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time. Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness. Beautifully decoupled. Extremely testable. Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests. A welcome-page refactor breaks the profile page. “Didn’t you check the nightly build?” No. It runs at night. “Well, that’s your responsibility.” But you broke it. “Yes, but it’s your code.” Then why did we ship it? Fine. Schedule the postmortem with my mother. And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack. What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component. People react to that with horror: what if components are duplicated, behave or look slightly different? Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed. HTML. CSS. JavaScript. Or something close to it. Maybe I’m getting old.
  • dosisking 2mo ago
    > Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic. I guess I'm even older, because I prefer HTML4, without CSS. And I like using tables for layout instead of divs. I always hated CSS.
  • leecommamichael 2mo ago
    > I have to think about everything, everywhere, all the time. I think this is familiarity speaking, which is what you're expressing earlier in the comment anyway. The reality is that we have to think of everything when telling a machine what to do. Exactly how we get that done is preference.
• pupppet 2mo ago
  If you’re just getting AI to build you an iOS app, is there any reason to use SwiftUI over UIKit?
  • dagmx 2mo ago
    Yes because SwiftUI is way more self contained and minimally verbose, it’s a better fit for LLM use than AppKit/UIKit
  • wahnfrieden 2mo ago
    Some new platform capabilities are only available in SwiftUI. But you can wrap that for use in UIKit.
  • saagarjha 2mo ago
    Yes, because SwiftUI is (really!) the best way to build new apps for iOS. Your AI can probably figure out when it needs UIKit to do what it wants.
• deleted 2mo ago
  [deleted]
• deleted 2mo ago
  [deleted]
• slopinthebag 2mo ago
  [flagged]
• fenestella 2mo ago
  [flagged]
• mintflow 2mo ago
  As a solo app developper for two years mainly for apple platform(previously do networking infra software using C/Go) After two many trial and fail, now it's quite clear to me that for simple UI I will use swiftUI(such as help sheet or simple toggles), for complex and performance first, I will just use UIKit instead, it save a log of time and actually the imperative UIKit is also quite easy to read and review the feasibility of review is important because code is not mainly written by agent, though as my understanding of UIKit grows I can smell the bad part and let it rewrite
  • il-b 2mo ago
    Somehow, we’re still failing to realize that the most complex UIs - think CAD software, 3D editors, etc - are imperative, object-oriented, and written in C++. Their core development teams are usually very small. Yet you need a 20-person frontend team to deliver a primitive e-commerce app. It’s as clear as day that the promise of declarative and reactive programming is failing its users.
    • dminik 2mo ago
      How much of this is that most of these tools have been around for 20+ years and come from a time where OOP was the holy grail coming to save humanity?
      • jonhohle 2mo ago
        I think the key is these things were possible 20 years ago with small teams and now large teams and even teams at Apple can’t make competent apps with the flagship product. I worked at a FAANG and a team was tasked with implementing a new REST framework to replace/augment the supported RPC framework. Metrics were very important and this team might have know HTTP/REST well, but they didn’t understand what operators needed. It wasn’t even on their radar. As a senior engineer, without much traction I complained and fortunately someone one level higher from across the company saw my message and had the necessary influence to get them to pause and think. I don’t know if anyone has done that at Apple. Things that used to work universally - key bindings, drag and drop, context menus - just don’t work by default anymore. Why? Because now everything is some low level UI element and whose behavior is completely up to the programmer. Sounds like web programming, not like Mac programming. From a programming perspective, I don’t even like the paradigm. Once understood, IOC in AppKit and Interface Builder was incredibly efficient.
• interpol_p 2mo ago
  SwiftUI has a lot of failings, but it can also do a lot of things that are really tricky in UIKit. I can render Metal shaders trivially in SwiftUI. Rendering glows, and blurs, and animated effects is much easier in SwiftUI than in UIKit, just use `.blur(radius:)` or `.blendMode(...)` I have used AppKit and then UIKit since its inception. Creating visual effects like layer masks that modulate the opacity of underlying views is trivially easy in SwiftUI — far easier than the boilerplate and constant bookkeeping that CALayer's mask requires. So a lot of the advanced full-screen animations in some of my games and apps are SwiftUI, because they are performant, provide the cool effects and animations, and work great. A lot of the simple get-the-job-done views and tool palettes in my apps are also SwiftUI, again because they don't ask much and get the job done, and look great. However, where SwiftUI falls down is exactly what was demoed in the video: large collections of thumbnails that fetch asynchronously? Use UIKit. Multi-thousands of items in large, complicated lists? You can try SwiftUI, but you'll need to learn how to optimize it. Other things, not mentioned in the video, that are more annoying in SwiftUI: want to take control of a transition between views, end-to-end? Not really possible in SwiftUI. There are bugs with ZoomNavigationTransition that affect all of Apple's own apps, and you aren't gonna be able to fix them without switching to UIKit.
  • vintagedave 2mo ago
    But just imagine if they'd spent this time making them easy in UIKit.
• zombot 2mo ago
  You know those games you buy as Early Access while they're still in development, with the implied promise that development will be done some day? And how many of those games have stayed Early Access over so many years that you stopped believing they will ever be done? That's SwiftUI. I won't touch it.
• mpfh 2mo ago
  Any modern-day Windows developers want to chime in around WinRT and other stuff Microsoft has been up to? I’m still on Win32 and WinForms.
  • happytoexplain 2mo ago
    They are simply not relevant at this level of discussion.
• harrouet 2mo ago
  Agreed that SwiftUI because bloated and hacky, when it promised simplification and transparency. But is there a single UI abstraction that succeeded in affordability for newcomers while maintaining performance and solid architecture? It is high time to solve the write-3-apps for each usecase (iOS, Android, Windows). I use MAUI on some projects but it is still not perfect. The way forward for Apple is to open source more and more and let the Swift community build a cross-platform solution.
• willtemperley 2mo ago
  I would only take this article seriously if you have to support old iOS versions. NavigationStack has been around since iOS 16, @Observable since iOS 17. and I'm not sure if the author is aware that GeometryReader hasn't been necessary since iOS 18 added onGeometryChange modifiers. Nearly 100% of users are on iOS 16+. I'm doing some fairly complex work with SwiftUI and I find most components work identically between iPad and macOS. I can work for a week without needing to test on an iPad. There are problems with SwiftUI for sure: I'm finding macOS performance on an M2 Max is far worse than an iPad M1, especially with animations. Toolbars are very inconsistent between platforms and the compiler timeouts are a real pain (hopefully Swift 6.4 will fix that).
  • viktorcode 2mo ago
    > I'm not sure if the author is aware that GeometryReader hasn't been necessary since iOS 18 added onGeometryChange modifiers. I think the author does not understand how and why to use GeometryReader at all. He literally said "you find yourself wrapping everything in a GeometryReader" which is a different thing from simply measuring. For measuring you could always put GeometryReader into `.background()` and use that to avoid messing with the view layout. Also, "wrapping everything" is a good sign you are doing something wrong. Edit: by the way compiler timeouts are not a SwiftUI issue: it is a Swift issue. You can create a timeout situation in pure Swift. For SwiftUI specifically this situation is addressed in the upcoming OS27 SDK.
    • happytoexplain 2mo ago
      Compiler timeouts are only a Swift issue because it is so flexible. They don't happen outside of SwiftUI except in toy examples that look simple but aren't realistic. SwiftUI is the only realistic example where timeouts happen (which is unacceptable). Regarding GeometryReader: Just read your comment out loud.
      • deleted 2mo ago
        [deleted]
• sujee 2mo ago
  I have recently completed building a large native macOS app and my take is that, for 90% of work, SwiftUI is good but for the 10% you would need AppKit. For my app which is a AI chat app, I needed to load and show a large number of chat items in a list, SwiftUI is really bad at this. Another issue is, most of Swift markdown libraries don't perform perform well because each elements are rendered as SwiftUI views which introduced a lot of issues So I built my own renderer using TextKit. Even basic things like Settings window is broken. But I still prefer using SwiftUI as It gets the work done faster and I can always fallback to AppKit. I find that web tech like React are worst than SwiftUI. React also has re-rendering and state management issues
• lonelyasacloud 2mo ago
  Used SwiftUI mainly on macOS since it was first released. On macOS it is still comes up short on a lot of the GUI functionality. Stuff like window management, decoration, focus, undo/redo, finder tree type views etc. What Apple have implemented seems okay to me for iPad, iOS etc, but is not up to the standards users' expect for non-trivial native desktop applications. With enough determination most of the omissions on macOS can be worked around by breaking the SwiftUI encapsulation and delving into AppKit or jarringly inelegant solutions. All of which are somewhat liable to ended up binned when/if Apple pull their fingers out. I had higher expectations of Apple, and overall, it's easy to understand why it does not have a stellar reputation. As to why it's a bit rubbish on macOS; SwiftUI is largely a mapping to UIKit, AppKit etc primitives. At a guess Apple wants to reduce that number and are seeking to minimise investment in moribund technology.
• mathverse 2mo ago
  For small apps I use exclusively SwiftUI for anything more complicated I use a combo of Sciter and Swift (courtesy of https://news.ycombinator.com/user?id=c-smile https://news.ycombinator.com/user?id=c-smile). There are still a lot of rough edges when it comes to look and feel on Apple platforms but it gives me the performance and speed while also being multiplatform.
• searls 2mo ago
  I'll be honest, I struggled to get much done with SwiftUI each of the last four years but this summer I started 4 greenfield iOS 27 apps on SwiftUI and it's genuinely been pretty delightful and none have required escape hatches to UIKit/AppKit. I get people are upset, but the edge cases and frustration in no way feel like fundamental failures—just stuff they haven't gotten around to yet. Yes, they should have gotten to them all sooner but that doesn't convince me they won't eventually.
• saagarjha 2mo ago
  SwiftUI has a bunch of problems but almost none of them have anything to do with what this guy has to say :( Like, there are issues with almost every point: > We started with @State, @Binding, and ObservedObjects. Then Apple realized the performance was disastrous and SwiftUI was re-rendering views all the time. That’s when it introduced the Observation framework and the @Observable macro. They tried to solve the problem with compiler tricks, but it clearly wasn’t enough so the layout engine continued its guessing games. Not why @Observable was introduced > In SwiftUI, you can never know for sure how many times a view will update and, when it does, why it chose to. Instruments tells you these days > That demo project from the SwiftUI tutorial has a very standard, non-custom one. You build the project with the latest Xcode and launch the app on the latest macOS—only to get this. Yeah, it's a demo marked as "this is old, please do not use it"? > What is a SwiftUI problem is the overall fragility of UI layouts. They fall apart in the most unexpected ways and at the most unfortunate moments. You can see it in the very real, production apps like UTM. It’s a fantastic piece of engineering, but its reliance on SwiftUI sometimes makes it feel like an early prototype. This is an app written by someone who spends most of their time writing graphics APIs I think the fact that they can do something half-decent is really a testament to how approachable SwiftUI is > In the end, you find yourself wrapping everything in a GeometryReader. And this is the ultimate admission of defeat. No I only use GeometryReader when I actually want to do some coordinate math > Okay, maybe you want to let your users customize the window toolbar, just as they could since 2001 (or something like that). Well, SwiftUI received this “breakthrough” feature only a few years ago. iOS 14 my guy, this is literally one year after SwiftUI was released > And then there’s the most basic task: displaying images you fetched from the network. Well, you better write your own fetcher, because AsyncImage was introduced only in iOS 15. Can you point me at the API in UIKit that lets you do this? > But if you want to also cache those images, I’ve got bad news for you: You can’t do it at all because right now, in July 2026, this API is still in beta. Or this? > For all these scenarios, developers usually come up with their own hacks and workarounds. Yeah, it's called "you download one of a handful of libraries to do it for you". Now you don't have to do that.
  • blkhp19 2mo ago
    This should be the highest-rated comment. The guy who posted this video / transcript is wrong about so many things - I'm actually convinced he's being purposely misleading. It's an opinion about SwiftUI backed up by misleading and inaccurate claims.
• ChrisMarshallNY 2mo ago
  I liked the promise, but the reality has been disappointing. SwiftUI is great for test harnesses and admin utilities, but I won't use it for shipping software. I have one app that I rewrote in SwiftUI, just so that I can say that I have shipped it, but I am still using UIKit for most of my apps. I'm not thrilled with UIKit, but SwiftUI has kind of withered on the vine.
• dzonga 2mo ago
  my take is apple should've hired or worked more with external partners in terms of handling swift. 1. the language had all the right hook points to replace python - but then it was closed off in the apple ecosystem for a while. then it was made to be complex as C++ as time went on. if Swift had remained as simple as Go - and Apple had made a push for swift to go beyond apps in their ecosystem the language for data/ml would be swift 2. in regards to swiftUI - almost the same point as 1. react native took over cz it was a simpler more open ecosystem. then eventually most people stopped bothering with native apps (they're used to track you) - web apps are equally good. hence for most people they use native apps for maps, banking.
• flenserboy 2mo ago
  there's yet to be a decent-looking SwiftUI app on the desktop. elements are always too small, spacing is wrong, & the keyboard is a second-class citizen. mobile-first is a disaster.
• dep_b 2mo ago
  The odd thing is that UIKit can easily be transformed into a much more pleasant experience if you just fix some of the worst API’s, like embedding ViewControllers and adding constraints in code.
• smallstepforman 2mo ago
  Death by a thousand cuts. First the tech community screamed about memory leaks, so they bolted ARC (automatic resource counting) into Cocoa since unlike C++, Objective-C had no RAII. With swift to be compatible, they forced ARC to all objects. To make RAD (rapid application devolpment), they forced InterfaceBuilder onto the dev community, where artists do layout, but engineers do code. With variable sized screens, RAD tools add constraints to layout, since artists do gui, not engineers. To support Retina displays where GUI is x2, two sets of constraints were added. Spaghetti after twine after hack after crap. All this goes away if you use a language with RAII, dont treat your devs as morons that cannot manage resources, and allow procedural GUI - let smart dev fix layout and pixels per inch. Artist can create mockup screens in photoshot or after effects, devs do actual procedural coding. But no, we’ve gone the LEGO assembly way to avoid hiring smart devs. Disclaimer - I do graphic engines with GUI toolkits for a living.
  • mmustapic 2mo ago
    ARC was basically avoiding typing retain/release when using Cocoa libraries. If you don’t want to use ARC in Swift, use Unmanaged. Same for autolayout, just use view frames and bounds if you want. And Interface Builder comes all the way from Next.
• Alex_L_Wood 2mo ago
  I think SwiftUI is just a reflection of the times we live in. If you look around, many things which used to be done at "great" or "amazing" levels, are now just "good enough". Cars, houses, software, service - it all is just a reflection of the attitude, and even I noticed that I follow this in some of my day-to-day decisions.
• palata 2mo ago
  Can we talk about SwiftPM still not having a proper package registry? I just don't get it.
• waterTanuki 2mo ago
  I shipped an internal company application using SwiftUI a couple of years ago and the author pretty much nailed all of my pain points. At the very least in JavaScriptLand™ you are provided very opinionated ways to go about reactivity: choose your framework flavor and start shipping. In SwiftUI, you have all of these declarative macros, some of which do the same thing, so you spend hours going over whether you should do MVVM or MVC or some other thing to structure your code instead of actually writing the code. It wasn't mentioned in the article but half if not more of swiftui's issues also stem from XCode being the worst IDE to work with. It's incredibly bloated, tries to drive you towards GUI-driven interactions instead of using CLI, and takes ages to explore and understand all the different features/settings. I've never had any other IDE or editor refuse to compile my code because of a memory overflow during the compilation step, yet for some reason, even when compiling swift on an M2 MAX with 64GB of ram in 2026, I regularly get these kinds of cryptic errors that tell me it can't compile. Likely due to misuse of some code expansion feature, but then it rarely tells me where the source of misuse is.
• Decabytes 2mo ago
  There was a post on here awhile ago from Jeffrey Snovers blog about how Microsoft screwed this up as well. Given how many people have moved to electron, and how big companies don’t seem to be able to handle native GUI’s anymore, have we just made the desktops too complicated?