6 ms·

SwiftUI is convenient, but slow (2022)

64 points by goranmoomin 3y ago

willio58 3y ago
It’s kinda like React in that way. And it’s similar in that newer devices run it well enough that devs might think they don’t have performance issues at all, but when using an older iPhone you can start to see it stutter.
Alifatisk 3y ago
The way SwiftUI is structured reminds me a lot of Flutter, it has its perks but can be quite deep when nesting widgets.
- Alifatisk 3y ago
  Any reason why I got downvoted? Was my comment bad?
  - conradfr 3y ago
    HN loves Flutter;)
  - refulgentis 3y ago
    No you're absolutely right. Came here to post ~the same thing. Mine was going to be a lot more aggressive in favor of Flutter, ex. SwiftUI doesn't have hot reload, looks like it _always_ needs to repaint on a state change (whereas Flutter has that widget | paint boundary that keeps things brutally efficient). Once you use InheritedWidgets / Provider / Riverpod you get provably minimal CPU usage, i.e. minimal rebuilds, the subwidgets never repaint unless you want them to. Top it off with pervasive StatelessWidgets and you have provably minimal RAM usage. I guess what I'd say is, it doesn't add much to the conversation: every view framework that needs to repaint a deep view tree entirely has issues, and in retrospect, there's deeper observations to make w/r/t SwiftUI and flutter.
    - zogrodea 3y ago
      Flutter has had its performance issues in the past (like scrolling on iOS, and shader performance issues), and I recall someone saying that Flutter apps lag on an Android phone that is still able to play the latest games decently. However, things are looking up with the change from Skia to Impeller and I'm hopeful about the future.
      - refulgentis 3y ago
        Way, way, way overrated, the "write a brand new rendering engine to eliminate all runtime shader creation" leaves me much more confident speaking strongly in public. Flutter in 2020 could render a complicated UI (new Google Assistant UI with glowing effect) on a 2015 $200 Android, and there was simply no way to do the same in Android proper. (Source: built Android version at Google and built Flutter version after for no particular reason, side project to teach myself Flutter) People tend to remember Flutter anecdotes that correlate well with previous xplatform framework fundamental issues, but in Flutter's case, they're not fundamental, they're more "holding it wrong" / "could use better docs" That being said it's probably a year or two away from me being brave enough to post that on an HN article (safe here, because articles old, weekend, and not directly related to Flutter).
        zogrodea 3y ago
        Nice to see we're mostly in agreement, since (as I said in my previous comment) I'm hopeful for Flutter's future. The team writing their own rendering engine is unexpected and I hope to see the same engine used in other projects too. Rive renderer is very impressive too. https://twitter.com/gordonphayes/status/1654107954268782595 https://twitter.com/gordonphayes/status/1654107954268782595
- deleted 3y ago
  [deleted]
alin23 3y ago
Author here! To this day, the app still struggles with sales because of the lag. Many smart devs tried to help me, and I added some of their recommendations: - caching views to a bitmap using Metal - trying smaller windows so that less pixels have to be redrawn Unfortunately nothing made a noticeable difference, this will have to wait until I get a really boring weekend.
- emllnd 3y ago
  Could you add the date of publication to the top of the page on each blog post? (Or year+month.) Looks like they’re there in the blog list, but not on the individual posts? Would help understand the context on posts that describe tech that has evolved rapidly and probably still will
  - alin23 3y ago
    Does it not appear on the top right for you? https://shots.panaitiu.com/8BvwKN7N https://shots.panaitiu.com/8BvwKN7N
    - serhack_ 3y ago
      Very hard to read it, please change the color. Thanks, my eyes
      - deleted 3y ago
        [deleted]
      - alin23 3y ago
        ..I prefer to keep it dimmed, in my eyes it does not have the same importance (and brightness) as the article itself.
    - lylejantzi3rd 3y ago
      It completely disappears on a mobile browser. https://imgur.com/GgDdUWM https://imgur.com/GgDdUWM
