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

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.

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.

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...

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

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.

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.

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?

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!

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.

Pricing link: https://skip.tools/pricing/

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.

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

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?

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?

> first-class development environment (Xcode)

Are you sure

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

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).

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.

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.

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?

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!

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.

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. :)

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).

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.

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

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

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!

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

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?

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?

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

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

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

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.

This looks great! Thanks for sharing here.

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

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

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

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.