17 ms·

SwiftUI Is Convenient, but Slow

223 points by mort96 4y ago

qwerty456127 4y ago
Are there any non-Apple UI toolkits like this?
- ericlewis 4y ago
  react-native, native script, flutter. xamarin (does that still exist?)
  - c-smile 4y ago
    Sciter here too. On MacOS it renders UI primitives using Skia/Metal.
- SV_BubbleTime 4y ago
  I’ve been down this road, a lot. We use Flutter now. And are quite happy.
- Apocryphon 4y ago
  RxSwift
mort96 4y ago
I'm not the author of this piece, but I find the transition to SwiftUI incredibly interesting and a bit frightening. I've noticed myself that things you'd expect to be swift (pardon the pun), such as loading a screen with a few simple controls in the new Ventura SwiftUI System Settings app, can take a second or more. I'm hoping things like that is either shoddy work on the part of the app or issues which will get ironed out, but I fear that we might see an era of much more random latency issues until hardware becomes powerful enough to make that go away.
- sgt 4y ago
  Haven't done Swift and Cocoa in a while, but is there any major disadvantage to just not using SwiftUI?
  - AJRF 4y ago
    Apple keep pushing it incredibly hard, despite it being poorly implemented. The net effect is less thoughtful developers use it because Apple push it. Eventually it will infect your project because those developers will start pushing it into new features. I regret not being more vocal in my current job about not using it in production and now we have a huge amount of bugs caused by it even between point releases of iOS.
    - data-ottawa 4y ago
      It’s certainly a lower barrier of entry, which is both good and bad. I can mock up an app on my iPad or build some simple utilities quickly, but one things get complex it can become difficult to debug.
  - alin23 4y ago
    Author here! Aside from Lunar (https://lunar.fyi/ https://lunar.fyi/) all my apps over at https://lowtechguys.com/ https://lowtechguys.com/ are 100% SwiftUI. In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass) But if that case does not apply to your UI, the advantages are massive. For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI. [1] https://lowtechguys.com/volum https://lowtechguys.com/volum
    - soapdog 4y ago
      Your apps look really neat. :D
bottlepalm 4y ago
I can see how creating a calendar with hundreds of little interactive elements could be challenging in any UI framework. Like Angular with its digest cycles and React with its DOM reconciliation.
- stephc_int13 4y ago
  No, it should barely be challenging on a 8-bit CPU.
- pornel 4y ago
  Modern computers are incredibly fast. We're just used to layers upon layers of inefficient abstractions. The GPU can animate many millions of vertices per second, the CPU can crunch GB/s of data, but on the high level it ends up so absurdly inefficient that 365 boxes sounds like a lot.
- danpalmer 4y ago
  It's very different due to how the languages work. In React, you're creating JS objects. Naively, each of those is a heap allocation and a bunch of initialisation. With Swift on the other hand, you're creating Views which are structs, which are value types, allocated on the stack, don't have much if any initialisation to do, and are much cheaper to work with. I say naively, because JS interpreters are probably doing smart things to try to minimise the impact of this sort of allocation of many small objects, but they still come at a cost that just isn't present in Swift.
- jonhohle 4y ago
  Look at any AAA game. 10s of millions of textured polygons every 16ms. A render graph with several thousand nodes should not be visibly slow on any modern hardware. I’m always disappointed that people are willing to accept the immense performance penalty of modern frameworks and libraries. Having just finished installing Windows XP on a 2.4GHz P4, its sad to be reminded how wasted current hardware is.
  - 323 4y ago
    > 10s of millions of textured polygons every 16ms But at what cost? 100% CPU and GPU usage, tons of system/video memory. Also, rendering text with full capabilities (arbitrary font/size/color, emoji, ...) is much more complicated than drawing a textured polygon. And how easy is to use a modern 3D engine versus HTML/CSS? You are right that modern frameworks are slow, but there is a reason we don't write Notepads in Unreal Engine.
ohgodplsno 4y ago
"Developer doesn't read best practices documents, thinks he can outperform lazy views and shoots himself in the foot". Feels like a remake of last year's React version, and a sequel is coming out with Compose & Flutter. SwiftUI & AppKit just moves complexity around. Simple UIs take up a lot of work with AppKit just to set things up, but are easier to maintain when it gets complex, and vice versa. In the case of the calendar view rerendering everything, maybe don't pass world changing updates to your top level component. In Compose world, this is using a lambda for state reads to delay them as much as possible.
- alin23 4y ago
  Author here! My best selling app Lunar (https://lunar.fyi/ https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar https://github.com/alin23/Lunar). So much that I finally created a SwiftUI menubar menu for it where I can add the more dynamic bits easily, and just leave the AppKit UI for static preferences stuff. Both AppKit and SwiftUI are good though, Lunar was the first time I was able to create a native UI from scratch and also release it without remorse. But I felt that the dynamic parts were much harder to reason about in AppKit, mostly because of the Delegate paradigm. I also have a preference for a not-so-native look which is much simpler to style using SwiftUI modifiers like clipShape, shadow etc.
  - jdmoreira 4y ago
    > My best selling app Lunar (https://lunar.fyi/ https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar https://github.com/alin23/Lunar) I just wanted to say that you can and most likely should use UIKit without touching interface builder. It's been over 5 years since I've used interface builder and I have no regrets. Just build your UI programatically relying mostly on UIStackViews, constraints and multiple levels of views embedded in views. Write your own helpers on top of UIKit to help you compose views in a more compact way. I basically have a dozen functions I re-use over and over and over to build complex UI from these simple primitives.
stephc_int13 4y ago
Given the powerhouses that are modern CPU, even on mobile, I find it difficult to imagine. Imagine if we used the same kind of tech to build AAA games?
gr__or 4y ago
Wondering if this is related: In MacOS Ventura navigating around settings has become VISIBLY slow. Seconds can pass between clicking a settings option and its contents being rendered. Kind of fascinating that it got released like this at Apple. That said it's only slow to load, it does not freeze or stutter. I guess that's still an upside to what it would've looked like under Windows or Linux.
- stephc_int13 4y ago
  With modern displays being able to refresh at 144-350Hz we could expect modern UI to feel smoother and smoother over time. GPU is not a bottleneck. CPU should not be a bottleneck. Then why?
  - hbn 4y ago
    What Andy giveth, Bill taketh away
  - bzzzt 4y ago
    Seems the setting screens are loaded on-demand, maybe using some plug-in architecture that results in overhead. Also, some panels require network communication which makes them even slower. But even then, I agree there's no excuse.
    - philo23 4y ago
      Some parts of the panes are also webviews too, which definitely doesn't help. From memory you can go in and inspect them from the Safari web inspector.
    - galad87 4y ago
      Each settings panel is run in a separate xpc process, that is launched on demand. So the UI is rendered out of process too. Open Activity Monitor and see how many processes are run when navigating around in System Settings.
  - edflsafoiewq 4y ago
danpalmer 4y ago
SwiftUI might be slower than UIKit at the moment, but it has significantly more potential for performance improvements in the frameworks. With UIKit, developers mostly express the "how" – put this control at these coordinates etc. This makes it quite hard for the framework to a) understand if anything has actually changed, and b) optimise how the UI gets rendered. With SwiftUI, developers much more express the "what" – show the user this information, with these constraints, etc. This allows the framework much more scope to optimise how the layout is accomplished. For example a List of 3 items could skip a bunch of complexity around the handling of swapping views in and out of the hierarchy as it's unlikely to scroll far enough. Additionally, by making the data model a first class concept more than it was with UIKit, SwiftUI has much more understanding about data flow and when the UI needs to be re-rendered, or which parts need to be re-rendered. It's still early days, compared with the maturity of UIKit (which stems from AppKit, which is 20+ years old at this point), but the scope is much deeper and I'm confident the performance will improve as Apple iterate, and as they understand how it's used by developers and improve those code paths.
- terhechte 4y ago
  But this is also one of the big problems of SwiftUI. Because it is effectively a fancy DSL for combining interactive lego pieces, many subtle interactions are just assumed implementation detail. Like how should a "tap" on a Rectangle with a transparent color be interpreted if the rectangle is offset. Because the underlying framework (UIKit) has no notion of these things and because the SwiftUI DSL can't foresee all permutations of its members (Rectangles, HStacks, Spacers, GeometryReaders, etc), oftentimes people build a certain combination of things that results in a certain behaviour. But then the next iOS update this behaviour changed because it was just an ever-changing implementation detail. This leads to constant churn. I agree that at some point we will see less of these surprising behaviours, but as long as Apple iterates on SwiftUI they will happen again and again. Also, regarding performance, any performance optimisation will lead to more of these surprises. To keep my example: Maybe at some point an engineer will add a SwiftUI optimisation for offset rectangles and suddenly the tap doesn't work anymore. After using SwiftUI a lot I'd rather use a more deterministic framework. Or, have it be open source so I can understand what's happening under the hood. The current game of build, inspect and pray every version update is frustrating.
mrtksn 4y ago
SwiftUI is easy to get results quickly but its actually quite hard to master. It's very easy to screw up the rendering lifecycle and bringing the UI to crawl as you cause full UI recalculation at a tiniest data change.
- mromanuk 4y ago
  Yes, it's simple, but no easy (I love this quote). The View Model loop seems deceptively simple at first sight, but you quickly realize that it isn't really the case. You have a long road of learning ahead of you. Specially at the beginning was really buggy. It is undoubtedly improving with every release.
kybernetyk 4y ago
Can't wait till SwiftUI is ready for complex application on macOS. Until then I'm trapped in Cocoaland.
- samuria 4y ago
  Can you please elaborate on what you mean by complex application? Having just started getting into SwiftUI, what are the limitations?
haint_ 4y ago
What's so special about SwiftUI compared to e.g Flutter/Jetpack Compose that I see posts about it frequently on the front page?
- password1 4y ago
  It's from Apple and it's the endorsed UI framework for native development in their ecosystem (more or less). Flutter is not for native development and Jetpack Compose is the equivalent of SwiftUI for Android. It's been the shiny new thing in iOS development since it's launch and of course there's a lot of division about in the community (it's good, it's bad, it's the future, it will never be the future, etc.)