premysl 3y ago
> These damn animations man... they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere. The constant animations are what makes me dread and despise working with Apple software. Each time something moves for no good reason whatsoever, I die inside a little. Every few seconds. > [...] the same animation was driving me nuts because I was switching spaces so often, that the animation was slowing me down Exactly. Props to the author for making them possible to turn off. The operating system at large still has _tons_ of them that you can't get rid of, but it's the thought that counts. > Reacting to keyboard events is still something I do outside of SwiftUI SwiftUI is a nice idea in principle, what with being reactive, but I found that I cannot achieve anything worthwhile without piercing down into the lower layer of AppKit. And then I asked myself why do this clownery in the first place. Ultimately, trying to learn Apple frameworks has made me love GTK+, because it's so beautiful and elegant in comparison (disregarding that it's currently deeply broken on macOS).
- JimDabell 3y ago
  > The operating system at large still has _tons_ of them that you can't get rid of Have you tried System Settings > Accessibility > Display > Reduce motion?
  - premysl 3y ago
    Of course. It has almost no effect at all, as far as I can say. These are also important: defaults write com.apple.dock autohide-time-modifier -float 0.1 defaults write -g NSUseAnimatedFocusRing -bool NO defaults write com.apple.dock springboard-show-duration -float 0 defaults write com.apple.dock springboard-hide-duration -float 0 defaults write com.apple.dock springboard-page-duration -float 0.1
  - snazz 3y ago
    Then it takes just as much time, but instead of movement you get smooth fading between views :)
- modeless 3y ago
  This is one thing I like about Android. In developer settings you can make every UI animation twice as fast or even turn them off entirely. It's the first thing I do on every device I use.
lapcat 3y ago
(2022) https://news.ycombinator.com/item?id=33772876 https://news.ycombinator.com/item?id=33772876 (189 comments)
andrewmcwatters 3y ago
There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. iOS has felt so stupidly slow since then, because you're waiting for all of these dumb screens to swipe and pan and you can sit there and tap a button in the middle of all of this like 3-5 or more times and the damn phone does nothing until everything is all settled and complete, and only then will it listen to your tap event. Who are these utter grandpas who make these stupid UI decisions?
- jwells89 3y ago
  > There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. Is this specific to certain types of scroll views? I just played around in my Mail app inbox (most likely built with UICollectionView) initiating flick-scrolls and then double-tapping to stop the scroll and select the message under the tap and it works exactly like the original behavior you describe with zero delay.
eximius 3y ago
I am very hopeful that Xilem will prove an interesting local optimum that combines the necessary optimization and DevEx and UX. My only complaint is it's being developed so slow! Which isn't a fair complaint, really, I just want it!
- DrDroop 3y ago
  I find Xilem and the other work that Linus is doing very interesting, but at this point I've lost hope. The momentum just isn't there, maybe the overlords of Google can be convinced to put more resources behind it because if I extrapolate where this is going from where they are at now it is not going anywhere.
stephc_int13 3y ago
Gamedev here, I've worked on UI code more than once, using both commercial engine and in-house. I consider it basically impossible to take more than 1ms on the CPU to update+render an UI screen, even the most complex one. As long as rendering is done on the GPU it should not be more than 2ms even on full-screen 4K. The architecture of SwiftUI must be really weird to be slow/janky on a M1.
- h0l0cube 3y ago
  I’m an ex gamedev with the misfortune of having to work with a legacy SwiftUI project. SwiftUI, and Jetpack Compose on Android, are basically react-style functional dom-diffing style renderers and have all the problems that come from that. What’s worse is that often the project has to be recompiled in order to preview changes with this functions-as-UI-components philosophy
  - Gibbon1 3y ago
    The dom-diffing style makes me think of one of my beliefs about software. You have two styles. An active style where where when state is updated side effects happen directly inside the same call graph. And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future. The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.
    - stephc_int13 3y ago
      Magic is always bad in the software world.
      - deleted 3y ago
        [deleted]
    - varjag 3y ago
      The words you're looking for are procedural and declarative.
