Swiftly 1.0
swift.org
swift.org
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-...
Ten minutes isn't very good for 30K lines.
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.
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.
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.
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.
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.
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.
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 compiler is just too slow, and the language is too complex.
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
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.
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.
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.
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.