hckrnws

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.

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

Flutter's grim outlook? It's being used more now than ever before, with both enterprise use as well as 30% of all new free iOS app store apps are now using Flutter.

https://shorebird.dev/blog/flutter-not-dead/

Flutter is undergoing a major refactor where they're decoupling Material and Cupertino into separate packages. This is the reason why they're not implementing those new conventions right away. The way you've framed it is pretty disingenuous.

> Flutter isn't going to be implementing these new interface conventions

To be fair reading those updates it sounds a lot more positive than this comment makes it seem. I.e. "they're pausing design updates while they figure out the best way to do it" rather than "they're not going to bother":

> This strategic pause on design updates gives us the space to ensure the long-term health and maintainability of Flutter's design libraries. We are committed to being transparent with our contributor community as we explore these options and will have more to share on our findings and future direction in the coming weeks.

and

> The material and cupertino libraries are being decoupled into standalone packages to accelerate feature development. All new work for iOS26 updates in Cupertino will happen in the new packages once established in flutter/packages.

Well sorry. But Android UI is bad just bad. The settings, the menus. Its bloated and almost as if they deliberately made it annoying to use. It just sucks.

Have you seen iOS or macOS settings, like ever? Especially on macOS, the UI is infantile, you have settings in different menus that change each other (mouse / touchpad scroll direction, two buttons in two menus, they change each other). On iOS you have amazing features like a wheel spinning forever without telling you there is a problem and what it is (like, for an app with in-app purchases, you must have a payment configured, otherwise the app installation just spins forever).

Compared to that, my (OxygenOS version of) Android UI is pretty good, concise, flexible and customisable if I want to. I hate the ambiguity of gestures, so I keep the buttons for navigation. I don't want everything splattered on the home screen, so I use a different launcher than the default. The menus are all logical.

[flagged]

It's a valid opinion. People can have opinions and also not be "in a cult." I would say this default response is rather cultish in its own right by your own use of the word.

Maybe go back to reddit. thats the place for cult obsessed ones.

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

That is absolutely not true. Elements with dirty layouts are tracked and layout is only recomputed up to the neearest layout boundary.

Interesting, I didn’t know that it was immediate mode. According to the article [1] though, it now uses rendering engine with Retained Mode due to performance issues.

[1] https://medium.com/@0s.and.1s/flutter-part-iv-skia-vs-impell...

ah neat, so they rewrote the rendering engine in C++ and exposed it via Dart APIs, as opposed to everything being in Dart.

It has been like that since the very beginning (sky engine).

I'd say it's the opposite, on crappy devices, Flutter feels faster than native, not sure how but that's the end result. I've been testing on an old Samsung J3 and it's definitely better than native.

That's also maybe why it's so popular in India.

Flutter is essentially a game engine so it bypasses the typical cycles involved with native widgets and there are several different ways why Flutter works well on lower end phones

I've noticed several of the apps that don't respect device animation settings were built with Flutter. Not sure if that's a limitation of it or if the developers culturally don't bother.

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 doesn't use Skia anymore and you can absolutely bind to native libraries from Flutter with ease [0]. The current strategy (build hooks) is relatively new. You can also just write Kotlin or Swift for your application [1] using channel APIs. Finally, you can still have native pages in your app if needed for certain widgets [2] and still save time rewriting everything and all of your business logic for every single other page of the application that doesn't need those widgets. In fact, you can even mix native widgets and Flutter-rendered widgets in the same screen.

[0]: https://docs.flutter.dev/platform-integration/bind-native-co...

[1]: https://docs.flutter.dev/platform-integration/platform-chann...

[2]: https://docs.flutter.dev/add-to-app

What?! Flutter is literally a game engine, its faster than native even on older phones and pretty much most of the issues you are talking about is old news lol

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.

https://shorebird.dev/blog/flutter-not-dead/

Also, the layoffs were for infrastructure engineers who were working on Flutter builds not actual core Flutter devs. And the layoff was just an offshoring, they moved the same jobs from the US to Europe.

That sounds like the worst parts of native dev + PWAs combined

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.

> Flutter still doesn't support liquid glass on iOS

Literally every iOS developer under the sun will tell me that this is a good thing.