n8cpdx 3y ago
SwiftUI apps get basic things about the experience wrong. Things like margins around window borders and interaction with system UI. SwiftUI apps stick out like a sore thumb, just as bad as Electron if not worse. The worst offenders on my phone are SwiftUI. And it is horrible on Mac - see System Settings, which has somehow managed to turn their lead over Windows into being worse than the Windows 10 era settings app. SwiftUI apps are. not. native. Full stop. Apple needs to try harder if they want to maintain their reputation for high-quality, high-polish, premium software experiences.
- jarjoura 3y ago
  SwiftUI is a black box, yes, but under the hood, it's just wrapping all of the same AppKit/UIKit controls. It likely started as an answer to React for iOS and then late became a cross-platform toolkit. The API to get what you want and expect is terribly documented and poorly named. Countless times I stumble across the "right way" to do something, and it works well. You just won't find it on StackOverflow (or ChatGPT) nor in any tutorial site. It will be buried in a small section of sample code from Apple or listed on a slide in a WWDC video. My biggest complaint is that it tries to be too magical. Sometimes certain values are ignored and no amount of working around it will force it. Some internal decision for optimization didn't consider a specific use-case and there's no way to know. All I get is, configured one way, everything works, but change it, and suddenly it's ignored. It took UIKit a decade to ease up on magical behavior, but SwiftUI didn't seem to learn that lesson and so it's back to square one.
  - pohl 3y ago
    I thought it started for the watch, and was then brought to iOS and then macOS.
- deleted 3y ago
  [deleted]
tayistay 3y ago
The article matches my experience with SwiftUI [1][2]. For example, AFAICT, it's not really possible to write a usable node-graph editor using SwiftUI due to layout and dependency analysis overhead. You have to put the entire node graph inside a Canvas and do your own event handling, which is what we did in [3]. UIKit and AppKit aren't slow though, and Apple has every incentive to make this faster (they wrote SwiftUI's dependency graph in C++ after all, so they do seem to care), which makes me think there is just inherent slowness from the dependency analysis that is required for these sorts of systems (that seems to be what I see on the profiles). [1] https://audulus.com https://audulus.com [2] https://sculptura.app https://sculptura.app [3] https://github.com/audiokit/flow https://github.com/audiokit/flow
saagarjha 3y ago
If there’s one thing I could ask for when it comes to SwiftUI it would be for them to stop stripping symbols for the framework. It’s a complete black box in the profiler unless you put an unreasonable amount of effort into reverse engineering it.
obrhoff 3y ago
It’s important to mention that SwiftUI is for some reason in a terrible state under macOS. You notice that mostly when you try cross platform apps such as IceCubes. iOS version works great but the Mac version has a terrible performance.

64 points by goranmoomin 3y ago

It’s kinda like React in that way. And it’s similar in that newer devices run it well enough that devs might think they don’t have performance issues at all, but when using an older iPhone you can start to see it stutter.

Alifatisk 3y ago

The way SwiftUI is structured reminds me a lot of Flutter, it has its perks but can be quite deep when nesting widgets.

Alifatisk 3y ago
Any reason why I got downvoted? Was my comment bad?
- conradfr 3y ago
  HN loves Flutter;)
- refulgentis 3y ago
  No you're absolutely right. Came here to post ~the same thing. Mine was going to be a lot more aggressive in favor of Flutter, ex. SwiftUI doesn't have hot reload, looks like it _always_ needs to repaint on a state change (whereas Flutter has that widget | paint boundary that keeps things brutally efficient). Once you use InheritedWidgets / Provider / Riverpod you get provably minimal CPU usage, i.e. minimal rebuilds, the subwidgets never repaint unless you want them to. Top it off with pervasive StatelessWidgets and you have provably minimal RAM usage. I guess what I'd say is, it doesn't add much to the conversation: every view framework that needs to repaint a deep view tree entirely has issues, and in retrospect, there's deeper observations to make w/r/t SwiftUI and flutter.
  - zogrodea 3y ago
    Flutter has had its performance issues in the past (like scrolling on iOS, and shader performance issues), and I recall someone saying that Flutter apps lag on an Android phone that is still able to play the latest games decently. However, things are looking up with the change from Skia to Impeller and I'm hopeful about the future.
    - refulgentis 3y ago
      Way, way, way overrated, the "write a brand new rendering engine to eliminate all runtime shader creation" leaves me much more confident speaking strongly in public. Flutter in 2020 could render a complicated UI (new Google Assistant UI with glowing effect) on a 2015 $200 Android, and there was simply no way to do the same in Android proper. (Source: built Android version at Google and built Flutter version after for no particular reason, side project to teach myself Flutter) People tend to remember Flutter anecdotes that correlate well with previous xplatform framework fundamental issues, but in Flutter's case, they're not fundamental, they're more "holding it wrong" / "could use better docs" That being said it's probably a year or two away from me being brave enough to post that on an HN article (safe here, because articles old, weekend, and not directly related to Flutter).
      - zogrodea 3y ago
        Nice to see we're mostly in agreement, since (as I said in my previous comment) I'm hopeful for Flutter's future. The team writing their own rendering engine is unexpected and I hope to see the same engine used in other projects too. Rive renderer is very impressive too. https://twitter.com/gordonphayes/status/1654107954268782595 https://twitter.com/gordonphayes/status/1654107954268782595
