17 ms·

Why I quit using SwiftUI

• jph 4y ago
  SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of code examples for how to escape out of SwiftUI to handle more-complex cases, and 2) accelerate Xcode speedups of SwiftUI testing-and-instrumentation techniques such as View testing (e.g. ViewInspector) and integration testing vs. unit testing (e.g. reactive vs. dependency injection vs. extension tests vs. protocol tests etc.)
  • coldcode 4y ago
    It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many companies who try to support back at least 1 year. Will it ever be mainstream for iOS/MacOS? Maybe, if Apple would use it way more than they have so far, thus improvement by dogfooding. It is nice to build apps this way, but there are way too many bizarre gotchas still for most people unless you can live with more flexible designs.
    • dpmitu 4y ago
      At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.
      • WanderPanda 4y ago
        Is looking like a generic iOS app that bad?! Especially here on HN where the sentiment is pro plain html etc. a generic iOS UI should be well received
        • deleted 4y ago
          [deleted]
        • wzwy 4y ago
          I’m new to HN. Why the inclination towards plainness? Is it because of performance or look or something else?
          • JohnDeHope 4y ago
            I think a lot of hackers in general, not just on Hacker News, feel like a lot of UI concerns are just bikeshedding.
            • consumer451 4y ago
              What do you think might be good counter examples of this not being the case? Maybe Instagram, Discord... I was going to say Robinhood, but the free trading might have been the real differentiator?
              • kaba0 4y ago
                I think both Instagram and Discord is quite bad on the UX-front on iOS. Strangely enough Microsoft’s Outlook is quite decent while it still looks a bit distinct. It is not generally true of google’s iOS apps that I assume started using Flutter and it feels from time to time (mostly not-smooth scrolling)
                • WanderPanda 4y ago
                  I think Instagram is actually quite fabulous considering how navigating stories has become muscle memory for hundreds of millions of people. And even after they have been around for some time it is still satisfying to tap that profile pic with the ring around it.
    • ozgung 4y ago
      > designers are asking for stupidly complex UI I think a mobile app should have a stupidly simple UI instead. Designers traditionally use a graphics program to design pixels. SwiftUI let’s you design layouts and components. Maybe designers should change how they design and start using SwiftUI as a design tool.
      • azemetre 4y ago
        Your comment reminds me how asinine some Designs orgs have become at companies. Basically chasing fashion statements and demanding Engineers “just do it” with little consideration to the development, maintenance, and testing costs. Modern development, at some companies, can truly feel regressive at times.
        • aYsY4dDQ2NrcNzA 4y ago
          It’s like Design for Machining, if you’re fabricating metal parts.
        • deleted 4y ago
          [deleted]
        • int_19h 4y ago
          Become? Frontend web development was always like that.
    • bradgessler 4y ago
      There’s a back port of the nav view at https://github.com/johnpatrickmorgan/NavigationBackport https://github.com/johnpatrickmorgan/NavigationBackport
      • saagarjha 4y ago
        Obviously, this should be something Apple invests into itself. But they're not going to do it because their culture does not value it; actually, they're often culturally blind to the fact that it might even be useful to provide this. With SwiftUI this kind of nearsightedness really hurts the platform.
        • andrekandre 4y ago
          i think they have a very strong momentum to pushing os releases since... forever... decoupling is hard to do and i was shocked (and gratified) they backported async/await... but swiftui is ui-level, im guessing there must be some real pushback for backporting it... as a customer/developer, the whole os release every year is getting kind of old tbh...
  • elpakal 4y ago
    > but at the same time the docs are terribly lacking at how to handle any kind of edge cases. I agree that Apple’s documentation needs help (this year’s improvements are a nice step) but can we really expect them to provide extensive documentation for handling edge cases (you’re telling me UIKit docs offer that)?
    • heavyset_go 4y ago
      Yes, I expect a trillion dollar company to invest in good documentation of their dev products.
      • worik 4y ago
        My feeling is that Apple hates the developers that develop the software that makes them rich. Forcing myself to be rational "hate" is probably too strong a word. If you are down the Apple cul-de-sac there is really no turning back. So investing in things like code examples for all of their API (there are a few, a very few) is a waste for Apple. It does not attract new developers and the old ones are stuck in the cul-de-sac.
        • ummonk 4y ago
          I suspect you’re ascribing an unrealistic amount of intentionality and rationality to the prioritizations of a giant bureaucracy.
    • diffeomorphism 4y ago
      That sounds very different from what was written? The complaint was about "lacking ... any kind of" yet you write about "extensive documentation". There obviously is a trade off with how much you can/should expect, but "you cannot expect 9/10" is not a valid reply to "it currently is 3/10".
      • elpakal 4y ago
        well thats good because I didn’t say “you cannot expect”, did I?
  • darinf 4y ago
    So wish they would decouple SwiftUI from the OS releases and opensource it!
    • bhedgeoser 4y ago
      ..and from the crappy excuse for an IDE that they distribute along with their build tooling.
      • kaba0 4y ago
        I legit didn’t want to believe my eyes that it takes half a second after each code change before the IDE realizes whether a given change was correct or not. Also, you need clean builds quite often and I even got a “type inference times out” error message once which I haven’t seen in any PL ever even though I did dabble with quite a few static languages with even wider reaching type inference.
        • pixel_tracing 4y ago
          Well this isn’t a runtime time language it’s a compile time language they’ve actually done some great work behind the scenes to enable live view debugging (Previews).
  • choxi 4y ago
    You can integrate UIKit into SwiftUI, I always found that to be a pretty general purpose fallback on any missing functionality in SwiftUI.
  • abiro 4y ago
    They should just acquihire the Big Mountain Studio guy. It’s crazy that you have to pay $300 for proper docs.
  • NonNefarious 4y ago
    We've been hearing this for years now, though. And we've seen SwiftUI takedowns on here before, a year or more ago, and even then SwiftUI wasn't exactly new. Meanwhile, my team has built an entire cross-platform desktop app in Qt with QML, which has been around for years and works refreshingly well. You're telling us that Apple, starting fresh and with several years under its belt now, still hasn't gotten its shit together with SwiftUI? And the word is that nobody at Apple even understands how Xcode works at this point. It's a patched-together shitshow that desperately needs a ground-up rewrite... but we all know how those go. Remember the "ground-up rewrite" of Finder we were promised several major OS releases ago? Still waiting.
    • KerrAvon 4y ago
      What “word”? What “ground-up rewrite”? Do you really believe everything you read on the internet?
      • NonNefarious 4y ago
        Or that I heard while working as an engineer at Apple for 10 years. WHOOPS
        • lapcat 4y ago
          > Or that I heard while working as an engineer at Apple for 10 years. This seems extremely unlikely given your other uninformed comment: https://news.ycombinator.com/item?id=32650545 https://news.ycombinator.com/item?id=32650545
          • NonNefarious 4y ago
    • lapcat 4y ago
      > Remember the "ground-up rewrite" of Finder we were promised several major OS releases ago? No? I've never heard of this. Do you have any citation for such a promise?
