Nothing non-standard about it, and you can certainly convert existing code. But if you want to convert an app - as opposed to a framework - you should start with our template and move your code over. The Xcode app project file format is opaque, making it very hard to migrate, and we rely on it being set up in a certain way to be able to build for Android
Most Android apps also now include an on-screen back arrow similar to iOS's standard. Designs have converged a lot... probably due to big companies wanting to unify the designs of their iOS and Android apps as much as possible for simplicity.
the code I got is pretty maintainable and it’s all standard kotlin & jetpack compose. Even the ui tests converted nicely. The big effort was the initial conversion of the app to Android, for maintenance I won’t necessarily use LLMs
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.
You don’t manually edit the generated Kotlin. You change the Swift. And if there are things you can't or don't want to do in Swift, there are mechanisms for writing Kotlin inline in your Swift, dropping Kotlin files into the project, and other platform customization options: https://skip.tools/docs/platformcustomization/
> given the point of this is not having to learn android
We wouldn't say that is the point of using Skip. The benefit you get from using Skip is that you can use a single language and a single framework for building your app, and you can iterate on your app's development without needing to constantly context-swift between different worlds.
But there is no denying that at some point, you will need to interact with the Android universe: you will need to run the app on an Android emulator or device to test it, you will need to use Android Studio (or IntelliJ) to run the app in a debugger, you will need to grapple with the Android-specific nuances of deploying you app to the Play Store.
- The LGPL license for Skip's libraries is the same license used in projects like WebKit. It does not interfere with using Skip in commercial, closed-source apps.
- Skip is based on Swift Package Manager and fully both dual-platform and iOS and Android-specific dependencies.
- Skip has a suite of dual-platform libraries, and for anything that isn't covered, multiple techniques for integrating platform-specific code and libraries. These include being able to use Kotlin right inline with your Swift and mix Compose code in with your SwiftUI.
Skip isn't a minimum denominator framework. With Skip, you write normal iOS code. So you legitimately make zero sacrifices to your iOS app.
Now of course Skip can't have complete Android coverage for every iOS framework - far from it. So if you use something on the iOS side that has no Android coverage, you have to create a separate code path for Android, where typically you'll utilize an equivalent Android framework/function. Skip has several mechanisms for integrating Android code, including being able to call Kotlin and Java API directly from your Swift. These mechanisms are also how you can differentiate parts of your Android app as desired, and how we create our own cross-platform libraries.
