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.
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.
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.
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.
Well, for Android specifically I’m not sure anti-Java sentiment is necessarily entirely unjustified with how Android tends to be stuck on some ancient version, and it’s not as if the JVM ecosystem doesn’t have its warts (though those are largely shared by Kotlin).
Which is made on purpose to sell Kotlin on the platform, those having had this decision are part of the same anti-Java group I was mentioning, as per remarks on podcasts and other appearances.
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.
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
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.
> 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.
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.
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.
> 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
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.
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.
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
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.
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.
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?
I was asking the flutter app to act as a bluetooth mesh hub and it started dropping packets when the (external) simulator got to 5000 devices, when the same algorithm in C++ running on a pi 2020 (which is much weaker than the A17!) managed the full 16000 theoretically possible. The profiler (which… opened in a web browser?) tracked it back to most of the time being spent in averaging and rolling encryption, it wasn’t bluetooth-locked.
Developing was also frustrating, with Android Studio simply being unable to signal compilation errors, and many issues only showing up on one phone or another. The zeroconf libraries have different methods, but this could not be detected until runtime on either device. The device I wasn’t actively testing on frequently had some regression in sensors, bluetooth, or even UI.
It did display an animation OK, so no fault there I suppose.
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.
You’ve posted one dumb thing after another and pretended like you’ve made a great point after each one. That’s really a special kind of moron who does that. Have a good day.
Google has the attention span of a crack addled flea. It is crazy to base any part of your career on a technology that the company doesn’t use extensively internally.
It doesn’t worry you that Google doesn’t have enough confidence any Flutter to use it in its own native apps?
Just one app? Flutter will die like most google projects. At best it's a mediocre language that only does mobile. The kind of people who are fine with that kind fluff in their brain already picked swift and/or kotlin. They're not moving to a new language just to gain ONE single extra platform (none if they're already efficient in both)
I can’t tell if this is a parody account or you’re just completely mismatched between confidence and skill.
Your comment history seems to just be filled with you talking about topics that you clearly have zero conceptual understanding of with full confidence while you argue with people who try to explain to people how you are wrong.
Today it’s thinking flutter is a language or that it only does mobile or that nobody uses it. Like all three of those points are objectively wrong.
Yesterday it’s somehow managing to get confused between gRPC and MCP then the idea of stateless and stateful protocols and a bunch of other things.
Maybe you should spend a lot more time reading and less time confidently telling people they are wrong on topics you don’t actually understand.
You’re very much in a bubble. Most apps aren’t written using Flutter - including apps by Google.
It would be like Apple creating a new app and not using Swift.
It’s just an insane career move to be dependent on Flutter or any Google technology really instead of using Java or Kotlin or a more popular cross platform frameworks.
No confusion there, guy just asumming mcp should be higher than grpc in the thread where we are agueing where should mcp be. It's too idiotic for me to continue arguing with. Same to stateful vs stateless. Tool calling is stateless, if you wrap it up with a protocol and claim that it should be stateful, then it's reasonable to ask how exactly.
And then you "psst dart can do web and server" me, like kotlin, swift, typescript and basically everything else these days cannot do the same thing. No one takes server side swift or server side dart seriously, you don't pick a technology based on what it theoretically does, should be based on what it practically does, and that only.
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.
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
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.
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.
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).
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.
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.
I think that is a bit of an overstatement given the amount of legacy code and bindings generation capabilities. I do think it had to swing towards memory safe and C++ still didn’t have a plan for smart pointers much less move semantics when Swift dev started.
Who knows what present day Objective-C++ could have been if it had been the workhorse language of choice. Maybe this profiles thing Bjarne is pushing could have been in the roadmap. We will never know.
Not at all, besides Objective-C would have been dead by now, had it not been for NeXT reverse acquisition of Apple.
Additionally Objective-C++ never was seen anything beyond interop with existing C++ code, and only old timers like myself have its documentation, you will hardly find anything about it on Apple's documentation nowadays.
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.
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.
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.
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.
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.
...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.
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.
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.
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.
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.
The decay in Apple software quality has neatly coincided with the adoption of Swift.
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
Developing was also frustrating, with Android Studio simply being unable to signal compilation errors, and many issues only showing up on one phone or another. The zeroconf libraries have different methods, but this could not be detected until runtime on either device. The device I wasn’t actively testing on frequently had some regression in sensors, bluetooth, or even UI.
It did display an animation OK, so no fault there I suppose.
https://techcrunch.com/2024/05/01/google-lays-off-staff-from...
https://9to5google.com/2021/10/10/google-ios-apps-native/con...
You’re making shit up. Take the L and move on
And Google Earth - as opposed to Google maps, Drive, Sheets, Docs, etc is not a “major app”.
Flutter and Dart are going to end up in the same graveyard as many of their other products - https://killedbygoogle.com/
It doesn’t worry you that Google doesn’t have enough confidence any Flutter to use it in its own native apps?
Your comment history seems to just be filled with you talking about topics that you clearly have zero conceptual understanding of with full confidence while you argue with people who try to explain to people how you are wrong.
Today it’s thinking flutter is a language or that it only does mobile or that nobody uses it. Like all three of those points are objectively wrong.
Yesterday it’s somehow managing to get confused between gRPC and MCP then the idea of stateless and stateful protocols and a bunch of other things.
Maybe you should spend a lot more time reading and less time confidently telling people they are wrong on topics you don’t actually understand.
It would be like Apple creating a new app and not using Swift.
It’s just an insane career move to be dependent on Flutter or any Google technology really instead of using Java or Kotlin or a more popular cross platform frameworks.
And then you "psst dart can do web and server" me, like kotlin, swift, typescript and basically everything else these days cannot do the same thing. No one takes server side swift or server side dart seriously, you don't pick a technology based on what it theoretically does, should be based on what it practically does, and that only.
People like you are impossible to deal with. I’m ending this chat.
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.
From language features and community culture point of view.
Who knows what present day Objective-C++ could have been if it had been the workhorse language of choice. Maybe this profiles thing Bjarne is pushing could have been in the roadmap. We will never know.
Additionally Objective-C++ never was seen anything beyond interop with existing C++ code, and only old timers like myself have its documentation, you will hardly find anything about it on Apple's documentation nowadays.
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.