• adamnemecek 4y ago
  I like SwiftUI even if most of my views are still NSViewRepresentables, it makes the application structure so much nicer and I don't have to use Interface Builder as much. I know you can use AppKit without Interface Builder but it's more annoying.
• dmitriid 4y ago
  > I profiled the whole thing and discovered several things. First, the view provided by the selectable object was completely recreated with every redraw. I gained some performance back by caching it, but things remained barely usable. That... is exactly the same thing with React. You don't notice everything is redrawn until suddenly everything is unbearably slow. And then it's useMemo etc. galore. I'll withhold my judgement on SwiftUI for now though.
  • solomatov 4y ago
    IMO, you shouldn't use React-like tools in performance critical UI code. Direct DOM manipulation in such cases is much better and more maintainable option. I.e., it's easier to maintain straightforward direct DOM manipulations than all the tuning around making a React-like system more performant.
    • bdougherty 4y ago
      I would call Svelte a React-like system that actually does do direct DOM manipulations and works great for performance-critical UI code as well as everything else.
    • jollybean 4y ago
      Then why use it anywhere? I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner. I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'. The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.
      • solomatov 4y ago
        >Then why use it anywhere? To write code quicker, and make it easier to maintain. If it's a moderately complicated UI, then I could code it up much faster in React (my guess is around 10x). IMO, React isn't about functional programming, it's just a good DSL for writing UI.
• retskrad 4y ago
  People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?
  • bsaul 4y ago
    I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..
    • GrabbinD33ze69 4y ago
      I agree, in my experience, MacOS is one of the most reliable operating systems I've used in terms of lack of crashes or spurrious bugs; the most common bug I see is my mouse pointer dissapearing, which is fixed by opening the tasks view.
      • DelightOne 4y ago
        My mouse pointer also disappeared for a time when it by accident crossed over to my iPad. After disabling that feature it never happened again.
      • pohuing 4y ago
        If only they could so something about the truly terrible window switching crap, where you'll have to hit the same icon in your doc multiple times to eventually with a bit of luck get to the window you wanted. Why can't we have window previews like Windows has had since Windows 7 or just about every DE on Linux
        • mml 4y ago
          hold down option when you release the selection to force hidden windows up. i too hate this behavior.
        • resist_futility 4y ago