Why? I'm an iOS developer and, while I don't love everything about liquid glass, that is the current design language of iOS.

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"

No. I’m an iOS developer and will not tell you that, except to say it’s a good thing to have one more reason for the people not to use flutter.

That’s not a good thing if you don’t adapt liquid glass. I’m an iOS developer.

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.

I've heard bad things about liquid glass and plan to skip that OS release, so not implementing it seems like an advantage from my perspective.

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.

> 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 highest quality tools in the software development space tend to be FOSS

> People build tools that they want to use, then share it with others because it's free to

This maybe sounds true on the surface, but isn't really? Prior to VSCode, Visual Studio was the most-used editor by professional developers for a very long time, with Sublime Text and Jetbrains' IDEs being close behind, and the paid options are still among the most popular. While VSCode is wildly successful, and has completely unprecedented adoption rates, it was not borne out of people "building tools because they want to, then sharing it because it's free", but is rather the result of Microsoft's calculated gamble that open-source would give them more ecosystem capture and useful data through telemetry in the long run.

> 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"

This shouldn't really be true if software developers would think rationally about tools for three seconds. I believe the US median compensation for developers is approaching $200k? Any tool that saves a single hour of productivity is likely paying for itself, maybe two or three for the more expensive ones. Something that saves 40 hours of productivity is basically worth its weight in gold. You might be able to say "I can build this myself", but can you build it yourself in 1 hour? 40 hours? For most software, it would still take even longer than that. If you are a paid professional, and value your own time anywhere near what your employer does (I personally value my time more than any employer ever did), you should be extremely grateful for any opportunity to spend trivial sums of money in a way that allows you to reclaim hours to use in other ways.

