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.
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.
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
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.
Let’s be honest. It’s a mess targeting iOS. It’s like the old days with VB - first 80% done in no time, last 20% takes forever, requiring ever more elaborate hacks to get around stupid restrictions (eg try hiding the keyboard associated with a TextField when you tap on a Picker).
Don’t have links, but it’s true. iTunes for Windows also includes chunks of AppKit.
The Windows ports of AppKit in both likely trace their lineages back to Yellow Box, which was the Windows port of AppKit that Apple briefly made available prior to the release of OS X 10.0.
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.
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).
Yes historically but not by design. It's more of a transition tactic.
Starting with iOS 26, new UIKit and AppKit features are implemented by "native" SwiftUI (specifically, Liquid Glass's implementation). In recent years they have also been replacing UIKit/AppKit-backed SwiftUI views with "native" SwiftUI implementations.
But besides this technical change I don't think Apple has any desire to bring SwiftUI to other platforms.
BTW: https://skip.tools has bridged it to Compose. Your SwiftUI code runs in native Swift on Android.
> 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.
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.
> The only native contenders in the field right now are IMHO are [...] and flutter
I wouldn't really call Flutter "native".
I don't have a strong enough grasp of where React Native is at now. It was severely lacking when I looked at it circa 2018. But then we needed to call in to our own native code libraries, so we were probably quite niche.
Xamarin.Forms worked well enough, but the transition to MAUI has been full of woe and even more bugs and weird edge case functionality than Xamarin had.
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.
You can watch Lattner's interview with Theprimeagen. It's a haphazardly designed language where pressure to ship from Apple as a whole overrides any design or development considerations.
That's why you end up with a compiler that barfs at even the simplest SwiftUI code because Swift's type system is overly complicated and undecidable. And makes the compiler dog slow.
That's why you end up with 200+ keywords [1] with more added each release.
That's how you end up with idiocy like `guard let self = self else { return }` (I think they "fixed" this with some syntax sugar) because making if statements understand nulls is beyond the capabilities of heroes apparently.
And this is just surface level that immediately came to mind.
Some anecdotal evidence of its terrible qualities are the major degradation of software quality in the Apple ecosystem.
In particular the rewrites or brand new softwares feel much worse than it used to be.
I feel like if it was a good language, it should make things better; of course there may be some other confounding factors but it's hard to not link the software quality problem to the Swift push.
I see what you mean, but I am not sure it's the arrows and not the archers.
While anyone working at Big N company is likely a far better dev than me, I must admit that on the surface, I have not been too impressed with the quality from any them in the past decade or so.
I am less inclined to blame the languages than I am to blame the perverse incentives of these large companies and some of the personality types they sometimes seek to hire. Though, I do understand there are a lot of great devs at those orgs. Just in my experience, greatness doesn't always strongly correlate with ability to call the shots.
Yes I definitely agree that a lot of the problem is rooted in the type of people (or even just management, who knows ?) that get hired there nowadays.
But my thinking is that the language maybe makes things worse ? If you hire people that already are not that competent and force them to use a language that is harder to master it cannot help.
Something I have noted is that many "OG" Mac indie devs have complained about the language and their software quality seems to have gone done a bit as well (but it may have to do with the framework churn as well...).
But yeah, clearly it's impossible to really know from an external observer point of view.
Oh, sick! Thank you for bring this to my attention. I didn't even know this interview existed. I watched Lattner's three interviews with Lex (though I'm not a indifferent about Lex). I do love Theprimeagen though -- he represents us neurodiverse devs well.
> a compiler that barfs at even the simplest SwiftUI code
I have never used Swift UI. I honestly have used Swift mainly for automating a lot of stuff I used to do with Applescript or little scripts for minor things. I have never actually used Swift for any GUI application development.
> That's why you end up with 200+ keywords [1] with more added each release.
Sure, like I previously said, no language is perfect. I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need. I do not feel like I honestly have had to use any more than what I commonly user in .NET/C#. In fact, I think C# might honestly be worse.
That's the thing though: it affects you even if you don't use it. E.g. Swift's type system was made more complex because SwiftUI needed opaque types, function builders etc. and that was shipped with little consideration or design.
> I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need
Onve again, they affect you even if you don't use them. Because the compiler and the libs and the systems etc. now have to aware of these, and use them extensively.
E.g.
--- start quote ---
The Compiler's semantic analysis simply looks for the raw source string "DispatchQueue.main", and adds the hidden @_unsafeMainActor attribute
C# is 25 years old, Swift is 11, and already basically on par with C#? ;)
Also, "this language could he worse" is not a good argument :)
BTW that chart is outdated. It shows C# 8 (it's 14 now) and Swift 5. Swift now has twice as many keywords as C# 8 :) And as many as the Visual Basic 2019 (at 207 keywords).
> I think you can do something like this as Swift 5 or 6
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.
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?
> 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.
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.
Thats cool I knew those were coming but the most interesting thing in here is that it seems to be running the Linux images under the Linuxlator (hence he had to enable the linux service) as opposed to creating a Linux VM like the other operating system do. Pretty cool!
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).
Swift just needs to gain cmake bidirectional support, like, SPM should be able to compile CMake projects and vice-versa, or be able to use vcpkg. Once that's done, I could very much see myself switching to it for a lot of things.
I know, and that's a good thing. That's probably one of the biggest blockers for it's wider adoption. I hope that CMake can eventually get similar abilities for calling into SPM or just outright handling Swift package manifests. That might be too much to ask though.
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!
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.
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 :(
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.
> 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.
That’s generally true of most languages. Rust is struggling with this right now.
I’d say though that Oracle is highly unlikely to stop working on Java and Google is still invested in the JDK even though they’re trying to shift new code in this space towards Kotlin (another “corp owned” language)
For a significant portion of time Python was funded by Google, Meta and Facebook and maybe some other corps.
Zig doesn’t have any serious adoption in the industry yet but if/when it does I’d expect corps to be hiring the language devs.
JS is a consortium but it’s filled primarily with Google and Apple engineers.
Same goes for C/C++ lot of Apple, MS and Google engineers.
Elixir I’m not sure about. Rust was largely turns out employed by Amazon until the most recent culling.
It’s not surprising. This is technically difficult work and if the language is important to a corp they’ll hire the maintainers. There needs to be a funding source and in the industry that typically means a for profit company paying the salary of the people moving things forward. Indeed - it’s one of the things Rust is struggling with for now.
They fund it cos they want to use it for their thing. Does not mean they own them. They are all community governed projects.
Rust, Julia, Typescript on the other hand are governed by Corps. They are not community projects.
Elixir is BDFL (good one) last I checked. Dont know if they became a company or foundation.
Zig is for all purposes a good example of community governed project. Itcs in production at Bun and TigerBeetle. But also, its not yet production ready (v1.0). So their current trend make sense.
But I could've been wrong with JS and C. Not sure about their governance now that I think about it.
This is patently wrong on at least several of these.
Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Zig is a BDFL project like Python was (not sure how it is these days) - community contributes sure, but Andrew makes the big calls and directional changes.
> Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Non-profit doesn't mean community project. Rust foundation is a non-profit 501-c(6). Which is a non-profit category for trade unions and stuff. It's not a charity categorization. It's run by corporate members and works only for the members which are - surprise corporates. A community member like you or me doesn't have any say (Unless you have $325k per year to pay) - https://rustfoundation.org/get-involved/. This is the same case with Linux foundation as well. It's NOT a community project. The only difference is, Linus has more say cos trademark is on him.
PSF and Zig foundation are charity / commuinty projects cos they are non-profit 501 c(3). It's categorised as public charity or for the good of people. You and I can have more say in it. NOT THE CASE WITH RUST.
>Which language would you classify as not corp owned?
I would like to respectfully disagree with you there as well.
The above was the context. I was replying to this which opened the conversation.
Not to mention, end users and consumers don't get a say in the corp funded projects. Everything works as long as it aligns with the goals of the corp. Not otherwise.
I’ve been in the Apple ecosystem in one form or the other 40 years and that’s definitely not true compared to Microsoft.
Most recently they dropped support for 32 bit Mac and iOS apps. But before that it was dropping support for PPC apps and 68K apps.
On the hardware side, the funniest was they dropped support for my Core 2 Duo Mac Mini and I could still install a supported version of Windows 7 on it.
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.
Not viable to stay on an old version, especially doing iPhone dev. The real answer back in the Swift 1-4 times was to just use ObjC instead, it still had full support.
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.
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:
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.
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.
Sadly this project is getting steadily slower. Adopting async made it slower than Django. But this is due to Swift limitations. Hopefully Swift replaces Codable and improves async performance.
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.
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.
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.
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.
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.
> …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.
My encounters with Gradle have mainly been through Android development, so the example that springs to mind is how much of a pain in can be to get a project that's been sitting for a while patched up.
Basically, as a result of dependencies working only with certain versions of Gradle, it's very easy for an project with moderate to high complexity to wind up in a huge tangled mess when updating anything — updating Gradle might require you to update your dependencies, but all your dependencies might not support the version of Gradle you updated to, and the errors that get thrown as a result will be generic and won't tell you as much, sending you on a goose chase. This chain of events can also be set off by upgrading a single library for some feature you need.
It also makes it a pain to read others' Gradle files since there's no agreed upon standard, with everybody doing it a little bit differently.
In contrast, in the several years after switching my Apple platform projects to Swift Package Manager and away from CocoaPods, it's been rare for either toolchain or library upgrades to cause any sort of problem, and broadly speaking there's only a single correct way to write Swift package files, which makes them easier to read and work on.
Yes, because Apple gave up on the server market, so that demography usually uses Linux based servers and does code sharing between backend and their iDevices apps.
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.
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.
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.
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
I did try to build a medium sized project with this today. Still a lot of dependencies that will need to be updated for the differences between glibc and libc.
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)
> 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.
It’s a fantastic language? I’ve come to really like it. Strong type system, is it to work with, lots of resources available, compiles to a binary, interfacing with any other language that you can link to with C, the syntax doesn’t look ugly to me (quite subjective), excellent concurrency support…
This isn't to dispute your assertion, but I think things are still quite a bit different. A lot of things provided by Foundation on macOS are still not available in Linux's Foundation, nor CoreFoundation, so one has to defer to something like Glibc — which, then again, is not available to the static Linux distro. On Windows, it's useful to use WinSDK to do things that Foundation would normally do.
There's all sorts of little things that Swift on non-Apple platforms just don't have yet. Little footguns because the Swift rewrite of Foundation isn't quite equivalent yet.
It is getting close though, which was my point. Honestly I got bit recently by DateComponentFormatter that does not exists on Linux, but it’s been a while since I’ve had things like that. We even have (NS)AttributedStrings (including the NS version, which I did not expect…). Of course no fonts and co, but that’s AppKit/UIKit/SwiftUI, so it’s normal.
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.
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.
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
Do you have a link that talks about Proton Mail's use of UniFFI-rs? A quick search didn't turn up anything.
here is a reddit thread about it: https://www.reddit.com/r/rust/comments/1nq3vk9/proton_mail_r...
the proton mail team claimed they will write a technical writeup soon
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.
SwiftUI is also a mess when targeting desktop (macOS).
Let’s be honest. It’s a mess targeting iOS. It’s like the old days with VB - first 80% done in no time, last 20% takes forever, requiring ever more elaborate hacks to get around stupid restrictions (eg try hiding the keyboard associated with a TextField when you tap on a Picker).
> 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.
Qt has grown so huge that I rather choose Tk or GTK for cross platform GUI.
i would love to see how Swift will do cross platform gui.
SwiftUI is more realistic actually. UIKit, much tougher (more mature, more tied to the IOS ecosystem).
Highly doubt it, Safari on Windows ran on AppKit and that thing is from the early 1990s. You'd be surprised how high level UIKit actually is.
Source?
Don’t have links, but it’s true. iTunes for Windows also includes chunks of AppKit.
The Windows ports of AppKit in both likely trace their lineages back to Yellow Box, which was the Windows port of AppKit that Apple briefly made available prior to the release of OS X 10.0.
My understanding was Foundation and bits of CoreGraphics but not AppKit. Yellow Box required DPS.
skip.tools is one third-party solution for creating Swift + SwiftUI apps for Android today.
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.
Oops, TIL Jetpack Compose doesn't use Android native controls. That is unfortunate.
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.
Great! I appreciate the claification, thank you.
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).
From what I've read, SwiftUI is using parts of UIKit under the hood, so it also doesn't seem too likely.
Yes historically but not by design. It's more of a transition tactic.
Starting with iOS 26, new UIKit and AppKit features are implemented by "native" SwiftUI (specifically, Liquid Glass's implementation). In recent years they have also been replacing UIKit/AppKit-backed SwiftUI views with "native" SwiftUI implementations.
But besides this technical change I don't think Apple has any desire to bring SwiftUI to other platforms.
BTW: https://skip.tools has bridged it to Compose. Your SwiftUI code runs in native Swift on Android.
> 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.
Yeah, also the ecosystem, aspire, ef core, Orleans, ML.NET etc..at this point I don't know what's really missing.
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/
Not yet, still release candidate, not the final release.
Swift is a “may you live in interesting times” kind of deal. Not the kind of stress you want in your day job.
I donnow. C# and .NET are amazing. People tend to ignore it because Microsoft, but they are being short-sighted. What shiny things are you missing?
Speaking of .NET, I've been successfully running .NET 9 on AMD64 FreeBSD. It's nice to have that choice.
> The only native contenders in the field right now are IMHO are [...] and flutter
I wouldn't really call Flutter "native".
I don't have a strong enough grasp of where React Native is at now. It was severely lacking when I looked at it circa 2018. But then we needed to call in to our own native code libraries, so we were probably quite niche.
Xamarin.Forms worked well enough, but the transition to MAUI has been full of woe and even more bugs and weird edge case functionality than Xamarin had.
Aspire, extensions everywhere, field variables, spans as part of the type system, and naturally plenty of AI, isn't fancy enough?
>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
Flutter is not a language.
https://en.wikipedia.org/wiki/Flutter_(software)
From that page:
>Flutter apps are written in the Dart language.
>https://en.wikipedia.org/wiki/Dart_(programming_language)
most know that, it's implied to simplify the phrasing.
just mixing appkit and language in the same phrase implies swift.
This is a blessing and a curse. I, for one, preferred Swift from before, when it wasn't hell bent on replacing C++.
It was a simpler Swift, I could understand all of it. Just look at the explosion of keywords in Swift.
[dead]
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.
You can watch Lattner's interview with Theprimeagen. It's a haphazardly designed language where pressure to ship from Apple as a whole overrides any design or development considerations.
That's why you end up with a compiler that barfs at even the simplest SwiftUI code because Swift's type system is overly complicated and undecidable. And makes the compiler dog slow.
That's why you end up with 200+ keywords [1] with more added each release.
That's how you end up with idiocy like `guard let self = self else { return }` (I think they "fixed" this with some syntax sugar) because making if statements understand nulls is beyond the capabilities of heroes apparently.
And this is just surface level that immediately came to mind.
[1] It's not a typo: https://x.com/jacobtechtavern/status/1841251621004538183
Some anecdotal evidence of its terrible qualities are the major degradation of software quality in the Apple ecosystem. In particular the rewrites or brand new softwares feel much worse than it used to be.
I feel like if it was a good language, it should make things better; of course there may be some other confounding factors but it's hard to not link the software quality problem to the Swift push.
I see what you mean, but I am not sure it's the arrows and not the archers.
While anyone working at Big N company is likely a far better dev than me, I must admit that on the surface, I have not been too impressed with the quality from any them in the past decade or so.
I am less inclined to blame the languages than I am to blame the perverse incentives of these large companies and some of the personality types they sometimes seek to hire. Though, I do understand there are a lot of great devs at those orgs. Just in my experience, greatness doesn't always strongly correlate with ability to call the shots.
Yes I definitely agree that a lot of the problem is rooted in the type of people (or even just management, who knows ?) that get hired there nowadays.
But my thinking is that the language maybe makes things worse ? If you hire people that already are not that competent and force them to use a language that is harder to master it cannot help.
Something I have noted is that many "OG" Mac indie devs have complained about the language and their software quality seems to have gone done a bit as well (but it may have to do with the framework churn as well...).
But yeah, clearly it's impossible to really know from an external observer point of view.
> Lattner's interview with Theprimeagen.
Oh, sick! Thank you for bring this to my attention. I didn't even know this interview existed. I watched Lattner's three interviews with Lex (though I'm not a indifferent about Lex). I do love Theprimeagen though -- he represents us neurodiverse devs well.
> a compiler that barfs at even the simplest SwiftUI code
I have never used Swift UI. I honestly have used Swift mainly for automating a lot of stuff I used to do with Applescript or little scripts for minor things. I have never actually used Swift for any GUI application development.
> That's why you end up with 200+ keywords [1] with more added each release.
Sure, like I previously said, no language is perfect. I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need. I do not feel like I honestly have had to use any more than what I commonly user in .NET/C#. In fact, I think C# might honestly be worse.
https://github.com/e3b0c442/keywords
> `guard let self = self else { return }`
I think you can do something like this as Swift 5 or 6:
`guard let self else { return }`
Don't quote me though (It's also not much better looking, imo).
> I have never used Swift UI.
That's the thing though: it affects you even if you don't use it. E.g. Swift's type system was made more complex because SwiftUI needed opaque types, function builders etc. and that was shipped with little consideration or design.
> I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need
Onve again, they affect you even if you don't use them. Because the compiler and the libs and the systems etc. now have to aware of these, and use them extensively.
E.g.
--- start quote ---
The Compiler's semantic analysis simply looks for the raw source string "DispatchQueue.main", and adds the hidden @_unsafeMainActor attribute
https://x.com/jacobtechtavern/status/1986705344748220529
--- end quote ---
It's not language design. It's a minefield of unspecified hacks and workarounds. And the list is growing.
Speaking of SwiftUI, and how it affects the compiler https://x.com/krzyzanowskim/status/1818881302394814717
> In fact, I think C# might honestly be worse.
C# is 25 years old, Swift is 11, and already basically on par with C#? ;)
Also, "this language could he worse" is not a good argument :)
BTW that chart is outdated. It shows C# 8 (it's 14 now) and Swift 5. Swift now has twice as many keywords as C# 8 :) And as many as the Visual Basic 2019 (at 207 keywords).
> I think you can do something like this as Swift 5 or 6
Yeah, I vaguely remember something like that :)
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.
Swift is such an excellent language. I hope it continues to grow outside of the Apple ecosystem.
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?
> 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.
The Swift toolchain includes LLDB, which relies on python for some debugging features. The compiler and runtime itself do not use python.
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
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.
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-...
LLDB also needs python if you want to use its scripting integration.
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.
That greatly depends on the codebase and the language.
https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/...
Loving all the new developments with FreeBSD.
I believe apple is making OCI-compliant containers which is written in swift. I hope this helps the containerization in FreeBSD.
Just this week the foundation dropped an article about OCI compliant containeraztion: https://freebsdfoundation.org/blog/oci-containers-on-freebsd...
Thats cool I knew those were coming but the most interesting thing in here is that it seems to be running the Linux images under the Linuxlator (hence he had to enable the linux service) as opposed to creating a Linux VM like the other operating system do. Pretty cool!
This is awesome. I have an Omada container running on my desktop that would be great to move to my FreeBSD server.
In what sense? FreeBSD had containers before anyone heard about Docker ;)
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).
Jails are not containers.
By what definition would LXC be containers and jails not be?
Jails are great but are not OCI-compliant.
Then Podman for FreeBSD exists for a while too.
But it relied on Linux virtual machines didn't it?
So? They predate a standard which was basically extracted from Docker.
I think the OCI factor being noted here is the packaging not the containerized runtime.
Porting on more platforms is always great, and a good way to find hidden assumptions.
Swift just needs to gain cmake bidirectional support, like, SPM should be able to compile CMake projects and vice-versa, or be able to use vcpkg. Once that's done, I could very much see myself switching to it for a lot of things.
SPM support for CMake is in progress
I know, and that's a good thing. That's probably one of the biggest blockers for it's wider adoption. I hope that CMake can eventually get similar abilities for calling into SPM or just outright handling Swift package manifests. That might be too much to ask though.
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!
Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?
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.
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 :(
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.
> 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.
That’s generally true of most languages. Rust is struggling with this right now.
I’d say though that Oracle is highly unlikely to stop working on Java and Google is still invested in the JDK even though they’re trying to shift new code in this space towards Kotlin (another “corp owned” language)
Python, Zig, Elixir, JS, C to name a few?
Also rust, c++
> Python, Zig, Elixir, JS, C to name a few?
For a significant portion of time Python was funded by Google, Meta and Facebook and maybe some other corps.
Zig doesn’t have any serious adoption in the industry yet but if/when it does I’d expect corps to be hiring the language devs.
JS is a consortium but it’s filled primarily with Google and Apple engineers.
Same goes for C/C++ lot of Apple, MS and Google engineers.
Elixir I’m not sure about. Rust was largely turns out employed by Amazon until the most recent culling.
It’s not surprising. This is technically difficult work and if the language is important to a corp they’ll hire the maintainers. There needs to be a funding source and in the industry that typically means a for profit company paying the salary of the people moving things forward. Indeed - it’s one of the things Rust is struggling with for now.
They fund it cos they want to use it for their thing. Does not mean they own them. They are all community governed projects.
Rust, Julia, Typescript on the other hand are governed by Corps. They are not community projects.
Elixir is BDFL (good one) last I checked. Dont know if they became a company or foundation.
Zig is for all purposes a good example of community governed project. Itcs in production at Bun and TigerBeetle. But also, its not yet production ready (v1.0). So their current trend make sense.
But I could've been wrong with JS and C. Not sure about their governance now that I think about it.
This is patently wrong on at least several of these.
Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Zig is a BDFL project like Python was (not sure how it is these days) - community contributes sure, but Andrew makes the big calls and directional changes.
> Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Non-profit doesn't mean community project. Rust foundation is a non-profit 501-c(6). Which is a non-profit category for trade unions and stuff. It's not a charity categorization. It's run by corporate members and works only for the members which are - surprise corporates. A community member like you or me doesn't have any say (Unless you have $325k per year to pay) - https://rustfoundation.org/get-involved/. This is the same case with Linux foundation as well. It's NOT a community project. The only difference is, Linus has more say cos trademark is on him.
PSF and Zig foundation are charity / commuinty projects cos they are non-profit 501 c(3). It's categorised as public charity or for the good of people. You and I can have more say in it. NOT THE CASE WITH RUST.
I may be wrong, but I think what they meant was rather "funded mostly by a single corp". Bus factor.
Nope. Rust is governed by corps. Its not a community project.
Sure, but slightly better than one corp.
One can argue about that - but probably not in context of the sub-thread:
> With the single commercial party owning it ...
>Which language would you classify as not corp owned?
I would like to respectfully disagree with you there as well. The above was the context. I was replying to this which opened the conversation.
Not to mention, end users and consumers don't get a say in the corp funded projects. Everything works as long as it aligns with the goals of the corp. Not otherwise.
Which corps govern rust? I’m not aware.
https://rustfoundation.org/members/
Apple’s the exception that proves the rule, they do a fantastic job supporting legacy APIs, frameworks, and devices
I’ve been in the Apple ecosystem in one form or the other 40 years and that’s definitely not true compared to Microsoft.
Most recently they dropped support for 32 bit Mac and iOS apps. But before that it was dropping support for PPC apps and 68K apps.
On the hardware side, the funniest was they dropped support for my Core 2 Duo Mac Mini and I could still install a supported version of Windows 7 on it.
> 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
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.
So then just use one version of Swift
Not viable to stay on an old version, especially doing iPhone dev. The real answer back in the Swift 1-4 times was to just use ObjC instead, it still had full support.
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.
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.
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.
There’s also hummingbird: https://github.com/hummingbird-project/hummingbird
Sadly this project is getting steadily slower. Adopting async made it slower than Django. But this is due to Swift limitations. Hopefully Swift replaces Codable and improves async performance.
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.
It's more of a peer to Go
In the case of Vapors (building "HTTP servers, backends and APIs") I'd say Node and Python are absolutely alternatives.
So is https://gotham.rs/!
I think they were just talking about the language features, not building web services generally
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.
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.
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.
Does not support Windows.
Like Rust, Swift is a compiled language that offers memory safety and data race safety by default.
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.
> by default
As far as I know there is no clear boundary between safe and unsafe.
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.
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.
async/await is useful
But what Swift lacked (in my day) was any support for parallelism.
They wrapped `fork` in a lot of mumbo jumbo, but it was just `fork`
May as well use C
> 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.
Righto. "Non-existent" is going too far.
I played around with their threads and found it was trivial to corrupt memory and crash.
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.
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.
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.
> …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.
Examples?
I think I have always seen it used in a relatively "simple" way. But that might be... "relative". :)
My encounters with Gradle have mainly been through Android development, so the example that springs to mind is how much of a pain in can be to get a project that's been sitting for a while patched up.
Basically, as a result of dependencies working only with certain versions of Gradle, it's very easy for an project with moderate to high complexity to wind up in a huge tangled mess when updating anything — updating Gradle might require you to update your dependencies, but all your dependencies might not support the version of Gradle you updated to, and the errors that get thrown as a result will be generic and won't tell you as much, sending you on a goose chase. This chain of events can also be set off by upgrading a single library for some feature you need.
It also makes it a pain to read others' Gradle files since there's no agreed upon standard, with everybody doing it a little bit differently.
In contrast, in the several years after switching my Apple platform projects to Swift Package Manager and away from CocoaPods, it's been rare for either toolchain or library upgrades to cause any sort of problem, and broadly speaking there's only a single correct way to write Swift package files, which makes them easier to read and work on.
Yes, because Apple gave up on the server market, so that demography usually uses Linux based servers and does code sharing between backend and their iDevices apps.
Only for iOS apps. Apple does not offer a backend.
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
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.
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.
Also announced today… AWS official support for Swift lambdas: https://aws.amazon.com/blogs/opensource/the-swift-aws-lambda...
Could SwiftUI ever be used outside of Apple?
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
Probably not, Apple would have to opensource it and that’s unlikely
No
I did try to build a medium sized project with this today. Still a lot of dependencies that will need to be updated for the differences between glibc and libc.
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)
> 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.
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.
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
> Why…
It’s almost always available resources.
Possibly demand as well. We know that Apple operates a whole bunch of Linux servers, do we know if they’re running FreeBSD internally?
I would say that LLVM is more important to FreeBSD than it is to Linux.
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.
I'm not complaining, but also why?
Why not? Why wouldn't an open source project want their increasingly platform-agnostic language to be supported on as many platforms as possible?
It’s a fantastic language? I’ve come to really like it. Strong type system, is it to work with, lots of resources available, compiles to a binary, interfacing with any other language that you can link to with C, the syntax doesn’t look ugly to me (quite subjective), excellent concurrency support…
What can I say I’m a fan.
What can you build with Swift on FreeBSD which isn't easier with other languages?
Everything will be easier to build with Swift on FreeBSD for a Swift developer compared to any other language
Software that is meant to run on Apple platforms.
Swift on Apple and Swift on literally-everything-else are very different stories at the moment.
Not that different anymore, except Apple-proprietary frameworks (e.g. SwiftUI) are not available outside of Apple platforms.
This isn't to dispute your assertion, but I think things are still quite a bit different. A lot of things provided by Foundation on macOS are still not available in Linux's Foundation, nor CoreFoundation, so one has to defer to something like Glibc — which, then again, is not available to the static Linux distro. On Windows, it's useful to use WinSDK to do things that Foundation would normally do.
There's all sorts of little things that Swift on non-Apple platforms just don't have yet. Little footguns because the Swift rewrite of Foundation isn't quite equivalent yet.
It is getting close though, which was my point. Honestly I got bit recently by DateComponentFormatter that does not exists on Linux, but it’s been a while since I’ve had things like that. We even have (NS)AttributedStrings (including the NS version, which I did not expect…). Of course no fonts and co, but that’s AppKit/UIKit/SwiftUI, so it’s normal.
absolutely not