deleted 3y ago
[deleted]

alin23 3y ago

Author here! To this day, the app still struggles with sales because of the lag. Many smart devs tried to help me, and I added some of their recommendations: - caching views to a bitmap using Metal - trying smaller windows so that less pixels have to be redrawn Unfortunately nothing made a noticeable difference, this will have to wait until I get a really boring weekend.

emllnd 3y ago
Could you add the date of publication to the top of the page on each blog post? (Or year+month.) Looks like they’re there in the blog list, but not on the individual posts? Would help understand the context on posts that describe tech that has evolved rapidly and probably still will
- alin23 3y ago
  Does it not appear on the top right for you? https://shots.panaitiu.com/8BvwKN7N https://shots.panaitiu.com/8BvwKN7N
  - serhack_ 3y ago
    Very hard to read it, please change the color. Thanks, my eyes
    - deleted 3y ago
      [deleted]
    - alin23 3y ago
      ..I prefer to keep it dimmed, in my eyes it does not have the same importance (and brightness) as the article itself.
  - lylejantzi3rd 3y ago
    It completely disappears on a mobile browser. https://imgur.com/GgDdUWM https://imgur.com/GgDdUWM

premysl 3y ago

> These damn animations man... they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere. The constant animations are what makes me dread and despise working with Apple software. Each time something moves for no good reason whatsoever, I die inside a little. Every few seconds. > [...] the same animation was driving me nuts because I was switching spaces so often, that the animation was slowing me down Exactly. Props to the author for making them possible to turn off. The operating system at large still has _tons_ of them that you can't get rid of, but it's the thought that counts. > Reacting to keyboard events is still something I do outside of SwiftUI SwiftUI is a nice idea in principle, what with being reactive, but I found that I cannot achieve anything worthwhile without piercing down into the lower layer of AppKit. And then I asked myself why do this clownery in the first place. Ultimately, trying to learn Apple frameworks has made me love GTK+, because it's so beautiful and elegant in comparison (disregarding that it's currently deeply broken on macOS).

JimDabell 3y ago
> The operating system at large still has _tons_ of them that you can't get rid of Have you tried System Settings > Accessibility > Display > Reduce motion?
- premysl 3y ago
  Of course. It has almost no effect at all, as far as I can say. These are also important: defaults write com.apple.dock autohide-time-modifier -float 0.1 defaults write -g NSUseAnimatedFocusRing -bool NO defaults write com.apple.dock springboard-show-duration -float 0 defaults write com.apple.dock springboard-hide-duration -float 0 defaults write com.apple.dock springboard-page-duration -float 0.1
- snazz 3y ago
  Then it takes just as much time, but instead of movement you get smooth fading between views :)
modeless 3y ago
This is one thing I like about Android. In developer settings you can make every UI animation twice as fast or even turn them off entirely. It's the first thing I do on every device I use.

lapcat 3y ago

(2022) https://news.ycombinator.com/item?id=33772876 https://news.ycombinator.com/item?id=33772876 (189 comments)

andrewmcwatters 3y ago

There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. iOS has felt so stupidly slow since then, because you're waiting for all of these dumb screens to swipe and pan and you can sit there and tap a button in the middle of all of this like 3-5 or more times and the damn phone does nothing until everything is all settled and complete, and only then will it listen to your tap event. Who are these utter grandpas who make these stupid UI decisions?

jwells89 3y ago
> There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. Is this specific to certain types of scroll views? I just played around in my Mail app inbox (most likely built with UICollectionView) initiating flick-scrolls and then double-tapping to stop the scroll and select the message under the tap and it works exactly like the original behavior you describe with zero delay.