I've been programming since ~1999 and anecdataly don't remember programmers having a culture of paying for their dev tools. On linux everything's free, and on windows I've used a plethora of freeware IDEs/compilers/etc. from turbo pascal, dev c++ (that's the name of it), later on eclipse took the stage in it's buggy mess and right before vscode there was atom. The only people that I know that used visual studio either got it for free for being a student/teacher, had their job pay for it, or most commonly: pirated it.

According to this[1] site visual studio had a 35.6% marketshare, tied at #1 with notepad++.

[1] https://asterisk.dynevor.org/editor-dominance.html

> or most commonly: pirated it.

Yes, I'm aware. That's the problem elucidated in the article. Developers expect everything for free, even though the price of tools relative to what they get paid to deliver products using those tools is completely trivial. This reluctance to pay for anything harms developers themselves most of all. If developers normalized a culture of paying for things they use, more developers would be able to develop their own independent software and sustain themselves without being beholden to $awful_corp_environment to pay the bills. But because developers will do anything they can to avoid paying <1 hr salary for a tool that saves them many hours, there is a huge gap between corporate professionals, who make lots of money, and open-source developers, most of whom make almost nothing, with only a relatively limited subset of independent developers able to bridge the gap and make a living producing good, non-corporate-nightmare software.

I'm pretty pro-piracy for students and such. It is an extremely good thing for learning to be as available as possible, even to those in poverty, so that they can make something better of their situation and contribute more to society than if they were locked in to low-knowledge careers solely by virtue of the random chance of their upbringing. But people who make a living off software development never graduate from the mindset of piracy. Even for open-source software, the vast majority of users never contribute to funding those projects they rely on. If we think open-source software is good for the world, why are we so opposed to anyone being able to make a living creating it? The world's corporate capture by non-free software is a direct result of our own collective actions in refusing to pay anything for anything even when we can afford to.

As heavy Borland user I am quite sure none of their software was freeware.

Yes they had educational discounts, but that was it.

Turbo Pascal was not freeware when it was new.

It did have a remarkably low price, though - less than a tenth of UCSD p-System or Topspeed. Even the competitors in the hobbyist space like the original IBM/Microsoft Pascal and DRI's Pascal/MT originally cost 4-5x as much.

Really, it was responsible for as big a step change in pricing of programming tools in the 1980s as GNU, BSD, and Linux were in the 90s.

True. I never paid for it myself, but I think i got it from my uni. I had some of my fondest coding memories with it

While many hobbyists developer market, like the hobbyist graphic design market, pirated their tools, the corporate market did paid for their tools.

The issue here is that they the developers aren't convincing their companies to pay for libraries now, partly because a lot of the tools are now free.

The pain process and paperwork to obtain a license for anything in a corporate environment is usually the biggest factor imho.

Well, I've been programming since 1986 and I had to buy all the compilers I used. For the Mac: Lightspeed Pascal, Lightspeed C and Metrowerks. I wish I had the money to buy MPW. Linux then was just a glint in Linus's eyes. We didn't have the internet with easy access to pirated software. I didn't do BB's so I don't know about that area. Once I went to uni in the 90's I started using Usenet but even then I didn't download any pirated software. Microsoft was virtually giving away Visual Studio/Visual Basic to University students. Back then I also remember reading Linus' arguments with Tanenbaum over microkernels and this funny language called Python and its creator unveiling/supporting it on Usenet. Around that time more and more tools were being offered for free and as a poor student I was delighted. Also we got access to free Unix tools since as we were doing work on Unix systems. Oh yeah, I remembered using this cool functional language called Miranda in one of my courses but was sad that it was a paid product. And then I heard about the debut of Haskell which was sort of a free answer to Miranda.

I remember paying something like $400-500 for Glockenspiel C++ for MS-DOS, which was based on AT&T's cfront and compiled to C code. Not long after that, Turbo C++ and Zortech C++ made things a lot easier, since they didn't compile through C, like cfront did. Those were in the $150-200 range, iirc. I also remember paying for PC-YACC from Abraxas, something like $400.

Back in ye olden days, prior to teh interwebs, compilers were not free and it was an assumed price of entry to programming. Pirating has always been a thing, but I've paid for more than one compiler in my life and I wasn't exactly flush with cash.

As a hobbyist programmer I make precisely zero dollars a year so paying for my tools only makes sense if they increase my nonmonetary enjoyment. As an employee I have very little power to convince my company to buy a certain tool and I tend to prefer the tools I‘m already familiar with from my hobby.

Equipment for any real life hobby costs money, and people are willing to pay for good equipment. Why is software so different? FOSS has made us so resistant to paying for good software. I'm not saying software has to be expensive, even $20 per major version could make a burgeoning indie industry thrive.

I believe that there is a difference between developers as persons and developers as employees.

As a person, I don't think that I am very likely to pay for the tool I use to develop in my free time.

As an employee, I need to convince my company to pay for the tool. If it is a subscription, that's even worse. So well-known ones like Microsoft tools might already be approved, but for not-so-famous ones, it's harder.

If I want to depend on a third-party library/tool, I need to convince my company that the licence is fine, that the security is fine, and if it's not free I need to convince them to pay for it.

Back when MSDN subscriptions where a thing and people still used Visual Studio, the tools were a lot better. Debuggers worked and did impressive things (time travel debugging! Rewind your entire program state! Step through from your website code all the way to your database queries within the same debugging session! Easily debug remote servers!). Developer documentation was professionally written and edited.

Now everything is free and we get what we pay for.

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

But the rest of the economy doesn't work like this, so support your OSS projects financially.

Very true. On immich, I've always wanted a way to do certain operations locally like adding to an album before the photo/video is fully uploaded, but I'm not frustrated that it's not possible because if I cared enough I'd create a pull request. For features that Google Photos is/was missing, I'm not as generous.

> The highest quality tools in the software development space tend to be FOSS

LLMs are also software and OSS (let alone FOSS ones) aren't even close to the quality of closed models like GPT 5.2 or Opus 4.5.

LLMs are more money thrown at their training than software development, and you need prohibitive costly hardware to run the biggest ones.

Calling some "OSS" is simply misleading.

> distribution and manufacturing costs are zero.

???? citation needed

Once the software is written, it is ~free to copy. People pay a lot of money to avoid the software getting copied... and it gets copied anyways.

The thing is that one software is easy to crack and copy, so it is cheap...but a lot of softwares to work together is not, so that's why we have SaaS and PaaS today.

> you're always going to be competing with "I could build this myself"

Even more so these days with agentic coding

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

Post-AGI economics seems to bring cost of production and distribution very close to zero, so this may soon come to pass. Culture might need a minute to catch up though!

> Post-AGI economics seems to bring cost of production and distribution very close to zero, so this may soon come to pass. Culture might need a minute to catch up though!

People on HN read too much SciFi.

> Manufacturing costs are zero

No. The fact that you built something yourself doesn't make it free to produce.

More over, you __won't__. You simply cannot build all of the things that you could buy at scale. What if you had to write all of your own video games? Or operating systems?

I think they mean cost of incremental units. 0->1 is much more expensive than 1->100 in software, unlike with things like lattes or houses

I assumed that they meant "cost of production", since that's what you give to keep your money, so that includes 0->1. But if what they meant is what you said then I'd say that the cost of 0->1 is not somehow less important. Software does make 1->100 much more accessible though, so, in that way, you have an opportunity to help out very small businesses in a way that you can't in other industries, which is even more of a reason to buy code from your peers, IMO.

I think the comparison to other industries is that while they pay for tools, it's not the inventor of the hammer that gets paid, but the producer of the unit, which in software is ~0. I'm not arguing against paying/donating to FOSS, but I do support the discrete distinction to physical tools.

If the tool is saving you a large chunk of time, then why does it matter what's happening in another industry? We seem to be losing a really simple thread here: Pay for things because they present more value to you than you're giving away in payment.

Y'all seem to have some notion of what constitutes "fair" payment that you're so attached to that you're willing to shoot yourselves in the foot.

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.

Would you pay for source-available products? GPL and paid license?

Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?

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.

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.

I like the analogy. It is not perfect since recipes dont compose much (just a tiny bit) but a good analogy for the discussion.

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.

+1. AI agents can also fix minor bugs easily in open source software (it already did in two of the apps I use).

Paid tools are in my experience much more likely to engage in practices that make them less useful or more frustrating for me, like:

- 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

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.

> Importantly: it was never about cost. It was about the rights of users of software.

The cost (free) got me looking, but the rights, now that's what kept me.

Costs - being a poor student meant I was not ever in a position to pay for products (even those massively subsidised by companies like Microsoft) - there was no way I could buy an IDE, or a compiler, or anything that I needed to /learn/.

Rights - once I had the products, I was able to see how they worked, and, more importantly, make changes that worked for me, and, if desired, share those changes so other people could take advantage of them. None of that was possible under the other licences.

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.

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.

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.

Every company I know is lamenting their out of control SaaS spend for developer tooling.

$200/month/user isn’t a big incremental cost, to be honest. SaaS and subscription tooling costs are high for developers.

It's less a binary pay/no pay, and more the value of accessing the dev tools. If you consider the fact that AI companies are most likely losing money running the models, then AI tools are incredibly cheap - they're in some ways paying you to use it.

No model maker is going to try to generate a profit off users using their models, they're gonna try to generate it some other way - much like dev tools.

It's not that I don't want to pay for good tools. I don't want to invest time and effort into tools that I have to pay for.

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.

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.

This is only true for a subset of software like mobile apps. Web developers are not paying for anything except compute.

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!

What money do you think pays for most of the development of the Linux kernel? I assure you, it is not the altruistic goodwill of people around the world.

How do you think did development of Linux work for the first many years until corporations saw the value Linux is providing? (and developers demanded they use their favorite operating system)

Employees don't pay for tools and usually have no say in which tools are bought. Car mechanics don't pay for spanners, their employers do.

I've paid for tools in the past, but I think there's a difference, the value of a lot of our tools isn't that great, but more importantly, there is a huge cost to adoption. Going in blind on a paid tool, putting in the time to learn and train yourself to use it, that's a high cost for something that you need to pay for entry and recurring after, that maybe 50 hours into it you start to realize you don't like it.

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.

Engineers are happy to pay for tools (hello, Claude Code). Libraries are quite different and it's a little uncomfortable to build a business on a closed-source, proprietary library.

No one pays for Claude Code, they pay a subscription to access the Claude Models.

lmao who even unironcally uses claude code when other harnesses exist that eclipse them ?

The last paragraph is so accurate. Thanks. Just a small note: Developers, add your photo (mug shot) to your code, you receive more money. People do business with people.

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

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.

It's not simply that developers expect to get their tools for free.

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.

Completely agree with you. I skip most of the new tools that come out, because the ones I use already work well for me, and the probability of the new tool disappearing fast is high.

Learning a new tool is a mental effort that makes sense for the seller to propose, but doesn't for me. My mental energy is better spent on my loved ones. It has to be truly revolutionary for me to invest time into it, like the LLM stuff. But otherwise I've been happy with Bash, Vim, JetBrains products and Terraform for a very long while. I don't see any need to change that.

In most lines of work it's standard for the employer to pay for tools, not the worker. If anyone is cheap it's the capitalist bosses.

Companies should be paying for tools not workers.

I’ve paid for a few things for work, but I’m always living a bit outside of corporate rules when I do that. This makes it hard for me to justify if it’s only for work. In other cases, the licensing of the product doesn’t allow me to bring my personal license to work.

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.

Jetbrains

There is a difference between paying and owning a tool, vs paying, and then the tool gets enshittified to hell and becomes unusable.

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

simply put - it should be a B2B biz, not a B2C. B2C is tough, B2C saas is even tougher

I can't find a solid source to link to but the few I found shows that IT and Healthcare tops per employee spend on SaaS. The reality is nobody wants to spend for SaaS.

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.

In other markets, that is called dumping, and it is illegal. And in fact, Microsoft was convicted of being a monopolist and dumping.

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.

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

Not terribly surprising that one of the most true comments is at the bottom. The Stockholm syndrome by devs desperately wanting to believe that bad tools are good is insane.

It's not even hard to see why Worse is Better is just worse - among many other tests, you can look at the number of production-grade systems and popular tools written in Perl (virtually non-existent) and bash (literally zero). Empirical evidence strongly contradicts the core value tenets of the ideology.

Yeah, the downvotes were expected. Developers do not like being called out for the miserly and self-destructive bunch that we are.

I was building an advance IDE for C and gave up when I realised that no one would buy it because "lol vim is free". Finally, I am gathering the strength to resume working on it, but only for personal use and with no expectation of selling more than 100 copies.

What bothers me the most is the hypocrisy. It's okay to make money by showing predatory ads to unsuspecting populace, but not by selling useful tools. No, that is immoral.

Even worse is the entitlement, refusing to pay for the work of others while expecting to be paid for their own.

Hence why I am a strong advocate of dual licensing GPL + comercial, only be allowed to earn as much as willing to give upstream.

I will never pay for anything intellij again. Not because I don't have the money, not because I prefer everything free like a happy little munchkin, but because I loathe them for creating the best IDE for ruby and keeping it paywalled for 10+ years despite java/kotlin and python editors having community versions. IMO it basically killed the language. Now that ruby is uncommon, they released a community edition like a joke.

What killed the language is being so married to Rails that no one else thinks of Ruby in another use cases.

And the performance, that has made people migrate to JIT powered platforms like Elixir/Phoenix on Erlang.

this is simply not true, in tech "free" software actually one of the most expensive software you can buy

> damning indictment of how some of the most highly paid workers on the planet won't pay for tools

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.

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

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.

Which non sense? The lesser GPL doesn’t mean you have to license your firstborn under the GPL license.

I think it’s fair to milk enterprise companies that can’t read a FSF license. Otherwise the LGPL is fine.

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.

The license file linked provides an exception for 4d and 4e:

As a special exception to the GNU Lesser General Public License version 3 ("LGPL3"), the copyright holders of this Library give you permission to convey to a third party a Combined Work that links statically or dynamically to this Library without providing any Minimal Corresponding Source or Minimal Application Code as set out in 4d or providing the installation information set out in section 4e, provided that you comply with the other provisions of LGPL3 and provided that you meet, for the Application the terms and conditions of the license(s) which apply to the Application.

Alright, that’s a fair point.

You aren't shipping the LGPL part of Skip with your app. It's a build tool.

You don't need to worry about using (L)GPL build tools to produce non-GPL apps.

You have nothing to worry about with this license unless you are forking the Skip build tool itself. You can't ship this build tool to the App Store anyway, it's a build tool and not code you run inside your app.

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

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]