• TazeTSchnitzel 4y ago
  The post didn't go into much detail as to why it seems to be so slow. Is SwiftUI recreating an entire UI's worth of components when a state update happens?
  • bsaul 4y ago
    To me that’s the red flag. That an experienced game developer wasn’t able to properly troubleshoot down to the correct level, but ended up facing a black box and gave up.
    • bowsamic 4y ago
      Well that's supposed to be the point of SwiftUI. You write out your declarative structure, let the library worry about how to make it fast, and move on with your day. They literally introduced it that way. Obviously that is very detached from reality
    • ohgodplsno 4y ago
      I am not developing on Apple platforms, but just like any reactive UI framework, i am almost certain the documentation of SwiftUI starts with a massive red flag that says "make your updates granular and don't repost a whole ass struct on every frame" at the very beginning which is exactly what the author seems to be doing. If all you want is a declarative UI, just dump in ImGui and be done with it.
      • yakubin 4y ago
        ImGui doesn't give you native OS widgets.
    • saagarjha 4y ago
      Game developers typically redraw the entire world on each frame. This is not how UI frameworks are intended to be used, even though SwiftUI presents an interface that kind of looks like that. I'm not blaming the author for not understanding this, but I think this distinction is very important to make when working with SwiftUI.
• solarmist 4y ago
  It sounds like SwiftUI is capable, but not performant for his use case. Fair enough.
  • nishs 4y ago
    It's also not capable right now (macOS 12/iOS 15/Xcode 13) for some parts. For example, there is no simple way to declare initial focus for a text field in a view. One has to resort to "onAppear" hacks, such as: .onAppear { // 0.05 is a guess. anything lower seems to run too early // and does not have the desired effect. DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) { focusTextField = true } } Similarly, dismissing text field focus & on-screen keyboard upon scrolling/tapping away is a source of programming pain. It seemingly was bad in the old APIs. It is worse in SwiftUI in my limited experience. Same for scrolling a view such that an active text field isn't covered by the on-screen keyboard.
    • solarmist 4y ago
      Sure, I didn't necessarily mean it in a fully general way, just for the project being described. That is the obvious (comparatively) way it is still incomplete.
• pixel_tracing 4y ago
  The entire view shouldn’t be redrawn but certain views only (not the entire tree) maybe look into prevent entire view from being redrawn itself (React does this too and you can prevent redraw without utilizing useMemo by understanding it’s internals)
  • tadfisher 4y ago
    Compose bakes this into the framework at the function level. By default, if the function parameters are immutable and the function doesn't return a value (basically emits compositions by calling other Composable functions) the entire composition is memoized and the function can be skipped. The tricky part is knowing what is immutable, because standard JVM collections are not.
  • saagarjha 4y ago
    SwiftUI has this too. It's not particularly discoverable but if you do it correctly you can avoid these kind of issues. The problem is that SwiftUI doesn't really make it particularly obvious when and how you might want to use this, which leads to issues like these.
• socialdemocrat 4y ago
  I spent only about half an hour with Swift UI to decide it was bot worth it. Looks sleek but the underlying technology is too complex IMHO.
  • bowsamic 4y ago
    I agree. The amount of plumbing behind the scenes is really complex. This immediately becomes apparent if, for example, you want to use @AppStorage with something that isn't a very simple type. Then suddenly you are in no mans land reading Combine documentation with no examples
  • seanalltogether 4y ago
    I just wish that Apple had used this big effort to update their ui tooling to instead 1. Bring in stylesheets to UIKit/AppKit, 2. Let us define UIKit/Appkit views with simple straightforward xml like android or xaml.
• mrtksn 4y ago
  The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS. Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for specific versions of the iOS. That's what you get when a framework is not mature yet, I guess. That said, I don't think there's a turning back. It might be buggy but it definitely feels like the right way of building UI. Oh, about the performance, you can build very sluggish or very responsive UI with SwiftUI because there's a night and day performance cost difference between "re-calculating and re-drawing" the UI and adjusting a property of it. Always try to structure your components in a way that changes happen by changing passed values instead of inserting or re-doing the views. SwiftUI works quite a bit like React, many performance lessons from React will translate into SwiftUI.
  • jamil7 4y ago
    > Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. I've been able to workaround this by sticking a .id() on the view in question, I've seen similar issues with views falling out of the keyviewloop when you have a bunch of dynamic forms.
    • mrtksn 4y ago
      Thanks for the tip!
  • guelo 4y ago
    Tying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.
    • mrtksn 4y ago
      I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