- tpush 4y ago
  There are probably just more users of SwiftUI here than Flutter or Jetpack Compose (I think Apple in general is a bit over-represented on HN).
- alin23 4y ago
  They’re all about improving dev experience, and after all, there’s a large dev audience here wanting to write less and produce more.
- bitwize 4y ago
  It's Apple. Anything Apple is interesting/relevant to Hackernews.
jordanmorgan10 4y ago
SwiftUI is amazing, but the amount of polish you can only apply via representables is what's holding it back for me at the moment.
divan 4y ago
Can someone provide explanation why SwiftUI is slow? My intuition was that it should be extremely fast, especially on the modern MacBooks. I write quite a lot of desktop apps in Flutter (or run mobile apps as MacOS builds, because it's easier to develop and debug this way), and I've never had issues like this, but it's hard to believe that Flutter is faster than SwiftUI. I'm confused by this article.
- c-smile 4y ago
  I don't know internals of SwiftUI that match but if it still using CoreGraphics then it should be slow. CoreGraphics uses CPU rasterization of primitives and that's the problem on modern displays. Retina grade displays have ~9 times more pixels on surface than old 96 ppi monitors. So you need 10 times more performant CPUs for rendering - CPU rasterization is O(Npix) complex - as better (resolution) monitor you have as slow your UI. On the other side games use GPUs (Metal, OpenGL) to render primitives. In that case CPUs just generate lists of primitive definitions in vector forms (polygons, etc.). Rasterization of those primitives is done in parallel by crowd of GPU processors. Therefore, games UI is not tied with monitor resolution directly - same [display] lists are generated by CPU for any monitor resolution. In that respect GPU accelerated UI rendering is O(1) complex.
  - dev_tty01 4y ago
    You can directly enable the use of Metal with the drawingGroup() API. https://www.hackingwithswift.com/books/ios-swiftui/enabling-high-performance-metal-rendering-with-drawinggroup https://www.hackingwithswift.com/books/ios-swiftui/enabling-... You can also embed a UIViewRepresentable to "manually" embed a metal kit view inside a SwiftUI hierarchy. Basically use SwiftUI to manage most of it, but use metal to handle a bottleneck somewhere. Here is an example: https://developer.apple.com/forums/thread/119112 https://developer.apple.com/forums/thread/119112
  - divan 4y ago
    that sounds reasonable, thank you
  - saagarjha 4y ago
ChrisMarshallNY 4y ago
> how hard could it be? The programmer's Credo: We do this, not because it is easy, but because we thought it would be easy. > These damn animations man.. they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere. That's the case with many UI frameworks. Built-in animations are a big draw. For myself, I eschew frameworks, so I have to write the animations by hand. It's a fair bit of work, but they are all supported in UIKit/WatchKit/AppKit. Looks like the performance bottlenecks are from deep recursion. That's probably something that might be code-around-able. UIKit doesn't have as deep a recursion, but it has many other default behaviors that can result in slow performance, and a lot of my "tuning" is about finding these, and determining more optimal code solutions (like redrawing, as opposed to triggering new layouts, etc.; which isn't as easy as you might think. Sometimes, setting a variable in an instance can trigger a new layout). I think that the idea of "code once, deploy everywhere," which SwiftUI promises, is pretty much a smoke seller's[0] dream. It's a classic. C was supposed to do that. Java was supposed to do that, etc. I have found that I really need to write native for each platform, because the user experience is so different, that it's actually impossible to really cater to it, without delivering some lowest-common-denominator-something-just-doesn't-feel-right solution. So, even if I was using SwiftUI, I'd still release an iOS version, a Watch version, a Mac version, etc., with specializations for each. The thing that I like about the idea of SwiftUI (I haven't used it to create a shipping product, yet, so I don't have much more authority to declaim, than as an interested bystander), is that it allows great flexibility in the software development methodology. If I write AppKit/UIKit/WatchKit, it really should be MVC, and not just MVC, but NSObject-based MVC. I know, I know, "But what about MVVM?". I feel that MVVM is an excellent model, but that it is not how these frameworks were designed, so they need to be sort of "kludged" to support it. I work in MVC, because they are totally meant for that model. I'm looking forward to seeing how SwiftUI evolves, but I have yet to be convinced that it is a viable model for me to write shipping software. It's really no hurry. Lots of major shops still write a lot of their stuff in ObjC/UIKt/AppKit/WatchKit (including Apple). It will be a number of years before we're required to use SwiftUI. [0] https://www.tell-a-tale.com/nasreddin-hodja-story-smoke-seller/ https://www.tell-a-tale.com/nasreddin-hodja-story-smoke-sell...
- ericlewis 4y ago
meindnoch 4y ago
These declarative frameworks always work well for demo stuff, then fall flat for actual complex software. I’m talking not just about declarative UIs, but also declarative business logic tools (Windows Workflow Foundation anyone?) too. They always end up slow, incomplete, and in the end require a bunch of bolted-on imperative hacks to get an acceptable outcome. This is the case with React, this was the case with XAML, and this is the case with SwiftUI. Yes, I know, in theory they could be so performant, just like garbage collectors and JITted interpreters. In practice they never are. Hopefully the failing of Moore’s law will eventually put an end to all this inefficient declarative nonsense.
tr3ntg 4y ago
Declarative frameworks are deceptively simple. The promise is that "anyone can use it" - be it UIKit experts or entirely green developers. However, as this article makes clear, a deeper understanding is required to make SwiftUI views performant. It's too easy to end up with accidental anti-patterns scattered throughout your views. Plus, there are more ways to accomplish a given design now. Developers are left to figure out everything on their own without realizing there's a very specific intended approach.
system16 4y ago
It's convenient, until you've written 90% of your app in record time and then end up so blocked on the remaining 10% you wish you would have just used UIKit. I love how quick and easy SwiftUI is for simple, Apple-like / stock app interfaces. But the second you try to do something outside of their guard rails (some of which you don't even see until you've gone outside them), SwiftUI quickly makes you realize you are swimming against the current. I also find debugging SwiftUI to be exceptionally painful compared to UIKit. As others have said though, this improves with every release so I'm confident things will only get better.
- RandallBrown 4y ago
  It's not all or nothing. If you have an interface that would be easier to do with UIKit, simply use UIKit.
  - afro88 4y ago
    The frustrating thing is not knowing when to use UIKit in advance, until it's too late. But yes with experience you can learn and get a sixth sense of when UIKit will be needed.
