▲ 515 points
back
226 comments
I read appeals here asking developers to please pay for their tools. I would like to point out that collective behavior cannot be changed by appealing to individuals.
Furthermore, it is the employer's responsibility to provide tools for employees. I'm not going to get into a tug-of-war with my employer over this. I simply work with the tools I am provided.
For self-employed individuals and companies, this should be regulated by the market. If competitiveness correlates with the use of the right tools, the problem should resolve itself. If this correlation does not exist, then it is questionable whether these tools have any added value at all.
If this market mechanism does not work properly because Big Tech systematically undermines it, then it might be appropriate to consider whether this could (or could not) represent a more far-reaching social problem and what solutions there might be. If you go down that route (which I would advocate), it very quickly becomes very political. In any case, it should be clear that this problem cannot be solved by simply shouting at developers: “Pay for your tools!”
What complicates matters further is that our work requires more than just tools in the narrow sense. The entire stack, down to the compiler, web server, and ultimately the operating system and operating system kernel, is based on countless hours of unpaid human labor. On the one hand, it would render us incapable of acting if we were to economically quantify this entire value chain like Diocletian and then insist on slapping an appropriate price tag on it. On the other hand, there is no justification for why we should only do this with the tip of the iceberg that we call tools.
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.
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.
Tried using Flutter a year ago to make a simple Mac app. I don't think it was ready at the time. Also poor documentation.
https://github.com/skiptools/skip
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.
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
> 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!
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.
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.
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.
Software tools are not really tools like a knife. They are more like cooking recipes.
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.
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.
On the other hand, we're the only high paid workers that provide so much work for free through open source. Sure, there's lawyers and doctors that do the occasional pro bono, nut nothing on the scale you find in software development.
At previous companies, I was more than happy to use corporate money to pay for software I believed in. Tools like Hashicorp Vault were certainly worth paying for the Enterprise tier. What stopped me was climbing over huge bureaucratic hurdles cause someone at the company already spent millions on CyberArk which no one wanted to use and convincing anyone to spend a few thousand on anything else was out of the question. It’s not that devs don’t want to pay for it.
This is a wrong framing. I don't want to depend on anything fundamental that would be limited by my ability to pay. The problem is not the money, but the enforcement, the licensing. It usually implies closed source, problems provisioning (a separate license for CI/CD?), and ultimately stuff like hardware crypto keys and online checks.
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.
> some of the most highly paid workers on the planet won't pay for tools
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.
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.
Here’s another perspective. Developers aren’t budget approvers in engineering organizations by choice.
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.
I love the lowkey vibe that if you want quality software, you either have to pay for it or wait for FAANG money.
Just ignore the most widely used operating system!
"At least 32GB of memory is recommended for development with Skip."
Dear lord, what?
This is great news and hopefully makes SwiftUI more feasible as a long term cross-platform UI option.
What would be great is if Apple started working with and contributing to this toolset.
What would be even better is if Apple then open-sourced all (or at least some) of their SwiftUI implementations.
What would be amazing is the community can then takeover some of the issues in SwiftUI – especially on macOS – and help to make it more flexible, feature-rich and comparable to UI toolkits like AppKit.
A good, cross-platform, Swift-based UI toolkit would go a long way to ensuring increasing and enduring cross-platform Swift usage.
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?
This is amazing! Thank you for open sourcing the project. It must have been a hard decision.
There have been several iterations to have a unified way to build Android and iOS apps.
- using HTML
- using JavaScript
- using JS+React
- using Dart
- using Kotlin
- using Swift
This only works for devs who over time churn out as their app fails or becomes too big [1]
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.
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.
I just started to learn Kotlin, how does it compare with Kotlin Multi Platform for those that used both?
This is great for Skip users, but I'm curious how they plan on monetizing for long term sustainability. Donations are notoriously not sustainable and if they weren't able to get enough in license fees before, I don't see how they will get more donations in the future. Unless the plan is that by increasing the user base, the product will get significantly better so that even if there's a smaller percentage of donators, they will end up contributing more in total.
If I use Skip to make a cross-platform app, will TalkBack be able to read it to users as well as VoiceOver?
How is Skip’s support for building apps with maps or other more complex UIs? Can I build map overlays that work cross platform?
I've never quite found the right cross-platform phone dev setup before, so this piqued my interest a little.
Skip requires a macOS 15+ development machine with Xcode 16.4 or later installed.
With no additional managed runtime, Skip apps are as efficient as they can possibly be on both platforms.
At least 32GB of memory is recommended for development with Skip.
> 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.
But everything eventually goes to waste.
Can you please stop assuming that everyone knows your randomly named niche software and use a more descriptive title for your posts? Much appreciated.
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.
Reading about how Skip works made me wonder: how long until we can reliability code only for one platform (e.g. iOS, but also even web) and then have AI agents that translate the code to all the other platforms in truly native code and UI (Swift, Kotlin, etc.)?
I'm interested in the subject but I've never heard about someone actually using Skip. Can someone share his experience, like how long it takes to get an Android app from a working iOS project. What kind of work is needed here?
How is Skip compared to Jetbrains Compose and MAUI/Avalonia?
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.
is there product level app that handle really "complex" interaction or somebody really use this (other than template project in example gallery)
because after experiencing flutter/RN, crossplatform framework/tools really hard to get right and this is with fb and google resources btw.
sometimes you must really deep in shit and realize that you make mistake to choose these technology
Does it support MacOS as well? I didn't spot any explicit statement about that but I guess SwiftUI should support that automatically.
What big/famous apps are using Skip?
Welp atleast they make it more easier for us non-Apple Developer to make an App