>The fact that these vendor-supported toolkits – SwiftUI and Compose – are built atop the platform-native scrolling mechanics
I can't speak for iOS, but neither RecyclerView nor Compose's scrolling is built on top of the Android platform's scrolling - they both implemented new and different ways to do scrolling versus the ScrollView or ListView the platform shipped with. Both were built using the same public APIs any developer could use.
The reason they offer the performance they do is implementation choices by the developers who wrote them, around what work to perform when. Lots of Android developers implemented scrolling using the platform APIs and got jank, others implemented scrolling before RecyclerView was even available and had smooth performance. There is no magic performance guarantee because you transpile to kotlin.
The idea of single code base is false. It doesn't even save money nor time. You need more engineers to understand iOS, Android, and now insert single code base framework, not to mention more time solve framework specific issues. However, the buzzwords involved with such frameworks/tools are so attractive to non-technical management that they commit to it right from the start. Flutter doesn't even have a proper webview, and the amount of engineering time spent to build a flutter webview and maintain it blows my mind.
Skip does save a tremendous amount of time! It has a proper webview across both platforms.
There are two parts - that you can run SwiftUI on Android, and that you can run your Swift business logic & data on Android. You don't have to use the former to benefit from the latter per your concerns
In 2025 it's very common to have common cores and per-platform UI, such as with Rust (which popular apps like Brave and Anki do). This is one way to do so, plus optionally (not necessarily!) using SwiftUI on Android. I don't think you can go to the Brave or Anki open source projects and tell them they would save time by deconstructing their Rust cores into platform-specific redundancies without being laughed out of the room.
Common core single-codebase for business logic is different, that is actually useful. You can have a common core with native UI and native networking. However, it has its own pitfalls too. Some misguided people think that it's a good idea to write a Rust networking layer on iOS, which already has a mobile-optimized native network layer. Or write Android UI in Swift. Extremely costly on the long term because of all the problems involved with doing that. However, like I said, non-informed non-technical managers fall for what you did there, disguising common UI as common core, by using buzzwords and dropping names that you aren't even affiliated with
Sounds like you don’t know what you’re talking about except for old news and old experience (of things I’m also very familiar with) given specific errors in what you’ve said. I won’t elaborate for you given the dismissiveness. Bye
I can't speak for iOS, but neither RecyclerView nor Compose's scrolling is built on top of the Android platform's scrolling - they both implemented new and different ways to do scrolling versus the ScrollView or ListView the platform shipped with. Both were built using the same public APIs any developer could use.
The reason they offer the performance they do is implementation choices by the developers who wrote them, around what work to perform when. Lots of Android developers implemented scrolling using the platform APIs and got jank, others implemented scrolling before RecyclerView was even available and had smooth performance. There is no magic performance guarantee because you transpile to kotlin.
reply