htk 4y ago
I find SwiftUI to be fast on my projects, even in very complicated interfaces, but I'm always careful to make UI updates correctly target only the necessary views, otherwise the whole screen updates.
georgelyon 4y ago
Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI is a complexity-hiding abstraction. Specifically it hides the complexity of when UI is refreshed and how it is refreshed. This results in a situation where engineers who don’t have a clear understanding of how it works resorting to essentially guesswork to try and fix performance issues. Now, there are certainly folks who do have a deep understanding of how SwiftUI works but that group is likely small and the situation isn’t helped by middling documentation and SwiftUI being closed source. An analogue to this can be seen in something like SQL, which is a (somewhat) declarative specification for queries that is also complexity-hiding. SQL, wielded by a novice, can be pretty slow (just one ill-advised join would likely do it), but would still “work”. The difference with SQL is that there is a plethora of literature about how to write it in a way that results in fast queries and many of the consumers of SQL are open source so enterprising engineers can dig down and figure out what a particular query is doing and why something is slow. We’ve also invested a ton of resources in creating engineers who can write good SQL. I’m interested to see how SwiftUI progresses in these regards. Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.
- terhechte 4y ago
  I really like the SQL comparison. I'll remember that the next time I have to explain a non-iOS developer why a given piece of SwiftUI code is flaky or slow.
- alin23 4y ago
  drawingGroup is exactly what I was looking for, thanks a lot! I didn’t know this was added to SwiftUI.
  - georgelyon 4y ago
    I’m happy this worked for you. This in itself is an interesting anecdote about documentation quality. I knew this API existed but forgot the exact API and searches for “caching SwiftUI rasterized view” and similar queries did not return this API (which, for the record, isn’t exactly what it does…) . I eventually found it in a roundabout way but had I not been pretty sure it existed, I would probably have given up.
shp0ngle 4y ago
Only marginally related, but… I am not sure if I would pay actual money for a calendar app that’s read only… The UX of the app seems nice, but.. why can’t I write there? Do I need to have a separate app for editing?
- alin23 4y ago
  Author here! You probably just don’t have the same need as me, I was expecting this to not be a popular app because of this :) My need is to be able to check when I’ll be able to visit parents, plan trips with friends, answer my wife about when’s our next dentist appointment before she gets tired of waiting and checks it herself, when’s our niece’s birthday, what is the next religious holiday etc. I find I have to check the calendar way more than I have to add something into it. And when I need to add something, I usually like to take the time and fill in useful info like location, travel time, useful URLs and notes. And Calendar.app is already good enough for that.
  - spfzero 4y ago
    Ah! You mentioned in the article needing single button keyboard shortcuts. You can actually do this in SwiftUI, by passing an empty array on for the modifiers. I have code up right now so I'll copy a line: .keyboardShortcut(KeyEquivalent("e"), modifiers: []) That's for using just the "e" key, with no modifiers.
mfDjB 4y ago
It seems like every time a new UI framework comes around, a tradeoff is made between convenience and flexibility, with the advertising always being around "look how easy it is to make a table view", but this doesn't particularly impress me anymore, because as I've used these newer paradigms it seems like I am trading 5 minutes (UIKit) for 3 minutes (SwiftUI) when it comes to basic UI development, but later on trading 30 minutes (UIKit) for 3 hours (SwiftUI) when it comes to anything significantly complex. This is not just true for iOS but web as well. I'm unsure how feasible it would be but it would be really cool if it were possible to benchmark frameworks both by how quick it is to implement basic UI components as well as more complex UIs and score them based on that. I do feel like its quite an insidious trap to do a project to 80% completeness in a framework then be forced to make the awkward decision of "Do I continue with the current framework where the extra 20% will take a long unknown amount of time or rewrite in the old framework and take the time hit but with easily estimatable timelines?".
- bob1029 4y ago
  > "look how easy it is to make a table view" My trap in web dev was "look how easy it is to do responsive layout". Once CSS flex & grid became broadly available, I quickly began to shed my use of frameworks. It took me ~10 years of hard work to get to the point of feeling comfortable in a 100% vanilla web development ecosystem. MDN is my bible now. The advantages of owning your entire web development vertical are impossible to overstate. The counter arguments are so painful to hear in 2022 - "why would you want to re-invent the wheel" kind of crap. The truth is, I don't write most of my vanilla web code from scratch anymore. Once you build 1 thing and it's in github, it takes 5 seconds to copy/paste that component to some other project. Good luck doing that same activity between Angular and React code piles. Or even Angular code piles of differing versions.
  - scarface74 4y ago
    And then someone else has to come behind you to support your custom framework. I can’t count the number of times where an “architect” has evolved their own custom framework because they thought their problem was a special snowflake. It’s usually worse, less document and less tested than the popular alternative.
