14 ms·

Skip is now free and open source

515 points by dayanruben 8mo ago

gouthamve 8mo ago
https://github.com/skiptools/skip 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 https://github.com/skiptools/skipstone but it vendors the other repo according to the readme? I am super confused about how this would work.
- marcprux 8mo ago
  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!
- zahlman 8mo ago
  LGPL3 has now been added: https://github.com/skiptools/skip/commit/7ad94680a801ca393fe9715565766ccb0629cdfa https://github.com/skiptools/skip/commit/7ad94680a801ca393fe...
  - gpm 8mo ago
    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.
    - speedgoose 8mo ago
      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.
      - gpm 8mo ago
        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.
        mdasen 8mo ago
        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.
        speedgoose 8mo ago
        Alright, that’s a fair point.
        wahnfrieden 8mo ago
        It's fully irrelevant because the LGPL code is for the build tool only.
      - deleted 8mo ago
        [deleted]
    - wahnfrieden 8mo ago
      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.
- wahnfrieden 8mo ago
  You can chill - it was their oversight that they’ve already corrected, not an omission by design
liuliu 8mo ago
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.
- wahnfrieden 8mo ago
  Closest thing is SwiftCrossUI. Maybe Skip will come to Windows one day.
- solarkraft 8mo ago
  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 https://github.com/thebrowsercompany/swift-winrt However it seems like it could be a good basis for such a project.
pxc 8mo ago
If I use Skip to make a cross-platform app, will TalkBack be able to read it to users as well as VoiceOver?
- marcprux 8mo ago
  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.
  - pxc 8mo ago
    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.
  - well_ackshually 8mo ago
    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.
ppeetteerr 8mo ago
This is amazing! Thank you for open sourcing the project. It must have been a hard decision.
- marcprux 8mo ago
  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.
  - sneak 8mo ago
    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.
    - Imustaskforhelp 8mo ago
      > 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!
jstummbillig 8mo ago
"At least 32GB of memory is recommended for development with Skip." Dear lord, what?
- dlcarrier 8mo ago
  IDEs targeting mobile development saw the bloat in FPGA IDEs and said "we can beat that".
- marcprux 8mo ago
  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.)
  - giancarlostoro 8mo ago
    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.
    - marcprux 8mo ago
      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.
    - cachvico 8mo ago
      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.
  - jstummbillig 8mo ago
    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.
sabdarmdhn 8mo ago
Welp atleast they make it more easier for us non-Apple Developer to make an App
publicdebates 8mo ago
> 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.
- giancarlostoro 8mo ago
  Did you reach out to Lua heavy shops?
- fn-mote 8mo ago
  > 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.
  - bossyTeacher 8mo ago
    >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.
DetroitThrow 8mo ago
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.
RobMurray 8mo ago
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 https://github.com/soundscape-community/soundscape
- marcprux 8mo ago
  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/ https://skip.dev/docs/components/accessibility/
jackbravo 8mo ago
What big/famous apps are using Skip?
kwanbix 8mo ago
I just started to learn Kotlin, how does it compare with Kotlin Multi Platform for those that used both?
- marcprux 8mo ago
  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/ https://skip.dev/blog/skip-and-kotlin-multiplatform/ [2]: https://talkingkotlin.com/going-from-swift-to-kotlin-with-skip/ https://talkingkotlin.com/going-from-swift-to-kotlin-with-sk... [3]: https://skip.dev/docs/modes/ https://skip.dev/docs/modes/ [4]: https://www.swift.org/android-workgroup/ https://www.swift.org/android-workgroup/ [5]: https://www.youtube.com/watch?v=EIGl6GOo210 https://www.youtube.com/watch?v=EIGl6GOo210
bbx 8mo ago
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.
- wahnfrieden 8mo ago
  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.
  - hn-acct 8mo ago
    Small views and the preview canvas are your friend
    - wahnfrieden 8mo ago
      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.
agentifysh 8mo ago
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.
- trevor-e 8mo ago
  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.
  - cosmic_cheese 8mo ago
    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.
  - skybrian 8mo ago
    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.
  - eptcyka 8mo ago
    > 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.
    - frizlab 8mo ago
      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.
    - 8mo ago