• solomatov 4y ago
  What surprises me the most is that Apple didn't open source it even many years since unveiling has passed. It doesn't look to me that they have any risks here. The library could be used only on Apple platforms. It will let users submit fix PRs, and make debugging code (by framework users) much easier.
  • worik 4y ago
    They will be embarrassed, perhaps, about code quality
  • makeitdouble 4y ago
    Perhaps there isn’t enough internal sponsors of open source initiatives now that Chris Lattner has left ? (I of course don’t think he was the only one pushing for it, but I also assume his departure triggered/coincided with other events that might not have been made public and shuffling happened in keys teams)
• kitsunesoba 4y ago
  The main issue with SwiftUI is sheer lack of maturity. People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as SwiftUI is isn't going to be able to compare in terms of polish or capability. So for now I'm sticking to UIKit in the apps I'm responsible for. I think SwiftUI's day in the sun is coming, but it's not here quite yet. That doesn't mean that there aren't issues with how it's being engineered and documented, though. It has serious shortcomings that need to be shored up, and hopefully that happens with its maturation.
  • ricardobeat 4y ago
    It is already three years old. I doubt AppKit, UIKit or any of the predecessors were in a bad state for three whole years after their launch.
    • kitsunesoba 4y ago
      I can’t speak for AppKit, but UIKit/Cocoa Touch was pretty rough early on. Major chunks of “standard” functionality were missing and standard widgets were somewhat inflexible. It was common to pull in third party libraries and write custom widget code for relatively basic things. Based on my experience, the UIKit dev experience didn’t start to reach the level of completeness it’s known for now until some time between iOS 7 and 9… at least that’s when I remember the number of “required” third party libraries start to steeply decline.
    • nemo 4y ago
      >I doubt AppKit, UIKit or any of the predecessors were in a bad state for three whole years after their launch I was there for Cocoa development in Mac OS X 10.3. AppKit was not mature. I wasn't there but have heard it was less mature in '91 3 years into NextSTEP.
    • Longhanks 4y ago
      AppKit was so not mature that Apple shipped its whole legacy UI framework Carbon for a decade to come, with even the Finder itself taking until 2009 to be rewritten in AppKit.
• Apocryphon 4y ago
  If I was to build a new mobile app using a shiny new declarative framework, I’d rather use Flutter, because at least that provides the benefit of targeting Android for free. Depending on the type and scale of the app, of course.
  • mhoad 4y ago
    I know that the HN crowd has a weird relationship with both Apple and Google that go in two very different directions regardless of the evidence but honestly I think what you are proposing is actually a really good long term plan. Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak that should clear up the remaining issues people seem to have with it when it comes to performance and the rest of the project is incredibly well supported and documented and most importantly as you hinted at genuinely cross platform. It’s a much better bet for basically any project outside of one that you know for a fact is only ever going to target Apple operating systems.
    • Apocryphon 4y ago
      To elaborate upon my previous post: 1. SwiftUI seems mainly suited for building quick proof-of-concept simple intro apps, with the difficult 20% still out of reach. Which doesn’t sound all that different from the notorious downsides of cross-platform frameworks, some of which can allow for small simple apps to be quickly spun up, but the tough under-the-hood cases still intractable. 2. Flutter, and React Native are more mature than SwiftUI is right now. SwiftUI will get there, and maybe it’s only 1-2 years away, but it still hasn’t hit its Swift 5 moment yet. That opens up the possibility of breaking API or even conceptual changes until then.
    • Bolkan 4y ago
      > Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak Source?
      • nextstepguy 4y ago
        https://github.com/flutter/flutter/wiki/Roadmap https://github.com/flutter/flutter/wiki/Roadmap