tayistay 4y ago
We hit performance issues when writing a dataflow graph editor in SwiftUI [1]. We couldn't express the graph as Views and instead used a Canvas to draw everything. So, we had to do manual layout of everything, and manual event processing. This also precludes putting custom views for user-defined UI inside the modules. The performance problem had to do with evaluating the positions of all the wires between the modules using many GeometryReaders. [1] https://github.com/audiokit/flow https://github.com/audiokit/flow
WhitneyLand 4y ago
Let’s slow down a minute here… It looks like some are assuming the problem is with SwiftUI and immediately speculating on the reasons, however even the author admits they do nut understand the framework architecture well enough to be sure. Some of the “problems” that needed to be optimized were using global state that triggered all kinds of unnecessary redraws. This is going to cause problems for any system. Also the author endorses adding “animations just for flourish”, then laments that animations make things slow. The first point is not really a good idea. Beyond that synchronous animations by definition cause latency, that’s not a performance problem. How much of the problem was due to this isn’t mentioned. The whole thing is not well argued and the conclusion of the title is suspect.
- vor_ 4y ago
  If SwiftUI makes it that easy to fall into anti-patterns and the magic behind it is difficult to reason about, then I think performance is going to be a common issue for years to come.
iamcalledrob 4y ago
I've worked with both SwiftUI (iOS/Mac) and Jetpack Compose (Android). Surprisingly, I've found that Compose is hands-down better on both the "developer experience" front as well as the "UI quality" front SwiftUI is "clever" and it's a black box. You get what you get, and Apple steers you away from customising too much. Compose is open source. I can see how the high level components have been built from lower-level primitives—and I can do the same. SwiftUI provides a set of Views and modifiers from Apple, and that's about it (without dropping into UIKit/AppKit, which is costly). Compose is lower-level. For example, a "Button" component in SwiftUI is a black box. I can modify it in a few basic ways, but that's it. Whereas in Compose, I can customise anything. Including jumping into the implementation of "Button", and referencing that to build my own fully custom implementation. SwiftUI is at the bleeding edge of the Swift type system, and you're always fighting with it. You quickly start getting compile errors if your method bodies are deemed too complex ("The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions"). Customising views with styling protocols is a mess too. Compose doesn't make me think about the type system. Rather than returning views, Compose functions render them. This makes a huge difference. After using Compose, I think Apple have made a real design mistake with SwiftUI by relying too heavily on hacking the Swift type system.
- jarjoura 4y ago
  Except for a few complex components, Compose is for all intents, a complete rewrite of the Android view system. SwiftUI, at least in its current iteration, mostly wraps UIKit and AppKit controls and is bound by the contract of those controls. I get the impression that Compose was started as a project to build a platform native version of React or Flutter, with a strong emphasis on incorporating it into existing projects with large teams. SwiftUI on the other hand, seems like it was originally built as a layout engine, then someone saw React and Flutter and incorporated some of its best ideas into it during a later part of the design. A hypothetical comparison: Compose: Button { Surface { Label() } } SwiftUI: if (mac) { NSButton(...) + modifiers } else if (ios) { UIButton(...) + modifiers } Let's say you want to create an icon button for your app: Compose: IconButton { Surface { Column { Icon() Label() } } } SwiftUI: IconButton { Button() + modifiers } Compose provides all of the building blocks you need to push the framework in the ways you want to go in. SwiftUI seems designed to look at it from a Xib/Storyboard perspective. The first problem you can run into with SwiftUI is that if Apple hasn't implemented support for certain modifiers on a Button, you can either create something entirely from scratch, or you can try to figure out hacky ways around the problem. The second problem is that it's entirely closed source and locked to each OS release. So if they decide in a future release to change the underlying implementation, you now have to rewrite that IconButton to say, "do this on older release, and do this new thing on newer releases"
buskila 4y ago
For this kind of an app wouldn’t it be easier to implement it in html/css (probably don’t even need JavaScript) and host it in a webview inside a native wrapper?
RetpolineDrama 4y ago
>This container is lazy so it takes more time get the view rendered because SwiftUI has to check if each row is visible before rendering it. There is absolutely no way a lazy grid ends up being "slower" than a huge list of VStack and HStacks This is a terrible post
- alin23 4y ago
  Maybe try it before jumping to conclusions? In that specific case a lazy container is slower because the views are visible at all times so non-lazy views can render immediately without any boundary checks.