1 - https://ashishb.net/tech/react-native/

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

Good for you.

I meant as a general rule of thumb.

Genuinely curious: What does the number of installs have to do with anything? I didn't see anything about that in the linked post (which is brief, and only about React Native), and can't figure out how popularity of an app connects to which framework is used.

Would be interested to learn how this general rule of thumb works.

You said "fundamentally", not as a rule of thumb :)

Fair point. I should have said broadly.

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

In the short-term it can work.

Over time maintenance becomes hard

New iOS and Android features, sometimes backward-incompatible are introduced.

And now, you need your dependencies to implement them. Which might or might not happen. At best, this makes usage inferior. At worst, you can no longer publish an update in app stores.

This app was started in 2017 and it is still running today and making (way more modest than back then) revenue. It’s just that I don’t work on it anymore.

I mean, this is "fundamentally" wrong. Shopify for example continues to use React Native [0].

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

Goodnotes has tens of millions of monthly-active users (not just installs) and uses Swift WASM to run the same Swift code across iOS, Android, Windows, and web.

"At least 32GB of memory is recommended for development with Skip."

Dear lord, what?

Well, you're running both the iOS development tools (Xcode, iOS Simulator), plus the Android development tools (Gradle, Android emulator, and maybe Android Studio too). These add up.

16GB might be possible, though.

