6 ms·

Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?

by vtail 11mo ago

rootnod3 11mo ago
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 11mo ago
Only for iOS apps. Apple does not offer a backend.
- turnsout 11mo ago
  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 https://vapor.codes
  - repelsteeltje 11mo ago
    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 11mo ago
      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.
      - timsneath 11mo ago
        Also announced today… AWS official support for Swift lambdas: https://aws.amazon.com/blogs/opensource/the-swift-aws-lambda-runtime-moves-to-awslabs/ https://aws.amazon.com/blogs/opensource/the-swift-aws-lambda...
tiltowait 11mo ago
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 11mo ago
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/ 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 11mo ago
  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.
  - morshu9001 11mo ago
    It's more of a peer to Go
  - afavour 11mo ago
    In the case of Vapors (building "HTTP servers, backends and APIs") I'd say Node and Python are absolutely alternatives.
    - myko 11mo ago
      So is https://gotham.rs/ https://gotham.rs/! I think they were just talking about the language features, not building web services generally
  - ux266478 11mo ago
    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.
deleted 11mo ago
[deleted]
andrewl-hn 11mo ago
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.
- andrekandre 11mo ago
  > Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet. whats the holdup?
GeekyBear 11mo ago
Like Rust, Swift is a compiled language that offers memory safety and data race safety by default.
- worik 11mo ago
  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 11mo ago
    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.
    - worik 11mo ago
      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
  - w10-1 11mo ago
    > 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.
    - worik 11mo ago
tehnub 11mo ago
Could SwiftUI ever be used outside of Apple?
- dejv 11mo ago
  No
- MattDamonSpace 11mo ago
  Probably not, Apple would have to opensource it and that’s unlikely
- viktorcode 11mo ago
  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 11mo ago
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 11mo ago
  Apple’s the exception that proves the rule, they do a fantastic job supporting legacy APIs, frameworks, and devices
  - worik 11mo ago
    > 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 11mo ago
    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.
    - rTX5CMRXIfFG 11mo ago
      So then just use one version of Swift
      - morshu9001 11mo ago
        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.
  - 11mo ago
mk89 11mo ago
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 11mo ago
  > …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.
  - mk89 11mo ago
    Examples? I think I have always seen it used in a relatively "simple" way. But that might be... "relative". :)
    - cosmic_cheese 11mo ago
      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.
lukeh 11mo ago
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.
pjmlp 11mo ago
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.

Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?

by vtail 11mo ago

Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?

rootnod3 11mo ago

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 11mo ago

Only for iOS apps. Apple does not offer a backend.

turnsout 11mo ago
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 https://vapor.codes
- repelsteeltje 11mo ago
  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 11mo ago
    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.
    - timsneath 11mo ago
      Also announced today… AWS official support for Swift lambdas: https://aws.amazon.com/blogs/opensource/the-swift-aws-lambda-runtime-moves-to-awslabs/ https://aws.amazon.com/blogs/opensource/the-swift-aws-lambda...

tiltowait 11mo ago

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 11mo ago

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/ 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 11mo ago
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.
- morshu9001 11mo ago
  It's more of a peer to Go
- afavour 11mo ago
  In the case of Vapors (building "HTTP servers, backends and APIs") I'd say Node and Python are absolutely alternatives.
  - myko 11mo ago
    So is https://gotham.rs/ https://gotham.rs/! I think they were just talking about the language features, not building web services generally
- ux266478 11mo ago
  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.

deleted 11mo ago

[deleted]

andrewl-hn 11mo ago

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.

andrekandre 11mo ago
> Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet. whats the holdup?

GeekyBear 11mo ago

Like Rust, Swift is a compiled language that offers memory safety and data race safety by default.

worik 11mo ago
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 11mo ago
  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.
  - worik 11mo ago
    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
- w10-1 11mo ago
  > 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.
  - worik 11mo ago

tehnub 11mo ago

Could SwiftUI ever be used outside of Apple?

dejv 11mo ago
No
MattDamonSpace 11mo ago
Probably not, Apple would have to opensource it and that’s unlikely
viktorcode 11mo ago
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 11mo ago

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 11mo ago
Apple’s the exception that proves the rule, they do a fantastic job supporting legacy APIs, frameworks, and devices
- worik 11mo ago
  > 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 11mo ago
  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.
  - rTX5CMRXIfFG 11mo ago
    So then just use one version of Swift
    - morshu9001 11mo ago
      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.
- 11mo ago

mk89 11mo ago

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 11mo ago
> …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.
- mk89 11mo ago
  Examples? I think I have always seen it used in a relatively "simple" way. But that might be... "relative". :)
  - cosmic_cheese 11mo ago
    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.

lukeh 11mo ago

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.

pjmlp 11mo ago

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.