deleted 4y ago
[deleted]
eiiot 4y ago
The main issue with SwiftUI is not its syntax, but how Apple refuses to actually adopt it. Apple pretends that SwiftUI is the "default" for the development of iOS apps, but then refuses to adopt basic features within their APIs (like in MapKit[0] for example, where it's literally impossible to build an interface with anything complicated without moving over to UIKit). For SwiftUI to actually be usable by the majority of iOS developers, Apple needs to start taking it seriously. [0]: https://developer.apple.com/documentation/mapkit/ https://developer.apple.com/documentation/mapkit/
paul7986 4y ago
I'm learning SwiftUI now and would love to talk shop with other SwiftUI and Swift developers. IS there a discord channel, a Twitter group and or something where Swift developers hang out and or follow? Overall love to find a mixture of a tutor and someone to help (hire) me build one of my many super crazy (lol) ideas while I learn through developing it together.
- waprin 4y ago
  I just shipped my first SwiftUI app and have more queued up. Don't know of any Discords but happy to join one or start one with you.
  - paul7986 4y ago
    Hi Bill nice to meet you im Ryan (@ryanspahn & @speakerblast_ap on Twitter) and great to hear of our mutual interests! Congrats on releasing your first app. What's the best way to reach out to you? Email, Twitter or ?
    - waprin 4y ago
      Email is most reliable since I try to moderate social media but Ill ping you on Twitter
      - paul7986 4y ago
        Thanks for the follow and sending an email. I have lost access to my 2006/2007 Twitter account (@ryanspahn followed you via one of my web apps Twitter) yet hoping one day I can pay to have access back.
lordleft 4y ago
Could we just take a moment to acknowledge that this dude wrote an app to support his brother's college expenses? Kudos to the app writer. It's a beautiful thing to tangibly support the people you love.
samsquire 4y ago
It feels that GUI generation is a cache coherency problem. What's rasterized and not re-rendered is part of the dirty cache, anything that renders on top of it is dirty.
wildpeaks 4y ago
As much as I like SwiftUI (and I hope they continue improving it), it still lacks so many features compared to the UIKit equivalents that I recently had to completely rewrite a SwiftUI app recently because half of it was just UIKit wrapped in representables, and Combine doesn't require SwiftUI. It ended up simplifying things because we no longer had to deal with two UI frameworks instead of just one.
LeicaLatte 4y ago
SwiftUI is the worst thing not just because it’s bad. The non stop shilling from Apple has led too many wwdc scholars astray and they are twisting and turning their way filling up stack overflow with weird questions even Apple has no answers for lol. Too much marketing, not enough guidance or documentation from Apple.
tngranados 4y ago
Have you tried using EquatableViews? That would let you customize if you want the view to get updated when the diffing occurs. Seems like a perfect fit for your issue.

223 points by mort96 4y ago

qwerty456127 4y ago

Are there any non-Apple UI toolkits like this?

ericlewis 4y ago
react-native, native script, flutter. xamarin (does that still exist?)
- c-smile 4y ago
  Sciter here too. On MacOS it renders UI primitives using Skia/Metal.
SV_BubbleTime 4y ago
I’ve been down this road, a lot. We use Flutter now. And are quite happy.
Apocryphon 4y ago
RxSwift

mort96 4y ago

I'm not the author of this piece, but I find the transition to SwiftUI incredibly interesting and a bit frightening. I've noticed myself that things you'd expect to be swift (pardon the pun), such as loading a screen with a few simple controls in the new Ventura SwiftUI System Settings app, can take a second or more. I'm hoping things like that is either shoddy work on the part of the app or issues which will get ironed out, but I fear that we might see an era of much more random latency issues until hardware becomes powerful enough to make that go away.

sgt 4y ago
Haven't done Swift and Cocoa in a while, but is there any major disadvantage to just not using SwiftUI?
- AJRF 4y ago
  Apple keep pushing it incredibly hard, despite it being poorly implemented. The net effect is less thoughtful developers use it because Apple push it. Eventually it will infect your project because those developers will start pushing it into new features. I regret not being more vocal in my current job about not using it in production and now we have a huge amount of bugs caused by it even between point releases of iOS.
  - data-ottawa 4y ago
    It’s certainly a lower barrier of entry, which is both good and bad. I can mock up an app on my iPad or build some simple utilities quickly, but one things get complex it can become difficult to debug.
- alin23 4y ago
  Author here! Aside from Lunar (https://lunar.fyi/ https://lunar.fyi/) all my apps over at https://lowtechguys.com/ https://lowtechguys.com/ are 100% SwiftUI. In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass) But if that case does not apply to your UI, the advantages are massive. For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI. [1] https://lowtechguys.com/volum https://lowtechguys.com/volum
  - soapdog 4y ago
    Your apps look really neat. :D

bottlepalm 4y ago

I can see how creating a calendar with hundreds of little interactive elements could be challenging in any UI framework. Like Angular with its digest cycles and React with its DOM reconciliation.

stephc_int13 4y ago
No, it should barely be challenging on a 8-bit CPU.
pornel 4y ago
Modern computers are incredibly fast. We're just used to layers upon layers of inefficient abstractions. The GPU can animate many millions of vertices per second, the CPU can crunch GB/s of data, but on the high level it ends up so absurdly inefficient that 365 boxes sounds like a lot.
danpalmer 4y ago
It's very different due to how the languages work. In React, you're creating JS objects. Naively, each of those is a heap allocation and a bunch of initialisation. With Swift on the other hand, you're creating Views which are structs, which are value types, allocated on the stack, don't have much if any initialisation to do, and are much cheaper to work with. I say naively, because JS interpreters are probably doing smart things to try to minimise the impact of this sort of allocation of many small objects, but they still come at a cost that just isn't present in Swift.
jonhohle 4y ago
Look at any AAA game. 10s of millions of textured polygons every 16ms. A render graph with several thousand nodes should not be visibly slow on any modern hardware. I’m always disappointed that people are willing to accept the immense performance penalty of modern frameworks and libraries. Having just finished installing Windows XP on a 2.4GHz P4, its sad to be reminded how wasted current hardware is.
- 323 4y ago
  > 10s of millions of textured polygons every 16ms But at what cost? 100% CPU and GPU usage, tons of system/video memory. Also, rendering text with full capabilities (arbitrary font/size/color, emoji, ...) is much more complicated than drawing a textured polygon. And how easy is to use a modern 3D engine versus HTML/CSS? You are right that modern frameworks are slow, but there is a reason we don't write Notepads in Unreal Engine.

ohgodplsno 4y ago

"Developer doesn't read best practices documents, thinks he can outperform lazy views and shoots himself in the foot". Feels like a remake of last year's React version, and a sequel is coming out with Compose & Flutter. SwiftUI & AppKit just moves complexity around. Simple UIs take up a lot of work with AppKit just to set things up, but are easier to maintain when it gets complex, and vice versa. In the case of the calendar view rerendering everything, maybe don't pass world changing updates to your top level component. In Compose world, this is using a lambda for state reads to delay them as much as possible.

alin23 4y ago
Author here! My best selling app Lunar (https://lunar.fyi/ https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar https://github.com/alin23/Lunar). So much that I finally created a SwiftUI menubar menu for it where I can add the more dynamic bits easily, and just leave the AppKit UI for static preferences stuff. Both AppKit and SwiftUI are good though, Lunar was the first time I was able to create a native UI from scratch and also release it without remorse. But I felt that the dynamic parts were much harder to reason about in AppKit, mostly because of the Delegate paradigm. I also have a preference for a not-so-native look which is much simpler to style using SwiftUI modifiers like clipShape, shadow etc.
- jdmoreira 4y ago
  > My best selling app Lunar (https://lunar.fyi/ https://lunar.fyi/) is done in AppKit with Storyboards and it’s a pain to maintain (source here: https://github.com/alin23/Lunar https://github.com/alin23/Lunar) I just wanted to say that you can and most likely should use UIKit without touching interface builder. It's been over 5 years since I've used interface builder and I have no regrets. Just build your UI programatically relying mostly on UIStackViews, constraints and multiple levels of views embedded in views. Write your own helpers on top of UIKit to help you compose views in a more compact way. I basically have a dozen functions I re-use over and over and over to build complex UI from these simple primitives.

stephc_int13 4y ago

Given the powerhouses that are modern CPU, even on mobile, I find it difficult to imagine. Imagine if we used the same kind of tech to build AAA games?

gr__or 4y ago

Wondering if this is related: In MacOS Ventura navigating around settings has become VISIBLY slow. Seconds can pass between clicking a settings option and its contents being rendered. Kind of fascinating that it got released like this at Apple. That said it's only slow to load, it does not freeze or stutter. I guess that's still an upside to what it would've looked like under Windows or Linux.

stephc_int13 4y ago
With modern displays being able to refresh at 144-350Hz we could expect modern UI to feel smoother and smoother over time. GPU is not a bottleneck. CPU should not be a bottleneck. Then why?
- hbn 4y ago
  What Andy giveth, Bill taketh away
- bzzzt 4y ago
  Seems the setting screens are loaded on-demand, maybe using some plug-in architecture that results in overhead. Also, some panels require network communication which makes them even slower. But even then, I agree there's no excuse.
  - philo23 4y ago
    Some parts of the panes are also webviews too, which definitely doesn't help. From memory you can go in and inspect them from the Safari web inspector.
  - galad87 4y ago
    Each settings panel is run in a separate xpc process, that is launched on demand. So the UI is rendered out of process too. Open Activity Monitor and see how many processes are run when navigating around in System Settings.
- edflsafoiewq 4y ago

danpalmer 4y ago

SwiftUI might be slower than UIKit at the moment, but it has significantly more potential for performance improvements in the frameworks. With UIKit, developers mostly express the "how" – put this control at these coordinates etc. This makes it quite hard for the framework to a) understand if anything has actually changed, and b) optimise how the UI gets rendered. With SwiftUI, developers much more express the "what" – show the user this information, with these constraints, etc. This allows the framework much more scope to optimise how the layout is accomplished. For example a List of 3 items could skip a bunch of complexity around the handling of swapping views in and out of the hierarchy as it's unlikely to scroll far enough. Additionally, by making the data model a first class concept more than it was with UIKit, SwiftUI has much more understanding about data flow and when the UI needs to be re-rendered, or which parts need to be re-rendered. It's still early days, compared with the maturity of UIKit (which stems from AppKit, which is 20+ years old at this point), but the scope is much deeper and I'm confident the performance will improve as Apple iterate, and as they understand how it's used by developers and improve those code paths.

terhechte 4y ago
But this is also one of the big problems of SwiftUI. Because it is effectively a fancy DSL for combining interactive lego pieces, many subtle interactions are just assumed implementation detail. Like how should a "tap" on a Rectangle with a transparent color be interpreted if the rectangle is offset. Because the underlying framework (UIKit) has no notion of these things and because the SwiftUI DSL can't foresee all permutations of its members (Rectangles, HStacks, Spacers, GeometryReaders, etc), oftentimes people build a certain combination of things that results in a certain behaviour. But then the next iOS update this behaviour changed because it was just an ever-changing implementation detail. This leads to constant churn. I agree that at some point we will see less of these surprising behaviours, but as long as Apple iterates on SwiftUI they will happen again and again. Also, regarding performance, any performance optimisation will lead to more of these surprises. To keep my example: Maybe at some point an engineer will add a SwiftUI optimisation for offset rectangles and suddenly the tap doesn't work anymore. After using SwiftUI a lot I'd rather use a more deterministic framework. Or, have it be open source so I can understand what's happening under the hood. The current game of build, inspect and pray every version update is frustrating.

mrtksn 4y ago

SwiftUI is easy to get results quickly but its actually quite hard to master. It's very easy to screw up the rendering lifecycle and bringing the UI to crawl as you cause full UI recalculation at a tiniest data change.

mromanuk 4y ago
Yes, it's simple, but no easy (I love this quote). The View Model loop seems deceptively simple at first sight, but you quickly realize that it isn't really the case. You have a long road of learning ahead of you. Specially at the beginning was really buggy. It is undoubtedly improving with every release.

kybernetyk 4y ago

Can't wait till SwiftUI is ready for complex application on macOS. Until then I'm trapped in Cocoaland.

samuria 4y ago
Can you please elaborate on what you mean by complex application? Having just started getting into SwiftUI, what are the limitations?

haint_ 4y ago

What's so special about SwiftUI compared to e.g Flutter/Jetpack Compose that I see posts about it frequently on the front page?

password1 4y ago
It's from Apple and it's the endorsed UI framework for native development in their ecosystem (more or less). Flutter is not for native development and Jetpack Compose is the equivalent of SwiftUI for Android. It's been the shiny new thing in iOS development since it's launch and of course there's a lot of division about in the community (it's good, it's bad, it's the future, it will never be the future, etc.)
tpush 4y ago
There are probably just more users of SwiftUI here than Flutter or Jetpack Compose (I think Apple in general is a bit over-represented on HN).
alin23 4y ago
They’re all about improving dev experience, and after all, there’s a large dev audience here wanting to write less and produce more.
bitwize 4y ago
It's Apple. Anything Apple is interesting/relevant to Hackernews.

jordanmorgan10 4y ago

SwiftUI is amazing, but the amount of polish you can only apply via representables is what's holding it back for me at the moment.

divan 4y ago

Can someone provide explanation why SwiftUI is slow? My intuition was that it should be extremely fast, especially on the modern MacBooks. I write quite a lot of desktop apps in Flutter (or run mobile apps as MacOS builds, because it's easier to develop and debug this way), and I've never had issues like this, but it's hard to believe that Flutter is faster than SwiftUI. I'm confused by this article.

c-smile 4y ago
I don't know internals of SwiftUI that match but if it still using CoreGraphics then it should be slow. CoreGraphics uses CPU rasterization of primitives and that's the problem on modern displays. Retina grade displays have ~9 times more pixels on surface than old 96 ppi monitors. So you need 10 times more performant CPUs for rendering - CPU rasterization is O(Npix) complex - as better (resolution) monitor you have as slow your UI. On the other side games use GPUs (Metal, OpenGL) to render primitives. In that case CPUs just generate lists of primitive definitions in vector forms (polygons, etc.). Rasterization of those primitives is done in parallel by crowd of GPU processors. Therefore, games UI is not tied with monitor resolution directly - same [display] lists are generated by CPU for any monitor resolution. In that respect GPU accelerated UI rendering is O(1) complex.
- dev_tty01 4y ago
  You can directly enable the use of Metal with the drawingGroup() API. https://www.hackingwithswift.com/books/ios-swiftui/enabling-high-performance-metal-rendering-with-drawinggroup https://www.hackingwithswift.com/books/ios-swiftui/enabling-... You can also embed a UIViewRepresentable to "manually" embed a metal kit view inside a SwiftUI hierarchy. Basically use SwiftUI to manage most of it, but use metal to handle a bottleneck somewhere. Here is an example: https://developer.apple.com/forums/thread/119112 https://developer.apple.com/forums/thread/119112
- divan 4y ago
  that sounds reasonable, thank you
- saagarjha 4y ago

ChrisMarshallNY 4y ago

> how hard could it be? The programmer's Credo: We do this, not because it is easy, but because we thought it would be easy. > These damn animations man.. they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere. That's the case with many UI frameworks. Built-in animations are a big draw. For myself, I eschew frameworks, so I have to write the animations by hand. It's a fair bit of work, but they are all supported in UIKit/WatchKit/AppKit. Looks like the performance bottlenecks are from deep recursion. That's probably something that might be code-around-able. UIKit doesn't have as deep a recursion, but it has many other default behaviors that can result in slow performance, and a lot of my "tuning" is about finding these, and determining more optimal code solutions (like redrawing, as opposed to triggering new layouts, etc.; which isn't as easy as you might think. Sometimes, setting a variable in an instance can trigger a new layout). I think that the idea of "code once, deploy everywhere," which SwiftUI promises, is pretty much a smoke seller's[0] dream. It's a classic. C was supposed to do that. Java was supposed to do that, etc. I have found that I really need to write native for each platform, because the user experience is so different, that it's actually impossible to really cater to it, without delivering some lowest-common-denominator-something-just-doesn't-feel-right solution. So, even if I was using SwiftUI, I'd still release an iOS version, a Watch version, a Mac version, etc., with specializations for each. The thing that I like about the idea of SwiftUI (I haven't used it to create a shipping product, yet, so I don't have much more authority to declaim, than as an interested bystander), is that it allows great flexibility in the software development methodology. If I write AppKit/UIKit/WatchKit, it really should be MVC, and not just MVC, but NSObject-based MVC. I know, I know, "But what about MVVM?". I feel that MVVM is an excellent model, but that it is not how these frameworks were designed, so they need to be sort of "kludged" to support it. I work in MVC, because they are totally meant for that model. I'm looking forward to seeing how SwiftUI evolves, but I have yet to be convinced that it is a viable model for me to write shipping software. It's really no hurry. Lots of major shops still write a lot of their stuff in ObjC/UIKt/AppKit/WatchKit (including Apple). It will be a number of years before we're required to use SwiftUI. [0] https://www.tell-a-tale.com/nasreddin-hodja-story-smoke-seller/ https://www.tell-a-tale.com/nasreddin-hodja-story-smoke-sell...

ericlewis 4y ago

meindnoch 4y ago

These declarative frameworks always work well for demo stuff, then fall flat for actual complex software. I’m talking not just about declarative UIs, but also declarative business logic tools (Windows Workflow Foundation anyone?) too. They always end up slow, incomplete, and in the end require a bunch of bolted-on imperative hacks to get an acceptable outcome. This is the case with React, this was the case with XAML, and this is the case with SwiftUI. Yes, I know, in theory they could be so performant, just like garbage collectors and JITted interpreters. In practice they never are. Hopefully the failing of Moore’s law will eventually put an end to all this inefficient declarative nonsense.

tr3ntg 4y ago

Declarative frameworks are deceptively simple. The promise is that "anyone can use it" - be it UIKit experts or entirely green developers. However, as this article makes clear, a deeper understanding is required to make SwiftUI views performant. It's too easy to end up with accidental anti-patterns scattered throughout your views. Plus, there are more ways to accomplish a given design now. Developers are left to figure out everything on their own without realizing there's a very specific intended approach.

system16 4y ago

It's convenient, until you've written 90% of your app in record time and then end up so blocked on the remaining 10% you wish you would have just used UIKit. I love how quick and easy SwiftUI is for simple, Apple-like / stock app interfaces. But the second you try to do something outside of their guard rails (some of which you don't even see until you've gone outside them), SwiftUI quickly makes you realize you are swimming against the current. I also find debugging SwiftUI to be exceptionally painful compared to UIKit. As others have said though, this improves with every release so I'm confident things will only get better.

RandallBrown 4y ago
It's not all or nothing. If you have an interface that would be easier to do with UIKit, simply use UIKit.
- afro88 4y ago
  The frustrating thing is not knowing when to use UIKit in advance, until it's too late. But yes with experience you can learn and get a sixth sense of when UIKit will be needed.

htk 4y ago

I find SwiftUI to be fast on my projects, even in very complicated interfaces, but I'm always careful to make UI updates correctly target only the necessary views, otherwise the whole screen updates.

georgelyon 4y ago

Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI is a complexity-hiding abstraction. Specifically it hides the complexity of when UI is refreshed and how it is refreshed. This results in a situation where engineers who don’t have a clear understanding of how it works resorting to essentially guesswork to try and fix performance issues. Now, there are certainly folks who do have a deep understanding of how SwiftUI works but that group is likely small and the situation isn’t helped by middling documentation and SwiftUI being closed source. An analogue to this can be seen in something like SQL, which is a (somewhat) declarative specification for queries that is also complexity-hiding. SQL, wielded by a novice, can be pretty slow (just one ill-advised join would likely do it), but would still “work”. The difference with SQL is that there is a plethora of literature about how to write it in a way that results in fast queries and many of the consumers of SQL are open source so enterprising engineers can dig down and figure out what a particular query is doing and why something is slow. We’ve also invested a ton of resources in creating engineers who can write good SQL. I’m interested to see how SwiftUI progresses in these regards. Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.

terhechte 4y ago
I really like the SQL comparison. I'll remember that the next time I have to explain a non-iOS developer why a given piece of SwiftUI code is flaky or slow.
alin23 4y ago
drawingGroup is exactly what I was looking for, thanks a lot! I didn’t know this was added to SwiftUI.
- georgelyon 4y ago
  I’m happy this worked for you. This in itself is an interesting anecdote about documentation quality. I knew this API existed but forgot the exact API and searches for “caching SwiftUI rasterized view” and similar queries did not return this API (which, for the record, isn’t exactly what it does…) . I eventually found it in a roundabout way but had I not been pretty sure it existed, I would probably have given up.

shp0ngle 4y ago

Only marginally related, but… I am not sure if I would pay actual money for a calendar app that’s read only… The UX of the app seems nice, but.. why can’t I write there? Do I need to have a separate app for editing?

alin23 4y ago
Author here! You probably just don’t have the same need as me, I was expecting this to not be a popular app because of this :) My need is to be able to check when I’ll be able to visit parents, plan trips with friends, answer my wife about when’s our next dentist appointment before she gets tired of waiting and checks it herself, when’s our niece’s birthday, what is the next religious holiday etc. I find I have to check the calendar way more than I have to add something into it. And when I need to add something, I usually like to take the time and fill in useful info like location, travel time, useful URLs and notes. And Calendar.app is already good enough for that.
- spfzero 4y ago
  Ah! You mentioned in the article needing single button keyboard shortcuts. You can actually do this in SwiftUI, by passing an empty array on for the modifiers. I have code up right now so I'll copy a line: .keyboardShortcut(KeyEquivalent("e"), modifiers: []) That's for using just the "e" key, with no modifiers.