(Skip itself doesn't take much memory. If you run it headlessly as a SwiftPM plugin, you wouldn't need nearly that much.)

Do you have to run both at the same time? Because my flow with React Native is to focus on one platform at a time, I don't try to run everything in one shot.

No, you can configure it to just build and launch for iOS or Android separately. But we do recommend iterating on both in parallel for most of the UI work, just to make sure that everything stays in sync.

For framework/library development, you can of course build and test separately for each platform.

And if we're talking Expo, that's only for prebuilds of course; once you've got the native app installed then you can absolutely code and see updates in near real-time on both Android and iOS devices.

Ah, yeah yeah, not meant as slight towards Skip (seems like a cool project). Just me being offended by the plain content of that sentence.

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

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

yep, the pricing is getting ridiculous... on the other hand if you are using that 32gb to make money then its an investment thats worth it imo

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

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

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?

[1] https://github.com/soundscape-community/soundscape

Yes, as I just responded there, Skip uses the native toolkits and conventions on both platforms: SwiftUI on iOS and Jetpack Compose on Android. So you automatically get the platforms' built-in accessibility support.

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

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?

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.

Probably the usual models of offering support, training, and commercial add-ons.

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.

Looks like they will rely on enterprise customers who pay for priority support access.

This is amazing! Thank you for open sourcing the project. It must have been a hard decision.

