On the Swift/iOS side, it simply uses Swift's excellent C integration; on the Java/Android side, it uses the venerable JNA library to handle loading and calling into embedded native libraries.
You are correct that JNA's C++ integration – while possible – is not exactly seamless. It is an area that we are actively researching better solutions for.
We do have a showcase app, literally called "Showcase": https://skip.tools/docs/samples/skipapp-showcase/. It is available on both the Apple App Store and Google Play Store, so you can compare the two experiences side-by-side, if you have both an iOS and Android device.
tbh this is the main thing I was looking for on the webpage. It's hard for me to jump ship from my existing workflows unless I see a professional and highly sophisticated app example. I am sure it works for simple cases but I am concerned about limitations that one hits as one does more complex things
Out of curiosity, what are your existing workflows?
Note that Skip doesn't put any constraints on the iOS side of your app at all: if it can be expressed with SwiftUI or UIKit, then you can do anything. If there are bits that SkipUI doesn't translate to your liking (or at all), you can always drop down directly into Kotlin and Jetpack Compose to implement those any way you want. See https://skip.tools/docs/platformcustomization/ for details.
To answer the other part of your question: you don’t manually edit the generated Kotlin. Instead 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/
The Skip transpiler runs locally on every build. It is implemented as an Xcode build plugin, so it is transparent and instantaneous. Every change you make to the Swift code is immediately converted into Kotlin, so each time you launch the app in the iPhone Simulator, the Android app will launch next to it in the Android Emulator. For a good overview of this process, take a look at: https://skip.tools/tour/skip-showreel/
Since both SwiftUI and Jetpack Compose are declarative and semantic user-interface frameworks, components are generally presented in what the system believes to be the "correct" layout. So if you have a `SwiftUI.VStack` (which translates to a Compose `Column`) of buttons and text fields, then they will generally be presented with the "correct" spacing and alignment for the platform.
That being said, there is often plenty of need for customization with any but the most trivial app. So Skip has a lot of options for that, which is covered in the Platform Customization guide at https://skip.tools/docs/platformcustomization/.
Thanks for the positive words! Any limitations in the transpiler (such as some advanced generics) will only be limitations on the Android side – the iOS side can still do anything that is support in Swift. We discuss this a bit at https://skip.tools/docs/platformcustomization/
> Also, using SwiftUI cross-platform makes me think that many android libraries would be a no-go.
A unique feature of Skip is that the Kotlin/Android side is free to integrate with whatever gradle libraries it wants (see https://skip.tools/docs/dependencies/). Similarly, the Swift side can have any SwiftPM dependencies it wants.
Only your own transpiled modules, and the core Skip modules, will need to support transpilation. You can then include any native dependencies via your app's transpiled code that branches based on which platform/language you are targeting. So, for example, the Swift/SwiftUI side of the project can depend on the SwiftPM "https://github.com/firebase/firebase-ios-sdk.git" dependency, and the Kotlin/Compose side can depend on the Gradle "com.google.firebase:firebase-bom" dependency. This is what we ourselves do in the various integration modules we have (such as SkipFirebase, for this particular example).
Hello Hacker News. I'm Marc, one half of the team that created skip.tools. Skip is a tool that transpiles your SwiftUI iOS app into a Kotlin Jetpack Compose app, and enables you to use a single language to create a complete app that reaches the entire mobile marketplace.
What it is: Skip stands in contrast to other cross-platform development tools like Flutter, React Native, and Xamarin, in that it enables the creation of genuinely native applications for both of the dominant mobile platforms. It doesn't embed a separate engine or runtime into your app, but instead lets you use pure Swift and SwiftUI to create the iOS side of the app (as per Apple's recommended best practices for creating iOS apps), and transpiles it into a pure Kotlin and Jetpack Compose app for the Android side (which is Google's recommendation for building Android apps). So your application will use platform-native controls and will automatically have all the affordances provided by the platform vendor: animations, accessibility, and future-proof evolution alongside OS updates.
How it works: you build a Skip app using the same tools that you use to create a standard iOS app: Xcode, Swift, and SwiftUI. Skip augments this workflow with a Swift Package Manager plugin called "skipstone", which transpiles your Swift into Kotlin each time you build your app, and launches the Android app side-by-side with the iOS app each time you run the app. The transpilation works not just on your primary app module, but also transitively processes all your dependent SwiftPM modules, so you can break complex projects down into individually testable sub-modules containing business logic or UI code. In fact, this is how our own adaptor modules for the standard frameworks are structured: SkipFoundation adapts the Foundation framework and SkipUI adapts the SwiftUI framework, so the same familiar API can be used when building the app. And there's a GitHub ecosystem of open-source modules supporting popular frameworks, including SQLite, Firebase, Lottie, and many other common building blocks of modern apps.
Over the past year Skip has evolved into a fully-capable solution for creating best-in-class apps for both iOS and Android. And today we are delighted to announce the release of version 1.0, meaning that it is ready for production use.
We have a wealth of videos and documentation available at https://skip.tools, and I'll be around to field any questions that any of you might have. Thanks in advance for taking a look!
Take a look at skip.tools. It's pure SwiftUI on iOS and Jetpack Compose on Android, with the tool automatically handling the translation from Swift to Kotlin as part of the Xcode build process.
Will have to try it to see how well it works in practice, but very cool. I can see this being popular for side project apps written by iOS devs that otherwise wouldn’t have an Android port.
Yes, web views (backed by WKWebView on iOS and android.webkit.WebView on Android) are one of the Skip modules under active development: https://github.com/skiptools/skip-web
As an indie dev who quit my job to try to make it solo, I'll either need to wait until I have more revenue to afford this, or hopefully you add some indie-friendly tier for bootstrapped pricing (such as a discount on team size, or ARR like Apple does with its small business program).
I am building an open-source (AGPL) distribution network for native macOS apps at https://appfair.net, along with a catalog browser and installer application at https://appfair.app. It features homebrew casks integration for third-party apps along with security disclosure, an automated build system (using GitHub actions), and verifiably reproducible builds for appfair.net apps.
Creating and distributing apps using appfair.net is instantaneous and free. I'm looking for SwiftUI developers to try out the system to help build up the appfair.net catalog of applications beyond my own little collection of sample apps.
My advice from years of notarizing my apps is to make sure you do it at least once per day for each of your apps. If you only notarize once every release (say, every month or so), you are almost guaranteed to encounter some new cryptic error that you've never seen before, either due to some glitch in signing your app or frameworks, or else some server-side error such as new terms & conditions that you are being "encouraged" to agree to. It will take you hours to research and resolve them if they aren't spotted right away.
As others pointed out, https://github.com/mitchellh/gon is a great tool for doing this on your local machine (e.g., with a cron job). In addition, if you are building your app using a GitHub action (which I highly recommend if it is open-source), you can use my https://github.com/hubomatic/hubomat action to package, notarize, and staple a release build in one shot. The sample/template app does this automatically on every commit as well as once per day: https://github.com/hubomatic/MicroVector/actions.
So when this fails from a scheduled job, you at least know that something has changed on the Apple side and can investigate that right away. And if it fails as a result of a commit, then at least you can start looking at what changes you may have made to your entitlements or code signing settings or embedded frameworks or any of the other million things that can cause it to fail.
I auto notarize my app when I push to a release-candidate branch even if I don't deploy it. I also have a general code signing CI test that catches stuff before notarization would. I believe I've never, in thousands of pushes to this branch, hit a non-obvious notarization issue.
The main annoying thing so far for me using notarization long term is the terms and conditions signing step, which is silly because they're only updating the paid apps contract and we're notarizing explicitly so we can distribute outside the app store.
Smoke-testing your code signing is a good idea, and would probably catch most notarization issues. Aside from those, through, I've encountered numerous issues with embedded frameworks and app extensions whose error reporting wouldn't be described as obvious. Catching those right away rather than right before you are trying to deploy a release is critical.
I check that executables don't depend on libraries from outside the app, I check that I successfully shipped everything as universal2, and I check for stuff like .DS_Store and vim .swp files.
On the Swift/iOS side, it simply uses Swift's excellent C integration; on the Java/Android side, it uses the venerable JNA library to handle loading and calling into embedded native libraries.