mfDjB 4y ago

It seems like every time a new UI framework comes around, a tradeoff is made between convenience and flexibility, with the advertising always being around "look how easy it is to make a table view", but this doesn't particularly impress me anymore, because as I've used these newer paradigms it seems like I am trading 5 minutes (UIKit) for 3 minutes (SwiftUI) when it comes to basic UI development, but later on trading 30 minutes (UIKit) for 3 hours (SwiftUI) when it comes to anything significantly complex. This is not just true for iOS but web as well. I'm unsure how feasible it would be but it would be really cool if it were possible to benchmark frameworks both by how quick it is to implement basic UI components as well as more complex UIs and score them based on that. I do feel like its quite an insidious trap to do a project to 80% completeness in a framework then be forced to make the awkward decision of "Do I continue with the current framework where the extra 20% will take a long unknown amount of time or rewrite in the old framework and take the time hit but with easily estimatable timelines?".

bob1029 4y ago
> "look how easy it is to make a table view" My trap in web dev was "look how easy it is to do responsive layout". Once CSS flex & grid became broadly available, I quickly began to shed my use of frameworks. It took me ~10 years of hard work to get to the point of feeling comfortable in a 100% vanilla web development ecosystem. MDN is my bible now. The advantages of owning your entire web development vertical are impossible to overstate. The counter arguments are so painful to hear in 2022 - "why would you want to re-invent the wheel" kind of crap. The truth is, I don't write most of my vanilla web code from scratch anymore. Once you build 1 thing and it's in github, it takes 5 seconds to copy/paste that component to some other project. Good luck doing that same activity between Angular and React code piles. Or even Angular code piles of differing versions.
- scarface74 4y ago
  And then someone else has to come behind you to support your custom framework. I can’t count the number of times where an “architect” has evolved their own custom framework because they thought their problem was a special snowflake. It’s usually worse, less document and less tested than the popular alternative.