Thanks! It has been a long time coming.

As we mentioned in the post, developer tools really need to be freely obtainable in order to gain mass adoption. In that sense, it was an easy strategic decision. And we felt that the time was right, given that Skip's benefits are being thrust to the foreground in light of recent developments.

You should really consider why free software exists. Open source is open source, sure, but it is a disservice to your users to ever release proprietary software for any reason.

I personally would not start or run a business that didn’t release all software it builds under free software licenses. We don’t open source it because “developers expect it”, we open source it because it’s the right thing to do by your users.

Free software is an ideology, not just a license.

> 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!

Yeah but if that was the only reason to do open source that was encouraged then there’d almost certainly be a lot less open source software overall (and lower quality). Personally I’d prefer OSS win overall even if it costs some ideological purity.

I don’t open source my iOS apps that provide my living because there are many examples already of others using this to release identical apps without credit or sharing their work back (even with AGPL), which would remove my source of income that enables me to work on it in the first place. I haven’t found a way to make a living off open source yet for the type of products I produce.

I’m not independently wealthy to be able to afford to work for free. If I release my work for free, then I will have to live on the streets or in a cell, or take a job and lose the time I have to produce my work in the first place.

This is indeed a dilemma, but note that copyleft licenses like GPL or MPL do give you considerably more protection than a pushover license like MIT/BSD. I wrote about this last year at https://appfair.org/blog/gpl-and-the-app-stores.

It gives near zero practical protection as the devs that clone in the App Store do not respect licenses and Apple is slow to act (sometimes shutting your own dev account instead of the copycat’s, another high risk).

Enabling copycats also encourages them to target my apps for fake negative review spam and bot activity that gets my dev account (and personal iCloud) flagged and banned without recourse.

