A very solid release with very nice immediate conveniences/improvements and foundational long term work.
I’m particularly impressed at the team’s continued investment in non-Apple platforms. IMO, true cross platform Swift codebases still seems out of reach for most shops. But if they keep this up for a few more years then Swift could become a very compelling cross platform language — for both systems and application programming.
The big hurdle they need to figure out is the standard library and especially SwiftUI. SwiftUI is the single most important library that essentially all Apple swift codebases use, so until there is a real cross platform SwiftUI then for app programming IMO Swift will remain a novelty.
There are other frameworks, like eg Network.framework, which really should be in the stdlib as well.
SwiftUI is Apple secret sauce. That’s never going to be released.
All the compiler features are there. Others can make similar libraries or other new libraries.
But I don’t see why Apple would ever release that outside Apple land. Swift can still be used for shared logic and server stuff and command line tools and GUIs using other libraries.
Which was open sourced sometime back, and builds iOS and Android apps, which is really neat, because it means your Android app's logic etc is all natively compiled, only a shim of Java to run it. I wish Google would let people publish standard compiled binaries for their OS instead of just making everything rely on the ART.
Honestly, I am jealous of the number of RAD IDEs from the 90s and early 00s we need to start investing in good tooling again.
Actually that’s supposed to have switched this year. Reportedly the legacy stuff is now wrapped SwiftUI so they all render the same buttons/text boxes/etc.
No more 2 (or maybe 3 for carbon?) implementations.
Hopefully this will let them add features and fix bugs faster.
I think cross-platform Swift is likely to always be a niche like it was with Objective-C. Apple has too much control over the language and too much of a vested interest in retaining that control and modifying the language for its own needs. E.g., the stuff that got shoved in to support SwiftUI with none of the typical review processes until AFTER Apple had already built a shipping framework on it. It was around that time IBM announced it was abandoning server-side Swift as well.
The opensource cross-platform equivalent, but not drop-in, alternative of Network.framework is https://github.com/apple/swift-network-evolution, which re-implements much of the API surface from scratch, including QUIC.
I love the friendly competition between Swift, Rust and Zig. Swift has been adding borrow checking features for a while, now they also have arenas, better C interop and more language support for non GC platforms.
As a coder of 30+ years in various other languages that sincerely wants to learn Swift can someone please help me understand why it is not diametrically opposed for a company to suggest, effectively in the same breath no less, that I should learn to code Swift myself and/or just have some AI do it?
Every time I set out to learn I just feel like I'm being an idiot because in a year, or now, nobody will hand code anything. And even if we still reckon that some knowledge will be required to verify the voluminous output of AI there is now a vast moat of Jr. unemployability that has arisen making it exponentially harder to justify learning to code in the first place?
If you're looking for a pay off for learning anything at all, just don't---AI is projected to take over a lot of knowledge areas. You'd better invest in learning a physical skill or build a network of high net worth people and somehow make something of it.
Now, if AI eating the world doesn't matter to you, then just learn what you want to learn.
Beautiful? Just the number of keywords and reserved words and compiler attributes makes it very ugly to me. There are so many ways to do things (and if SwiftUI is involved I can expect a significant subset to... just not work - but I don't think that's the language's fault).
What would you have done differently? All healthy languages need to constantly evolve, you only get to decide where. You can change syntax, add keywords, attributes, etc but it's a tradeoff.
Any attributes or keywords relating to Objective-C or interop are not everyday baggage for most people.
For SwiftUI, attributes seem like as good a choice as anything else.
As a whole concurrency is a mishmash syntactic mess, but I agree with the direction and the result, they're trying to manage the improvements they keep adding over years of investment.
Why click into this thread then? Do you think they will make a Swift 7 with these release notes:
- removed 10 keywords cause chairhairair didn't like them
- fixed swiftui cause too many users don't know order matters
- added another dsl implementation
The number of keywords in Swift is not an uncommon criticism . Even Chris Lattner is critical of the direction Swift went in after its inception. I'm not sure what you're referring to with "order matters," but SwiftUI's issues go far beyond the order of the modifiers used.
Init can become a hassle. And I'm not the only one, I remember listening (to a podcast?) where Chris Lattner himself remarked that there were many nitty-gritty details to the init phase of objects.
I don't know how long visionOS will survive, it seems Apple has scaled down further development of Vision Pro quite substantially. And for something like Meta-style smart glasses, visionOS is probably not a good fit.
I didn’t realise Swift in WebAssembly has come as far as it has. I’ll be interested to try it out, I’ve used Rust before now but Swift is definitely easier to work with.
Yes to the subprocess 1.0. CommandLine utils are how I try out any new language. I feel like Swift hits the sweet spot for me in terms of safety, cross platform capability, ahead of time compilation, and automatic memory management compared to other languages currently available.
I think a lot of the cross-platform interest from other companies diminished after features like result builders were quietly dropped in to support SwiftUI, with the usual community review process happening after it was already revealed at WWDC and shipping in Xcode (!). It's clear that Apple runs the show, and like Objective-C, it seems destined to be primarily an Apple language for Apple platforms and tools.
It's been over a decade since Swift came out, and cross-platform Swift remains extremely niche. I think that ship has sailed and that Swift is in the same situation Objective-C was, perceived as being an Apple language for Apple platforms, controlled by Apple.
It isn't, I didn't deny Swift's usability in other platforms, but you'll see it barely mentioned anywhere else, and Swift Circles are also mainly centered around Apple
Man I can't count the number of shell wrappers I've written or reached out to over my career. Looking forward to having an official Swift SubProcess helper.
This is a very impressive release. The continued type checker improvements are amazing, improved memory safety helping to expose hidden traps, improved debugging, improved dev experience for Android. Great job!
I really hope the debugger improvements are noticeable. The number of times I've stopped in a debugger and I can't see the variables I want to look at has been extremely high.
it's surprising how often this has been an issue. given up on it a long time ago. now old school print statements instead. seem to work better anyway. the debugger isn't slowing the app down.
Interesting tidbit about not having the Foundation library. Every Swift project I worked on had to import that, so I imagine it's annoying to lose that
I am building the backend of a social media app I am making in Swift. I've previously used Vapor for the web server but right now, I am trying out Hummimgbird.
Has anyone tried either? Would love to hear your experience with them.
reminds me that macOS could really use something like powershell (I know you can run powershell on macOS) where you pass around structured data, rather than the endless parsing and reparsing. This is mostly a feature of the shell but you do need some language infrastructure to accomplish it.
To me the secret sauce behind powershell is the .NET infrastructure, which allows much more runtime introspection than the usual compiled programming languages, allowing a lot of flexibility without being too wonky. Unfortunately the Windows team seemed to not be on board with this vision, and thus it cannot achieve its full potential. The objective-c runtime may have been a good alternative here too, but I don't think Apple is encouraging its use anymore (and Objective-C is not the right language for that, neither is AppleScript imo).
You can also access COM from PowerShell, which basically opens up a lot of the Windows world to it.
And both .NET and COM and the object-oriented history of Windows is probably also why PowerShell will never really feel "at home" on UNIX platforms, for better or worse.
I was a big fan of Nushell for some time but has the same problems as unix shells. I have this CLI tool that manages a lot of things for me (a big one is downloading and cataloging arxiv papers, it downloads them and tags them with metadata and gives each PDF a proper filename based on the author's name and publication year). I tried building this in Nushell but it became eventually so painful.
It's both curse and blessing. Of course it gives you ultimate freedom, but like with programming languages, I personally prefer the guardrails that a type system provides.
A very solid release with very nice immediate conveniences/improvements and foundational long term work.
I’m particularly impressed at the team’s continued investment in non-Apple platforms. IMO, true cross platform Swift codebases still seems out of reach for most shops. But if they keep this up for a few more years then Swift could become a very compelling cross platform language — for both systems and application programming.
The big hurdle they need to figure out is the standard library and especially SwiftUI. SwiftUI is the single most important library that essentially all Apple swift codebases use, so until there is a real cross platform SwiftUI then for app programming IMO Swift will remain a novelty.
There are other frameworks, like eg Network.framework, which really should be in the stdlib as well.
SwiftUI is Apple secret sauce. That’s never going to be released.
All the compiler features are there. Others can make similar libraries or other new libraries.
But I don’t see why Apple would ever release that outside Apple land. Swift can still be used for shared logic and server stuff and command line tools and GUIs using other libraries.
You don't 100% need them to release it, there's projects like Skip:
https://skip.dev/
Which was open sourced sometime back, and builds iOS and Android apps, which is really neat, because it means your Android app's logic etc is all natively compiled, only a shim of Java to run it. I wish Google would let people publish standard compiled binaries for their OS instead of just making everything rely on the ART.
Honestly, I am jealous of the number of RAD IDEs from the 90s and early 00s we need to start investing in good tooling again.
Incidentally, there's a nascent OSS project called OpenSwiftUI.
https://github.com/OpenSwiftUIProject/OpenSwiftUI
Not to mention it’s built on top of Apple’s other private UI frameworks
Actually that’s supposed to have switched this year. Reportedly the legacy stuff is now wrapped SwiftUI so they all render the same buttons/text boxes/etc.
No more 2 (or maybe 3 for carbon?) implementations.
Hopefully this will let them add features and fix bugs faster.
I think cross-platform Swift is likely to always be a niche like it was with Objective-C. Apple has too much control over the language and too much of a vested interest in retaining that control and modifying the language for its own needs. E.g., the stuff that got shoved in to support SwiftUI with none of the typical review processes until AFTER Apple had already built a shipping framework on it. It was around that time IBM announced it was abandoning server-side Swift as well.
The opensource cross-platform equivalent, but not drop-in, alternative of Network.framework is https://github.com/apple/swift-network-evolution, which re-implements much of the API surface from scratch, including QUIC.
“Novelty” is a stretch. There’s a lot of headless code in the world.
I love the friendly competition between Swift, Rust and Zig. Swift has been adding borrow checking features for a while, now they also have arenas, better C interop and more language support for non GC platforms.
As a coder of 30+ years in various other languages that sincerely wants to learn Swift can someone please help me understand why it is not diametrically opposed for a company to suggest, effectively in the same breath no less, that I should learn to code Swift myself and/or just have some AI do it?
Every time I set out to learn I just feel like I'm being an idiot because in a year, or now, nobody will hand code anything. And even if we still reckon that some knowledge will be required to verify the voluminous output of AI there is now a vast moat of Jr. unemployability that has arisen making it exponentially harder to justify learning to code in the first place?
groan
If you're looking for a pay off for learning anything at all, just don't---AI is projected to take over a lot of knowledge areas. You'd better invest in learning a physical skill or build a network of high net worth people and somehow make something of it.
Now, if AI eating the world doesn't matter to you, then just learn what you want to learn.
If you have that much experience, swift is probably just a mix of what you already know? Do a couple of tutorials and then you are ready to vibe it.
It's the people who haven't done the grind of learning a new language so have the problem, since LLM will give them solutions but not experience.
Happy to see Swift progress. Its a beautiful language and well thought out. Would love to see it expand outside of iOS
Beautiful? Just the number of keywords and reserved words and compiler attributes makes it very ugly to me. There are so many ways to do things (and if SwiftUI is involved I can expect a significant subset to... just not work - but I don't think that's the language's fault).
What would you have done differently? All healthy languages need to constantly evolve, you only get to decide where. You can change syntax, add keywords, attributes, etc but it's a tradeoff.
Any attributes or keywords relating to Objective-C or interop are not everyday baggage for most people.
For SwiftUI, attributes seem like as good a choice as anything else.
As a whole concurrency is a mishmash syntactic mess, but I agree with the direction and the result, they're trying to manage the improvements they keep adding over years of investment.
Why click into this thread then? Do you think they will make a Swift 7 with these release notes: - removed 10 keywords cause chairhairair didn't like them - fixed swiftui cause too many users don't know order matters - added another dsl implementation
Oh, are only positive reactions allowed?
The number of keywords in Swift is not an uncommon criticism . Even Chris Lattner is critical of the direction Swift went in after its inception. I'm not sure what you're referring to with "order matters," but SwiftUI's issues go far beyond the order of the modifiers used.
For many people a beautiful language is which looks beautiful, as opposed to one which reads beautifully.
Except for the rules around init
What do you mean?
This[1], I suspect.
https://docs.swift.org/swift-book/documentation/the-swift-pr...
Init can become a hassle. And I'm not the only one, I remember listening (to a podcast?) where Chris Lattner himself remarked that there were many nitty-gritty details to the init phase of objects.
You can use it on macOS, iPadOS, watchOS and tvOS as well. Oh, and visionOS, at least for now.
For now?
I don't know how long visionOS will survive, it seems Apple has scaled down further development of Vision Pro quite substantially. And for something like Meta-style smart glasses, visionOS is probably not a good fit.
Thanks Mr. Steve not Jobs for outsider information.
Always welcome. Just ask if you want to hear more.
I didn’t realise Swift in WebAssembly has come as far as it has. I’ll be interested to try it out, I’ve used Rust before now but Swift is definitely easier to work with.
Goodnotes is already doing it. Their web app runs a large amount of the same Swift code used by their iOS app inside the browser through WebAssembly.
Goodnotes wrote about their WebAssembly work on the Swift blog earlier this year: https://www.swift.org/blog/bringing-goodnotes-to-web-with-sw...
From that post: "Shared Swift code: 1.47 million lines (66% of the web app, 34% of the iOS app)"
Yes to the subprocess 1.0. CommandLine utils are how I try out any new language. I feel like Swift hits the sweet spot for me in terms of safety, cross platform capability, ahead of time compilation, and automatic memory management compared to other languages currently available.
Its really a shame Swift had to be the Apple language, it is really very nicely made
I think a lot of the cross-platform interest from other companies diminished after features like result builders were quietly dropped in to support SwiftUI, with the usual community review process happening after it was already revealed at WWDC and shipping in Xcode (!). It's clear that Apple runs the show, and like Objective-C, it seems destined to be primarily an Apple language for Apple platforms and tools.
This is a troll comment considering the post is all about Swift’s portability on other platforms.
It's been over a decade since Swift came out, and cross-platform Swift remains extremely niche. I think that ship has sailed and that Swift is in the same situation Objective-C was, perceived as being an Apple language for Apple platforms, controlled by Apple.
It isn't, I didn't deny Swift's usability in other platforms, but you'll see it barely mentioned anywhere else, and Swift Circles are also mainly centered around Apple
Man I can't count the number of shell wrappers I've written or reached out to over my career. Looking forward to having an official Swift SubProcess helper.
This is a very impressive release. The continued type checker improvements are amazing, improved memory safety helping to expose hidden traps, improved debugging, improved dev experience for Android. Great job!
I really hope the debugger improvements are noticeable. The number of times I've stopped in a debugger and I can't see the variables I want to look at has been extremely high.
Since the release of Swift. :|
it's surprising how often this has been an issue. given up on it a long time ago. now old school print statements instead. seem to work better anyway. the debugger isn't slowing the app down.
Huh I thought I just didn't know what I was doing
Anyone have experience with embedded Swift or know any interesting embedded projects running on Swift?
One fun example is this Playdate game: https://news.play.date/news/four-corners-swift/
Here's a more comprehensive list of different platform examples: https://github.com/swiftlang/swift-embedded-examples
> Here's a more comprehensive list of different platform examples: https://github.com/swiftlang/swift-embedded-examples
(About?) the same list in a nicely formatted way: https://www.swift.org/get-started/embedded/
Thanks!
Interesting tidbit about not having the Foundation library. Every Swift project I worked on had to import that, so I imagine it's annoying to lose that
I am building the backend of a social media app I am making in Swift. I've previously used Vapor for the web server but right now, I am trying out Hummimgbird.
Has anyone tried either? Would love to hear your experience with them.
Looking at things like this
```
let result = try await Subprocess.run(
)print(result.standardOutput)`
```
reminds me that macOS could really use something like powershell (I know you can run powershell on macOS) where you pass around structured data, rather than the endless parsing and reparsing. This is mostly a feature of the shell but you do need some language infrastructure to accomplish it.
To me the secret sauce behind powershell is the .NET infrastructure, which allows much more runtime introspection than the usual compiled programming languages, allowing a lot of flexibility without being too wonky. Unfortunately the Windows team seemed to not be on board with this vision, and thus it cannot achieve its full potential. The objective-c runtime may have been a good alternative here too, but I don't think Apple is encouraging its use anymore (and Objective-C is not the right language for that, neither is AppleScript imo).
You can also access COM from PowerShell, which basically opens up a lot of the Windows world to it.
And both .NET and COM and the object-oriented history of Windows is probably also why PowerShell will never really feel "at home" on UNIX platforms, for better or worse.
They should adopt Nushell! It would be seen as very "Apple"- a brave great somewhat non interoperable user experience upgrade
I was a big fan of Nushell for some time but has the same problems as unix shells. I have this CLI tool that manages a lot of things for me (a big one is downloading and cataloging arxiv papers, it downloads them and tags them with metadata and gives each PDF a proper filename based on the author's name and publication year). I tried building this in Nushell but it became eventually so painful.
I'm sorry, what are the same problems you're referring to? I ended up leaving because:
- it was unstable and kept changing (less of an issue now)
- I still need to know bash due to its ubiquity
- it was worse than python for data crunching scripts (ide tooling + my familiarity)
This was several years ago so I'm curious about a more recent perspective
There is some unstability yes.
For me the larger problems were the lack of types which in practice meant that I was running into the same problems as with bash.
Nushell does have types: https://www.nushell.sh/book/types_of_data.html
So you mean the ability to run a shell from code And receive structured data back?
Something like that yes. The endless parsing and reparsing that you need to do in the unix shells is such a pain.
It's both curse and blessing. Of course it gives you ultimate freedom, but like with programming languages, I personally prefer the guardrails that a type system provides.
We are on the same page then.
I just realized Swift has support for embedded hardware [1]. It's very niche but having a high level programming language as Swift is a great option.
[1] https://github.com/swiftlang/swift-embedded-examples/blob/ma...
[flagged]
Don’t worry, that’s almost every other page on the feed