That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.
Best is to have an IR.
Now maybe that IR can be turnt into native code. But we shouldn't be constrained.
As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated.
And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Just like any engineering and business decision, this is a tradeoff.
I probably don't see things from the same vantage point.
Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
It is virtual dom like.
We don't have access to a stable underlying element like we would with plain UIKit.
You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably.
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Yes, declarative UI is just an abstraction of imperative code. :)
The rest is properties of the internal implementation.
The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately.
It is so because the diffing and reconciliation algorithm have to be able to remove any subtree of views/nodes from the UI tree.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react.
Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model.
They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain.
Except playing chess has side effects. A mere snapshot does not encode those.
I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.
the tricky part about React Native is that you almost always need to use it with expo.
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
LOL, flutter/dart are pretty awesome and we have yet to encounter something that needed improvement.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?
That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Best is to have an IR. Now maybe that IR can be turnt into native code. But we shouldn't be constrained. As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated. And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
> That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.
Is that something we should be engineering for right now?
Just like any engineering and business decision, this is a tradeoff. I probably don't see things from the same vantage point. Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.
It is virtual dom like. We don't have access to a stable underlying element like we would with plain UIKit. You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably.
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Yes, declarative UI is just an abstraction of imperative code. :) The rest is properties of the internal implementation. The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately. It is so because the diffing and reconciliation algorithm have to be able to remove any subtree of views/nodes from the UI tree.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.
the tricky part about React Native is that you almost always need to use it with expo.
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
Yep. Flutter has been dead-end for a while. RN won't last through 2027.
LOL, flutter/dart are pretty awesome and we have yet to encounter something that needed improvement.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?