I am starting to learn SwiftUI and it’s so much the same as JetpackCompose, much more than I expected! Just the syntax is different.
At the same time, I also understand why JetpackCompose is not going to follow the same mobile cross-platform road of Flutter, by writing directly into the iOS canvas.
I can see how SwiftUI is awesomely tight to the iOS framework, and how a “foreign” UI could never match that. I am very impressed by how the exact same SwiftUI control renders differently on iPhone, iPad, Mac or iWatch, and that is all managed by the OS framework.
Given how similar the code structure between JetpackCompose and SwiftUI is, I believe transpiling from JetpackCompose to SwiftUI makes much more sense than JetpackCompose writing into iOS canvas. And I believe JetBrains is very much aware of that. Given their experience in this kind of stuff, they could probably create a JetpackCompose->SwiftUI transpiling tool that achieves perfection.
For the same reason, I am really starting to understand the limitations of Flutter. It’s quite clear now that Flutter is just a toy project, which cannot stand the competition of native UIs.
In the future much more than now, the quality of apps will depend on their native UI look and feel. Apps not implementing the native UI will be perceived of lower quality.
I am pretty sure native UI in mobile is going increase its “market share” thanks to these new declarative UIs. In 2 years time we’ll see many more native UI apps than we see now. ReactNative, Xamarin or even Flutter will stand no chance.
@Ash great! I wish I could see your live talk, but here in Europe it would be in the middle of the night, so I will not be able. Hopefully it will be recorded, and I can watch it later. Great stuff! Keep on!
09/12/2020, 3:12 PM
If it is a good talk, will post the link to the talk here ... if not I will bury it 😂
09/12/2020, 7:08 PM
As someone who has never looked at SwiftUI, could you help me understand why it's not best for Compose not to write to iOS canvas? I think that Compose could be pretty good for Multi-platform (not cross-platform) by re-using widgets, maybe with some changes to make variations / "themes" easier
09/12/2020, 8:57 PM
I use the language of the platform. So Kotlin (Android), Swift (iOS), Python (ML) and JS (Web). I might do Swift on TensorFlow just because the Google Brain Team is pushing it.
They each have strengths the platform uses. Swift is perfect for Protocol Oriented Programming because structs are value types. Both Java and Kotlin plan to add this but have not.
With SwiftUI you get all "i" platforms pixel perfect. SwiftUI came from the iWatch team. Everything about SwiftUI feels right on iOS like the just added SwiftUI Maps ...
When I talk to Android /iOS devs they both want to talk their native language ...
Compose on iOS might be a good idea but I need LiDAR (https://developer.apple.com/augmented-reality/arkit/) on iOS and Radar https://atap.google.com/soli/ on Android ASAP so it just makes sense to work on the language of the
Too many friends started too many projects cross platform just to have to return to native at some point ... and also bond to how good the multi-platform is ??? lessons learned and years lost ... a word of warning!