• aaaaaaaaaaab 4y ago
  People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.
  • rudedogg 4y ago
    > They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff. At WWDC 2022 they specifically said that Swift+SwiftUI is the best way to build apps, and the future of their platforms. I thought AppKit/UIKit would stick around, but I guess not. --------------------------- Edit: Here's the direct quote from the "Platforms State of the Union": > We're continuing to expand our adoption of SwiftUI across our apps and system interfaces. For example, iOS's new Lock Screen widgets were designed from the ground up using SwiftUI. The new Font Book app was completely rewritten with it. And the modern, forward-looking design of the new macOS System Settings app was built using it. Swift and SwiftUI were designed from the start to provide a single, native language and API for all Apple platforms. You can learn them once and apply them everywhere. Whether your vision is to provide quick access to information at a glance on Apple Watch, productivity tools on MacBook Pro and iPad, new experiences on iPhone, or a new way to relax with Apple TV, Swift, SwiftUI, and Xcode provide a next-generation integrated development platform to help you build apps for all of our products. Now, if you have an existing app, it's easy to adopt these new technologies incrementally. And if you're new to our platforms or if you're starting a brand-new app, the best way to build an app is with Swift and SwiftUI. The slide had a Swift, SwiftUI, and Xcode logo with nothing else.
    • bowsamic 4y ago
      There is no evidence to suggest that Apple are deprecating AppKit and UIKit
      • 4y ago
• bowsamic 4y ago
  I just don't get what purpose it really solves over UIKit. Everything seems far more complicated in SwiftUI, and the data dependence problems it solves did not ever really seem to be a huge issue in UIKit anyway. Apple's sell for SwiftUI was "it's like going to a chef who knows how to cook for you" instead of "cooking yourself". But is that really a good thing? Do we really want to be taking less control of our applications when we write them? The worst part is all these tutorials that have to combine SwiftUI and UIKit because the former is very buggy in certain cases, like navigation trees on iOS have really janky animations using SwiftUI. So you have to coordinate all your Views using UIKit. It just seems barely easier to use SwiftUI most of the time. EDIT: Basically, in summary, it seems like a very complicated (look at the crazy language features they had to add for it) plus very opaque ("it magically does it for you just how you wanted") way to write the same apps you were already writing fine in UIKit and AppKit
  • aaaaaaaaaaab 4y ago
    I have some friends at Apple... The story goes something like this: SwiftUI came about because someone who has never been a software engineer, got concerned about losing mindshare to ReactNative et al. So this person created a "task force" to deal with the problem by tacking something on top of UIKit that resembles React, to create a "friendly" ingress funnel into the iOS world.
    • andrekandre 4y ago
      > SwiftUI came about because someone who has never been a software engineer so... management?
    • firecall 4y ago
      That sounds about right! I recently began developing with Flutter for a project. And whilst I dont love Flutter/Dart that much, I must admit that Google have done an amazing job of proving resources and documentation for the frameworks! The whole Flutter community and available resources feels very rich, welcoming and embracing! Tech like Flutter is fresh and exciting to a lot of people, and Apple is right to be worried! So say what you will about Flutter/Dart, love it or hate it, the docs and community are excellent!
• jmull 4y ago
  The declarative, "reactive" approach is good, and worthy of rolling out a new UI API even given that Apple has an excellent MVC-style API... But it looks like the task was somewhat beyond the people who had the responsibility for rolling out SwiftUI at Apple. We're several years in to SwiftUI. Apple's in a tough spot now. I'm really glad I don't have anything too high-stakes dependent on it. (I only have a project with ~200 hours invested -- not zero! -- it's heavily UI, but it's tiny... maybe ~30-40 hours to port to UIKit, if needs be.)
• ChrisMarshallNY 4y ago
  I like what SwiftUI will become, but I'm not there. yet. The current project that I'm working on, is pretty big. It peaked at 40 screens, but I'm trying to get it down to half that. I've been working on it for two years. I also wrote one of the backends (and most of another). There was no way that I was going to start on a project of that complexity on SwiftUI, which, at the time I started, had only been demonstrated in a few small projects. I already knew that UIKit could do it. But I think that SwiftUI will become the standard, sooner or later. I look forward to being able to write more reactive applications in it. In my experience, if I use UIKit, it's a fairly bad idea to stray from the old MVC model (This, I have learned. <Pulls up shirt> See this scar?).
