return to table of content

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

mad_tortoise
20 replies
1d10h

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.

anakaine
10 replies
1d10h

I thoroughly disagree with your positions about foresight, multiple specialists, a lack of need in this space, etc.

There is space in the market for something like this, and it would suit small teams who may be lean, single devs who are starting out, and those who would like to use native code with few if any dependencies.

You may not see the point because you are deeply experienced with the existing tools. I see the point as someone who has struggled to get deep with the existing tools.

mad_tortoise
7 replies
1d10h

In terms of forethought, I can't imagine anyone outside of the US/EU developing an app solely for an iOS user base other than creating an MVP. And then even still, once you have proof it can work why build something that intentionally shuts off the majority of your userbase, or provides a lower quality product to the user base? If you are lean and starting out, don't put all your eggs in a Swift/iOS basket and then hope for a tool like this to sort out your problems. It may be an easy quickfix for a basic app, but once you go even a little bit deeper than surface level you're going to run into problems, have to backtrack and start over with either native Android code, or a cross platform framework.

That said the cost is also something that is odd, when you have free alternatives that provide far more mature ecosystem.

In terms of getting deep with existing tools, what is the difference here when using XCode as to Android Studio or VSCode? The tools aren't difficult to use, at least any more so than XCode. If you're not a developer then sure, but if you are then AS or VSCode should be a breeze. We're far removed from the days of Eclipse and Notepad++ where you didn't have the tooling, online resources or automatic fixes that these tools come with today.

So yeah maybe my experience doesn't see the need for this, which is exactly the issue here. Who is making the majority of the apps we use today? Who is paying to use tools that speed up development? Engineers like myself.

ElFitz
6 replies
1d8h

In terms of forethought, I can't imagine anyone outside of the US/EU developing an app solely for an iOS user base other than creating an MVP. And then even still, once you have proof it can work why build something that intentionally shuts off the majority of your userbase, or provides a lower quality product to the user base?

I can see a simple reason for solely targeting the iOS user base, wherever one comes from: on average they earn more and spend more, making them better targets for both advertising and in-app purchases business models.

Apple’s AppStore represents 65% of global app stores consumer spend, and ~7% of iOS users spend some amount of money on apps, while on Android it’s ~4.5%.

On top of that, the hardware is much less diverse, making it easier have a consistent experience across devices. I still remember a client building an internal bar-code scanning app for their warehouse, then complain it didn’t work well enough, only to realise they had equipped their staff with the cheapest crap they could find, which had a terrible camera.

Back on topic, perhaps yhis kind of tool can be useful for teams who didn’t intend to or couldn’t afford to invest any effort into making an Android app.

MrDresden
5 replies
12h9m

On top of that, the hardware is much less diverse, making it easier have a consistent experience across device

Which is why iOS is usually not the platform you need to worry about when doing cross platform projects. So it doesn't feel like a benefit to start on the least diverse platform and then move on from there.

Back on topic, perhaps yhis kind of tool can be useful for teams who didn’t intend to or couldn’t afford to invest any effort into making an Android app.

But they were however able to invest in both iOS developers, the required hardware and this tool?

ElFitz
4 replies
8h55m

So it doesn't feel like a benefit to start on the least diverse platform and then move on from there.

On the contrary. What are you trying to validate? That enough people are interested in your product. Anything that gets in the way of that is just another distraction, and there already will be more than enough of those.

But they were however able to invest in both iOS developers, the required hardware and this tool?

Developer cost is the same. The difference in hardware costs, if there is any, is negligible.

The tool? It starts quite literally at 0$, and the first paid tier is 29$ / month.

There are two cases where I can see how it would make sense to focus on Android.

First, the WhatsApp example: you are making an app that, by its very nature, entirely relies on massive network effects, and somehow can afford to focus on growth without monetising.

Second, a product that targets people with average to low incomes.

Other than that, if you have to pick between the two, I don’t see the point in starting with Android.

mad_tortoise
3 replies
8h38m

