> The plain truth is that developers expect to get their tools free of charge.
This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession.
Folks, if you can afford it, please pay for quality software, instead of relying on FAANG and VC money to keep the tools going!
To be completely fair, this becomes significantly less mystifying when you trace back the origins of the free software movement...
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.
The fewer proprietary abandonwares are in my dependencies the more I can actually do things. It's less about the price and more about the freedom.
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.
If it's GPL, it's not really source-available anymore. The dual licensing thing is more to give big companies a cheaper way out than bothering their lawyers.
Me personally, I treat source-available roughly the same as proprietary. I fix bugs in other people's code as suits my needs, and source-available is just hostile to the whole idea of anyone else touching the source.
Personally, probably not, although I would be more likely to than if I couldn't access the source.
I just don't have a good history with software created and sold by a company. Their incentives rarely seem aligned with mine, and I have had too many rug-pulls to fall for it again.
Companies that start out with sensible and open policies too often struggle to make money, and then end up trying to pull back on their openness and suddenly important bits aren't able to be modified or controlled by the user anymore.
> Would you pay for source-available products? GPL and paid license?
I'm not GP but I would at least consider it. I say that as someone who refuses to build on closed-source tooling or libraries. I'd even consider closed-source if there was an irrevocable guarantee that the source would be released in its entirety (with a favorable open source license) if the license/pricing terms ever changed or the company ceased to exist or stopped supporting that product.
> Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?
I like that for personal tools but I wouldn't build my products or business on top of those. I've had too much trouble getting old binaries to work on new OS versions to consider these binaries to be usable in the long term.
The highest quality tools in the software development space tend to be FOSS, because unlike any other field, we are employed in the field that makes the tools our field uses, and distribution and manufacturing costs are zero.
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.
That's because open source tools are way better for software developers.
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.
But, as the article points out, developers do pay for the tools indirectly - "First-party IDEs like Xcode and Android Studio, popular integration frameworks, and essential dev tools are all given away at no (direct) cost. The platform vendors monetize through developer program fees, app store commissions, and cloud services. Framework providers typically monetize through complementary services."
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.
Paying for things that aren't worth it is noble, but not good economics in the long run. If people want to buy a tool not for what it produces but for the story it tells, this is fine. But just like startups need product-market fit, tools also need product-market fit, and if no one is buying, it could simply be that the alternatives are suitable replacements.
I agree. When people bemoan the death of lisp machines and RAD and whatnot, remember that we deserve it. We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this.
This is a welcome addition but why should Flutter devs use this ?
Seems like it requires 32gb of ram! Also Flutter is already very mature and can produce not only near-native mobile apps (the difference is almost negligible) but can target desktop and even web applications.
I do wonder how much of a boost skip offers vs Flutter's mobile apps. Will give skip a try when dram prices normalize.
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 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.
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 re-generates the entire layout every tick and diffs it (immediate-mode), like a game engine. If your device isn't quite fast enough it'll lag, yep. RN is retained mode (but written in immediate-mode style and the diffing only happens when it has to).
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.
And are comfortable making a 1-2 million dollar per devteam per year bet that Google won't rug pull you. And they seem to have no important or big app on it.
On an unrelated note, in 2024 Google did layoffs on the Flutter team.
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.
In general, the "render UI as if it were a video game" route feels like a bit of a dead end on mobile to me. On desktop it's more workable but still isn't without issues.
This is cool, but there is no LICENSE file putting this in DONT USE territory.
This has a license: https://github.com/skiptools/skipstone but it vendors the other repo according to the readme? I am super confused about how this would work.
Huh, what does one have to do to comply with the LGPL on iOS anyways?
I'm sort of surprised that only the largest plan ($5000/month) and not the ($10/$500/$2,500/month plans) includes a license that doesn't involve figuring that nonsense out.
As I understand the LGPL - not a lawyer - you have to somehow enable all your users to relink your application against a different version of Skip (4.d.0 since 4.d.1 isn't possible on iOS). This means that your application must do something like include a copy of all the files that went into linking the application and convey that to the users along with your application, with scripts to build the application against a different version of Skip...
I can't imagine the app store would be particularly amused with this during app review... though I've never tried.
This is great news, thank you. I have been looking into a way to port Soundscape Community [1], a navigation app for the blind to Android without having two codebases to maintain. Skip looks ideal; I was planning on asking you about licensing for a very small team with almost no funding.
Someone else already asked about talkback accessibility; I assume it will work because it translates to native UI controls on android. Is that correct?
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.
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.
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.
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.
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.
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.
> 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!
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.
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.
Thank you for making it open-source (and free!) I looked into Skip before because I’d rather write native Swift than the in-between tangle of code that React Native tends to become. What prevented me from using it was the lack of case studies or apps in production. Has that changed? I looked on the homepage and couldn’t see any. Of course, I understand it might be a growing community and targeted to early adopters for now.
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.
Interesting. I used Expo recently and loved the development experience. I also built a simple iPhone app with Swift, and it was a decent experience. I have plans of building another iPhone app and was considering Swift again, which would make me miss building an Android app, but maybe Skip would allow me to do it anyways.
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.
Small views don't solve this for human use either. The only solutions for fast builds are to stop using SPM and also to adopt the "microfeatures" pattern with interface stubs and dependency injection so that very little must be rebuilt/linked. This is a huge change for many projects and carries ongoing development maintenance overhead so it is not a trivial decision to make.
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 wish there are something for SwiftUI on Windows. I meant to support Windows for Draw Things, but the opportunity cost is too high without proper UI tooling.
The reasoning for making this choice was refreshingly sober and clear-minded. If there was anything that would help tooling reach critical mass, it's turning it into OSS.
I've built with Flutter and React Native a few times over the years, but I will give Skip a go in my next project, I've heard a lot actually.
> The plain truth is that developers expect to get their tools free of charge.
I've run into this too with my own app. I thought people would like a Lua GUI framework that's professional grade and gives you full access to WinAPI via Lua. I was using DragonRuby as my model.
So I wasted a thousand hours making the app and its documentation. Turns out, even after people understood what it was (I suck at marketing), everyone still agreed that whatever it could become or ever evolve into was still not worth a dime.
Now I'm faced with a decision. Do I open source it? I think, no. 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.
Then, should I open source it altruistically? What for? First of all, giving things away for free is not inherently good. One negative side effect is teaching people not to rely on their own industry. Another is that they may use it for evil. And then, it feels like such a waste to let the code die out.
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.
> 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.
>most people are not experiencing career-ending levels of performance from LLMs.
You don't have to. Experiencing increased competition for jobs or lower pay for the same job (because less devs are needed for the same level of output) is just as bad.
Experiencing increased competition for jobs or lower pay for the same job (because the AI industry imploded and the devs from that industry are now in the market) is just as bad.
The rise of companies you might end up where some/most the codebase or db schemas were vibe generated is just as bad. LLMs are the new VB6. At least, with VB6 the initial complexity of the apps would be limited by how much the cowboy coder could handle (ie. not infinite). With LLMs that limit is an order of magnitude higher. I expect many of the future legacy apps to be dangerous jungles of vibes many contractors will be urgently hired to immediately fix when things begin behaving weirdly and the causes of the issue are hidden somewhere in the jungle.
Any of the above is bad enough on its own, let alone combined. I strongly believe two of the above will happen within the next 5 years.
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.
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!
This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession.
Folks, if you can afford it, please pay for quality software, instead of relying on FAANG and VC money to keep the tools going!
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.
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.
Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?
Me personally, I treat source-available roughly the same as proprietary. I fix bugs in other people's code as suits my needs, and source-available is just hostile to the whole idea of anyone else touching the source.
I just don't have a good history with software created and sold by a company. Their incentives rarely seem aligned with mine, and I have had too many rug-pulls to fall for it again.
Companies that start out with sensible and open policies too often struggle to make money, and then end up trying to pull back on their openness and suddenly important bits aren't able to be modified or controlled by the user anymore.
I'm not GP but I would at least consider it. I say that as someone who refuses to build on closed-source tooling or libraries. I'd even consider closed-source if there was an irrevocable guarantee that the source would be released in its entirety (with a favorable open source license) if the license/pricing terms ever changed or the company ceased to exist or stopped supporting that product.
> Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?
I like that for personal tools but I wouldn't build my products or business on top of those. I've had too much trouble getting old binaries to work on new OS versions to consider these binaries to be usable in the long term.
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.
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.
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.
Seems like it requires 32gb of ram! Also Flutter is already very mature and can produce not only near-native mobile apps (the difference is almost negligible) but can target desktop and even web applications.
I do wonder how much of a boost skip offers vs Flutter's mobile apps. Will give skip a try when dram prices normalize.
> 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
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.
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.
On an unrelated note, in 2024 Google did layoffs on the Flutter team.
Literally every iOS developer under the sun will tell me that this is a good thing.
I certainly don't think having my app sticking out like a sore thumb, using a design language from old outdated iOS versions is "a good thing"
This is cool, but there is no LICENSE file putting this in DONT USE territory.
This has a license: https://github.com/skiptools/skipstone but it vendors the other repo according to the readme? I am super confused about how this would work.
Thanks for pointing out that the /skip repo itself doesn't have a license. We'll fix that asap!
I'm sort of surprised that only the largest plan ($5000/month) and not the ($10/$500/$2,500/month plans) includes a license that doesn't involve figuring that nonsense out.
I think it’s fair to milk enterprise companies that can’t read a FSF license. Otherwise the LGPL is fine.
I can't imagine the app store would be particularly amused with this during app review... though I've never tried.
Someone else already asked about talkback accessibility; I assume it will work because it translates to native UI controls on android. Is that correct?
[1] https://github.com/soundscape-community/soundscape
You can see a sample snippet at https://skip.dev/docs/components/accessibility/
Dear lord, what?
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.)
For framework/library development, you can of course build and test separately for each platform.
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.
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!
Have a nice day skip team!
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.
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.
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?
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.
What are your thoughts on it?
Still, assume people are using TalkBack and don't take reports from anything else, it'll prevent you from going insane.
Small views don't solve this for human use either. The only solutions for fast builds are to stop using SPM and also to adopt the "microfeatures" pattern with interface stubs and dependency injection so that very little must be rebuilt/linked. This is a huge change for many projects and carries ongoing development maintenance overhead so it is not a trivial decision to make.
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
Are you sure about that?
https://code.cash.app/native-ui-and-multiplatform-compose-wi...
However it seems like it could be a good basis for such a project.
I've built with Flutter and React Native a few times over the years, but I will give Skip a go in my next project, I've heard a lot actually.
I've run into this too with my own app. I thought people would like a Lua GUI framework that's professional grade and gives you full access to WinAPI via Lua. I was using DragonRuby as my model.
So I wasted a thousand hours making the app and its documentation. Turns out, even after people understood what it was (I suck at marketing), everyone still agreed that whatever it could become or ever evolve into was still not worth a dime.
Now I'm faced with a decision. Do I open source it? I think, no. 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.
Then, should I open source it altruistically? What for? First of all, giving things away for free is not inherently good. One negative side effect is teaching people not to rely on their own industry. Another is that they may use it for evil. And then, it feels like such a waste to let the code die out.
But everything eventually goes to waste.
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.
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.
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.
You don't have to. Experiencing increased competition for jobs or lower pay for the same job (because less devs are needed for the same level of output) is just as bad.
Experiencing increased competition for jobs or lower pay for the same job (because the AI industry imploded and the devs from that industry are now in the market) is just as bad.
The rise of companies you might end up where some/most the codebase or db schemas were vibe generated is just as bad. LLMs are the new VB6. At least, with VB6 the initial complexity of the apps would be limited by how much the cowboy coder could handle (ie. not infinite). With LLMs that limit is an order of magnitude higher. I expect many of the future legacy apps to be dangerous jungles of vibes many contractors will be urgently hired to immediately fix when things begin behaving weirdly and the causes of the issue are hidden somewhere in the jungle.
Any of the above is bad enough on its own, let alone combined. I strongly believe two of the above will happen within the next 5 years.
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!