• rudedogg 4y ago
  I'm building an IDE in (mostly) SwiftUI, and have been using it since release, so I feel like I've worked with it more than most people. A couple observations: - SwiftUI is really complex It's going to take you at least a year to get used to the declarative way it works, and be able to make UIs without struggling to figure out how to shuffle data around. If you look at SwiftUI examples/code, most of the complexity is hidden, but it's there, and you're going to have to interact with it to do anything non-trivial. - Is SwiftUI the way? SwiftUI has enabled me to build out huge amounts of beautiful UI quickly – faster than anything I've ever used. But you will run into things you can't do, forcing you have to fall back to AppKit/UIKit. And the area where AppKit/SwiftUI meet will disappoint and frustrate you. I just got done refactoring a huge amount of my app to use the "AppKit App Lifecycle" instead of the SwiftUI App lifecycle since I need some specific windowing behavior. Now I can't use .toolbar, .menu, and other stuff, which makes things much more complicated for me, and forces me to think about both SwiftUI/AppKit. Switching mental models like that, and trying to remember all the intricacies of both SwiftUI and AppKit is rough. -------------- Regarding the performance issues of this specific post, my guess is they put everything into an ObservableObject, and used @Published properties to get bindings for their UI controls. This means any view with a reference to the ObservableObject gets re-rendered when @Published values change. Instead you need to silo your changes, so your entire App isn't redrawn every frame. This goes back to the complexity – it's not straightforward at all.
  • jules 4y ago
    How do you silo the changes? The issue was that changing a property of an object caused the inspector to be redrawn. With old fashioned UI libraries you would only change the value of one text field in the inspector. Can this be achieved with SwiftUI? To be honest I'm surprised that it's that slow even if the entire inspector is redrawn. Surely on a modern computer you can redraw a couple of text fields at 30fps?
    • rudedogg 4y ago
      See this answer: https://swiftui-lab.com/digital-lounges-2022/#data-15 https://swiftui-lab.com/digital-lounges-2022/#data-15 > Surely on a modern computer you can redraw a couple of text fields at 30fps? Yeah this is the tricky thing, with how (I'm guessing) the code looks, you would think it's only updating the text fields. But in reality it's probably re-rendering the entire hierarchy using the @EnvironmentObject. So the SceneKit view gets setup and rendered every update of the Slider. ------------------ I have real-time color pickers for changing all windows in my app. Same with font sizes. It's possible to make it work, you just have to modify your design (which is unfortunate).
• deleted 4y ago
  [deleted]
• worik 4y ago
  > I profiled the whole thing and discovered several things Well done After two years with Xcode/Swift/SwiftUI I never succeeded in getting anything useful out of the profiler.
  • saagarjha 4y ago
    I assume you mean Instruments? What have you tried doing? Do you have past experience with how to profile and optimize applications?
    • worik 4y ago
      > What have you tried doing? Following the instructions from "blogs", official videos, and what official documentation exists > Do you have past experience with how to profile and optimize applications? Yes. About three decades
      • saagarjha 4y ago
        The first step is usually to figure out what is actually taking all the time, Instruments is good at this. What did it say? Was it your code, or AttributeGraph stuff? Or maybe layout code in UIKit/AppKit? Once you find that you will probably want to isolate which part of your UI is actually triggering this. Ideally identifying if it's a "I got called once and SwiftUI freaked out" or "SwiftUI keeps calling me for changes and I don't have any changes, but this is still bad for performance".
• ncmncm 4y ago
  Coding for a walled garden will always be an exercise in futility. The tooling will always be less mature than you can find elsewhere. And in the end, all you have is a thing that works only in the walled garden. Of course this observation is not limited to any particular garden.