This is such an ignorant First World perspective - for reasons I've stated in other comments. It's mind-boggling there are people like yourself who see's the world in such a narrow vision. As if the Third World doesn't exist and people who develop apps are only in the First World.

Really funny, that you probably consider yourself highly educated, and yet have zero ability to see why iOS is actually not the primary choice for engineers in the global south. Your two cases are beyond laughable.

I'm really sorry I'm being rude, but I highly doubt you have ever built a mobile app yourself if these are your hot takes.

gbalduzzi
1 replies
2h54m

I wanna expand by saying that is not even a full First-World perspective, but purely an US one.

In Europe iOS has a big market share, but Android is still the most used.

ElFitz
0 replies
23m

I’m not from the US.

And while Android has the largest market share in Europe, it still doesn’t change the fact that the iOS app store captures most of the global app store revenue.

Including in Europe.

ElFitz
0 replies
2m

Again, it exists.

It’s not where the advertising money is.

It’s not where most in-app purchases income can be found.

Don’t believe me? Have a look at Meta’s ARPU on a per country basis. Over $50 in the US, around 15$ in Europe, $5 in Asia-Pacific, less than $5 in the rest of the world.

Don’t like those numbers? Look at Genshin Impact’s.

Don’t like those numbers? Look at how much people spend on the AppStore vs the Play Store. The AppStore represents 66% of global app stores revenue, and 76% of global app stores subscriptions revenue.

Now, if you’re building Grab in Indonesia, sure, Android makes perfect sense as a first choice.

You can be rude all you like, it won’t change the numbers.

isodev
1 replies
1d5h

it would suit small teams who may be lean, single devs who are starting out, and those who would like to use native code with few if any dependencies

I think that's already covered by Kotlin Multiplatform, Flutter, React Native and others. It's extremely easy to get started and they all have a vibrant and thriving ecosystem.

I'm not blind to your use of "native" here, but again that's a descriptor typical for the iOS/macOS dev bubble to imply "build with Apple tooling" vs. "build with a 3rdparty/cross-platform framework". It was mentioned in another reply - the years when that was noticeable in any meaningful way are long gone.

raydev
0 replies
22h56m

Seems absurd to include Kotlin Multiplatform with Flutter and RN, given KMM is far less user-friendly.

cvwright
5 replies
1d7h

The problem with this perspective is that iOS is where the money is. Almost ALL the money.

So if western B2C companies have to pick just one platform to start with, it will almost always be iOS. This lets them then port that initial app to Android once they are established with western audiences, so they can also serve the (much larger, much less profitable) rest of the world.

mad_tortoise
2 replies
1d6h

My problem with this is that it show's almost no forethought by those creating the app. If your goal is first an iOS app that you will develop into an Android app. Then why go this route? It doesn't solve any of the bigger cross platform problems, is a far less mature ecosystem, and will seemingly only paper over the basic needs - but in-depth development will become an issue. But if you're only porting an "initial app" and expecting the next iteration to be either native or cross platform, then start like that rather than waste 6-12 months on transposing the code to a different language.

To me this presents as something a business person with very little knowledge of app development will be drawn to. But the long term drawbacks of this approach far outweigh the short term gains from trying to quickly port an existing iOS app to Android.

Sure there's more money in the Western app ecosystem for iOS apps, but that doesn't mean your app should inherently cater for iOS first. In fact that's a very first world and reductive approach, when there's billion's of people that don't interact in the same way.

joshuakcockrell
1 replies
1d1h

Sure there's more money in the Western app ecosystem for iOS apps, but that doesn't mean your app should inherently cater for iOS first

That's exactly what it means. When I was at Twitter, the Android app generated 1/10th the revenue of iOS. If you care about building a business that generates revenue, you should definitely cater to iOS first.

mad_tortoise
0 replies
10h17m

If you care about building a business that generates revenue

You missed the end of that sentence "... in the first world". The ignorance or arrogance to assume all businesses that are started are aiming for first world markets. You think entrepreneurs in Africa, South and Central America, Asia are all aiming to expand into Europe and the US? That Third World business problems don't exist and solely cater for Third World needs?