eximius 3y ago

I am very hopeful that Xilem will prove an interesting local optimum that combines the necessary optimization and DevEx and UX. My only complaint is it's being developed so slow! Which isn't a fair complaint, really, I just want it!

DrDroop 3y ago
I find Xilem and the other work that Linus is doing very interesting, but at this point I've lost hope. The momentum just isn't there, maybe the overlords of Google can be convinced to put more resources behind it because if I extrapolate where this is going from where they are at now it is not going anywhere.

stephc_int13 3y ago

Gamedev here, I've worked on UI code more than once, using both commercial engine and in-house. I consider it basically impossible to take more than 1ms on the CPU to update+render an UI screen, even the most complex one. As long as rendering is done on the GPU it should not be more than 2ms even on full-screen 4K. The architecture of SwiftUI must be really weird to be slow/janky on a M1.

h0l0cube 3y ago
I’m an ex gamedev with the misfortune of having to work with a legacy SwiftUI project. SwiftUI, and Jetpack Compose on Android, are basically react-style functional dom-diffing style renderers and have all the problems that come from that. What’s worse is that often the project has to be recompiled in order to preview changes with this functions-as-UI-components philosophy
- Gibbon1 3y ago
  The dom-diffing style makes me think of one of my beliefs about software. You have two styles. An active style where where when state is updated side effects happen directly inside the same call graph. And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future. The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.
  - stephc_int13 3y ago
    Magic is always bad in the software world.
    - deleted 3y ago
      [deleted]
  - varjag 3y ago
    The words you're looking for are procedural and declarative.

n8cpdx 3y ago

SwiftUI apps get basic things about the experience wrong. Things like margins around window borders and interaction with system UI. SwiftUI apps stick out like a sore thumb, just as bad as Electron if not worse. The worst offenders on my phone are SwiftUI. And it is horrible on Mac - see System Settings, which has somehow managed to turn their lead over Windows into being worse than the Windows 10 era settings app. SwiftUI apps are. not. native. Full stop. Apple needs to try harder if they want to maintain their reputation for high-quality, high-polish, premium software experiences.

jarjoura 3y ago
SwiftUI is a black box, yes, but under the hood, it's just wrapping all of the same AppKit/UIKit controls. It likely started as an answer to React for iOS and then late became a cross-platform toolkit. The API to get what you want and expect is terribly documented and poorly named. Countless times I stumble across the "right way" to do something, and it works well. You just won't find it on StackOverflow (or ChatGPT) nor in any tutorial site. It will be buried in a small section of sample code from Apple or listed on a slide in a WWDC video. My biggest complaint is that it tries to be too magical. Sometimes certain values are ignored and no amount of working around it will force it. Some internal decision for optimization didn't consider a specific use-case and there's no way to know. All I get is, configured one way, everything works, but change it, and suddenly it's ignored. It took UIKit a decade to ease up on magical behavior, but SwiftUI didn't seem to learn that lesson and so it's back to square one.
- pohl 3y ago
  I thought it started for the watch, and was then brought to iOS and then macOS.
deleted 3y ago
[deleted]

tayistay 3y ago

The article matches my experience with SwiftUI [1][2]. For example, AFAICT, it's not really possible to write a usable node-graph editor using SwiftUI due to layout and dependency analysis overhead. You have to put the entire node graph inside a Canvas and do your own event handling, which is what we did in [3]. UIKit and AppKit aren't slow though, and Apple has every incentive to make this faster (they wrote SwiftUI's dependency graph in C++ after all, so they do seem to care), which makes me think there is just inherent slowness from the dependency analysis that is required for these sorts of systems (that seems to be what I see on the profiles). [1] https://audulus.com https://audulus.com [2] https://sculptura.app https://sculptura.app [3] https://github.com/audiokit/flow https://github.com/audiokit/flow

saagarjha 3y ago

If there’s one thing I could ask for when it comes to SwiftUI it would be for them to stop stripping symbols for the framework. It’s a complete black box in the profiler unless you put an unreasonable amount of effort into reverse engineering it.

obrhoff 3y ago

It’s important to mention that SwiftUI is for some reason in a terrible state under macOS. You notice that mostly when you try cross platform apps such as IceCubes. iOS version works great but the Mac version has a terrible performance.