See my response below on the KMP question: the comparison with CMP mostly applies to Flutter as well.
> near-native mobile apps (the difference is almost negligible)
Not as of the advent of Liquid Glass on iOS (and, to a lesser extent, Material Expressive on Android). Flutter isn't going to be implementing these new interface conventions[1], and so the UI for these apps are stuck on the last generation and are already starting to feel outdated.
Flutter's grim outlook has resulted in a surge of interest in Skip, and it was one of the drivers for us to open up the platform and catch the wave. If you love Dart, or if your apps don't need to look native (e.g., games or very bespoke interfaces), then Flutter might continue to be acceptable. But everyone else is starting to look elsewhere, especially in cases where their business depends on their apps feeling premium and native.
Flutter's grim outlook? It's being used more now than ever before, with both enterprise use as well as 30% of all new free iOS app store apps are now using Flutter.
Flutter is undergoing a major refactor where they're decoupling Material and Cupertino into separate packages. This is the reason why they're not implementing those new conventions right away. The way you've framed it is pretty disingenuous.
It really isn't. Did you see their latest time estimate (https://youtu.be/W4olXg91iX8?t=538)? Late 2026 just to get the widget sets broken out into separate packages? And only then can they start considering modernizing them and trying to mimic the latest UI?
Flutter can't even get animations to look and feel right for iOS 18 and below (read through this thread and every other HN/Reddit thread that mentions Flutter vs. native components). Do you really think they'll ever get Liquid Glass looking and feeling convincing, let alone performing acceptably?
Read over the 100+ comments in the GH issue I posted. You see actual Flutter contributors — not people who merely vibe-coded a Potemkin L.G. demo and declared victory — saying that it is effectively impossible.
> Flutter isn't going to be implementing these new interface conventions
To be fair reading those updates it sounds a lot more positive than this comment makes it seem. I.e. "they're pausing design updates while they figure out the best way to do it" rather than "they're not going to bother":
> This strategic pause on design updates gives us the space to ensure the long-term health and maintainability of Flutter's design libraries. We are committed to being transparent with our contributor community as we explore these options and will have more to share on our findings and future direction in the coming weeks.
and
> The material and cupertino libraries are being decoupled into standalone packages to accelerate feature development. All new work for iOS26 updates in Cupertino will happen in the new packages once established in flutter/packages.
Well sorry. But Android UI is bad just bad. The settings, the menus. Its bloated and almost as if they deliberately made it annoying to use. It just sucks.
Have you seen iOS or macOS settings, like ever? Especially on macOS, the UI is infantile, you have settings in different menus that change each other (mouse / touchpad scroll direction, two buttons in two menus, they change each other). On iOS you have amazing features like a wheel spinning forever without telling you there is a problem and what it is (like, for an app with in-app purchases, you must have a payment configured, otherwise the app installation just spins forever).
Compared to that, my (OxygenOS version of) Android UI is pretty good, concise, flexible and customisable if I want to. I hate the ambiguity of gestures, so I keep the buttons for navigation. I don't want everything splattered on the home screen, so I use a different launcher than the default. The menus are all logical.
It's a valid opinion. People can have opinions and also not be "in a cult." I would say this default response is rather cultish in its own right by your own use of the word.
Good question. I'll try to answer as objectively as possible, despite my bias towards Skip's approach.
Kotlin Multiplatform (KMP) enables you to target different platforms with your Kotlin. In the context of mobile apps, it allows you to compile your Kotlin to a native framework for iOS, so you can reuse your business logic. On iOS, the Kotlin is running in its own little garbage-collected runtime, but it sets up a bridge to Objective-C and Swift, so the iOS developers can communicate with it from their apps (the interface of which will typically be written separately for each platform). It is neat technology, and Skip integrates with it[1]. We were on their Talking Kotlin podcast in 2024 talking about it[2].
When targeting just the shared business logic and not the UI, Skip is, in some ways, the inverse of KMP: whereas they let you share Kotlin logic between the iOS and Android app, Skip lets you share the Swift logic. Skip operates in two different modes[3]: Skip Lite and Skip Fuse. Skip Lite is the original version of Skip, and transpiles your Swift into Kotlin. Skip Fuse is a later iteration and resulted from the formation of the Swift Android workgroup[4], of which we are founding members. In both modes, you can share your Skip business logic layer between multiple apps, and this is a popular application of Skip (e.g., see this talk at NSSpain[5]).
So that's the story for shared logic. Now onto the user interface part:
While I mentioned that Skip _can_ be used just for sharing business logic, it really shines when you build your whole app with it. You write your app in conventional SwiftUI, and Skip will translate it into the equivalent Jetpack Compose (which is now Android's official recommended way to build apps). Launching your app from Xcode will bring up both your iOS app in the simulator, and the equivalent Android app in the emulator. It is designed to be a single vertically-integrated app creation solution, and enables a single team (or a single developer) to iterate on both platforms at the same time, without any of the coordination overhead of building two separate apps for the two platforms.
KMP itself doesn't have an equivalent, but it does have a sibling project "Compose Multiplatform" (CMP), which is built on top of KMP and sort of does the opposite: it lets you write your app in Kotlin and Jetpack Compose and run it on iOS. But the way that it achieves this is different from Skip's approach: it doesn't use native controls on iOS, but instead paints pixels on the screen that mimic the native iOS UI (à la Flutter). The results are predictable: an uncanny valley UI that doesn't feel _quite_ right, and that struggles to keep up with the platform conventions. Notably, like Flutter, they won't be able to support Liquid Glass in any convincing form, and so apps built with it are going to be stuck on outdated iOS UI conventions. In short: CMP is native on Android but alien on iOS, whereas Skip is native on both platforms.
That's our take on the difference between the two. In fairness to KMP, they do have some distinct advantages in terms of reach: whereas Skip is squarely focused on just mobile platforms, KMP can target desktops and the web as well. If that is a priority for you, or you already have a lot of Kotlin experience or are invested in the ecosystem, then KMP might be a good fit for your needs. But if you like Swift and SwiftUI, and are happy working with the Apple developer tools, then you should give Skip a try. It really is magic.
I had a very quick glance at docs website, from Comparison page it says it uses native components, which is great. However, I did not find anything related to platform specific API usage, such as embedding camera into your view or using notification groups/channels? Is there a way to "offload" these parts to android, similar to what CMP allows you to do? (You can embed native iOS views inside Compose view or use expect/actual)
Yes, as I just responded there, Skip uses the native toolkits and conventions on both platforms: SwiftUI on iOS and Jetpack Compose on Android. So you automatically get the platforms' built-in accessibility support.
Yes, the unique benefit of Skip is that you are using the real native toolkits on both platforms. So you get both SwiftUI's accessibility support via VoiceOver, as well as Jetpack Compose's support via TalkBack.
Note: TalkBack is the best case scenario you're getting on Android. I've seen some abominations coming out of Samsung's implementation, and results will vary from device to device.
Still, assume people are using TalkBack and don't take reports from anything else, it'll prevent you from going insane.
That's awesome! My family has users of both, so this might be a convenient way to use a pleasant language to write mobile apps that all of my family members can play with.
As we mentioned in the post, developer tools really need to be freely obtainable in order to gain mass adoption. In that sense, it was an easy strategic decision. And we felt that the time was right, given that Skip's benefits are being thrust to the foreground in light of recent developments.
When it comes to the mass adoption of software development tools, I believe the proven formula is: Make all of the SDK/libraries/command-line tools permissive (e.g. MIT) open source licensed; Charge for a complex visual/RAD UI designer/IDE but make sure to have a free community version for indies and smaller shops. In the past, instead of a free community version there were easily available "pirated" releases.
You should really consider why free software exists. Open source is open source, sure, but it is a disservice to your users to ever release proprietary software for any reason.
I personally would not start or run a business that didn’t release all software it builds under free software licenses. We don’t open source it because “developers expect it”, we open source it because it’s the right thing to do by your users.
> Free software is an ideology, not just a license.
Yes and people shouldn't enforce ideology on top of each other. I am speaking this as an free software advocate too.
the fact of the matter is open source is still barely fundable and I am pretty sure that they evaluated multiple decisions to come up to this regarding how fundable it is and other factors.
If we have to indoctrinate someone into our ideology, it means that our ideology is unable to gain weight by its own merit. No, let open source do the work and welcome people for who are now open source. Have open arms to everyone who open sources their work & incentive them to do so with a happy heart.
Open source is about freedom. And being honest, If they wrote the code themselves, then its their freedom to have it in open source or not.
I for one, welcome another great open source! Thanks for going open source and Good luck to skip in future!
I know Open source has some issues regarding funding etc. so I hope that people donate to skip & make the project sustainable!
Yeah but if that was the only reason to do open source that was encouraged then there’d almost certainly be a lot less open source software overall (and lower quality). Personally I’d prefer OSS win overall even if it costs some ideological purity.
I don’t open source my iOS apps that provide my living because there are many examples already of others using this to release identical apps without credit or sharing their work back (even with AGPL), which would remove my source of income that enables me to work on it in the first place. I haven’t found a way to make a living off open source yet for the type of products I produce.
I’m not independently wealthy to be able to afford to work for free. If I release my work for free, then I will have to live on the streets or in a cell, or take a job and lose the time I have to produce my work in the first place.
This is indeed a dilemma, but note that copyleft licenses like GPL or MPL do give you considerably more protection than a pushover license like MIT/BSD. I wrote about this last year at https://appfair.org/blog/gpl-and-the-app-stores.
It gives near zero practical protection as the devs that clone in the App Store do not respect licenses and Apple is slow to act (sometimes shutting your own dev account instead of the copycat’s, another high risk).
Enabling copycats also encourages them to target my apps for fake negative review spam and bot activity that gets my dev account (and personal iCloud) flagged and banned without recourse.
I also have no funds to sue someone. And the copycats are often anonymous and overseas in random countries, adding to the challenge of doing anything about it besides begging Apple to help without accidentally hurting me instead.
hey, came from the other comment you messaged me but this feels like such an apple issue which is so fixable that I am not understanding why Apple won't do it.
I understand what you are feeling but I feel like what you are saying is genuine and although sad right now, it provides a course of action for Apple to work upon to meaningfully improve it so that we can get atleast either custom license source available (as I mentioned in my other comment) or GPL/restrictive Copyleft as this mentions.
If someone from Apple's reading this. This feels such a large issue even more than the license issues in general, is Apple working on this or not?
This would honestly show the real loyalty towards developers if Apple can do this so I am waiting and perhaps a movement can be created to establish some formally written demands/ perhaps a change.org petition?
Apple won't improve this out of charity for small businesses. Apple has no real loyalty to developers outside of their largest partners. This requires regulation, and/or mass organizing across developers.
> Apple won't improve this out of charity for small businesses. Apple has no real loyalty to developers outside of their largest partners. This requires regulation, and/or mass organizing across developers.
Isn't there an EU law where if Enough signatures happen they are forced to discuss it in the EU parliament or similar? I remember this from the stop killing games movement iirc.
Mass organizations can take place too but why not a mix of both utilizing both regulations and mass organizations?
AGPL seems like a joke when it comes up against the indie hacker world. Has there ever been an example of an open-source maintainer successfully suing someone who ripped off their codebase without attribution? Doubtful.
Shame that the world has to be like this in the first place :<
Perhaps I am way too altruist at times & the world is capitalist without any discrimination, stealing anyone's work and reselling it feels so scummy and I have heard it happen actually so you are not actually completely in the wrong and its your code and your lifestyle and so I respect it. (Even if I am an open source advocate, I will admit making money from Open source is super hard in many cases)
Interestingly, what's your thoughts on Source available licenses. Like, honestly, like use a license which doesn't allow reusing components or providing another appstore release of that or similar
If you use github actions with immutable and other instances, I feel like there is a real way of like verifying that the code written is safe & people can verify it & trust it.
If people want to modify your product, they have to pay you and get in touch with you.
I will take this with additional security context and being able to audit over having nothing in the first place! (Hopefully I hope this might not impact your living either in any way and honestly even if you do this! Some of us would deeply appreciate it)
Something is better than nothing. If even much of the world goes to source available licenses, I feel like the transition to open source of softwares becomes much simpler as well if enough conditions (like people start donating/govts start investing in open source) etc. happen!
Source availability still provides one to that direction & is still overall positive with atleast in this context, virtually zero downsides.
Well, you're running both the iOS development tools (Xcode, iOS Simulator), plus the Android development tools (Gradle, Android emulator, and maybe Android Studio too). These add up.
16GB might be possible, though.
(Skip itself doesn't take much memory. If you run it headlessly as a SwiftPM plugin, you wouldn't need nearly that much.)
Do you have to run both at the same time? Because my flow with React Native is to focus on one platform at a time, I don't try to run everything in one shot.
No, you can configure it to just build and launch for iOS or Android separately. But we do recommend iterating on both in parallel for most of the UI work, just to make sure that everything stays in sync.
For framework/library development, you can of course build and test separately for each platform.
And if we're talking Expo, that's only for prebuilds of course; once you've got the native app installed then you can absolutely code and see updates in near real-time on both Android and iOS devices.
I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…
I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.
This is a neat hack, and I don't want to diminish the effort. But I fear that any such loader apk would be marked as malware by Google and nuked by Play Protect Services.
And as others mention, using adb (or Shizuku) might also be a workaround for tech-savvy users (for the time being). We list some other potential temporary workarounds at https://keepandroidopen.org. But none of it is viable for the other 99%.
There's really no solution to the dilemma other than stopping Google from implementing it altogether. And for that, we need regulatory action — which means we need to advocate and educate consumers and lawmakers about the threat that this poses.
> near-native mobile apps (the difference is almost negligible)
Not as of the advent of Liquid Glass on iOS (and, to a lesser extent, Material Expressive on Android). Flutter isn't going to be implementing these new interface conventions[1], and so the UI for these apps are stuck on the last generation and are already starting to feel outdated.
Flutter's grim outlook has resulted in a surge of interest in Skip, and it was one of the drivers for us to open up the platform and catch the wave. If you love Dart, or if your apps don't need to look native (e.g., games or very bespoke interfaces), then Flutter might continue to be acceptable. But everyone else is starting to look elsewhere, especially in cases where their business depends on their apps feeling premium and native.
[1] https://github.com/flutter/flutter/issues/170310
reply