tayistay 4y ago

We hit performance issues when writing a dataflow graph editor in SwiftUI [1]. We couldn't express the graph as Views and instead used a Canvas to draw everything. So, we had to do manual layout of everything, and manual event processing. This also precludes putting custom views for user-defined UI inside the modules. The performance problem had to do with evaluating the positions of all the wires between the modules using many GeometryReaders. [1] https://github.com/audiokit/flow https://github.com/audiokit/flow

WhitneyLand 4y ago

Let’s slow down a minute here… It looks like some are assuming the problem is with SwiftUI and immediately speculating on the reasons, however even the author admits they do nut understand the framework architecture well enough to be sure. Some of the “problems” that needed to be optimized were using global state that triggered all kinds of unnecessary redraws. This is going to cause problems for any system. Also the author endorses adding “animations just for flourish”, then laments that animations make things slow. The first point is not really a good idea. Beyond that synchronous animations by definition cause latency, that’s not a performance problem. How much of the problem was due to this isn’t mentioned. The whole thing is not well argued and the conclusion of the title is suspect.

vor_ 4y ago
If SwiftUI makes it that easy to fall into anti-patterns and the magic behind it is difficult to reason about, then I think performance is going to be a common issue for years to come.

iamcalledrob 4y ago

I've worked with both SwiftUI (iOS/Mac) and Jetpack Compose (Android). Surprisingly, I've found that Compose is hands-down better on both the "developer experience" front as well as the "UI quality" front SwiftUI is "clever" and it's a black box. You get what you get, and Apple steers you away from customising too much. Compose is open source. I can see how the high level components have been built from lower-level primitives—and I can do the same. SwiftUI provides a set of Views and modifiers from Apple, and that's about it (without dropping into UIKit/AppKit, which is costly). Compose is lower-level. For example, a "Button" component in SwiftUI is a black box. I can modify it in a few basic ways, but that's it. Whereas in Compose, I can customise anything. Including jumping into the implementation of "Button", and referencing that to build my own fully custom implementation. SwiftUI is at the bleeding edge of the Swift type system, and you're always fighting with it. You quickly start getting compile errors if your method bodies are deemed too complex ("The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions"). Customising views with styling protocols is a mess too. Compose doesn't make me think about the type system. Rather than returning views, Compose functions render them. This makes a huge difference. After using Compose, I think Apple have made a real design mistake with SwiftUI by relying too heavily on hacking the Swift type system.