vishrajiv 8mo ago
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.
danielhep 8mo ago
How is Skip’s support for building apps with maps or other more complex UIs? Can I build map overlays that work cross platform?
juicytip 8mo ago
[dead]
dtreliz 8mo ago
Does it support MacOS as well? I didn't spot any explicit statement about that but I guess SwiftUI should support that automatically.
- dfabulich 8mo ago
  Yes, SwiftUI supports macOS automatically.
nsm 8mo ago
> 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!
- ipnon 8mo ago
  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.
  - fragmede 8mo ago
    In other markets, that is called dumping, and it is illegal. And in fact, Microsoft was convicted of being a monopolist and dumping.
- HexDecOctBin 8mo ago
  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.
  - throw10920 8mo ago
    > 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.
ashishb 8mo ago
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 fundamentally does not work for anyone with more than 10M+ installs just like you can't write Mandarin and English in one script. 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/ https://ashishb.net/tech/react-native/
- doodlesdev 8mo ago
  > This fundamentally does not work for anyone with more than 10M+ installs just like you can't write Mandarin and English in one script. Provably false. My bank app (Nubank) is written in Flutter and it's one of the most used banks in Brazil (100mi+ clients who rely on the iPhone or Android app, since it's a digital bank with no web interface).
  - ashishb 8mo ago
    Good for you. I meant as a general rule of thumb.
    - doodlesdev 8mo ago
      You said "fundamentally", not as a rule of thumb :)
      - ashishb 8mo ago
        Fair point. I should have said broadly.
    - will_unrulr 8mo ago
      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.
tonyhart7 8mo ago
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
stevefan1999 8mo ago
How is Skip compared to Jetbrains Compose and MAUI/Avalonia?
bentocorp 8mo ago
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.
letwhile 8mo ago
Can you please stop assuming that everyone knows your randomly named niche software and use a more descriptive title for your posts? Much appreciated.
- internetter 8mo ago
  Please refresh yourself on https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - letwhile 8mo ago
    Please provide a helpful comment instead of "rtfm".
    - ckcheng 8mo ago
      “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.
mrkeen 8mo 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. So not really the cross-platform I was imagining. That one's on me. With no additional managed runtime, Skip apps are as efficient as they can possibly be on both platforms. Bold claim. These guys must really care about every byte. At least 32GB of memory is recommended for development with Skip. (!)
- wahnfrieden 8mo ago
  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).
- satvikpendem 8mo ago
  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.
ildon 8mo ago
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.)?
xmprt 8mo ago
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.
- wahnfrieden 8mo ago
  Looks like they will rely on enterprise customers who pay for priority support access.
- jillesvangurp 8mo ago
  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.
igogq425 8mo ago
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.
- deleted 8mo ago
  [deleted]
frouge 8mo ago
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?

515 points by dayanruben 8mo ago

https://github.com/skiptools/skip 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 https://github.com/skiptools/skipstone but it vendors the other repo according to the readme? I am super confused about how this would work.

marcprux 8mo ago
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!
zahlman 8mo ago
LGPL3 has now been added: https://github.com/skiptools/skip/commit/7ad94680a801ca393fe9715565766ccb0629cdfa https://github.com/skiptools/skip/commit/7ad94680a801ca393fe...
- gpm 8mo ago
  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.
  - speedgoose 8mo ago
    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.
    - gpm 8mo ago
      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.
      - mdasen 8mo ago
        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.
      - speedgoose 8mo ago
        Alright, that’s a fair point.
        wahnfrieden 8mo ago
        It's fully irrelevant because the LGPL code is for the build tool only.
    - deleted 8mo ago
      [deleted]
  - wahnfrieden 8mo ago
    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.
wahnfrieden 8mo ago
You can chill - it was their oversight that they’ve already corrected, not an omission by design

liuliu 8mo ago

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.

wahnfrieden 8mo ago
Closest thing is SwiftCrossUI. Maybe Skip will come to Windows one day.
solarkraft 8mo ago
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 https://github.com/thebrowsercompany/swift-winrt However it seems like it could be a good basis for such a project.

pxc 8mo ago

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

marcprux 8mo ago
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.
- pxc 8mo ago
  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.
- well_ackshually 8mo ago
  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.

ppeetteerr 8mo ago

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

marcprux 8mo ago
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.
- sneak 8mo ago
  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.
  - Imustaskforhelp 8mo ago
    > 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!

jstummbillig 8mo ago

"At least 32GB of memory is recommended for development with Skip." Dear lord, what?

