[HN Gopher] Swift on FreeBSD Preview
___________________________________________________________________
Swift on FreeBSD Preview
Author : glhaynes
Score : 152 points
Date : 2025-11-06 17:37 UTC (5 hours ago)
(HTM) web link (forums.swift.org)
(TXT) w3m dump (forums.swift.org)
| hazn wrote:
| what i am pondering is: is it easier in theory to port swift to
| freebsd rather than linux? the facts that macOs has shared
| history with freebsd tells me yes, the fact that llvm favors
| linux (?) tells me both.
|
| also, congrats, the swift and freebsd are ambitious in terms of
| new deployment platforms and compatibility! (see embedded swift,
| oci freebsd containers, freebsd on firecracker)
| rootnod3 wrote:
| Why would llvm favor linux? FreeBSD also officially moved from
| GCC to LLVM for the base system, so I don't see why LLVM
| wouldn't support it.
| rjsw wrote:
| I would say that LLVM is more important to FreeBSD than it is
| to Linux.
| hazn wrote:
| a good question, my line of thinking was: if llvm allows easy
| ports to freebsd, why is freebsd always a lower tier than
| linux in llvm based projects?
|
| weak reasoning, as it might just be a supply/demand and not a
| product quality question
| Klonoar wrote:
| _> Why..._
|
| It's almost always available resources.
| zapzupnz wrote:
| > is it easier in theory to port swift to freebsd rather than
| linux? the facts that macOs has shared history with freebsd
| tells me yes
|
| That shared history goes back a LONG way. The base components
| from FreeBSD that are in macOS are absolutely ancient. I think
| the most modern shared components are just the userland tools.
|
| So I don't think it would make much difference at all.
| Someone wrote:
| I don't know whether you know, but there has been a Linux port
| for quite a while (https://www.swift.org/blog/swift-linux-port/
| is from December 2015).
|
| https://www.swift.org/install/linux/ points to
| https://hub.docker.com/_/swift, which has images for Red Hat,
| Amazon Linux, maybe others.
| jiehong wrote:
| Porting on more platforms is always great, and a good way to find
| hidden assumptions.
| rootnod3 wrote:
| Are they also gonna take the reigns and officially be the
| maintainer of the FreeBSD package in ports or are they gonna wait
| for some volunteer to package it for them and choke on the bug
| reports whenever someone finds an issue?
| vtail wrote:
| Do people use Swift outside of Apple iOS/macOS development in
| real life? Especially on platforms like Windows/Linux/*BSD?
| rootnod3 wrote:
| I guess so. In a way it makes sense if you can share your code
| base between the iOS/MacOS app and your backend. It makes
| development easier. But I guess that the majority of apps is
| not running MacOS servers for the backend. So far it's probably
| some node backends and all going JSON inbetween. But for some
| dedicated apps without a web portal inbetween it might be
| easier if app and backend are both in Swift.
| repelsteeltje wrote:
| Only for iOS apps. Apple does not offer a backend.
| turnsout wrote:
| Not true at all. Swift is a very capable backend language,
| Apple has open sourced a lot of great libraries to power
| server software development, and there are projects like
| Vapor [0] that are used in production.
|
| [0]: https://vapor.codes
| repelsteeltje wrote:
| Ah. You're right, I phrased that ambiguously, sorry.
|
| I meant to point out that there is no apple native cloud
| solution where you can run swift on apple hardware.
|
| So if your iOS app needs to talk to a backend that you want
| to develop and host, you need to run that backend on an OS
| with cloud support, like Linux, some other Unix or windows.
| But not macOS or some other "Apple cloud" hosting.
|
| For reasons stated above, you might in that case choose
| Swift.
| turnsout wrote:
| Ah, gotcha--yes, that is actually a pain point and a
| strange omission. If you need to run backend code for any
| reason to support your app, Apple literally offers
| nothing.
|
| IBM at one point offered Swift "serverless" lambdas/cloud
| functions, which made me briefly hopeful that Apple could
| do the same, but that service was deprecated years ago,
| and Apple has shown no motion there.
| tiltowait wrote:
| It's not super popular, but support is necessary to make it so.
| There are some well-regarded frameworks, like Vapor, that are
| written in Swift.
| afavour wrote:
| Chicken/egg, I think. There was a burst of activity of Swift on
| the server a few years ago and frameworks like Vapor seem like
| they're still pretty active:
|
| https://vapor.codes/
|
| But I think "why" remains a valid question when you could make
| a safe pick like Node, Python etc. I really like Swift as a
| language but I'd still struggle to justify using it outside of
| iOS.
| KerrAvon wrote:
| Swift is a peer to Rust, not Node / Python. It has some nice
| affordances that Rust doesn't, while still being a native-
| compiled language.
| afavour wrote:
| In the case of Vapors (building "HTTP servers, backends and
| APIs") I'd say Node and Python are absolutely alternatives.
| myko wrote:
| So is https://gotham.rs/!
|
| I think they were just talking about the language
| features, not building web services generally
| ux266478 wrote:
| Swift is absolutely not a peer to Rust. Even without GC,
| Swift comes with a substantial runtime to enable a lot of
| features that precludes such a comparison like everything
| to do with messages and actors. With regards to safety,
| Swift's data isolation system is cute, but isn't comparable
| to a substructural type system at all, and it's useless if
| you're not writing code that uses actors.
|
| Most of what makes Rust's safety powerful is that lifetime
| analysis is universal and highly granular. Things like no
| dangling references to local variables, no 'collection
| cycles', handling parametric code, etc. are basic features
| that Swift can't provide. On top of it all, the whole
| system is ruinously complicated compared to Rust's type
| system. That's the sad reality of what happens when you try
| to implement something so fundamental as an extra bolt-on
| to a language that can't properly accomidate it.
| cosmic_cheese wrote:
| On the other hand, Swift has a more gentle learning curve
| with plenty of progressive disclosure (many features
| aren't strictly required to build something useful) and
| generally more approachable syntax.
|
| Swift is also more conducive to "old style" retain mode
| imperative UI frameworks like AppKit (sometimes
| declarative and/or immediate mode doesn't fit the bill),
| which has to date been a major weak point for Rust.
| ux266478 wrote:
| For what it's worth, I'm _not_ an active user (or fan) of
| Rust. I 've just used a lot of languages, it's a hobby of
| mine to learn new tools.
|
| > a more gentle learning curve ... and generally more
| approachable syntax.
|
| This is all the more reason it's not a peer. The
| heavyweight class Rust belongs to (which includes things
| like Sepples, ATS, Ada/SPARK, D) are as a rule not
| approachable things. All of them are serious industrial
| tools whose target audience are experienced professionals
| that prioritize extremely broad functionality and
| flexibility in output. What the input looks like, or the
| cost of learning to operate these tools is not even a
| consideration for this audience. Swift doesn't fit this
| bill. It simply compromises too much for things that this
| class of language isn't concerned with. People reaching
| for a new language in this class aren't thinking about
| how easy it is to learn, or even how nice it is to use.
| Rust abandoned ML-family syntax to babyduck C++ at
| massive cost to its "niceness".
|
| On syntax, do you mean semantics? Syntactically they're
| both generic curly-brace algol stuff with minor
| differences at best. Semantically Rust is certainly more
| complicated.
|
| > which has to date been a major weak point for Rust.
|
| It's very ironic, given Rust's original purpose was to
| replace C++ as the implementation language for Firefox.
| Retained mode GUIs have unfortunately fallen by the
| wayside due to a number of factors, it's not just unique
| to Rust. If a language hasn't inherited a legacy retained
| mode lib, it's not likely it'll get a decent one unless
| it's really lucky. Unfortunate, because you're right,
| retained mode GUIs absolutely have their upsides and web
| browsers aren't a solid replacement. They're just
| complicated to implement, and computers are fast enough
| now that the much simpler immediate mode paradigm is the
| choice for every new framework being written. It is what
| it is.
| morshu9001 wrote:
| It's more of a peer to Go
| wlesieutre wrote:
| There were three major server side Swift projects, and Vapor
| is the surviving one from that era
|
| Dead projects are
|
| - Kitura https://github.com/Kitura/Kitura
|
| - Perfect https://github.com/PerfectlySoft/Perfect
|
| Don't know of large organizations using it in production, the
| vibe I get is that it's useful for an iOS developer who wants
| to deploy a small server for their product without learning
| Python or Javascript.
|
| You could certainly use it at larger scale, but you have to
| justify giving up the big ecosystems of its competitors.
| fastily wrote:
| There's also hummingbird: https://github.com/hummingbird-
| project/hummingbird
| zerr wrote:
| Does not support Windows.
| andrewl-hn wrote:
| Arc browser famously had native parts of the UI done in Swift,
| which admittedly is not a lot: browser tabs, some popups and
| buttons here and there, a lot of their settings UI is rendered
| in HTML and is stock Chromium. Which is probably why they
| actually made a port of it to run on Windows rather than
| rewriting it into something like Qt or WPF or whatever.
|
| Ladybird browser team _planned_ to start using Swift in their
| codebase, but it hasn 't happen yet.
| GeekyBear wrote:
| Like Rust, Swift is a compiled language that offers memory
| safety and data race safety by default.
| worik wrote:
| Not really that much
|
| It's been two years since I was an iOSSwift programmer, but
| the concurrent/parallel facilities were quite woeful. Memory
| protection no nonexsistant
|
| I do not miss it. This might be useful for porting Apple
| software, but do not start new projects with it.
| seankit wrote:
| Swift concurrency used to be a bit rough around the edges,
| but since Swift 5.5 it uses async/await and structured
| concurrency, which has been a massive improvement. We also
| have built in ways to handle data races around mutable
| state with actors and the main thread with @MainActor.
|
| Rust has a more explicit and strict approach to
| ownership/borrowing for sure, but I'd argue Swift has
| worked to be memory safe be default since the start, with
| ARC, no unchecked pointer arithmetic in normal code, etc.
| it's still tightly coupled to Apple platforms, but the
| swiftlang teams has been hard at work changing that and I
| think it's a fine language to start new projects with in
| 2025.
| w10-1 wrote:
| > Memory protection no nonexsistant
|
| Exclusivity is guaranteed by the compiler, and Apple has
| integrated tagged pointers on arm while Linux/x86 is still
| thinking about it.
| viktorcode wrote:
| Data race safety is not offered by default. In Swift 6.2 you
| can enable strict mode and it will cover majority of data
| race problem, but not all.
| tehnub wrote:
| Could SwiftUI ever be used outside of Apple?
| dejv wrote:
| No
| MattDamonSpace wrote:
| Probably not, Apple would have to opensource it and that's
| unlikely
| viktorcode wrote:
| SwiftUI is build upon Apple's frameworks like Metal,
| CoreGraphics, CoreAnimation, and UIKit / AppKit. If someone
| want's to make a version for another platform, they will have
| a whole lot of work to do. That is the real show stopper, and
| not the core SwiftUI features like many were led to believe
| wkat4242 wrote:
| Personally I stay away from Corp owned languages. Even cross
| platform ones like .net, Java and also swift. With the single
| commercial party owning it you never know if theyll close it,
| change things for the worse or get acquired by a hostile party
| which obviously happened to java :(
| MattDamonSpace wrote:
| Apple's the exception that proves the rule, they do a
| fantastic job supporting legacy APIs, frameworks, and devices
| worik wrote:
| > they do a fantastic job supporting legacy APIs,
| frameworks, and devices
|
| They do not.
|
| They talk a good game, but the development tools, bright
| and shiny, but mostly work.
|
| Mostly, is not good enough.
|
| While they have so much mind share in the USA they are
| unavoidable. But from a developer perspective they are dire
|
| As of two years ago. I find it hard to believe they have
| changed
| morshu9001 wrote:
| There are 10 different answers for how to take a substring
| by index+len, depending on which version of Swift. They
| even changed how arrays as function parameters work between
| versions.
| vlovich123 wrote:
| Which language would you classify as not corp owned?
|
| It's also weird to include Java and Swift in that list
| considering both afaik are maintained by a separate
| foundation. Java from Sun is even predominantly basically
| OpenJDK with some remaining proprietary Sun / Oracle bits but
| it's the reference open source implementation used by most
| everyone.
| ndiddy wrote:
| > Java from Sun is even predominantly basically OpenJDK
| with some remaining proprietary Sun / Oracle bits but it's
| the reference open source implementation used by most
| everyone.
|
| Note that Oracle contributes around 90% of the work to
| OpenJDK. If they decided to stop working on it, there would
| be a big gap to fill.
| mk89 wrote:
| It'd be nice to use it for server side too, but the ecosystem
| is really not mature and the build system is not on the same
| level of Gradle or similar.
|
| Plus, most of the open source libs are one person's weekend
| projects, from 3 years ago...
|
| It's a great language, but nowadays tooling/ecosystem and build
| systems are key to success.
| cosmic_cheese wrote:
| > ...and the build system is not on the same level of Gradle
| or similar.
|
| Worth noting that Gradle's long list of capabilities can
| sometimes be as much of a liability (or at least a
| frustration) as it is a boon. A great many projects don't
| need even a fifth of its complexity.
| lukeh wrote:
| I'm using it on Linux for an embedded product. No reason other
| than it's a nice language that I am familiar with and
| productive in. The async/await features are quite nice too when
| you need to implement a lot of protocols / state machines.
| latexr wrote:
| > The Swift compiler and runtimes have a few dependencies. Please
| install the following dependencies:
|
| > (...) python3 (...)
|
| Wait, which part requires Python, and why? And is that only for
| FreeBSD, or in general? And is that something which will change?
| Feels very weird that a compiled systems language is dependent on
| a high-level scripting language.
| TheJoeMan wrote:
| https://github.com/orgs/swiftlang/repositories?q=lang%3Apyth...
| From a quick look, appears to be the test suite. Which makes
| sense, hard to validate your language with itself.
| ux266478 wrote:
| That greatly depends on the codebase and the language.
|
| https://github.com/SWI-Prolog/swipl-
| devel/blob/master/tests/...
| jshier wrote:
| LLDB also needs python if you want to use its scripting
| integration.
| bananapub wrote:
| it's not weird at all - you need something sensible to run
| complicated things while bootstrapping the compiler. Rust does
| the same thing: https://rustc-dev-guide.rust-
| lang.org/building/how-to-build-...
| mshockwave wrote:
| It's likely that Swift compiler is using LLVM LIT
| (https://llvm.org/docs/CommandGuide/lit.html), which is
| implemented in python, as the test driver
| airspeedswift wrote:
| Python and LIT are used heavily to build and test the
| compiler, but that is only for building it, you do not need
| it to download and use the built toolchain. The python
| dependency is more about its use in LLDB.
| airspeedswift wrote:
| The Swift toolchain includes LLDB, which relies on python for
| some debugging features. The compiler and runtime itself do not
| use python.
| hirvi74 wrote:
| I absolutely love Swift. I understand some may disagree, and
| perhaps many of their arguments are quite valid. However, no
| language is perfect, and I just feel like Swift has some features
| that shows that a lot of thought was put into some features --
| not to disrespect any other languages.
|
| Considering the static typing, guard statements, protocols, lack
| of ++/-- operators (Lattner's argument was convincing), let/var,
| being able to make function parameters immutable, being able to
| lock symbols down to the file level, easy integration with c
| languages, etc..
|
| I have not used SwiftUI, so I cannot judge it, but I do not think
| any issues with it are compelling arguments against Swift as a
| language (that I have read).
|
| Lattner is my modern-age programming-hero. I'm glad to see
| FreeBSD will be able to share the love soon enough.
| ezfe wrote:
| And SwiftUI is not part of Swift open source, it's just for
| Apple platforms. The underlying Swift language features could
| be used by other UI systems if someone wanted to make a
| crossplatform system, though.
| myko wrote:
| Swift is such an excellent language. I hope it continues to
| grow outside of the Apple ecosystem.
| turnsout wrote:
| Wow, this is great news. I still don't understand why it has
| taken so long, when Swift on Linux has been around for 10 years.
| But as a FreeBSD user, this is very welcome!
| fridder wrote:
| Loving all the new developments with FreeBSD.
| kchoudhu wrote:
| I'm not complaining, but also why?
| gocsjess wrote:
| I believe apple is making OCI-compliant containers which is
| written in swift. I hope this helps the containerization in
| FreeBSD.
| bartekrutkowski wrote:
| In what sense? FreeBSD had containers before anyone heard about
| Docker ;)
| righthand wrote:
| Yeah talk about reinventing the wheel so Linux people don't
| have to learn a slightly different system (one that is
| ironically easier to use and better organized than Oci
| containers).
| Gud wrote:
| Jails are not containers.
| fridder wrote:
| Just this week the foundation dropped an article about OCI
| compliant containeraztion:
| https://freebsdfoundation.org/blog/oci-containers-on-freebsd...
| jonhohle wrote:
| This is awesome. I have an Omada container running on my
| desktop that would be great to move to my FreeBSD server.
| DeathArrow wrote:
| What can you build with Swift on FreeBSD which isn't easier with
| other languages?
| jhatemyjob wrote:
| Software that is meant to run on Apple platforms.
| frizlab wrote:
| absolutely not
| bhokbah wrote:
| Everything will be easier to build with Swift on FreeBSD for a
| Swift developer compared to any other language
| oaiey wrote:
| A lot of good news recently for swift. I am a bit jealous as my
| go to language C# / .NET is recently not announcing fancy things.
|
| I really like swift going beyond Apple. Particularly the port to
| android is IMHO crucial, however, now they are in the UI cross
| platform hell. Let us see if Apple is playing this better than
| Microsoft. Unfortunately, I have little hope. The only native
| contenders in the field right now are IMHO are react native and
| flutter which are both UI toolkits first and language second.
| Which I find gruesome.
| troupo wrote:
| > I am a bit jealous as my go to language C# / .NET is recently
| not announcing fancy things.
|
| Depends on what you think fancy things are. Both C# and .net
| are busy releasing a lot of features.
|
| You're forgetting that C# is a 25-year-old language at this
| time. The exciting features they release are things like
| "access native memory allocation in a GC language", "native
| Arm64 support", "support for post-quantum cryptography",
| "tensor support" etc. while already running on all the
| platforms that Swift is only now announcing as achievements.
| SvenL wrote:
| Yeah, also the ecosystem, aspire, ef core, Orleans, ML.NET
| etc..at this point I don't know what's really missing.
| cosmic_cheese wrote:
| It'd be nice if Apple made SwiftUI cross platform and I'd be
| singing in the streets if UIKit got ported, but that seems
| unlikely at best.
|
| I believe that there's strong community interest in some kind
| of Swift UI framework for Android, though, and so there's a
| substantial chance that a third party solution will appear.
| CharlesW wrote:
| skip.tools is one third-party solution for creating Swift +
| SwiftUI apps for Android today.
| cosmic_cheese wrote:
| It still translates SwiftUI to Kotlin+Compose, right? Very
| cool and useful, but not quite the same as a Swift-based UI
| framework for Android.
| CharlesW wrote:
| Oops, TIL Jetpack Compose doesn't use Android native
| controls. That is unfortunate.
| tadfisher wrote:
| Jetpack Compose is just as "native" as Android views at
| this point; it hooks into the same accessibility
| frameworks and renders to the same surfaces as the
| framework toolkit. This isn't like Flutter which renders
| to an opaque Skia buffer.
| CharlesW wrote:
| Great! I appreciate the claification, thank you.
| rubyn00bie wrote:
| I'd absolutely love it if they made SwiftUI cross platform
| for both mobile and desktop. Flutter is nice but it's still
| sort of a mess sometimes when targeting desktop instead of
| mobile.
| n8cpdx wrote:
| SwiftUI is also a mess when targeting desktop (macOS).
| troupo wrote:
| > It'd be nice if Apple made SwiftUI cross platform
|
| It's a nearly impossible task. Just ask Qt, who have been at
| this for thirty years.
| ardit33 wrote:
| SwiftUI is more realistic actually. UIKit, much tougher
| (more mature, more tied to the IOS ecosystem).
| garbthetill wrote:
| Correct me if im wrong, but isn't the pain points for mobile
| devs, the need to have intimate knowledge of both pl to build
| & maintain a good "backend/functionality" of the app over
| time and that the UI portion of the app is quite simple to
| learn, build and maintain.
|
| So is it necessary for the swift team to try get swift ui
| onto android, versus a developer building their app
| "backend/functionality" in swift, compiling it down for both
| ios and android, then bridging the android bindings with a UI
| made in kmp etc
|
| I recently learnt that amo and protonmail use this solution
| but instead of swift android, they were using uniffi-rs and
| seemed to have great results, I think proton ditched react
| native for this solution, which to me sounds like a more
| streamlined way of getting native performance without needing
| the overhead of managing multiple language. I guess we will
| have to see how mature swift android gets and if it can
| replace uniffi-rs etc which would save even more time
| ardit33 wrote:
| UIKit is very mature and tied to the iOS ecosystem and a bit
| more complex. SwiftUI is easier to port (since it is still a
| incomplete / subset features of UIKit).
| idatum wrote:
| Speaking of .NET, I've been successfully running .NET 9 on
| AMD64 FreeBSD. It's nice to have that choice.
| runjake wrote:
| I guess it's a matter of perspective. Dotnet 10 just came
| out[1] with a bunch of solid new shiny that I'm enjoying.
|
| And, as it stands, Dotnet is much further along in the multi-
| platform game than Swift. As far as I know, none of the Swift-
| based UI stuff is being ported to, let alone going to be usable
| on non-Apple platforms.
|
| 1. https://www.c-sharpcorner.com/article/whats-new-in-net-10/
___________________________________________________________________
(page generated 2025-11-06 23:00 UTC)