Being able to share any parts of your business logic and UI that you want between iOS and Android versions is a huge win for companies of any size. Traditionally this has been a PITA, has added significant performance overhead and bloat (JS runtime, added garbage collector, etc depending on the framework), and on the UI side, has often given you non-native UIs. Skip solves all of these problems, and because it uses your code as-is on iOS and generates native code on Android, you can trivially and directly mix in platform-specific code wherever you need to, without any bridging.
Edit: I see you work for Skip, which I think you should state upfront. But I do understand your bias or blinders in assessing the tool.
I get the benefit of being able to share business logic. That's not the issue at stake here. If it was, this wouldn't be a company in the first place as there's multiple frameworks that enable this and do this better - at zero cost.
I don't believe performance issues is a relevant metric anymore, having dealt with them on RN, KMP, Flutter. Non-native UI, is also quite irrelevant these days. Perhaps if we were having this conversation 2-3 years ago I would agree with you. But with how RN/Flutter UI's are now, and the native aspect of KMP it's a non-issue.
> Skip solves all of these problems, and because it uses your code as-is on iOS and generates native code on Android, you can trivially and directly mix in platform-specific code wherever you need to, without any bridging.
I will believe it when I see it. You say "Skip solves all of these problems", when Kotlin multi-platform was essentially doing the same thing in reverse, but with far larger backing and it took years before it was production ready. It is not trivial to keep up with ever changing Android ecosystem, multiple API levels that need to be catered for, differing UX interactions, different native API's e.g databases, push notifications, permissions etc. Again you say trivial, not sure what is trivial about this.
I feel like you've either never tried cross platform work on a (large) production project? This is solving an aspect of mobile development that personally I don't see a need for. But if it's for you go for it, in my experience across languages and platforms, I would recommend against this option unless you solely only have iOS Engineers, no ability to cater for a native Android experience and hadn't thought of having an Android app before starting development. Then sure, use it. Any project I plan would be both platforms and wouldn't require this level of abstraction.