dlcarrier 8mo ago
IDEs targeting mobile development saw the bloat in FPGA IDEs and said "we can beat that".
marcprux 8mo ago
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.)
- giancarlostoro 8mo ago
  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.
  - marcprux 8mo ago
    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.
  - cachvico 8mo ago
    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.
- jstummbillig 8mo ago
  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.

sabdarmdhn 8mo ago

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

publicdebates 8mo ago

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

giancarlostoro 8mo ago
Did you reach out to Lua heavy shops?
fn-mote 8mo ago
> 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.
- bossyTeacher 8mo ago
  >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.

DetroitThrow 8mo ago

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.

RobMurray 8mo ago

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 https://github.com/soundscape-community/soundscape

marcprux 8mo ago
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/ https://skip.dev/docs/components/accessibility/

jackbravo 8mo ago

What big/famous apps are using Skip?

kwanbix 8mo ago

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

marcprux 8mo ago
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/ https://skip.dev/blog/skip-and-kotlin-multiplatform/ [2]: https://talkingkotlin.com/going-from-swift-to-kotlin-with-skip/ https://talkingkotlin.com/going-from-swift-to-kotlin-with-sk... [3]: https://skip.dev/docs/modes/ https://skip.dev/docs/modes/ [4]: https://www.swift.org/android-workgroup/ https://www.swift.org/android-workgroup/ [5]: https://www.youtube.com/watch?v=EIGl6GOo210 https://www.youtube.com/watch?v=EIGl6GOo210

bbx 8mo ago

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.

wahnfrieden 8mo ago
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.
- hn-acct 8mo ago
  Small views and the preview canvas are your friend
  - wahnfrieden 8mo ago
    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.

agentifysh 8mo ago

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.

trevor-e 8mo ago
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.
- cosmic_cheese 8mo ago
  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.
- skybrian 8mo ago
  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.
- eptcyka 8mo ago
  > 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.
  - frizlab 8mo ago
    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.
  - 8mo ago

vishrajiv 8mo ago

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.

danielhep 8mo ago

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

juicytip 8mo ago

[dead]

dtreliz 8mo ago

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

dfabulich 8mo ago
Yes, SwiftUI supports macOS automatically.

nsm 8mo ago

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

ipnon 8mo ago
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.
- fragmede 8mo ago
  In other markets, that is called dumping, and it is illegal. And in fact, Microsoft was convicted of being a monopolist and dumping.
HexDecOctBin 8mo ago
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.
- throw10920 8mo ago
  > 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.

ashishb 8mo ago

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 fundamentally does not work for anyone with more than 10M+ installs just like you can't write Mandarin and English in one script. 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/ https://ashishb.net/tech/react-native/

doodlesdev 8mo ago
> This fundamentally does not work for anyone with more than 10M+ installs just like you can't write Mandarin and English in one script. Provably false. My bank app (Nubank) is written in Flutter and it's one of the most used banks in Brazil (100mi+ clients who rely on the iPhone or Android app, since it's a digital bank with no web interface).
- ashishb 8mo ago
  Good for you. I meant as a general rule of thumb.
  - doodlesdev 8mo ago
    You said "fundamentally", not as a rule of thumb :)
    - ashishb 8mo ago
      Fair point. I should have said broadly.
  - will_unrulr 8mo ago
    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.

tonyhart7 8mo ago

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

stevefan1999 8mo ago

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

bentocorp 8mo ago

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.

letwhile 8mo ago

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

internetter 8mo ago
Please refresh yourself on https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- letwhile 8mo ago
  Please provide a helpful comment instead of "rtfm".
  - ckcheng 8mo ago
    “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.

mrkeen 8mo 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. So not really the cross-platform I was imagining. That one's on me. With no additional managed runtime, Skip apps are as efficient as they can possibly be on both platforms. Bold claim. These guys must really care about every byte. At least 32GB of memory is recommended for development with Skip. (!)

wahnfrieden 8mo ago
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).
satvikpendem 8mo ago
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.

ildon 8mo ago

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

xmprt 8mo ago

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.

wahnfrieden 8mo ago
Looks like they will rely on enterprise customers who pay for priority support access.
jillesvangurp 8mo ago
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.

igogq425 8mo ago

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.

deleted 8mo ago
[deleted]

frouge 8mo ago

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?