Steve Klabnik talked about how he and rest of the early Rust team recognised the importance of tools like this on a recent Oxide and Friends episode[0], it's well worth a listen.
I think this is a positive sign for Swift and Apple's continued push to increase it's viability as a general purposes language outside of Apple's ecosystems. It's still early, but directionally it's promising.
What I really want to know: If Rust developers are 'Rustaceans' and Golang developers are 'Gophers', are Swift developers 'Swifties'?
isodev
Some of us are also Swifties :)
DeepYogurt
Logic checks out
ein0p
I know a number of people at Apple, some of them pretty high up. The long and short of it is, Apple doesn't really give a shit about the world outside its ecosystem. It will interoperate when it has to (e.g. wifi, bluetooth, web standards) but if an effort does not help with selling Apple hardware, that effort will not get headcount or funding. So whatever multiplatform efforts you are seeing happen in spite of, not thanks to, Apple's stance.
K0nserv
I don't doubt that, but someone is definitely trying.
For example they moved Swift out of the Apple GitHub org and the announcement blog post[0] calls out Swift's use outside Apple's ecosystems.
Their blog archives has more posts that I read as a focus on improving Swift outside the Apple ecosystem, some examples:
* Updating the Visual Studio Code extension for Swift[1]
* Introducing Oblivious HTTP support in Swift[2]
* How Swift's server support powers Things Cloud[3]
I can see arguments for how wider adoption of Swift outside of Apple, and especially in the server ecosystem, helps Apple. In particular, lots of apps are being written using React Native and Flutter and at least one hurdle there is that Swift lacks developer mindshare.
It’s nice that a Swift LSP exists, is supported by the company behind the language, and is actively being worked on, because that makes it much more feasible to do things like build alternative IDEs.
Contrast this to Kotlin, which doesn’t have an LSP due to conflicts of interest with Jetbrains’ business. You either use a Jetbrains IDE or you don’t write Kotlin.
pjmlp
This and the whole anti-Java attitude on Android circles is what made me disregard Kotlin, how can one be so out of touch with what makes their ecosystem possible in first place.
It’s wholly a community effort and not supported by Jetbrains, which means it will always be at a disadvantage. Even development on it continues, it’ll always be a few steps behind the current version of Kotlin and will probably be missing a number of things compared to the autocomplete in Jetbrains IDEs.
It’s also built on the internal APIs of the Kotlin compiler, which are subject to change at any time. If Jetbrains shifts those around too dramatically it could break the LSP beyond the point that anybody is willing to repair it.
For corporate-developed languages first party LSPs are important.
yyyk
>3:... Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.
Ten minutes isn't very good for 30K lines.
e28eta
My guess is that 30k LOC is the 1st party code, and there’s probably a bunch of 3rd party dependencies that are also compiled as part of that. But maybe I’m wrong
mdhb
Apple so very clearly does not give a shit about anything outside of the Apple ecosystem, it’s kind of a core part of their company DNA at this point.
I can’t ever see Swift on the server or in other contexts catching on and honestly just with the way platforms as a whole are developing I can’t see Swift surviving as a mainstream language beyond the next 5 years. Its value proposition is already on shaky grounds and is actively getting worse with time the moment you look outside Apple’s walled garden. Unless they are able to keep that lock in at the same level moving forward it’s just got very little going for it.
I think something like 1/3 apps in the App Store are ALREADY written in Dart / Flutter which is probably even a nicer language from a developer experience point of view, with much much better tooling and documentation, that runs everywhere and has comparable performance.
rudedogg
> I can’t see Swift surviving as a mainstream language beyond the next 5 years.
I got into macOS development when Swift was first released, and used it heavily up until 2022 or so. I think I agree with you. The compiler is just too slow, and the language is too complex. And I think the issues are fundamental.
It sucks because I’m willing to develop for macOS exclusively, but the whole package is so rough and frustrating. Somehow they had every advantage (endless resources and complete platform control) and couldn’t put something together that’s better than Rust/Zig/whatever. Not to mention the inability to ship any useful AI developer tools, the dumb constraint of only shipping new major updates once a year at WWDC, the lack of ANY modern game development framework, etc..
I think I’ve finally talked myself into giving up on it.
lenkite
Apple should have incrementally improved Objective-C. It was pretty nice to work with. Sure there were some warts, but it was quick to compile and easy to grok. Swift is a huge ball of slow complexity.
The decay in Apple software quality has neatly coincided with the adoption of Swift.
cosmic_cheese
I can’t speak for Zig, but it seems like Rust is rather awkard with imperative UI frameworks, and instead is more inclined toward declarative/reactive frameworks. That’s one area where Swift is a bit more flexible, and one reason why I like it.
While I like to write simpler bits of UI in something like SwiftUI (think small components, recycled cells, etc) I find that declarative UI gets increasingly cumbersome as projects gain more features and become complex, and that doesn’t change much with the language it’s written in. As such my projects tend to be imperative-dominant with declarative components and maybe simpler screens sprinkled throughout. UIKit and SwiftUI work together nicely for this.
The only issue is the lack of UI frameworks for non-Apple platforms. There’s decent GTK+Adwaita bindings for Swift which is pretty solid for Linux, but to my knowledge the only thing out there for Windows at the moment are WinUI bindings written by The Browser Company for Arc, but as I understand it those are still pretty incomplete.
Compile times haven’t be a problem for me, even with complex codebases. Incremental builds are fast enough and I’m not running full builds often enough for that to impact my overall evaluation of the language.
andrekandre
> The compiler is just too slow, and the language is too complex.
also error messages are next to useless in many cases
this really trips up new users and (speaking from experience) unless you have someone that can mentor them they're gonna give up pretty fast
swift is evolving so quickly to fill gaps in capabilities but the tooling and ux of actually coding (speed, error messages, fixits etc) really needs heavy work badly imo
hirvi74
Since Apple cares about their ecosystem so much, I wish they would give a bit more of a shit about Xcode.
I wish they'd keep updating AppleScript more, or just completely replace it, but I do not blame Apple on that one. Swift could absolutely replace AppleScript in terms of functionality, but that wouldn't make Apple any money. So, we all know that will never happen.
icedchai
I hadn't fired up Xcode in years. Yesterday, I compiled an open source app and was amazed how little the UI and UX has improved. I used to do quite a bit of Objective C mobile development up until 2012 or so.
andrekandre
im the opposite, i want them to give up and switch over to open source tooling - instead of all the bespoke apple stuff - we should be able to build apps with lsp and swift package manager imo
the xcode ui part can be open sourced so the community evolve/improve it better since apple has like max 3 people working on it apparently
pjmlp
The story of Swift on server is for Apple shops doing iDevices development, which server backends, remember Apple no longer sells OS X servers.
Additionally Apple isn't Google, Swift has more chances to survive as proprietary language on Apple ecosystem, than Dart as FOSS if Google ever gets bored as usual.
ein0p
I kinda wish it did actually catch on outside the Apple ecosystem. I like the language quite a bit, but since I no longer program for MacOS even peripherally, I don't get to use it. But I'm afraid it's going to need a miracle at this point, Rust and Go have a massive, insurmountable lead on non-Apple platforms. It could be argued that Swift's catching on outside macOS would be very good for Apple, by expanding the pool of developers proficient in Swift, and removing the friction towards people using their Linux code on Apple systems. But Apple is blessed with an AppStore which is not a complete dumpster fire, so they probably don't feel the need to do any of that, and feel like they'd be sinking millions into an initiative that has zero chance of success.
freeone3000
That’s honestly depressing. I used flutter because I couldn’t figure out XCode, and am continually lamenting the poor type-checking, static analysis, and mediocre performance… how is swift worse?
mdhb
Darts type system and static analysis are genuinely great… I have no idea what you’re talking about.
Flutter does 120fps with ease I’m also confused what you’re talking about there too
That story never happened, I remember it well because everyone like you went insane about it but when the truth came out it ended up being that their headcount has literally changed by one person.
More or less this, with some able to produce a few community nuggets, but it will take another vendor (and IBM tried at some point) to push Swift into actuality as a true cross platform language.
In another world, maybe instead of Java / Kotlin Google would have pivoted onto Swift as a language for mobile, closing the gap between the platforms a bit.
scarface_74
You mean for profit companies only do things that are in their self interest? I am shock!
afiori
The complaint is that a lot of companies have a very shallow and short term sense of self-interest as if they were starved for cash and in a non-positive sum game
scarface_74
You don’t survive in the tech industry for 50 years and be the most valuable company for the last 15 by thinking short term.
This isn’t unique to Apple. Microsoft has been around for 50 years and been one of the five most valuable companies since 2000. Amazon has been around for 30.
afiori
The strategies to get to the top and those to stay there can be very different.
Still you are right, thinking more about what I was trying to say I agree that my comment was off.
I think that what I was trying to criticize was better described as a myopic focus on a few quantifiable metric, often lacking an olistic approach
steveklabnik
Glad you enjoyed!
And yeah, it’s good to see this for Swift.
babuloseo
whats your thoughts on uv https://github.com/astral-sh/uv I am blown away, installing python packages used to take so long now I dont even think about it, really made Python more viable.
steveklabnik
It seems quite good!
lukeh
Things I like about Swift: works great on Linux, fun to write in, excellent interoperability with C, C++ and even Java.
Thinks I like less: compile times, binary size, runtime type introspection overhead (Codable performance was killing our application), getting async/await right (still that's always going to be hard whichever way you slice it).
sidkshatriya
What happened to Swift ? I used to hear so much about it -- now not so much. Maybe I'm in my echo chamber ?
pjmlp
Mostly likely your echo chamber is outside Apple developer ecosystem?
Swift is doing great.
jtrueb
??? Swift is terrible right now. Language features conflicting, async story migrating, compile issues horrific and IDE support in its infancy.
jmull
I haven't noticed particular issues.
I would hardly say perfect, but it's regular headaches.
cosmic_cheese
I’ve not had much trouble either, not recently anyway. The transition from v1 → v2 → v3 was rough, but that’s par for the course when you’re an early adopter.
The new async model looks like a bit of a bear, but that’s why there’s a toggle for it that works on a per-module level so you can incrementally adopt it whenever you see fit.
Honestly I’ve had more pain out of the Kotlin/Android experience in the past several years. If Swift suddenly became a tier 1 language option there I’d switch right away.
jtrueb
How many years old is your swift codebase?
pjmlp
Most Objective-C codebases are brown field development.
Apple themselves, the only framework that they started from scratch in recent years was Metal, and even there only die hards use Objective-C instead of the Swift bindings.
Could be better, it isn't as bad as you make it to be, for a language whose design goals are to replace C, C++ and Objective-C for Apple.
jtrueb
Having worked on the old, the migrating, and the new, I appreciate Swift more than Objective-C mostly due to IDE support.
If they had put the effort into Objective-C++ that they put into Swift, I struggle to imagine it in a worse place than Swift is in these days.
How many packages will work without NSBullshit though?
lukeh
More and more, and Foundation is now sharing a codebase between Darwin and non-Darwin platforms for many types now.
jshier
Nearly all, since they removed the NS prefix from most types imported into Swift years ago. ;)
danpalmer
I’ve been using it for a hobby project targeting a Linux server deployment. It’s good, and I don’t think the Apple ties are what’s holding it back now, I think it’s a relative lack of good frameworks and libraries. What’s there is often excellent quality, but it’s still a bit hit and miss even for common library use cases.
I often think about what my day-1 stack would be for a new company. Swift would be on the table as an option.
isodev
Indeed, it’s technically possible, but the level of discomfort, workarounds and paper cuts to get there makes it entirely a hobby thing.
If you really want to make “something” for the purpose of using Swift go ahead. If you want to make something, there are plenty of attentives to choose from.
liuliu
If you stick with x86_64 land and > Swift 6.0, there is nothing infeasible about it.
MarcusE1W
I can find binary packages for Linux ARM for Swiftly and Swift.
What issues do you see outside of X86_64 ?
So is this like UV for swift or what is the gain here or can I ditch Xcode and use this instead?
nindalf
It's like rustup or nvm (node version manager) for Swift. Swiftly installs Swift. If all you needed Xcode for was to install Swift then yes, you can replace Xcode with swiftly.
jagged-chisel
Keep in mind, however, that there seems to be an intentional handicap if you’re on an older version of macOS: you can’t install the latest Swift.
I have an Intel-based MacBook Pro that doesn’t update beyond macOS 13, and it runs neither Xcode 16 nor Swift 6. Presumably, one might be able to build Swift 6 from source. My workaround is containers.
throwaway48476
Apple is even more egregious than windows 10 years of support. As computers aren't getting faster at the same rate as before companies are forcing obsolescence more.
curun1r
> that doesn’t update beyond macOS 13
...in a way supported by Apple. But OpenCore [0] makes installing the latest OS on older Macs relatively simple. You lose out on some features that your hardware doesn't support (e.g. Apple Intelligence), but most of that is unnecessary at best.
no, its similar to pyenv, its for installing, updating, managing swift lang versions.
bonestamp2
This is cool. I haven't looked a swift since it first came out but I wonder if their documentation is any better now... I remember trying to do things and I'd read about commands on Stack overflow that I couldn't even find in their documentation, or they were listed in the documentation but had literally no useful information about them.
tiffanyh
Zig
Isn’t a major reason why people enjoy Zig so much is because of the built-in tooling such as this, having it Day 1 with the language.
natemcintosh
I think this will be a big boost to the swift ecosystem. The ability to add and remove language versions as needed is so convenient, and I'm glad more and more languages are adding it.
mleonhard
Will this make it possible to run unit tests of code that needs to import UIKit, outside of Simulator?
fithisux
Windows support would be good to have for people to try it out.
I think this is a positive sign for Swift and Apple's continued push to increase it's viability as a general purposes language outside of Apple's ecosystems. It's still early, but directionally it's promising.
0: https://oxide-and-friends.transistor.fm/episodes/a-happy-day...
For example they moved Swift out of the Apple GitHub org and the announcement blog post[0] calls out Swift's use outside Apple's ecosystems.
Their blog archives has more posts that I read as a focus on improving Swift outside the Apple ecosystem, some examples:
* Updating the Visual Studio Code extension for Swift[1]
* Introducing Oblivious HTTP support in Swift[2]
* How Swift's server support powers Things Cloud[3]
I can see arguments for how wider adoption of Swift outside of Apple, and especially in the server ecosystem, helps Apple. In particular, lots of apps are being written using React Native and Flutter and at least one hurdle there is that Swift lacks developer mindshare.
0: https://www.swift.org/blog/swiftlang-github/
1: https://www.swift.org/blog/the-next-chapter-in-swift-build-t...
2: https://www.swift.org/blog/introducing-swift-nio-oblivious-h...
3: https://www.swift.org/blog/how-swifts-server-support-powers-...
Contrast this to Kotlin, which doesn’t have an LSP due to conflicts of interest with Jetbrains’ business. You either use a Jetbrains IDE or you don’t write Kotlin.
It’s also built on the internal APIs of the Kotlin compiler, which are subject to change at any time. If Jetbrains shifts those around too dramatically it could break the LSP beyond the point that anybody is willing to repair it.
For corporate-developed languages first party LSPs are important.
Ten minutes isn't very good for 30K lines.
I can’t ever see Swift on the server or in other contexts catching on and honestly just with the way platforms as a whole are developing I can’t see Swift surviving as a mainstream language beyond the next 5 years. Its value proposition is already on shaky grounds and is actively getting worse with time the moment you look outside Apple’s walled garden. Unless they are able to keep that lock in at the same level moving forward it’s just got very little going for it.
I think something like 1/3 apps in the App Store are ALREADY written in Dart / Flutter which is probably even a nicer language from a developer experience point of view, with much much better tooling and documentation, that runs everywhere and has comparable performance.
I got into macOS development when Swift was first released, and used it heavily up until 2022 or so. I think I agree with you. The compiler is just too slow, and the language is too complex. And I think the issues are fundamental.
It sucks because I’m willing to develop for macOS exclusively, but the whole package is so rough and frustrating. Somehow they had every advantage (endless resources and complete platform control) and couldn’t put something together that’s better than Rust/Zig/whatever. Not to mention the inability to ship any useful AI developer tools, the dumb constraint of only shipping new major updates once a year at WWDC, the lack of ANY modern game development framework, etc..
I think I’ve finally talked myself into giving up on it.
The decay in Apple software quality has neatly coincided with the adoption of Swift.
While I like to write simpler bits of UI in something like SwiftUI (think small components, recycled cells, etc) I find that declarative UI gets increasingly cumbersome as projects gain more features and become complex, and that doesn’t change much with the language it’s written in. As such my projects tend to be imperative-dominant with declarative components and maybe simpler screens sprinkled throughout. UIKit and SwiftUI work together nicely for this.
The only issue is the lack of UI frameworks for non-Apple platforms. There’s decent GTK+Adwaita bindings for Swift which is pretty solid for Linux, but to my knowledge the only thing out there for Windows at the moment are WinUI bindings written by The Browser Company for Arc, but as I understand it those are still pretty incomplete.
Compile times haven’t be a problem for me, even with complex codebases. Incremental builds are fast enough and I’m not running full builds often enough for that to impact my overall evaluation of the language.
this really trips up new users and (speaking from experience) unless you have someone that can mentor them they're gonna give up pretty fast
swift is evolving so quickly to fill gaps in capabilities but the tooling and ux of actually coding (speed, error messages, fixits etc) really needs heavy work badly imo
I wish they'd keep updating AppleScript more, or just completely replace it, but I do not blame Apple on that one. Swift could absolutely replace AppleScript in terms of functionality, but that wouldn't make Apple any money. So, we all know that will never happen.
the xcode ui part can be open sourced so the community evolve/improve it better since apple has like max 3 people working on it apparently
Additionally Apple isn't Google, Swift has more chances to survive as proprietary language on Apple ecosystem, than Dart as FOSS if Google ever gets bored as usual.
Flutter does 120fps with ease I’m also confused what you’re talking about there too
https://techcrunch.com/2024/05/01/google-lays-off-staff-from...
https://9to5google.com/2021/10/10/google-ios-apps-native/con...
In another world, maybe instead of Java / Kotlin Google would have pivoted onto Swift as a language for mobile, closing the gap between the platforms a bit.
This isn’t unique to Apple. Microsoft has been around for 50 years and been one of the five most valuable companies since 2000. Amazon has been around for 30.
Still you are right, thinking more about what I was trying to say I agree that my comment was off.
I think that what I was trying to criticize was better described as a myopic focus on a few quantifiable metric, often lacking an olistic approach
And yeah, it’s good to see this for Swift.
Thinks I like less: compile times, binary size, runtime type introspection overhead (Codable performance was killing our application), getting async/await right (still that's always going to be hard whichever way you slice it).
Swift is doing great.
I would hardly say perfect, but it's regular headaches.
The new async model looks like a bit of a bear, but that’s why there’s a toggle for it that works on a per-module level so you can incrementally adopt it whenever you see fit.
Honestly I’ve had more pain out of the Kotlin/Android experience in the past several years. If Swift suddenly became a tier 1 language option there I’d switch right away.
Apple themselves, the only framework that they started from scratch in recent years was Metal, and even there only die hards use Objective-C instead of the Swift bindings.
Could be better, it isn't as bad as you make it to be, for a language whose design goals are to replace C, C++ and Objective-C for Apple.
If they had put the effort into Objective-C++ that they put into Swift, I struggle to imagine it in a worse place than Swift is in these days.
I often think about what my day-1 stack would be for a new company. Swift would be on the table as an option.
If you really want to make “something” for the purpose of using Swift go ahead. If you want to make something, there are plenty of attentives to choose from.
I have an Intel-based MacBook Pro that doesn’t update beyond macOS 13, and it runs neither Xcode 16 nor Swift 6. Presumably, one might be able to build Swift 6 from source. My workaround is containers.
...in a way supported by Apple. But OpenCore [0] makes installing the latest OS on older Macs relatively simple. You lose out on some features that your hardware doesn't support (e.g. Apple Intelligence), but most of that is unnecessary at best.
[0] https://dortania.github.io/OpenCore-Legacy-Patcher/
Isn’t a major reason why people enjoy Zig so much is because of the built-in tooling such as this, having it Day 1 with the language.