jarjoura 4y ago
Except for a few complex components, Compose is for all intents, a complete rewrite of the Android view system. SwiftUI, at least in its current iteration, mostly wraps UIKit and AppKit controls and is bound by the contract of those controls. I get the impression that Compose was started as a project to build a platform native version of React or Flutter, with a strong emphasis on incorporating it into existing projects with large teams. SwiftUI on the other hand, seems like it was originally built as a layout engine, then someone saw React and Flutter and incorporated some of its best ideas into it during a later part of the design. A hypothetical comparison: Compose: Button { Surface { Label() } } SwiftUI: if (mac) { NSButton(...) + modifiers } else if (ios) { UIButton(...) + modifiers } Let's say you want to create an icon button for your app: Compose: IconButton { Surface { Column { Icon() Label() } } } SwiftUI: IconButton { Button() + modifiers } Compose provides all of the building blocks you need to push the framework in the ways you want to go in. SwiftUI seems designed to look at it from a Xib/Storyboard perspective. The first problem you can run into with SwiftUI is that if Apple hasn't implemented support for certain modifiers on a Button, you can either create something entirely from scratch, or you can try to figure out hacky ways around the problem. The second problem is that it's entirely closed source and locked to each OS release. So if they decide in a future release to change the underlying implementation, you now have to rewrite that IconButton to say, "do this on older release, and do this new thing on newer releases"

buskila 4y ago

For this kind of an app wouldn’t it be easier to implement it in html/css (probably don’t even need JavaScript) and host it in a webview inside a native wrapper?

RetpolineDrama 4y ago

>This container is lazy so it takes more time get the view rendered because SwiftUI has to check if each row is visible before rendering it. There is absolutely no way a lazy grid ends up being "slower" than a huge list of VStack and HStacks This is a terrible post

alin23 4y ago
Maybe try it before jumping to conclusions? In that specific case a lazy container is slower because the views are visible at all times so non-lazy views can render immediately without any boundary checks.

deleted 4y ago

[deleted]

eiiot 4y ago

The main issue with SwiftUI is not its syntax, but how Apple refuses to actually adopt it. Apple pretends that SwiftUI is the "default" for the development of iOS apps, but then refuses to adopt basic features within their APIs (like in MapKit[0] for example, where it's literally impossible to build an interface with anything complicated without moving over to UIKit). For SwiftUI to actually be usable by the majority of iOS developers, Apple needs to start taking it seriously. [0]: https://developer.apple.com/documentation/mapkit/ https://developer.apple.com/documentation/mapkit/

paul7986 4y ago

I'm learning SwiftUI now and would love to talk shop with other SwiftUI and Swift developers. IS there a discord channel, a Twitter group and or something where Swift developers hang out and or follow? Overall love to find a mixture of a tutor and someone to help (hire) me build one of my many super crazy (lol) ideas while I learn through developing it together.

waprin 4y ago
I just shipped my first SwiftUI app and have more queued up. Don't know of any Discords but happy to join one or start one with you.
- paul7986 4y ago
  Hi Bill nice to meet you im Ryan (@ryanspahn & @speakerblast_ap on Twitter) and great to hear of our mutual interests! Congrats on releasing your first app. What's the best way to reach out to you? Email, Twitter or ?
  - waprin 4y ago
    Email is most reliable since I try to moderate social media but Ill ping you on Twitter
    - paul7986 4y ago
      Thanks for the follow and sending an email. I have lost access to my 2006/2007 Twitter account (@ryanspahn followed you via one of my web apps Twitter) yet hoping one day I can pay to have access back.

lordleft 4y ago

Could we just take a moment to acknowledge that this dude wrote an app to support his brother's college expenses? Kudos to the app writer. It's a beautiful thing to tangibly support the people you love.

samsquire 4y ago

It feels that GUI generation is a cache coherency problem. What's rasterized and not re-rendered is part of the dirty cache, anything that renders on top of it is dirty.

wildpeaks 4y ago

As much as I like SwiftUI (and I hope they continue improving it), it still lacks so many features compared to the UIKit equivalents that I recently had to completely rewrite a SwiftUI app recently because half of it was just UIKit wrapped in representables, and Combine doesn't require SwiftUI. It ended up simplifying things because we no longer had to deal with two UI frameworks instead of just one.

LeicaLatte 4y ago

SwiftUI is the worst thing not just because it’s bad. The non stop shilling from Apple has led too many wwdc scholars astray and they are twisting and turning their way filling up stack overflow with weird questions even Apple has no answers for lol. Too much marketing, not enough guidance or documentation from Apple.

tngranados 4y ago

Have you tried using EquatableViews? That would let you customize if you want the view to get updated when the diffing occurs. Seems like a perfect fit for your issue.