from Hacker News

Show HN: Skip – Build native iOS and Android apps from a single Swift codebase

by marcprux on 8/28/24, 8:44 PM with 118 comments

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!

Home: https://skip.tools

FAQ: https://skip.tools/docs/faq/

GitHub: https://github.com/skiptools/

  • by LifeUtilityApps on 8/28/24, 10:54 PM

    Loving this so far, I've been working with it for a week now. I have a personal app, DownPay for iOS, that is built with SwiftUI that I want to bring to Android. I tried going the React Native route to build an android-only version but the context switching between SwiftUI, React Native, and then my day job made it challenging. I also tried Ionic and Ignite and wasn't successful with those either.

    After testing the feasibility of other cross-platform frameworks, I landed on Skip. I LOVE that I don't have to break out of the "Swift" mental context, I just have to focus on writing an app in 1 language.

    So before I commit fully I've been testing it out (building a demo app this week) and so far I am very impressed. The syntax to write platform-specific code (#if !SKIP #endif) is very easy to use once you get the hang of it.

    It's amazing I don't have to learn Android to get something up and running at this speed with Skip. Hitting run in xcode and watching both emulators open feels like magic. I want to put this to the test so I plan to build a complete App with it from start to finish, ship it to both App Stores, and if all that goes smoothly I will proceed to migrate my main app using Skip.

  • by mad_tortoise on 8/29/24, 8:07 AM

    I'm not sure I see the point, other than this being aimed at first world (see US/EU) businesses who solely have iOS application's and want to convert those to Android. So if you only have Swift developers and didn't have the forethought to want an Android version of the app going forward then this is a product for you. I would recommend, going pure native android or starting again with Flutter.

    Whereas the rest of the world is Android dominant, and there is no real reason to do this when there's multiple better frameworks for cross platform development. Flutter, React Native and Kotlin MP are and always will be miles ahead. Let alone those framework's being free whereas here there is a cost for professional development.

    As someone that has written various projects in Kotlin (including multiplatform), Swift, Dart/Flutter for over a decade I don't see the point. And I would be exactly the target market for this kind of product. The transpiling is the big issue for me, you will have to tap into every single Android API, write code to transpile those and then maintain across every Android version going forward.

    Let alone the denigrating of cross platform frameworks and promotion of yours due to "animations, accessibility, and future-proof evolution alongside OS updates" doesn't sound like much of a win, when the quality of these in cross platform is already at a very high level. Secondly "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." all of which exist in cross platform and kotlin multi platform.

    I'm sorry to the developers and team to knock it, but just my 2 cents coming from a more third world perspective.

  • by rock_artist on 8/29/24, 4:41 AM

    As others, from the videos, I really like the tight Xcode integration. Reading the FAQ I do have few concerns,

    1. Open-source, it mentions GPL forms, is there a reason MIT not mentioned? is that not considered open-source (especially with many iOS/Swift using MIT to be compliant with store distribution).

    2. Packages, how does it handled packages? or the cases when you need to have branching for iOS/Android? the FAQ does not address this.

    3. How Apple service APIs being handled on Android? I didn't look at the example weather app, but as an example, Apple got WeatherKit. or in my case case I use the built-in geolocation APIs.

    My concrete example, I have a small app I've made. It uses geolocation from Apple (to detect country city, etc), It uses AdMob and Apple's built-in In-App / Subscription services.

    I think this is a fair example of simple commercial product, and it'll be nice if you have some example for ads and in-app/subscription which might be important for closed/paid monetized projects...

  • by fifafu on 8/29/24, 5:54 AM

    I recently stumbled upon this (and it sounded great!), but was already too far in the development cycle of a medium sized Swift UI iOS app. Instead I used ChatGPT & Claude to convert the SwiftUI Code to Kotlin & Jetpack Compose & Material3. This worked crazy well. The generated code worked almost instantly and basically just needed small modifications for the styling /theming. I think the similarities in SwiftUI and Jetpack Compose make this a great match for LLMs

  • by amehregan on 8/28/24, 9:34 PM

    Can vouch- been using this tool the last couple months and it's been magic. It's new so there is definitely a learning curve, but once you get things working it solves the cross-platform problem completely.

  • by banashark on 8/15/24, 5:43 PM

    Looks very cool!

    Looking at the docs gives a good overview of how it works.

    Regarding transpilation and the tradeoffs (https://skip.tools/topic/transpilation-tradeoffs/), does the limitation of certain Swift features cause any significant friction with using parts of SwiftUI or other core libraries?

    Wondering how much those (understandable) limitations on the transpilation limit what a random iOS dev might be able to do compared to what they can do in iOS land.

    Also, using SwiftUI cross-platform makes me think that many android libraries would be a no-go.

    One of the reasons that Xamarin development was painful (other than the numerous bugs in trying to target 2 foreign platforms) was that you couldn't _really_ utilize the large native ecosystems of either platform, and you would end up spending a lot of time "rewriting" libraries in dotnet.

  • by wirelesspotat on 8/28/24, 10:50 PM

    Good to see Skip on the home page! We were evaluating Skip just a couple weeks ago for a side project.

    The issue we ran into is that we've already built a native iOS app with SwiftUI + a bit of UIKit. Integrating Skip with an existing app seemed like a significant task

    Does that hold true in your experiences? Do you have any examples of small- or medium-sized existing apps that have migrated to Skip?

  • by flawn on 8/28/24, 10:19 PM

    Damn, this sounds too good to be true. Really nothing to add here except than keep pushing!

    This fixes the big painpoint that nowadays' cross-platform frameworks come with performance tradeoffs as they have a unified presentation layer!

  • by happybuy on 8/29/24, 5:04 AM

    Most existing iOS apps are likely to use a suite of Apple platform frameworks beyond simply pure Swift and SwiftUI.

    For those cases, Skip's approach seems to be a range of Skip* frameworks that are minimal implementations of the Apple or Android versions. This will likely grow over time, but for most apps it would likely be very limiting at this stage.

    For instance in my iOS app I use StoreKit, WebKit, SafariServices, UserNotifications and CryptoKit amongst others that have no current implementation when using Skip.

  • by billylo on 8/29/24, 1:08 AM

  • by isodev on 8/29/24, 7:50 AM

    I can appreciate the effort of trying to make it easier for iOS developers to also target Android. However, there is no magic solution to cross-platform development. The effort required for the second platform doesn't disappear, it just moves.

    In the case of this tool, the complexity seems to move into a completely new layer of "re-implement Apple frameworks" of libraries + transpiled Swift code to Kotlin. Given that the audience for this framework is mainly iOS developers, support and maintenance for the Android side of things will become an increasing challenge.

    Perhaps it's easy to get started, but I can't possibly imagine this being easy to maintain several first party releases down't the road. Also, I did a quick look into the transpiled Kotlin code, the output is not at all optimal.

  • by nivertech on 8/29/24, 7:06 AM

    Can this tool be combined with LiveView Native (LVN)[1]?

    LiveView Native has good SwiftUI support on iOS[2], but only basic Jetpack Compose support on Android[3] (I'm not up to date, so things may have changed now).

    Is it possible to use this project to help with conversion of LVN SwiftUI apps to Jetpack Compose?

    ---

    1. https://github.com/liveview-native

    2. https://github.com/liveview-native/liveview-client-swiftui

    3. https://github.com/liveview-native/liveview-client-jetpack

  • by sharp11 on 8/29/24, 5:47 AM

    This looks super interesting, congrats on reaching 1.0! If you do a lot of customization on the Android side, do merge conflicts become a headache? Also, does the Skip plugin assume that you're using Xcode's built-in git?

  • by giamma on 8/29/24, 7:36 AM

    Hello, this looks like a cool product, congratulations.

    How does it handle the different UI guidelines on the two platforms?

    I have not been using Android for some years, but the first example that comes to my mind is that as far as I remember Android has a platform-level back button, while on iOS each application provides a "back" link to be tapped to go back to its previous screen. If I wanted a single code base that followed the recommended UI approach on each platform in order to be as user friendly as possible, would I need to write certain parts twice using #IFDEF or similar blocks?

  • by gavinh on 8/28/24, 10:22 PM

    > first-class development environment (Xcode)

    Are you sure

  • by badoongi on 8/29/24, 5:38 AM

    Nice, this somewhat reminds Apportable: https://www.ycombinator.com/companies/apportable

  • by jamil7 on 8/29/24, 3:22 AM

    Great work. Cool to see this here, I’ve been meaning to try it. We have two large Swift apps at work that wouldn’t be a good fit but I’ll check it out for a side project. The bulk of our Swift code is actually non-ui code as we have a somewhat complicated data and offline sync layer. We’re actually more interested in the Swift on Android and Wasm developments for this reason which (I saw you’ve also been contributing to the Android Swift toolchain Marc).

  • by cmt8 on 8/29/24, 4:03 AM

    This is really really awesome. The only thing is I feel like it would be heavily reliant on SwiftUI/Jetpack Compose and so breaking changes would break the entire codebase until the tool is updated since there is no 'runtime'. I'm also curious how hacky workarounds would be transpiled over to Compose, since in my experience SwiftUI can involve lots of hacks in order to get something more unconventional working properly.

  • by Cloudef on 8/29/24, 5:07 AM

    Interesting. One thing I don't like about flutter is the management of platform specific meta files. How does skip handle this? Do I still have to write bunch of .manifest, res and .plist files per platform? How about screenshot and all the other crap appstore and playstore wants?

    The flutter projects usually start clean, but then these platform specific hacks start to pile up and it's ugly and annoying to update to later flutter skeleton.

  • by RedComet on 8/29/24, 10:24 PM

    I've been following this for a while now.

    Skimming the page, it appears the answer is no, but I'll ask anyway: If all of the project's dependencies are pure Swift (+Foundation) Swift PM packages, is it possible to use them in transparently in the android project. Can they be compiled natively such that the transpiler's kotlin transparently calls into the native (Swift) libraries?

  • by gwbennett on 8/30/24, 6:09 PM

    I've been an iOS dev professionally since 2009! I just found Skip via Dave Verwer's newsletter today. Finally, finally! This is precisely what Apple should have built years ago!!!

    I have just started a new iOS app and didn't want to do the Android app in React Native, Flutter, etc! Write in SwiftUI once! Nice, Nice!

    Thank you!

  • by langcss on 8/28/24, 10:58 PM

    Sounds amazing. From a career point of view it is good for a dev as they click up native skills instead of some abstraction layer, while being able to do cross platform.

    Been a long time since I worked on mobile (pre Kotlin!) but how does it handle differences in the UIs. Do you need "is android" directives. Are there Swift objects in your library that are android specific.

  • by josh_carterPDX on 8/29/24, 3:20 AM

    I was just looking through everything and didn't see much when it came to scale. Having been the founder of a devtool platform in the past, one common question we had was what would happen to the platform if someone built the next Flappy Bird. Would we be able to keep up with the insanely fast growth?

    Have you addressed that with Skip?

    Looks incredible, btw. :)

  • by smusamashah on 8/28/24, 11:41 PM

    I am not into mobile dev and was just having a look and don't have anything to say on the project itself.

    The website is very slow to scroll on phone for some reason. Feels like scrolling has smoothing effect applied on it which does not work well everywhere and ends up slowing down scrolling (feels like 10 fps or something).

  • by piyushtechsavy on 8/29/24, 7:48 AM

    This sounds very cool. We have tried hybrid apps in past and reverted to native implementations due to various issues. Maintaining two code bases was always a problem. Although React native provides way to add native code as well. This can be a changer.

  • by dkga on 8/29/24, 1:23 AM

    Excellent development in the direction of reducing the browser+JS/TS apps! Congratulations!

  • by atentaten on 8/28/24, 11:20 PM

    How can I load a library in C or c++ with this in a way that will work in both Android and iOS?

  • by charliesbot on 8/29/24, 3:23 AM

    How does it handle cases like Material You Dynamic Colors?

    I am thinking about making an app, and we want to support the best offerings from each OS. So the dynamic colors is important on the Android side

    We’ve been thinking about KMP til I read about this, which sounds promising!

  • by 8mobile on 8/29/24, 5:17 AM

    Hi, Congratulations on the project. I'm trying to port my app to android and skip is making my life easier. Some things are broken but otherwise it works like magic. I'll start testing it with a more complex project. Thanks a lot

  • by lawgimenez on 8/29/24, 12:22 AM

    Our Jetpack Compose app is almost done, while our iOS app written in SwiftUI was released earlier this year. I would love to try this but I'm afraid it is too late in the development cycle.

    I would just like to ask, what Material version are you using?

  • by vinibrito on 8/29/24, 3:00 AM

    How do you handle the minimum denominator issue that is invariably present in all cross platform tools? In other words, what are the sacrifices you made in each platform to make it all work? And why each of these specifically?

  • by preciousoo on 8/29/24, 3:52 AM

    I was wondering a while back if a tool like this existed. Good job!

  • by grounder on 8/29/24, 2:35 AM

    Looks interesting. Does it support things like the device camera?

  • by mariocesar on 8/28/24, 10:16 PM

    Are there showcase apps? A "Built with Skip" list?

  • by yumraj on 8/28/24, 11:51 PM

    Given that this is now production ready, any limitations one needs to be aware of?

    Please feel free to point to a doc that may already answer that.

  • by thomasswift on 8/28/24, 10:38 PM

    This looks great! Thanks for sharing here.

  • by dilliwal on 8/29/24, 6:10 AM

    I was following your youtube videos and was quite excited for the release, going to give it a try.

  • by thomaskang08 on 8/29/24, 2:09 AM

    This is magical. Almost too good to be true. I hope this is indeed production ready.

  • by 486sx33 on 8/31/24, 1:59 PM

    This is terrific, Android app development is something I always avoided and found annoying, usually just pivoting to web view for Android users.

  • by neil459 on 8/29/24, 12:57 PM

    Sorry, but I don't have and won't install brew. It is just too undesciplined.

    Otherwise, looks like a good tool I could use.