• data-leon 4y ago
  Built an  macOS app (https://posturenet.app https://posturenet.app) to monitor my posture in real time with SwiftUI last year for fun. The lack of support for Video and Camera from SwiftUI was the most challenging part for me as a newbie  Mac dev. Took me a few weekends to get the core part done (ML and algorithm), but hooking up all the UI components and connecting them with the video stream gave me so many headaches. With that said, it was still much easier for me (complete newbie to  Mac App at the time) to learn and develop in SwiftUI than UIKit. Hope SwiftUI keeps getting better and  keeps investing in the team.
  • samatman 4y ago
    You're getting downvoted because HN filters emoji, and because people who aren't on Apple devices won't see the icon you expect, because the codepoint is in the Private Use Area, so they'll see tofu. Just an FYI.
• robertbmenke 4y ago
  My SwiftUI codebase for https://equater.app https://equater.app definitely has some "// TODO: when apple fixes X" comments, but there's no denying the MASSIVE developer velocity I gained from using the framework. If the bugs are bad enough I can always do something custom in UIKit via UIViewRepresentable.
• stephc_int13 4y ago
  Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.
  • gnlrtntv 4y ago
    The cost here is not from rendering speed — as you point out, UI rendering is so fast in most modern environments, even on a bad day, that drawing the UI itself is pretty much never the actual load that slows anything to a crawl. Based on the author's description, it sounds like the real cost here was from way over-diffing a set of models that weren't very efficiently bound to the UI. This is a very common source of bugs in all declarative frameworks. In SwiftUI, the consequences can be particularly bad, because there are a couple somewhat innocent-sounding ways of injecting dependencies into your UI that actually invalidate the whole thing on any value's change and cause major updates (including, if a custom "Representable" that uses its own GPU tools is not implemented carefully, potentially reallocating all kinds of buffers and drawing tools). This is all stuff that you learn how to deal with as you get used to the framework and learn its more advanced tools, but adapting to this part is not really something there's a lot of documentation for.
  • kevingadd 4y ago
    In my experience working with IMGUI-style libraries, it's definitely feasible to perform full layout and rendering for complex UI in 1-2ms at most. For simpler applications it should be basically free. It's depressing that people are willing to accept complex, slow layout APIs at this point considering it's been possible for stuff to be fast for a long time. Perhaps surprisingly, the most expensive part is usually text layout and rendering - text shaping is just really expensive and in the industry standard libraries it can take a long time to lay out a string, so you have to aggressively cache and do fancy things to get good performance. ASCII text is fast, though.
    • saagarjha 4y ago
      Whenever people come up with low numbers like that their mental model is really what they see as sticking some ASCII on the screen with a couple of colors blitted in. Doing text rendering that is actually good, transparency, shadows, the things that make a UI worth using makes things somewhat more expensive. It doesn't have to be overbearingly expensive–modern computers are fast, after all–but it's definitely going to be more than what you think an imgui thing is going to take. And this is pretty important when you're making an OS, otherwise you're really making something that a lot of people will not want to or be able to use.
• ChildOfChaos 4y ago
  Ugh. I haven't really coded things since I was a kid and since I have an iPad/iPhone/iMac and wanted to learn how to code again and potentially use it as a side hustle or some sort of future money making opportunity, I decided to learn swift/swiftUI and i'm currently taking an online course, but when I read through hacker news, all I see is articles bashing it constantly.
  • btreesOfSpring 4y ago
    Here is a 30 minute podcast episode titled, "Different, But Not Worse," on SwiftUI vs UIKit.[0] This thoughtful take is a whole lot less adversarial towards adopting SwiftUI than what you tend to read on this forum. [0] https://www.relay.fm/radar/247 https://www.relay.fm/radar/247
  • deleted 4y ago
    [deleted]
  • wzwy 4y ago
    If you’re just starting out, a lot of those complaints will probably be addressed by the time you start your Swift/SwiftUI side-hustle. Unless you’re a very quick-learner in which case you’ll just have to use it in its flawed state, or learn UIKit I guess.
• stackedinserter 4y ago
  In 2022 developing software for iOS (now iPhoneOS) feels like you're working for Apple for free. You have to look closely to new requirements that they roll out every few months. You should use Apple products in your app or gtfo (e.g. login with Apple ID). You have to update your laptop every few years because Xcode (which is monumental PoS) requires new MacOS that your hardware doesn't support. And when you go through all this trouble, you have to literally beg Apply to admit a new version of your app. You even have to pay Apple to be able to write apps for their phones/tablets. I'm so glad I jumped off iOS development a few years ago. If you're a young developer and still not decided what area suits you the most, think twice before entering iOS and MacOS development.
  • qudat 4y ago
    I couldn’t agree more, especially the bit about Xcode. I don’t even do apple development but still have to deal with it on every upgrade. What a pain
  • deleted 4y ago
    [deleted]
  • wzwy 4y ago
    Apple’s paywall to write apps for their AppStore is infuriating. On top of that, it’s a subscription. The only thing I want is to develop an app for my own use, but I need a paid account if I want an app that lasts long.
• brailsafe 4y ago
  I quite like SwiftUI most of the time, and have got past most of hurdles, such as integrating state with menubar views. But my biggest hangup is that it's used for 3 different platforms with 3 different sets of variation, and most tutorials focus on iOS
• foobarding 4y ago
  Dealing with SwiftUI recreating Views too often can be a challenge. I would have liked to have seen more details on how this guy setup his models. In my experience, you definitely have to minimize work done in Views and maybe avoid `@Published` properties on your model in favor of more explicit calls to `objectWillChange.send()` to signal when you really are ready for the Views to be updated. SwiftUI does not seem to do a very good job of coalescing by default.
• sonicrocketman 4y ago
  Interesting post. I'm curious about adopting Swift UI myself and this is good to know. btw, please add an RSS feed to your site. If you have one it's not discoverable via in-page links, link tags, or educated guessing.
• billjings 4y ago
  This discussion feels incomplete to me without a mention of developments in the opposing camp: Google's Compose UI framework. On Android, at least, Compose feels fully baked to us. Our shop is fully committed to new development on Compose UI; bridging tools for legacy components work great, and they work great for hosting new Compose views in our legacy framework as well. The Compose team is engaged with the community, and is generally ahead of the ball on problems real engineers are having. In addition to all that, the structure of Compose has led to its new tooling being used in a variety of other domains. Engineers outside of Google are wiring Compose up to TUI frameworks, to platform-independent view APIs, and even running Compose without any UI at all as an asynchronous programming framework. I don't have any experience with SwiftUI to compare it to. As an outsider, I know that the naysayers are sometimes louder than happy consumers of a new technology. But I will say this: there's a whole narrative in the Android world pointing out that Compose and Compose UI are two different things. Compose is available to use and work with even if you never touch the concrete UI framework Google has built. Does any equivalent narrative exist in the iOS world? Or is SwiftUI mostly just a UI framework?
  • darnthenuggets 4y ago
    I found mosaic which seems to be the compose tui library you mentioned. Any other projects you know of using compose interestingly?
    • billjings 4y ago
      Molecule is another. Glance (https://developer.android.com/jetpack/androidx/releases/glance https://developer.android.com/jetpack/androidx/releases/glan...) is built on top of Compose, but without using the local Compose UI runtime: it's for drawing remote widgets. And there's a session on native UI with multiplatform Compose on the agenda at Droidcon NYC next week: https://nyc.droidcon.com/agenda/ https://nyc.droidcon.com/agenda/
• deleted 4y ago
  [deleted]
• saagarjha 4y ago
  This is an interesting article, because SwiftUI has a lot of constraints and quirks (which I definitely will not go into here) but it identifies performance specifically as something they ran into problems with. SwiftUI, like all "reactive" frameworks, specifically tries to make your UI a function of state, trying to "logically" redraw everything so that it's always up-to-date. Obviously, this kind of UI is untenable so it will try to form a dependency graph of what needs updating and change only that. The issue is that Apple sort of claims that this is all you really need to do, and that the framework will kind of handle it for you. In reality you need to be really careful about what's being updated to avoid spurious updates. Actual SwiftUI code for anything non-trivial necessarily requires some manual debouncing and equatable checks. I hear React Native often has the same issue, but there people have experience with applying memo when necessary. With SwiftUI it's considered "advanced" and bites people before they really know how to deal with it. And, of course, that's assuming that the dependency graph is working correctly: if it's not, you're often stuck and there's often not much you can do.
  • pjmlp 4y ago
    Not only spurious updates, this kind of architecture generates tons of garbage every couple of seconds, which at least Swift can improve thanks to its support for value types. React and Jetpack Compose aren't so lucky, having to rely on the underlying optimizations of JS engines and ART, on escape analyis and GC algorithms. I never understood the love for reactive for interactive GUIs, when they are so bad in memory management and its effects to jank.
    • kaba0 4y ago
      Is it really that bad (the garbage generation)? Modern GCs are insanely good, short-lived objects can be quite cheap. Also, aren’t they basically push-based reactive frameworks? I would assume they just call a bunch of registered functions and that’s it. The graph itself shouldn’t change too often (and may be static as well, eg. React vs SolidJS) — but I am way out of my depth here.
      • pjmlp 4y ago
• captainmuon 4y ago
  I've encountered the problem he describes in WinUI, too. It can happen in any toolkit where you bind to change events of "observables". In my case I had a list view and a details view, and when you pressed down in the list view, it would get janky and struggle to update the detail view in time. To make it worse, sometimes selecting a different row would hit off a HTTP request in the background to update some cached data. I ended up implementing a similar rate limiter, I think based on this here: https://weblog.west-wind.com/posts/2017/Jul/02/Debouncing-and-Throttling-Dispatcher-Events https://weblog.west-wind.com/posts/2017/Jul/02/Debouncing-an... (I've never shipped it though.) The art is to get the behavior just right. You want the first request to go through immediately, so on a single click the user sees low latency. But afterwards you need to throttle it so that it only updates every, say, 500 ms. And you must not forget to display the very latest state, if there is no new event after e.g. 50 ms. This seems like one of those things that are really hard to get right and the toolkit developer should have solved for you. I've struggled with it a couple of times now.
  • pjmlp 4y ago
    If you mean WinUI 3.0, it is in worse state than SwiftUI, to the point Windows 11 is still making use of plain UWP (hence why WinUI 2.x releases keep happening). And in both cases, still not up to the set of WPF capabilities in that regard.