I also have no funds to sue someone. And the copycats are often anonymous and overseas in random countries, adding to the challenge of doing anything about it besides begging Apple to help without accidentally hurting me instead.

hey, came from the other comment you messaged me but this feels like such an apple issue which is so fixable that I am not understanding why Apple won't do it.

I understand what you are feeling but I feel like what you are saying is genuine and although sad right now, it provides a course of action for Apple to work upon to meaningfully improve it so that we can get atleast either custom license source available (as I mentioned in my other comment) or GPL/restrictive Copyleft as this mentions.

If someone from Apple's reading this. This feels such a large issue even more than the license issues in general, is Apple working on this or not?

This would honestly show the real loyalty towards developers if Apple can do this so I am waiting and perhaps a movement can be created to establish some formally written demands/ perhaps a change.org petition?

Apple won't improve this out of charity for small businesses. Apple has no real loyalty to developers outside of their largest partners. This requires regulation, and/or mass organizing across developers.

> Apple won't improve this out of charity for small businesses. Apple has no real loyalty to developers outside of their largest partners. This requires regulation, and/or mass organizing across developers.

Isn't there an EU law where if Enough signatures happen they are forced to discuss it in the EU parliament or similar? I remember this from the stop killing games movement iirc.

Mass organizations can take place too but why not a mix of both utilizing both regulations and mass organizations?

AGPL seems like a joke when it comes up against the indie hacker world. Has there ever been an example of an open-source maintainer successfully suing someone who ripped off their codebase without attribution? Doubtful.

Shame that the world has to be like this in the first place :<

Perhaps I am way too altruist at times & the world is capitalist without any discrimination, stealing anyone's work and reselling it feels so scummy and I have heard it happen actually so you are not actually completely in the wrong and its your code and your lifestyle and so I respect it. (Even if I am an open source advocate, I will admit making money from Open source is super hard in many cases)

Interestingly, what's your thoughts on Source available licenses. Like, honestly, like use a license which doesn't allow reusing components or providing another appstore release of that or similar

If you use github actions with immutable and other instances, I feel like there is a real way of like verifying that the code written is safe & people can verify it & trust it.

If people want to modify your product, they have to pay you and get in touch with you.

I will take this with additional security context and being able to audit over having nothing in the first place! (Hopefully I hope this might not impact your living either in any way and honestly even if you do this! Some of us would deeply appreciate it)

Something is better than nothing. If even much of the world goes to source available licenses, I feel like the transition to open source of softwares becomes much simpler as well if enough conditions (like people start donating/govts start investing in open source) etc. happen!

Source availability still provides one to that direction & is still overall positive with atleast in this context, virtually zero downsides.

What are your thoughts on it?

See my thoughts under sibling comment https://news.ycombinator.com/item?id=46712351

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.

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.

I just started to learn Kotlin, how does it compare with Kotlin Multi Platform for those that used both?

Good question. I'll try to answer as objectively as possible, despite my bias towards Skip's approach.

Kotlin Multiplatform (KMP) enables you to target different platforms with your Kotlin. In the context of mobile apps, it allows you to compile your Kotlin to a native framework for iOS, so you can reuse your business logic. On iOS, the Kotlin is running in its own little garbage-collected runtime, but it sets up a bridge to Objective-C and Swift, so the iOS developers can communicate with it from their apps (the interface of which will typically be written separately for each platform). It is neat technology, and Skip integrates with it[1]. We were on their Talking Kotlin podcast in 2024 talking about it[2].

When targeting just the shared business logic and not the UI, Skip is, in some ways, the inverse of KMP: whereas they let you share Kotlin logic between the iOS and Android app, Skip lets you share the Swift logic. Skip operates in two different modes[3]: Skip Lite and Skip Fuse. Skip Lite is the original version of Skip, and transpiles your Swift into Kotlin. Skip Fuse is a later iteration and resulted from the formation of the Swift Android workgroup[4], of which we are founding members. In both modes, you can share your Skip business logic layer between multiple apps, and this is a popular application of Skip (e.g., see this talk at NSSpain[5]).

So that's the story for shared logic. Now onto the user interface part:

