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.

[1] https://github.com/flutter/flutter/issues/170310

Dunno about Skip, but I can always tell when an app is Flutter. They feel like crap. Everything's a bit off with the native looking widgets. And fully custom designs still animate a bit weirdly. And they definitely still stutter. Somehow a tier below React Native.

Flutter is fine if you don't care about performance, accessibility, have no need to access native capabilities or non-fluttered widgets (ex: the Google map integration is awful) and overall just want to make an internal app.

The cost of making an excellent flutter app is about the same you'd pay making fully native apps. Except that you're always paying for Skia's costs with Flutter.

This recommends 32GB to run _everything_, so xcode, gradle, emulators, simulators, etc. Not fully surprising.

Flutter still doesn't support liquid glass on iOS so it doesn't seem like a serious contender to me at this point. And due to the nature of how Flutter is implemented, it's going to continuously be an uphill battle. Maybe it's fine if you intend on having a completely custom UI and don't care about platform look and feel.

The Xcode build plugin in the /skip repo uses the binary created by /skipstone (which is the repository that was just opened).

Thanks for pointing out that the /skip repo itself doesn't have a license. We'll fix that asap!

LGPL3 has now been added: https://github.com/skiptools/skip/commit/7ad94680a801ca393fe...

You can chill - it was their oversight that they’ve already corrected, not an omission by design

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.

You can see a sample snippet at https://skip.dev/docs/components/accessibility/

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

IDEs targeting mobile development saw the bloat in FPGA IDEs and said "we can beat that".

At current prices, if you do not already have 32GB RAM, it will cost over $300 for DDR5, and over $200 for DDR4...

I assume that’s for the development phase, not (necessarily) for apps developed with Skip

Likely because it uses both iOS and Android toolchains plus its own transpiler (with Skip Lite) or other overhead with Skip Fuse. iOS alone is already challenging with 16GB. Don't blame Skip for this - it's on Apple and Google for not shipping memory-efficient tooling, which shouldn't be a surprise if you've used their software.

Thanks! It has been a long time coming.

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.

Yes, SwiftUI supports macOS automatically.

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.

Biggest downside to SwiftUI development is lack of hot reloading. You can use the Inject framework but it’s fragile. This also makes it harder to iterate on with agents.

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.

[1]: https://skip.dev/blog/skip-and-kotlin-multiplatform/

[2]: https://talkingkotlin.com/going-from-swift-to-kotlin-with-sk...

[3]: https://skip.dev/docs/modes/

[4]: https://www.swift.org/android-workgroup/

[5]: https://www.youtube.com/watch?v=EIGl6GOo210

The point of open-sourcing is to put it on peoples’ map at all.

Development tools have to be fully dependable (maintained, no rug pull) and proprietary software just carries too much risk in that regard for a lot of people.

The path frameworks usually go: open source some of it and paywall extras or some related service. Look at Expo or Next.js.

It’s bold to assume people will spend money on something they can’t see in action and don’t know whether it will fit their needs.

> What's the point? Marketing for my skills as a developer? There's no more need for software consultants now with Copilot/etc. I have to change careers.

I encourage you to find a way out of this belief, or at least least fend it off as long as possible.

You can see from recent HN postings that most people are not experiencing career-ending levels of performance from LLMs.

Did you reach out to Lua heavy shops?

Hey! (firstly recognized you from your other post on HN)

Personally I would love the idea of creating a lua application natively. You don't know how much I wanted it now that you mention it.

I remember looking for such solutions,finding none, then I even thought of using kotlin apps with lua integration but didn't like the idea of learning kotlin

For some reason, even though I have only played just a little bit with lua, there are tons of options which compile down to lua which can make it really powerful too and so for the end developer, there are tons of possibilities and it starts out being so simple!

I think the problem with lua was that there is a lack of libraries & projects regarding it so this might actually help it

I have another question tho and I'd love it if you can answer it.

Is there any way that I can write a cli application in golang or port it to something with just glue code being lua and using it for android somehow?

I don't want to create an android application in golang itself for what its worth because I find the primitive a little lacking (what do I use, wails?)

I have heard people use python kite or something iirc which looked good but python-go support isn't the best & i dont even know if its on android

If you can actually provide lua as the UI/UX support (I am imagining something simple but powerful) with code being allowed in other languages where I can get some powerful libraries (golang), I would be super interested in it.

Regarding Open source, I would personally trust the project a lot more if this was open source.

That being said, I understand the worry of changing careers/consultancy/AI marketing because I am still a teenager in high school. I have anxiety because I have an exam for the colleg ein 2 days, I am a bit cooked haha but I guess I just gotta try

Your fears are valid and somehow I imagine you in a position wayy similar to raylib & I remembered this post.

https://gist.github.com/raysan5/04a2daf02aa2a6e79010331f77bf...

Honestly, what are your thoughts in teaching at a college about app development with lua, I mean I am a teenager and I would die for such a course!

Although I was never into roblox, some of my friends were and they treat lua as the holy grail because of roblox development and roblox's development community is from what I can gather decently respected especially if you are teen, some even learn lua just for it.

so you can get people who are interested in already having some gui experience with lua (more in a game environment but still) and you tell them that you can make apps with it just as easily? People will be hooked.

Of course there is some LLM but honestly, nobody cares. LLM's wont be able to recreate your project, I am mostly sure of it.

Marketing is something that I relate with too because we never know what the public really really wants.

I mean, I will admit it, We people are kind of hypocrites (speaking from my behalf)

Sometimes we would open source project and want it to be sustainable without paying the devs or donating to them, that sucks. Some of us just want open source for ideological reasons and um, honestly, I will admit it. It's your code, do what you want it, you built it and you should be proud of it!

We can only give suggestions but I recommend you to create some video of the project so that I can see it.

App developments are fucking nightmares. I had even thought of using godot just to create app development. Any new solution provided decent enough can absolutely help.

Personally I believe you should wait for some time & try to write a blog post about it. I want to hear all the nerdy details!

Create a show HN post, I saw tomhow mention to me how much of the audience wants originality and the idea of "aha moments"/something novel. Provide us with knowledge of what aha moments did you discover during building this, I am soo curious myself!

Good luck man and I genuinely hope the best of luck for you man! Just message me whenever you feel like it or mail me, Will try to respond to ya if you ever need my help (I don't think so but I'd love to playtest what you are mentioning too!)

Oh yea just a teeny bti suggestion adding on that golang one, can you just make it so that I can have a very simple and easy/fast way of compiling golang cli applications into gui android applications with lua code. I personally want this so bad because there are soo many good and lovely open source golang cli and I wanted to be part of f-droid by creating an application gui for some golang cli tool we might use but it felt sooooooo hard that I gave up. (Yes I even used tauri and ended up waking up till 5 am debugging)

The pain point's definitely real and LLM's won't be able to make this. Only the people like you who are truly passionate about such projects can make it. It's a unique project and you should be proud of it and I hope that the project has a good future!

Note that Swift/WinRT by The Browser Company does not qualify, as it’s one layer too low (directly exposes the Windows framework): https://github.com/thebrowsercompany/swift-winrt

However it seems like it could be a good basis for such a project.

Closest thing is SwiftCrossUI. Maybe Skip will come to Windows one day.