I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.
I heard this repeated many times. You can create closed-source Qt apps without paying any money. You cannot statically link, though; you must obey the LGPL license; that is all.
And yes, you cannot use commercial modules, but that is kinda expected.
Yes, Qt is mature and high-quality software. If you’re doing OSS, then Qt is truly a no brainer. The amount of C++ you have to write is truly minimal, and it’s not “raw” C++. There’s a lot of tooling and libraries. You can target web now too, and QML is legitimately good.
If KDE can develop a high performance stable desktop, you can design whatever.
I have been involved in two non-trivial Qt mobile apps. Never again.
I don't know what your experience is, and I mean no offence or anything, but the only people I have seen who were happy with Qt for mobile development were people who had never tried to do it with a modern language, like Kotlin.
With Compose Multiplatform and Kotlin Multiplatform, you can write a cross-platform app in a modern language, and that is far better than C++.
SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery.
Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.
I’ve worked on some award winning apps in the past, our experience with SwiftUI is it makes it really easy to develop a basic average looking app. As soon as you need something non-standard, you have to drop down to UIKit and figure out how to play nice between the two, which is often non trivial and hard to estimate. You file radars, which at best will be fixed in the next OS release and rarely back ported if at all.
In the end some of the more complicated apps just ditched SwiftUI altogether or applied a myriad of workarounds.
What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework. For instance, I can write a KMP library and a "pure" Android or iOS app can pretend it is a "pure" Android/iOS library.
That is, pure native apps, can integrate KMP libraries. They cannot integrate Flutter libraries.
In other words, if I write a KMP library, I can ship it for multiple platforms and developers can use it in their Flutter project, or in their pure Android/Kotlin project, or in their pure iOS project.
It's never "just working", you'll still have to debug the vibe-ported apps. And you won't be good at it if your devs don't actually know the target platform.
All that to say, I don't think that vibe-porting will give you more than cross-platform. With cross-platform, at least your engineers understand the codebase.
Same here, but Liquid Glass has been a headache lately. Google really dropped the ball here, but to their credit it almost feels like Liquid Glass was an intentional move by Apple to cause as much friction for cross platform frameworks as possible.
Define right, it’s hard to replicate the native UI especially Liquid Glass on iOS because it’s rendering everything using its own rendering engine, making it hard to feel right on iOS. I have also seen a lot of companies move away from flutter to either native or React Native.
Well we all love Liquid Glass. Most loved UX update in iPhone and macOS history. Massive dealbreaker for an app not to look like Liquid Glass. I definitely choose apps based on whether they look like proper Liquid Glass applications instead of the developer taking shortcuts and focusing on working features instead.
Well I’m a heavy Flutter user myself, and the app I built Hacki often gets reviews saying it doesn’t feel native on iOS. I personally don’t have anything against it and I think Flutter has the BEST developer experience compared to other mobile app dev toolkit/SDKs.
I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.
It's licensing is expensive though unless the app is opensource.
I heard this repeated many times. You can create closed-source Qt apps without paying any money. You cannot statically link, though; you must obey the LGPL license; that is all. And yes, you cannot use commercial modules, but that is kinda expected.
Yes, Qt is mature and high-quality software. If you’re doing OSS, then Qt is truly a no brainer. The amount of C++ you have to write is truly minimal, and it’s not “raw” C++. There’s a lot of tooling and libraries. You can target web now too, and QML is legitimately good.
If KDE can develop a high performance stable desktop, you can design whatever.
I have been involved in two non-trivial Qt mobile apps. Never again.
I don't know what your experience is, and I mean no offence or anything, but the only people I have seen who were happy with Qt for mobile development were people who had never tried to do it with a modern language, like Kotlin.
With Compose Multiplatform and Kotlin Multiplatform, you can write a cross-platform app in a modern language, and that is far better than C++.
There is no right way :)
SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery.
Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.
I’ve worked on some award winning apps in the past, our experience with SwiftUI is it makes it really easy to develop a basic average looking app. As soon as you need something non-standard, you have to drop down to UIKit and figure out how to play nice between the two, which is often non trivial and hard to estimate. You file radars, which at best will be fixed in the next OS release and rarely back ported if at all. In the end some of the more complicated apps just ditched SwiftUI altogether or applied a myriad of workarounds.
What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework. For instance, I can write a KMP library and a "pure" Android or iOS app can pretend it is a "pure" Android/iOS library.
That is, pure native apps, can integrate KMP libraries. They cannot integrate Flutter libraries.
In other words, if I write a KMP library, I can ship it for multiple platforms and developers can use it in their Flutter project, or in their pure Android/Kotlin project, or in their pure iOS project.
I wonder what experts think of this other option: going fully native for one platform then vibe-porting it to others.
It's never "just working", you'll still have to debug the vibe-ported apps. And you won't be good at it if your devs don't actually know the target platform.
All that to say, I don't think that vibe-porting will give you more than cross-platform. With cross-platform, at least your engineers understand the codebase.
Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.
Neither.
I developed a complicated app in Flutter and it’s one of the best engineering decisions I made. Flutter is great.
Flutter has been a great success for us.
Same here, but Liquid Glass has been a headache lately. Google really dropped the ball here, but to their credit it almost feels like Liquid Glass was an intentional move by Apple to cause as much friction for cross platform frameworks as possible.
Define right, it’s hard to replicate the native UI especially Liquid Glass on iOS because it’s rendering everything using its own rendering engine, making it hard to feel right on iOS. I have also seen a lot of companies move away from flutter to either native or React Native.
Well we all love Liquid Glass. Most loved UX update in iPhone and macOS history. Massive dealbreaker for an app not to look like Liquid Glass. I definitely choose apps based on whether they look like proper Liquid Glass applications instead of the developer taking shortcuts and focusing on working features instead.
You jest but yes, even as I do not love this new update, an application bucking Apple platform standards personally sours me pretty hard on it.
Well I’m a heavy Flutter user myself, and the app I built Hacki often gets reviews saying it doesn’t feel native on iOS. I personally don’t have anything against it and I think Flutter has the BEST developer experience compared to other mobile app dev toolkit/SDKs.
I despise Liquid Glass too but for most users there’s a broad feeling of “it fits” vs doesn’t. And apps with Liquid Glass fit today’s iOS.