SwiftUI isn’t native and here’s why SwiftUI apps may sometimes feel janky. It ditches the key element that made animations run so smoothly on iOS since the original iPhone: Core Animation. In SwiftUI animations run in-app without CA backing. Block the main thread: SwiftUI ball stalls while UIKit’s keeps moving on the render server.

Sep 15, 2026 · 10:15 PM UTC

54
78
39
1,093
611,267
RelevantRecentLikes
On the other hand, in React Native you absolutely can rely on the marvel of Core Animation-backed animations nitter.cf/O_Pawica/status/209949…
Oskar Pawica@O_Pawica
Sep 14
Is this Native or React Native? Both. Core Animation is coming to layout animations in React Native Reanimated. Stay tuned!
4
1
111
28,953
It’s easier to develop a high-performance native app in React Native. SwiftUI has limited functionality, poor layout and animation performance, and DX is mid at best. It’s been discouraging to see it barely improve since released 7 years ago!
5
8
1
131
21,483
💯 also main reason I’ve never been a fan of building react native wrappers of SwiftUI components. Take navigation as an example: react-native-screens is UIKit only
1
43
11,463
In the vast majority of SwiftUI that I’ve written, this has rarely ever been an issue. I would rather keep the ergonomics of SwiftUI and than decide I need yet another abstraction layer for the rare instances when a user may see an animation hitch. Or wrap it in a representable.
1
41
7,775
Does your agent care about the code ergonomics this much too?
1
25
6,913
You might be animating incorrectly in SwiftUI... nitter.cf/cifilter/status/210024…
Shannon Potter
@cifilter
Sep 16
Lot of speculation and misinformation floating around about SwiftUI today! I've done some reverse engineering of all relevant frameworks (including private frameworks), and I've made some interesting discoveries about SwiftUI that disprove a lot of the noise. More soon.
1
11
1,901
It’s noting fancy, just a withAnimation call with repeat. Blocking is done with sleep. Happy to get corrected, but it’s confirmed as expected behavior (perhaps your block handler doesn’t run on the ui thread?)
2
7
994
View more replies
I’d love to see the source code for this, because I have a feeling you are using a SwiftUI anti-pattern for updating state rather than SwiftUI being bad.
1
2
784
Open to feedback nitter.cf/kzzzf/status/210025847…
Krzysztof Magiera
@kzzzf
Sep 16
Replying to @kzzzf @cifilter
Stripped down the code to minimum if you’d like to take a look (it uses scale here to save a few lines of code but the effect is the same) gist.github.com/kmagiera/349…

SwiftUI vs UIKit: scale animations during a main-thread block

SwiftUI vs UIKit: scale animations during a main-thread block - SwiftUIVsUIKitAnimations.swift

gist.github.com
1,140
Yikes. Can’t believe they made such a major oversight like that
1
2,393
Not an oversight. It is a trade off for the shape of the animation API that SwiftUI provides (stuff like withAnimation). It simply requires more flexibility from what CA can offer and thus cannot use CA
1
6
2,140
Wrap a UIView (or custom CALayer) in UIViewRepresentable and bam!
1
1
2,105
yes, but you can also do this in react native or flutter
1
1,604
People forget that some of the best “native” engineers are working on react native
1
21
6,784
Yes! Licky to know some of them
2
8
6,360
Can just drop down to UIKit and CA whenever you need to
1
1
1,928
So can you in flutter 🤷
1
1,385
if this is really it, it's an absolute disgrace
1
3
4,711
It really it’s. But it is nothing else than a trade off for the nice and generic animation api that SwiftUI provides. Core Animation requires you to understand the entire transition before ahead which just isn’t compatible with this API model
1
4,022
block main thread and the ball freezes. that demo is brutal but clear
403
React Native is native to the same extent as Golang is native.
128
That makes sense, that's why SwiftUI animations stutter sometimes when main thread is busy.
484
You must be joking. Any view-state-driven framework would stall if you block the main thread. What is your point here? What do you gain by blocking the main thread?
2
216
serious question: why the fuck did they do this? couldn’t they just… not?
1
4
1,556
nitter.cf/kylemacomber/status/21…
Kyle Macomber
@kylemacomber
Sep 16
Fun fact: the creator of CoreAnimation is one of the creators of SwiftUI! The decision to run animations in the app process rather than the render server (as CoreAnimation does) was one of the earliest and most fundamental decisions we made when designing SwiftUI. Some of the most distinctive experiences of using an iPhone, like UIScrollView rubber banding and SpringBoard app switching are only possible as client-side animations. But these experiences aren’t easy to build with UIKit! This is because if you want a UI to be fully interactive and interruptible by the user while it’s animating, it has to be running in the same process as the event handling. In fact, in iOS 18 we added new APIs to AppKit and UIKit to adopt the SwiftUI client-side animation model. There are a lot of valid critiques of SwiftUI. The fact that SwiftUI doesn’t use CoreAnimation for its animations is not one of them.
58
4,879
Who the hell would use react native in the world where AI writes code? The best result could be achieved with UKit only and that is what should be used.
414
Michael Waitze
@MichaelWaitze
Sep 16
The technical distinction between in-app animations and the render server is a huge part of this debate. We actually went deeper on this here: nitter.cf/AGTPinsights/status/21…
AGTP
@AGTPinsights
Sep 16
SwiftUI just got called out today for how it handles animations. Here's what you need to know. Developer Krzysztof Magiera posted a demo showing that SwiftUI isn't fully native, because it ditches Core Animation, the system that's kept iOS animations smooth since the original iPhone. In SwiftUI, animations run inside the app process itself, without Core Animation backing them. That means if you block the main thread, a SwiftUI animation stalls, while a UIKit animation, which runs on a separate render server, keeps moving. Kyle Macomber, who helped design SwiftUI and also helped create Core Animation, confirmed it was a deliberate choice, made early on, to run animations in-app rather than on the render server. Jacob Xiao, another SwiftUI co-creator who spent 3 years on UIKit first, said solving this exact problem was his top goal. The post sparked a big native vs cross-platform debate, with some devs noting React Native's Reanimated library already leans on Core Animation-backed animations, and that react-native-screens still relies on UIKit under the hood. Key numbers: - Original post by @kzzzf: 40.2K views, posted 5:15 AM Sep 16, 2026 - SwiftUI has been out for 7 years - Macomber's reply thread: 3.9K views Apple hasn't issued an official response as of this writing.
1
825
That’s why we shouldn’t block the main thread 🌞
1
682
Matej Knopp@MatejKnopp
Sep 16
Yeah, no, this is kinda bullshit. Everything that needs event input or layout changes (including scrolling) has always run on main thread and is subject of main thread stalls. The example works for very simple canned animations that have been mostly irrelevant since iOS 7.
1
35
3,332
Isn’t this behavior because non ui stuff is being done on the main thread?
74
you can write swiftui without blocking the main thread, the animation architecture decision was to move things to the current process rather across to different process not the main thread in one process
40
Just like jetpack compose isn't Native
752
I thought native dev means you are making the react native / SwiftUI it self. Or you are making software on that level If you only use react native / SwiftUI, you are not native
1
1,863
big brain man, why are you blocking the main thread?
36
Load more replies