While I mentioned that Skip _can_ be used just for sharing business logic, it really shines when you build your whole app with it. You write your app in conventional SwiftUI, and Skip will translate it into the equivalent Jetpack Compose (which is now Android's official recommended way to build apps). Launching your app from Xcode will bring up both your iOS app in the simulator, and the equivalent Android app in the emulator. It is designed to be a single vertically-integrated app creation solution, and enables a single team (or a single developer) to iterate on both platforms at the same time, without any of the coordination overhead of building two separate apps for the two platforms.

KMP itself doesn't have an equivalent, but it does have a sibling project "Compose Multiplatform" (CMP), which is built on top of KMP and sort of does the opposite: it lets you write your app in Kotlin and Jetpack Compose and run it on iOS. But the way that it achieves this is different from Skip's approach: it doesn't use native controls on iOS, but instead paints pixels on the screen that mimic the native iOS UI (à la Flutter). The results are predictable: an uncanny valley UI that doesn't feel _quite_ right, and that struggles to keep up with the platform conventions. Notably, like Flutter, they won't be able to support Liquid Glass in any convincing form, and so apps built with it are going to be stuck on outdated iOS UI conventions. In short: CMP is native on Android but alien on iOS, whereas Skip is native on both platforms.

That's our take on the difference between the two. In fairness to KMP, they do have some distinct advantages in terms of reach: whereas Skip is squarely focused on just mobile platforms, KMP can target desktops and the web as well. If that is a priority for you, or you already have a lot of Kotlin experience or are invested in the ecosystem, then KMP might be a good fit for your needs. But if you like Swift and SwiftUI, and are happy working with the Apple developer tools, then you should give Skip a try. It really is magic.

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

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

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

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

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

I had a very quick glance at docs website, from Comparison page it says it uses native components, which is great. However, I did not find anything related to platform specific API usage, such as embedding camera into your view or using notification groups/channels? Is there a way to "offload" these parts to android, similar to what CMP allows you to do? (You can embed native iOS views inside Compose view or use expect/actual)

> KMP itself doesn't have an equivalent

Are you sure about that?

https://code.cash.app/native-ui-and-multiplatform-compose-wi...

Looks like Redwood, sadly, is no longer under active development as of a couple months ago.

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.

If you are making an iOS app, Apple requires you to have a Mac, regardless of whatever UI framework you use. It is not up to Skip or React Native or Flutter to obviate that need.

You are confused or making bad-faith comparisons.

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

If I use Skip to make a cross-platform app, will TalkBack be able to read it to users as well as VoiceOver?

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.

Can you please stop assuming that everyone knows your randomly named niche software and use a more descriptive title for your posts? Much appreciated.

Please refresh yourself on https://news.ycombinator.com/newsguidelines.html

Please provide a helpful comment instead of "rtfm".

“Please don't do things to make titles stand out…

“If the title includes the name of the site, please take it out…

“If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it…

“Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.” (From that link.)

Hope that helps.

How is Skip’s support for building apps with maps or other more complex UIs? Can I build map overlays that work cross platform?

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

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

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.

Third possibility negates the first two.

Also, did VB6 put anyone out of work?

> Asking whether VB6 was out of work is the wrong question.

Asking whether you would like to work with a cowboy coded VB6 for low pay is a better one. The companies that have less cowboy coded apps are the companies everyone wants to work at. The more companies with cowboy coded apps, the harder it gets to get a job at a company with minimal cowboys imo.

VB6 apps haven't disappeared anymore than Cobol systems have.

"Third possibility negates the first two." It doesn't. Those 3 things don't need to all happen. Any of them alone is enough to significantly worsen the pay or quality of life of your average dev. And the 3 things don't even need to happen at the same time anyway.

Did you reach out to Lua heavy shops?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 and the preview canvas are your friend

Preview canvas is unusable by 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.

How is Skip compared to Jetbrains Compose and MAUI/Avalonia?

Does it support MacOS as well? I didn't spot any explicit statement about that but I guess SwiftUI should support that automatically.

Yes, SwiftUI supports macOS automatically.

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.

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

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

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

What big/famous apps are using Skip?

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.

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

[dead]

Welp atleast they make it more easier for us non-Apple Developer to make an App