It never fails to amaze me at the absolute arrogance of these assumptions, as if the Global South isn't relevant in technology or entrepreneurship. Truly astounding.

isodev
0 replies
1d5h

iOS is where the money is. Almost ALL* the money.

* All the money made through an app store.

For everyone and everything else, apps are utility helpers for physical goods and services paid for externally. You setup your router, the app for your door lock, the app to hold your Carrefour discount codes, the app setup your printer etc.

MrDresden
0 replies
12h19m

This only applies to those applications whose role is to generate revenue directly (B2C), and in a specific market segment or region (high income and/or US/EU).

For other types of applications the need to service a wider audience can often trump this.

Think banking applications that are without any kinds of in-app purchasing or upfront cost of use.

Or state healthcare sponsored medical/health tech applications.

Or industrial applications that need to run on rugged devices.

abewhite
1 replies
1d7h

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.

mad_tortoise
0 replies
1d7h

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.

BodyCulture
0 replies
1d3h

Your criticism is very interesting, but instead of just presenting some abstract ideas of potential problems it would give much more impact to your argument to present some hard evidence that your way of thinking is better.

Can you show an example of an app that will generate more problems for developers with this approach than with other platforms?

BTW do not forget to add some possibilities to pay you for your work with such a publication, I would certainly be willing to pay for a good in-depth analysis.

mariocesar
7 replies
1d20h

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

marcprux
6 replies
1d19h

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.

No "built with" list yet, but coming soon…

nyrulez
5 replies
1d19h

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

marcprux
4 replies
1d19h

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.

yumraj
3 replies
1d18h

How does it work in practice?

In other words the Swift app will keep developing, requiring constant Android app generation via transpilation.

Does it keep track of generated and manually edited parts or will that step on each other?

marcprux
1 replies
1d18h

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/

yumraj
0 replies
1d17h

That I had understood, I was looking for what @abewhite replied.

abewhite
0 replies
1d18h

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/

amehregan
6 replies
1d20h

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.

itake
3 replies
1d17h

why is this better than RN or Flutter? Does it make styling easier? like android app can have a material design.

dkga
2 replies
1d17h

I would guess the apps are much lighter and less buggy.

itake
1 replies
1d13h

