Skip is now free and open source (opens in new tab)

> 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

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.

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

People build tools that they want to use, then share it with others because it's free to. If the rest of the economy worked like this we would be in full-blown utopia.

Selling software to software developers is always going to have a pretty low ceiling, because you're always going to be competing with "I could build this myself" while dealing with a bunch of users who will have the nagging thought of "Why the heck does this bug exist/this feature not exist? I could fix this in an afternoon." Ironically, open source relieves this pressure for multiple orders of magnitude more people than actually contribute, because they're only grappling with their own laziness, rather than resenting you, the developer.

From the link:

> Beyond pricing, there’s a deeper concern about durability. Developers are understandably wary of building their entire app strategy on a small company’s paid, closed-source tool.

I find quirks or bugs or limitations in my tools all the time, and when they are open source I can fix and augment the tools however I want, and I can share those changes with others.

I can't do that for closed source software.

Now, for most software users it doesn't really matter because they couldn't fix a bug or add a feature anyway. Closed and open source are functionally equivalent, and it makes more sense to pay for support and not care you can't change it yourself.

I think this is kind of like cars; people who work on cars want to buy a car that doesn't have a bunch of electronic and proprietary parts that can't be worked on in their garage. On the other hand, people who won't work on their car anyway don't care.

Traditionally, people don't pay for cooking recipes, they may pay for cookbooks, that is a nice packaging around the recipes, or they may keep their recipes secret. Cooking recipes are like the software tools of chefs.

The actual tools of developers are computers, which they pay for, like chefs pay for their knives.

Software tools, like recipes cost nothing to copy and distribute, while actual tools, like knives and computers cost money per unit to produce.

edit: To be a bit less opaque, a relevant quote:

> In the late 1970s, Richard Stallman had an issue with a new printer installed in the MIT AI Lab, where he worked at the time, which ran proprietary firmware. Richard Stallman was frustrated that he could not receive a copy of the printer software and edit the code to solve his problem. This early experience made him realize limits of non-free software was a social issue.

Importantly: it was never about cost. It was about the rights of users of software. It's just that the particular rights that GNU was concerned with also makes it challenging to have a moat on monetizing the resulting software.

This is acceptable for highly specialized software with hundreds or even dozens of installations (like some mega-CAD systems). It should rather not be the case for smaller-time, widespread tools. It just doesn't work well, like the maker of Skip noticed. It stunts the development of the tool, making it impossible to meaningfully contribute.

With that, I'm all for paying open-source developers: via donations, sponsorships, hiring them for contract work, or full-time. I'd like this to be a socially accepted norm, expected behavior for corporations, but not a legally enforced requirement.

Aren't we in the middle of literally the entire industry adopting 200/mo AI subscriptions? It seems to me like engineers will absolutely pay for tools if they justify their value.

And note that the article points out two other hurdles / drawbacks to adoption - their product required a subscription and developers are unwilling to commit to product from a small company that they fear may go under.

If you are a budget approver then your inbox and calendar are full of sales teams.

I find that experience is too distracting to concentrate on writing good code.

Just ignore the most widely used operating system!

When I've paid for tools, it tends to be a tool that was free for me to start using, that is now part of my workflow and I love, and I am worried it won't continue to be maintained or updated so I pay for it.

If a tool requires payment, someone is gatekeeping access to that tool. Even if prices and terms seem reasonable today, there's no guarantee that they will be in the future.

- repeatedly changing UIs in often deleterious ways - wasting my/CPU time on analytics and engagement - upselling tactics - focusing on making the most money, not providing the best tool - preventing or making difficult the use of old versions - reducing customization for the sake of reducing customer support or branding - preventing me from making minor tweaks to code that would improve or fix something

In some book about behavioral economy there was a test with people in company kitchenette.

Above the coffee machine, there was a sign asking people who drink coffee at work to contribute to a jar for the next cpurchase. One sign was just text, while the other was also made with eyes. The one with eyes raised more money.

This is just plain false. The total software and SaaS tool spend at every company I’ve worked for in the past decade has been incredibly high.

Developers also commonly bring their own paid tools when it’s allowed: JetBrains is common. Many people have paid Git GUIs or merge tools.

I think the hard truth is that getting adoption on a new paid tool is really hard, especially when you’re not sure if it’s even going to be around in a couple years.

When there are open source alternatives it’s usually not about cost. We’d happily pay for something that was higher quality and helped us develop faster if it didn’t come with its own set of risks. The difference is that OSS is something we can pick up and carry along with the community even if the maintainers go a different direction. We don’t have to worry about sudden license price increases or unfavorable terms appearing at renewal time, which happens constantly now.

So many developers have seen the rug-pulls and exploitation of non-free tools. Build on Oracle and your company will need to hire more lawyers than developers. Even in less-exploitive situations, we've seen a lot of situations where things become many times more expensive. Google AppEngine moved from charging based on usage to charging based on instance hours and some people saw their bills go up 10x. We saw the Unity price increase which proposed a runtime-install fee. We don't want to build off an ecosystem where we have no idea what the pricing will be going forward. We don't live in a world where we can just remain on an old version via a perpetual license. Security vulnerabilities will require upgrading at whatever price a vendor sets for the new version. Incompatibilities with changing environments (like iOS/Android upgrades) will mean having to pay for upgrades at whatever the new price is.

We've seen so many proprietary dead-ends where we invest a lot of time and money into a platform and then poof it's gone. You don't want to have 10 devs spend a couple years building with a tool that just disappears on you. Something small like Skip could easily run out of funding. This gives you a chicken-and-egg problem: you can't be proprietary unless you're huge, but you basically can't get huge at this point unless you're open source because no one will choose you. Skip was ejectable. It was generating Kotlin so you could just start developing two separate codebases in the future, but if you want a cross-platform toolkit and you're worried about a dead-end, you're just going to choose Flutter or React Native or something.

We also don't want a situation where devs are waiting on a vendor. With open source, I can go in and fix something at my company and put in a PR. Even if the PR doesn't get accepted for a while, we aren't stuck.

And it's not just developers. If I'm working at a company and I want to use a paid tool, I'm going to need to get approval for that which can just be a pain. Higher ups are going to want to know that we aren't going to get a rug-pull in the future. Skip was $1,000/year per developer, but that could change in the following year. Companies have gotten rich by offering you a good deal, locking you into their ecosystem, and then raising prices. Higher ups are going to want answers that don't really exist.

Finally, it's hard to know whether something is any good without putting a decent amount of time into it. We often learn things because they're free toys we can play with. I make something fun in my spare time with a free tool and I've learned something new. But I don't want to do that with something proprietary where I might have to deal with licensing. Yes, sometimes there's exceptions for non-commercial use, but sometimes the line is blurry on that - what if I have a tip jar. We don't want to deal with that.

A development kit like Skip isn't a hammer. A hammer will continue to be a hammer even if the company goes out of business. When we're choosing tools, we're not just making a bet on what it is, but also what it will be in the future. If it's going to become abandoned in the future, it'll be a lot less useful. When you're comparing tools at a hardware store, you might not make the best choice, but you aren't going to find out 18 months later that your hammer is incompatible with all nails going forward. You're also generally only out the price of the hammer, not out the price of the hammer plus 18 months worth of work that you need to redo.

I’ve paid for 2 text editors, that I used personally, but also took it to work. Now I use VS Code, because the company essentially mandated it with the way they rolled out GitHub Copilot and wanted to see metrics on it. This pushed me to VSCodium at home, so I don’t have to live 2 different worlds.

I paid for the font I use in my editor, I assume that’s not something that will get flagged.

Transmit (from Panic) and Kagi are the other two things I’m using at work with my personal account. I keep waiting for them to randomly stop working one day.

Getting an actual license for software through work, that isn’t already approved, requires so much bureaucracy and red tape; I don’t even know where to begin.

I sometimes daydream about working for myself or a small company, where I can use whatever I want.

I only buy licenses of software I can download the offline installer of; and a one time fee (per version is fine).

I'm gonna pay for work. I'm not gonna pay for copy of some bytes. Especially not because lawyers say so.

Figure out a business model that doesn't require you to put a policeman behind my back to make it work. It's not that hard. Steam has one. GOG has one.

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

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

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.

   > This fundamentally does not work for anyone with more than 10M+ installs just like you can't write Mandarin and English in one script.

Well, I did work on a Flutter app with a tiny team between 2018-2021 and we had 15M installs, were app of the day, got featured multiple times in the App Store, got Google’s design award, were a preloaded app on iPhones in Apple Stores in several countries, and were overall doing quite well.

It was a very focused app though, so the size of our codebase didn’t really grow with the number of installs.

[0] https://shopify.engineering/five-years-of-react-native-at-sh...

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

Independent UI frameworks like this don't stand a chance in closed source form if the main competition is all free and OSS, widely used, and high quality.

Interestingly, they went for LGPL 3 here. Nothing wrong with that as an OSS license. But I don't think it's the best license for the job here depending on their intentions. This might actually limit the enthusiasm of people to jump on this. At least they didn't go for AGPL 3 here. That would be a show stopper for many companies. Not much better than just flat out requiring a commercial license.

However, if you want to go all in on free and open source for commercial usage by whomever, probably a permissive license provides the least amount of friction for that. Since it just explicitly allows and encourages that sort of thing rather than attempting to constrain it.

If your goal is wide adoption and supporting a diverse community of contributors that are getting paid through their day job to work on this, that's generally what works best. Most of the mainstream UI frameworks are under licenses like that and for good reasons. SwiftUI, Flutter, Compose Multiplatform, React and React Native, etc. are all licensed permissively. There's a rich ecosystem of independent component and tool developers around those frameworks using similar licenses. Lots of competition as well; this is a very competitive space.

Permissive licensing is what enables ecosystems like that to form. And whether Skip likes it or not; that kind of is the competition. That's where most of the OSS developers are. Developer communities that include developers from companies that commercially depend on the software are stronger and more resilient long term. Building such communities is hard work. Unfortunately, that usually means letting go of being in control.

Small OSS companies tend to be conflicted between their own needs (monetization, protecting their IP, VC interests, etc.) and the needs of the user and especially developer community (unencumbered usage, freedom to adapt and use, etc.). That's all understandable and easy to sympathize with. But it doesn't change the reality of users and developers voting with their feet and mainly using permissively licensed stuff. Because it's there and it works. Also, diverse communities mean that is likely to stay that way. It's a thing I look for in OSS stuff I choose to use.

You're comparing the efficiency of the app that Skip produces, and the development environment (which is Xcode and Android Studio).

And you are comparing the cross-platform capabilities of the apps you can produce with Skip with the cross-platform capabilities of the development environments (which are still just Xcode and Android Studio).

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.

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.

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.

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!

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