Maybe? The docs say you have to build the swift app in a weird way (meaning you can't just convert your existing code to the new framework).

Doing something non-standard hints bugs to me.

abewhite
0 replies
1d6h

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

isodev
1 replies
1d5h

Does it really? The layouts on Android seem very iOS-y unless you apply "platform customisation" but that seems to defeat the purpose of this framework. I think it's a nice toy experiment to cross-compile things but not really transformative enough to be a viable option. Also becoming dependant on a for-profit company to build your app on top of the platform, I think there are others who have tried this as well.

lightyear_clone
0 replies
8h50m

I am curious, are you building your app on a non-profit company platform? If so, do you mind sharing it?

LifeUtilityApps
6 replies
1d19h

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.

AnonHP
5 replies
1d14h

It's amazing I don't have to learn Android to get something up and running at this speed with Skip

Any thoughts on how you would debug issues on Android that don’t show up on iOS?

abewhite
4 replies
1d7h

Skip generates native code, so you can open it in Android Studio and use all the native debugging tools

nprateem
2 replies
1d5h

If you know how given the point of this is not having to learn android

raydev
0 replies
23h1m

None of the alternatives like RN or Flutter will allow you to skip learning about a specific platform if you have a platform-specific bug or issue.

marcprux
0 replies
22h54m

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.

evereverever
0 replies
2h1m

So every version you release you'll have to go back and fix the same bugs?

Or re-patch them in some way?

yumraj
2 replies
1d17h

So far all looks interesting. The only thing that I’m still wrapping my head around is the pricing/licensing for “indie”

If I may suggest, instead of 6 month audit and machine locked license, perhaps something like where license is needed IFF the app is launched. This will reduce friction for individuals and pre-funding startups. I believe Unity and Unreal use this kind of licensing.

pzo
1 replies
1d8h

For me for "Indie" pricing is not clear what it means "members with less than 30K USD related annual revenue" Does it mean less than 30k revenue from app using Skip? Or any revenue such developer has? If the latter then any freelancer or indie will not qualify if have monthly salaries >2500usd doing any IT stuff or app dev using different frameworks.

yumraj
0 replies
1d

Yes, their pricing/licensing is not ideal at the moment, IMHO of course.

They need to build critical mass and hence initial tinkering should be as friction free as possible. Landscape is full of alternatives so people need to get started as quickly as possible.

They seem to have a valuable product, but this initial friction might reduce traction, again IMHO.

s_dev
1 replies
1d6h

If I learned anything from expo -- get signed up so you can get grandfathered in to future plans. They're almost gonna certainly increase prices.

yumraj
0 replies
1d

First they have to gain critical mass. Not sure what was Expo’s initial pricing like.

wirelesspotat
3 replies
1d19h

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?

yumraj
1 replies
1d18h

Have not read the docs, but what’s the reason for that?

Is it not just a transpiler, since then it should work at any stage. No?

wahnfrieden
0 replies
1d18h

It’s missing things that are harder to work around if you already have code relying on those missing bits or done in an architecture it can’t transpile

lawgimenez
3 replies
1d18h

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?

abewhite
1 replies
1d18h

Material 3

lawgimenez
0 replies
1d17h

Thanks for making Skip! I will try to contribute to your repo. I lead the mobile team so definitely will evaluate this.

pushupentry1219
0 replies
1d18h

It looks like 3.0 from the screenshots? But I'm not sure.

atentaten
3 replies
1d19h

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

marcprux
2 replies
1d19h

Glad you asked! We have an FFI framework (https://skip.tools/docs/modules/skip-ffi/) that enables you to use the same native code on both iOS and Android. I wrote a blog post about it at: https://skip.tools/blog/sharing-c-between-swift-and-kotlin/ . It is what powers some of our own frameworks like SkipSQL (https://skip.tools/docs/modules/skip-sql/).

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.

pzo
1 replies
1d10h

Will this work seemlesly with C only or C++ as well? I know swift this days have good c++ interop but not sure about jni/jna

marcprux
0 replies
1d6h

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.

yumraj
2 replies
1d18h

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.

marcprux
1 replies
1d18h

To put the question in context, I'll preface by saying that Skip is unique among cross-platform app development solutions in that it isn't imposing an "alien" language or runtime on your app. It uses Swift on iOS, and Kotlin on Android, which are both the first-class recommended development languages for the respective devices. Any translation limitations can always be overcome by branching on the platform/language you are using, and just writing custom code for the platform in question.

That being said, while we have good translation coverage at both the lower levels (Foundation to the Android SDK) and higher levels (SwiftUI to Jetpack Compose), there are many Apple frameworks that we simply don't have any compatibility frameworks for yet. One commonly-request example is maps: we don't have anything that takes the MapKit API and converts into the Google Maps equivalent. However, this doesn't prevent you from implementing it yourself. For a simple example, see the Travel Bookings sample demo at 2:15 at https://skip.tools/tour/skip-showreel/, where you can see how you can drop MapKit and Compose Maps inline into your code.

As time goes on, Skip's community ecosystem of compatibility frameworks will grow and expand. But until then, there aren't any barriers to simply implementing them yourself.

yumraj
0 replies
1d17h

Makes sense.. so any limitations are going to be on Android side, which if I understand correctly can just be implemented directly in Kotlin.

langcss
2 replies
1d19h

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.

marcprux
0 replies
1d19h

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

abewhite
0 replies
1d19h

Skip is definitely a great way to ease into the Android dev world.

Lots of options for adding platform-specific code - including being able to directly call Kotlin/Java APIs from your Swift, move back and forth between SwiftUI and Compose, etc.

https://skip.tools/docs/platformcustomization/

josh_carterPDX
2 replies
1d15h

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

jamil7
0 replies
1d14h

One big advantage here is you can “eject” at any point and have two functioning, normal native apps. If you’re talking about scaling a team then you can simply eject and hire for each platform if you outgrow the tool.

abewhite
0 replies
1d14h

Skip is a locally installed and run dev tool. It is infinitely scalable! :)

gavinh
2 replies
1d20h

first-class development environment (Xcode)

Are you sure

scosman
1 replies
1d19h

Also giggled at calling Xcode “an Idyllic IDE“.

I guess one ugly mobile app IDE is better than two.

pzo
0 replies
1d10h

Android studio is miles ahead from xcode this days - I'm envious ios dev. Wouldn't call android studio crappy

fifafu
2 replies
1d12h

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

abewhite
1 replies
1d7h

Super happy this worked out for you! But I could never trust an LLM to maintain my app over time

fifafu
0 replies
1d6h

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

banashark
2 replies
2w1d

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.

marcprux
0 replies
2w22h

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

vinibrito
1 replies
1d15h

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?

abewhite
0 replies
1d14h

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.

smusamashah
1 replies
1d18h

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

marcprux
0 replies
1d18h

It's fast for me my on my iPhone 12 Mini (Safari) and Pixel 6 (Chrome). What device and browser are you using? Are any particular pages slower than others?

rock_artist
1 replies
1d13h

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

abewhite
0 replies
1d7h

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

https://skip.tools/docs/platformcustomization/

https://skip.tools/docs/dependencies/#implementation

happybuy
1 replies
1d13h

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.

marcprux
0 replies
1d5h

This will likely grow over time

This is indeed our primary focus, now that Skip 1.0 is released. We already have a bunch of open-source frameworks that bridge common libraries like WebKit, Firebase, Lottie, SQLite, and more. We expect this ecosystem to grow quickly and organically along with the Skip community. If there are any other frameworks that you commonly use, please let us know (either here, or via any of our support channels) – we will definitely add them to the roadmap.

giamma
1 replies
1d10h

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?

abewhite
0 replies
1d7h

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.

That said, yes, you can easily use #if blocks to write iOS and Android-specific code: https://skip.tools/docs/platformcustomization/

cmt8
1 replies
1d14h

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.

jamil7
0 replies
1d14h

Yeah, we still leverage UICollectionView a lot even in SwiftUI as there’s no suitable replacement, grids have a bunch of downsides still right now.

charliesbot
1 replies
1d15h

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!

abewhite
0 replies
1d14h

Skip translates your SwiftUI into Compose, so it uses your Material theme just like any other native Compose app would

RedComet
1 replies
20h7m

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?

marcprux
0 replies
19h43m

Not yet, but this is a capability that we are actively investigating.

Cloudef
1 replies
1d13h

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.

marcprux
0 replies
1d6h

While the core of your Skip code and resources exists in one or more Swift Package Manager module (which will be transpiled into corresponding Gradle modules), the scaffolding of your actual app is still an Xcode project on the iOS side, and an Android Studio/Gradle project on the Android side.

When you create a new project with `skip init`, it will create the two projects for you, along with fastlane configurations for each of the projects. From there, you'll proceed with all the deployment-specific stuff (screenshots, preview videos, metadata, content ratings, etc.) as per each individual store's guidelines.

Each side of the project is always an individually valid project, following the corresponding platform's recommended conventions. There aren't any bespoke plist formats or any Skip-specific manifests to deal with, with the exception of one small central "Skip.env" file, that contains basic shared information like the app name and version number.

thomasswift
0 replies
1d19h

This looks great! Thanks for sharing here.

thomaskang08
0 replies
1d16h

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

sharp11
0 replies
1d12h

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?

preciousoo
0 replies
1d14h

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

piyushtechsavy
0 replies
1d10h

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.

nivertech
0 replies
1d11h

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

neil459
0 replies
1d5h

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.

jamil7
0 replies
1d15h

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

isodev
0 replies
1d10h

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.

gwbennett
0 replies
23m

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!

grounder
0 replies
1d15h

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

flawn
0 replies
1d20h

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!

dkga
0 replies
1d17h

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

dilliwal
0 replies
1d12h

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

8mobile
0 replies
1d13h

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