Swift seems like a really nice language that's held back by it's association with Apple.
Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
> Swift seems like a really nice language that's held back by it's association with Apple.
Or empowered by its association with Apple. That's a pretty big pond.
I like Swift, and I write software for Apple devices. I don't really care, whether or not it supports other platforms. For my backend work, I tend to use PHP, because there's a very broad base of servers that support it, it's good enough, fast enough, and, doggone it, people like it...
Another comment mentions that languages aren't really the issue, platforms are, and enumerates a number of application contexts, and the languages that are used to develop in those contexts.
If you want to write native Apple software, then you need to either use ObjC, or Swift. You can use C or C++, and JavaScript, if you don't mind gluing them on, but native is Swift/ObjC, and Apple doesn't really do much to support ObjC (but they have to, anyway, because I guarantee that some of the biggest apps out there, still run with ObjC -including some Apple ones).
I use Swift. I write both UIKit and SwiftUI, but find that UIKit is what I use to deliver a great user experience. I have to use SwiftUI, for a few applications (like Watch apps), and am constantly slamming into its limitations.
Eh. That's why I run showdead = no. That comment obviously got nuked.
It's really fun, knowing that some folks hate me, just because I write software for Apple platforms.
I don't hate them back. That kind of hatred isn't very good for you. It's Commissioner Dreyfus-level obsession.
But this also shows what a tiny, tiny minority of people are represented here. Apple's a three-trillion-dollar company, because most folks aren't like us.
The thread was about "Swift would be a good language, but all the attention and focus is on the Apple ecosystem and everybody using it for something else is an outlier and if you don't want to deal with apple it's a hard game"
My response was directed at that. I said that its lack of non-Apple support isn’t a bad thing for many folks.
It was designed by Apple, for Apple. They only care about non-Apple support, if it results in Apple software for Apple hardware. I suspect they will be using it for some of their new custom server farms (or Python).
Mercenary as hell, but it’s not an uncommon stance; especially with hardware companies. I had to work with that attitude all the time, at my last job.
We are all “main characters” of our own stories. If we keep the focus on ourselves, and what we have learned, from our own experiences, then we’re likely to be writing about stuff we know.
I have had decades of experience with people saying “I hate you” because I write software for Apple systems, so I’m not imagining it. I also know that I’m not alone. It’s not exactly a “cutting edge” mindset.
Personally, I’m offended. I think that it’s shallow. I have plenty of other fine qualities to hate.
I’m always tempted to project motivation and intention onto others, but I’m not very good at it, so I keep it to myself.
I mean, as long as Apple continues to support ObjC, you can use any language that has an ObjC interface. I've shipped native AppKit stuff in Rust before, people have done Ruby, etc.
ObjC is one of the greatest "glue languages" to have existed IMO.
If your response to "Swift is being limited by Apple" is "well at least Apple hasn't killed it yet" then yeah, you're proving their point. Assuming you're right, and Swift is being empowered by Apple, then what is the language without Apple's support? Another .Net situation. They control the vision, the pitfalls of Swift as a language are the result of Apple's discretion. You can't blame the community for refusing to do Apple's dirty work pro-bono.
And honestly, Apple shouldn't be unhappy with where Swift is at right now either. They got exactly what they wanted from it, having third-party language stakeholders was never part of the equation for supporting Swift. A best-case scenario like Mono for Dotnet wouldn't be worth it, and Apple devrel is already in the toilet to boot. Might as well just go mask-off and run the whole thing like any other iOS library, but that's just my $0.02.
My view is that languages don't matter only libraries and engines. If you want to make an iOS app then Swift is for you. If you want to make an Unreal Engine game then C++. If you want to make a website then JavaScript. If you want to play with Bevy or Servo libraries then Rust. If you want to play with Blender or do anything with AI then Python.
I think that argument is on increasingly shaky ground these days as the barriers are starting to come down in a lot of ways.
First in the sense of hand crafted interop solutions that modern languages provide.
Take Dart for example as something that has a (by comparison) very small package ecosystem.
However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head.
Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem.
So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
I am not sure but your comment seems to make the point of the person you're answering to.
Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production.
Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages.
Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for?
So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.
There's at least 2 bindings for QT in Dart (in general, darts a pretty big pond, there's been a strong steady uptake of Flutter that's not delineable enough in a way to concisely update impressions it's small)
Yeah, and I agree with you, I would think its nuts too. A couple years ago I didn't have any experience to tell me otherwise and would never have done that -- I'm only up for it now because I've had a great and literally painless time wrapping ONNX, llama.cpp, and a couple other C++ libraries using generated bindings.
I agree strongly on that it is good to make software architectural decisions, involving business, based on if you have a bunch of other people with the same problem shape as you.
And on specifically the idea that Darts not exactly hosting multiple UI frameworks, even though it theoretically could. (I don't know enough about Qt to know who uses it and why, my understanding vaguely is Linux UI. Canonical is all-in on Flutter, for whatever reason, so I discount the probability that Dart would naturally gain Qt bindings, if it was non-small)
There is a circular dependency — the language strongly influences what libraries/engines can and will be written.
Bevy and Servo wouldn't exist without Rust. Unreal probably wouldn't succeed without C++.
Languages may also matter for other reasons than just their feature set. Node.js got traction specifically because it was JavaScript.
Even though Fortran had state-of-the-art numeric libraries, Python enabled numpy to have the sweet spot of usability with good enough speed.
The killer libraries need years of effort to build them. That won't happen if users don't want to use the language, or the language isn't good enough for the task.
For Swift to have killer libraries, users must first choose Swift to build them. Catch22.
Spot on, for a long time, the project and platform dictactes the languages I use, not the other way around.
Being a YXZ Developer trying to fit YXZ into every domain, means that for many scenarios one ends up yak shaving until the foundations are in place for the actuall work one is supposed to do.
And even then, the tooling (IDE, debugging, build, libraries) will fail short from the platform native experience.
My motto is to always be curious and learn what is out there just in case, however in what concerns production work, only what is directly supported out of the box by the platform matters.
Typescript is maybe the exception, then again it is really a JavaScript linter in practice, the team has learned not to add additional language features.
After coding in swift for ~5 years at job - 1, I can count on one hand the times I had to deal with a reference cycle, and in each instance it was obvious in context that there was going to be a cycle so I used “weak” in anticipation. Zero times did I ever accidentally forget to use a weak reference.
A simple rule of thumb is that if anything has a parent/child relationship, the child should use the weak keyword (or even “unowned” if you’re certain about object lifetimes) when referring back to the parent. That and things like hand-rolled doubly linked lists, but the standard library already has that so who cares.
Also for all the hate Xcode deservedly receives, it comes with some really great tooling in the Instruments package that, among other things, makes it trivial to detect leaked memory when it does happen. And from my own experience developing in Obj-C and Swift for 15 years, I agree that it’s really not the big issue that anti-reference counting people make it out to be.
Well kinda; even in a tracing GC language like C# you have things like WeakEventManager (https://learn.microsoft.com/en-us/dotnet/api/system.windows....) to prevent memory leaks when using callbacks as event handlers. It is definitely not exclusive to ref counted languages.
True, but it only works on Apple systems, which makes Swift far less appealing on non-Apple systems. This adds weight to the point the GP comment makes about Swift being held back by its association with Apple
They used to. AppCode was excellent. Fleet kind of supports Swift well enough.
AppCode was abandoned because Apple is impossible to work with and never provided up to date semantics and language definitions for Swift, keeping everything under wraps and making every single Swift release a race to suddenly implement whatever new keyword they made up this week.
Fleet is more of a VSCode. Probably using the LSP these days, and it's good enough if a simple text editor is what you need.
Swift is literally developed in the open, so I don’t think your argument makes sense.
I think the reason they abandoned it was trouble keeping up with new iOS SDK features getting shadow dropped as part of new Xcode betas and iOS devs wanting to immediately prepare their apps to use those features, not anything to do with Swift language releases. Also things like having to recreate interface builder, then support auto layout in it, and then later SwiftUI previews, etc. Again all iOS platform stuff, not Swift language stuff.
I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better:
1. They had experience on the type of app and you tend to do things better when you do it the second time.
2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
> I don’t think anyone actually believes that the language change is what made the difference in that post
They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference.
Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance.
In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.
> They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage.
Yeah the startup costs are an active problem. I do think though that if they weren’t running an old runtime they wouldn’t have had the same GC issues.
No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
When I write code, I always start with the platform, which drives and limits the language choices. I don't say I want to write in C++, I say I want to write for web, or for iOS, or Windows, or whatever. If I'm writing for web, I'll reach for TypeScript. If iOS, then ObjC. If Windows, maybe C# if I'm being threatened. Using Rust to build a web app is like pulling teeth.
If many people think the same way, then yeah, there's no good reason to reach for Swift unless you're writing an iOS or Mac app and don't want it to be cross platform for some reason that I almost can't imagine in 2025.
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
What you've enumerated are also applicable to Dlang with potential of even faster compile and execution time than C++ or even the venerable Fortran [1].
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
>Swift seems like a really nice language that's held back by it's association with Apple.
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
Replace Apple with MS and Swift with C# and all of this is still true but makes my heart ache even more.
or embracing complexity as C++. It used to be very simple and pragmatic language. that stopped with Swift 3. Remember Protocol based Swift - better than OOP - but now it seems a bastard child of C++.
Swift at one point could've been Golang with better C++ interop. A better Rust since it's memory safe without the gymnastics.
I don't think anyone cares about Apple here. Swift solved a problem that people outside iOS/macOS didn't have. Then it took ~10 years to make Swift more seriously general purpose and multi-platform, it's simply too late to be compelling when other languages have progressed too.
Re: easy to write, I'm not sure, Swift's recent explosion in complexity makes it a hard sell vs Rust, even if the learning curve might be slightly less steep. At the end of the day, Rust's DX wins in almost every dimension, people are willing to learn slightly more complex semantics if it saves times everywhere else: tooling, libraries, build tool and package manager, ... I believe even compilation speeds don't compare favorably.
Of the opposite.. there’s soo much hate against Apple and all their contributions. But somehow Google, Meta, annd Microsoft are better represented.
Swift solves a problem that is still there. It was also released before the final release of Rust.
It’s just that people seem to think that because it’s from Apple, it’s only meant for iOS/macOS.
I love swift, it combines so many things, and Apple is really good get pushing the language forward with its compilers/warnings.
I’m also using it for shell scripts and small utils, and it’s really great. I made https://github.com/jrz/container-shell to improve the experience of scripting cli tools in Swift.
They deserve it. Look, Microsoft and Meta and Google are all evil companies too, but all of them actually make good-faith contributions to Open Source projects. Meta maintains React.js and Zstd, Microsoft does tons of open work on Typescript, VS Code and the Linux Kernel. Google handles the AOSP, Blink Engine, Go, Angular, JAX, Grpc... the list goes on. They're brimming with genuine, self-evident goodwill, even when their businesses detract from humanity.
So; what exactly are Apple's big, selfless contributions? XNU is Source Availible but unusable without buying proprietary Apple hardware. iBoot is mysterious and has to be reverse-engineered to use it like UEFI. Open standards like Vulkan are ignored for political reasons, CUPS is basically derelict, WebKit killed KHTML because sharing was too hard, and APFS and Metal are still both undocumented despite promised transparency. CoreML is proprietary but can't compete with CUDA, iPads can't use QEMU despite supporting it in-hardware, all the Apple Silicon DeviceTree code is private, competing runtimes like Corellium get sued and security researchers get ignored. Swift, as an offering to the Open Source community, is a punch line at the end of a 20 year long gag.
Apple does genuinely nothing to advance the wellbeing of common computing for mankind. Apple leaves behind no charitable contributions to anything that does not ensure their absolute preservation as a business. Combined with the proven anticompetitive damages that the App Store incurs on the burgeoning mobile market, they are unequivocally a net-negative force and aren't hated enough for their parasitic influence on global software production.
And yet, they make the best damn computers out there with hardware second to none, make the single best consumer-level AI computer, are better at product design than basically anyone in the world, and have defined at least four different product categories, while donating billions of dollars to truly charitable causes and being more clearly committed to sustainability than any of their other large tech giants.
Well, your first three claims are subjective and your second two claims are something both Meta, Microsoft and Google have all done themselves. I was focusing more on what made Apple unique, not why people want to exonerate them so desperately. Your could use the same defense to protect Facebook and nobody could objectively disprove you.
Cause like... we could start judging companies based on how many carbon credits they buy. But that wouldn't make Microsoft or Apple or Google any less evil, so it's a non-sequitur. Apple can simultaneously mass-produce the most desirable hardware in the world while creating anticompetitive market conditions that debilitates fair choice and destroys legitimate value. The United States threatened to break up Microsoft for the same overreach.
I'm fairness, when Swift was first released it was basically Apple devices only. It took forever for Foundation to get ported to other platforms (and good luck writing anything useful without Foundation).
Yes this exactly. People are also conveniently ignoring or forgetting that Apple kept changing the ABI for Swift binaries - it wasn't until 'v5' did they lock it down. Objective-C is 30+ years old and only once had this issue with the ObjC 2.0 release. Really, Swift v5 was the real v1.0 release because it was at that version Swift was truly ready for primetime.
When C#/.NET was first released it was basically Windows devices only, too. First release: 2000, cross-platform and opened up in 2014, if I’m reading Wikipedia correctly.
When Android was first released it was basically Android devices only, too. Still is.
Lots of folks are looking for a sweet spot that combines most of Rust's upsides with a less restrictive model. I'm working on a game in Swift (using Godot bindings) for that reason.
Meh, I could've been curious about playing with Swift if it wasn't so Apple-centric. Just like I could've been curious about playing with C# if it wasn't so Microsoft-centric.
I don't feel C# is that Microsoft-centric anymore - not after the release of Roslyn.
It works well on Windows, macOS, iOS, Android and I suspect Linux as well (but I never use Linux, hence I can't be sure). And if you want a multiplatform UI there's some decent options like Avalonia UI [0].
When Microsoft ported C# to Linux, they actually held off on releasing it because Linux ran C# applications better than Windows OS. They took time to refactor the code so Windows OS and Linux where on par. I cannot remember the source video where Microsoft employees talking about it is. The video was right after the .NET Core initial release.
That being said. Microsoft does not want a cross-platform C# that works on Linux. This is why their .NET MAUI does not support Linux and a 3rd party framework will be needed.
Only reason I would choose C# for non-Windows is because of existing / legacy code base. Any new application would use language and libraries that fit the problem versus trying to fit C# as the solution to all.
Mono actually is the primary project that greatly improved the C# world and evolved the latest .NET infrastructure, not Microsoft. Mono developers actually cleaner APIs. Even Microsoft Visual Studio for Mac is just Mono Developer with the Linux supporting bits removed.
I think the evolution of C# beyond Microsoft is overplayed. The entire tooling around the language remains a Microsoft product, with all the attendant Microsoft nonsense. It has opt out telemetry, even on Linux, and like every other MS product is currently having AI force-fed down its throat. It's only a matter of time until a compiler update automatically uploads all your code to Microsoft Azure Recall .net Passport Hotmail ft. the Copilot dancers.
If you're developing Windows apps or Windows games, C# is a fine choice; much as Swift is a fine choice for Apple apps. But no one worried about Apple's control of Swift should be pointing people to C# with a straight face.
To be fair, LLVM wasn't an Apple-initiated project, but one Apple noticed and decided to adopt later on (they hired Chris Latner in 2005; LLVM began in 2000, and had its first public stable release in 2003).
Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020).
If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.
Well since this is about the web site redesign, I’ll leave my opinions on the language to myself and just say that I like the color gradients and how the trail of color coming off of the mascot bird acts as a separator as you scroll down the page.
It’s a fresh change from your typical modern website.
The inclusion of "Embedded" on the front page when all the documents say it's experimental and not supported in public releases "yet" does make me curious if they will announce more at WWDC.
The big hopes for me this year of WWDC would be a Swift port of the Foundation DB record layer, from Java, along with a decent http server package. It's underappreciated just how useful it is in golang having a production capable http server in the standard library.
> Apple's Secure Enclave processors run software written in Embedded Swift, as was announced at WWDC last year. Apple shipped 225 million iPhones (just iPhones) in 2024, so that's a very large deployment by any industry's standards.
Released on a single architecture, hand in hand with the builders of them architectures that happen to also be the builders of Swift.
Working on a dozen architectures with only 10 000 units sold each would be a better proof of it being a valid option for embedded development, but I guess the industry standards are whatever we make up today.
They need sideline embedded until they release a proto board and a compute module with Apple Silicon SoCs running Linux or Darwin. If Apple drops support for the embedded variant of Swift then it would be up to enthusiasts to carry on and I don't see that happening. This is also why the other OEMs like Nordic and STMicro are more likely to support Micro/CircuitPython than Swift.
I know a lot of people don’t like extensive stdlibs, but I’m not among them. As long as the stuff in the standard library is actually decent, I’m all for including more.
The fewer dependencies I need, the better. It’s one of the reasons why I’m still a big fan of developing for Apple platforms despite the recent drama: it’s a very batteries-included experience, which means it’s not just feasible but pleasant to develop top-class apps with a dependency list that can be counted on one hand. That’s amazing for not just the dev process itself but also for long term maintenance.
I find the golang http server very basic, though. Like no content negotiation based on http headers by default, or any CORS by default. Also maybe writing headed after body does nothing since writing the body sends the response and it’s too late by then.
It does work, but I don’t find it ready for production without a lot of conf and extensions first.
I would like to work with a Swift version with reduced functionality (IMHO over time Swift became the same monstrosity as C++) but the embedded version cannot be used with “normal” operating systems only embedded ones. Why this artificial boundary? Apple…
That also doesn't seem to match reality. Extraordinary claims require extraordinary evidence, and in this case I just don't see the evidence. Which is not surprising since it's a lie, at least for the "only language" part (the fact that Swift actually scales in this way is up to debate imo)
I noticed that Go's and TypeScript's websites are massively more complicated than they were 10-15 years ago, much harder to find basically anything without google, which Swift's feels close to. But Lua's site remains as easy to use as ever.
That is truly awful, and does reflect badly on the stewardship of the project as a whole, which is a shame. It really is amazing how toxic programming language arguments become.
From the horribly slow typecheck that gets exponentially worse every time anyone adds a protocol extension to <very common type>, the debatable choices made with concurrency/async/actors/swift6, the only-very-recently-stable ABI, the regular titanic undertakings needed for bumping any major version that are almost unheard of in most other languages, etc.
Swift is an alright language today. Good even. But for a 10 year old language ? It aged horribly, going through senseless breaking changes just to fit Apple's needs. It's fine if you're locked in on Apple's platforms, but any other language doing that would have been set on fire already. Look at how painful the python2/python3 split was: Swift did worse than that, _four_ times.
MSVC was laughed at for only providing a stable C++ ABI in 2019. Swift is not immune to the same criticism, and has even fewer excuses for it: we knew for a long time stable ABIs are critical for interop.
You don’t have to? To clear out of the analogy Swift is available on all major platforms, no strings attached to Apple (except you have to download Swift from them oc).
There is something incredibly weird about people associated with Apple. I don’t know what it is but I think people are not wrong to describe it as a cult like mentality sometimes. But they notoriously do not like any criticism no matter how polite or how valid.
Kotlin, the Android language, isn't owned by Google. it's from Jetbrains. Picking Kotlin is one of a few great decisions Google has done for Android IMO.
They actually are not. Take a look at say the two most popular languages to come out of Google being Go and Dart… none of those communities ever really feel hard done by, the tooling is great, the documentation is amazing, it runs everywhere, it’s fast, it’s easy to work with, has excellent cross language interop and they are just generally well supported.
I think you’re just going on vibes here but it’s kind of bullshit when you think about it for more than a moment.
People that have been around Dart long enough absolutely felt hard done by. That project burned so much community good will on the way to finally getting slight traction with Flutter.
I’m actively a part of that community for the past 5 years and I have zero idea what you’re talking about. It’s one of the most loved languages out there when you look at surveys of its users and for good reason.
Half a decade is more than enough time for me to be able to say with a really high degree of confidence and authority that I’m positive that the situation with Google and Dart is in fact not at all like the situation with Apple and Swift as the OP was implying.
Also the Android and iOS development experiences are vastly different. Android is much more pleasant to work with. Android Studio exists but you don’t need to use it, unlike XCode. I’m very happy writing Android apps using vim and adb.
I develop for both platforms and don’t agree at all. The Android dev experience has a lot of potential to be good, but it’s dragged down by the unmitigated messes that are Gradle and ProGuard, both of which regularly cause more pain for me than their iOS counterparts (Swift Package Manager and clang’s code stripper).
It’s also only been relatively recently that Google has decided it’s ok to be opinionated and provide happy paths for devs to follow in their UI library with Compose. Android Framework was/is notorious for having 5 ways to accomplish any given task and none being “right” or the only one capable of doing what you need being deprecated.
And then there’s Kotlin, which is so close to being a great language but dies on weird hills ideologically (e.g. please just give me “if let” syntax, “.let {}” is ugly and automatic unwrapping fails just enough to not be useful).
Freedom of editor is nice but doesn’t make up for the rest, at least for me.
> it’s dragged down by the unmitigated messes that are Gradle and ProGuard
its crazy looking back though, when android studio first came out there was a big hope it would be better than ant but idk personally i also hate gradle with a passion...
> “if let” syntax, “.let {}”
probably guard let would be even better since it avoids indenting on the happy path but jmo
I find it interesting the call out windows apps specifically, but not mac apps, and from what I understand, the new tools for compiling to Android are getting quite good.
The last few days, I've been wondering if our commitment to building our mobile app in Swift was a mistake as the only member of our team that wrote swift is no longer with us.
Has anyone got experience with Android apps written in Swift? Thoughts?
I can't speak much for Android, Windows or just generally non-MacOS apps written in Swift, but it looks like they're trying avoid a Dart situation, which from what I've heard is quite a nice language but at this point lives and dies by Flutter. Intellij are doing a similar thing with Kotlin (and with great success too)
Some companies these days write majority of platform independent code in Kotlin and just a thin UI layer for iOS in Swift. So perhaps that is a smarter approach.
I can't tell from experience myself but talked with people who do this and they're happy with this way of working.
I'm using it on my most recent projects and have had a great experience. It doesn't have the ecosystem of a language like Java, which can be frustrating, but it certainly handles 90% of my needs out of the box. I've never had a performance issue with Vapor. Compile times can be a bit slow if you have a lot of dependencies, but runtime performance has been great.
I would love to try Swift for things other than iOS if it had nice development tools. I don't ask for much. A decent LSP and code formatter are all I want. I refuse to use Xcode, so being able to code Swift in my code editor of preference would be great.
I hope the website’s focus on non-Apple platforms coincides with an actual project focus on them.
I find Swift fascinating, but the software I want to write is not software locked into Apple platforms. The low level stuff looks particularly interesting, as the common low level languages all have their peculiarities.
Swift is usable (on Apple operating systems) if you use the add ons that Apple provides (like SwiftUI).
Other than that… forget about it.
Tried to use Swift for CLI apps (on macOS) and it failed miserably. The reason: after reaching a certain code size the Swift compiler is reporting vague syntax errors without line numbers. Unacceptable in 2025.
I can’t speak to the errors you’re seeing, only that my experience is different. I’ve written well over a hundred CLI apps on macOS, of all sizes. I consider it a very good language for it too (also for scripting). A nice thing is that you can leverage the whole of AppKit/Foundation/Carbon/etc in CLI apps allowing for uniquely powerful tooling & integration.
I’m happy for you and everyone else who has had the same experience as you.
I’ve saved my Swift CLI apps, so I might try it again when a new version comes out, hopefully they fixed such behavior.
I've got no experience, but I imagine you don't have to interface with C++ too often, and when you do it's probably unlikely someone haven't written a wrapper library already. That's how the entire Python ecosystem works, either someone has made a wrapper, you make a wrapper or you use subprocess if the library has a CLI and you're not in a performance sensitive part of execution.
Any language that makes programming easier is good. Modern C++ is also quite good, but I feel like there are more "nice to haves" in other languages. Reflection is one, for serializing things without boilerplate and his uncle. And just reflecting on types in general can be nice.
Quite frankly, this isn't even that large. There are entire books about topics like JNI (Java <-> C) or Swig (Python <-> C); this page is fairly short given the broad scope of Swift's C++ integration.
Really hard to imagine a use case for Swift outside of Apple platforms. It's a good language without much library support anywhere other than Apple platforms.
Not a good design, where is the search bar? Why is the site's footer area so vertically large? And why do you need two birds at the top limiting you to just a single sentence? Also the first page examples are undocumented
Swift seems like a really nice language that's held back by it's association with Apple.
Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
Doesn't seem like there's any maintained bindings for Qt though, although there are some interesting ones for GTK (e.g. https://git.aparoksha.dev/aparoksha/adwaita-swift)
> Swift seems like a really nice language that's held back by it's association with Apple.
Or empowered by its association with Apple. That's a pretty big pond.
I like Swift, and I write software for Apple devices. I don't really care, whether or not it supports other platforms. For my backend work, I tend to use PHP, because there's a very broad base of servers that support it, it's good enough, fast enough, and, doggone it, people like it...
Another comment mentions that languages aren't really the issue, platforms are, and enumerates a number of application contexts, and the languages that are used to develop in those contexts.
If you want to write native Apple software, then you need to either use ObjC, or Swift. You can use C or C++, and JavaScript, if you don't mind gluing them on, but native is Swift/ObjC, and Apple doesn't really do much to support ObjC (but they have to, anyway, because I guarantee that some of the biggest apps out there, still run with ObjC -including some Apple ones).
I use Swift. I write both UIKit and SwiftUI, but find that UIKit is what I use to deliver a great user experience. I have to use SwiftUI, for a few applications (like Watch apps), and am constantly slamming into its limitations.
Given this comment, the next one that starts with something like "I don't think anybody cares about Apple here" made me giggle.
Eh. That's why I run showdead = no. That comment obviously got nuked.
It's really fun, knowing that some folks hate me, just because I write software for Apple platforms.
I don't hate them back. That kind of hatred isn't very good for you. It's Commissioner Dreyfus-level obsession.
But this also shows what a tiny, tiny minority of people are represented here. Apple's a three-trillion-dollar company, because most folks aren't like us.
I don't believe that is the point of the thread.
The thread was about "Swift would be a good language, but all the attention and focus is on the Apple ecosystem and everybody using it for something else is an outlier and if you don't want to deal with apple it's a hard game"
My response was directed at that. I said that its lack of non-Apple support isn’t a bad thing for many folks.
It was designed by Apple, for Apple. They only care about non-Apple support, if it results in Apple software for Apple hardware. I suspect they will be using it for some of their new custom server farms (or Python).
Mercenary as hell, but it’s not an uncommon stance; especially with hardware companies. I had to work with that attitude all the time, at my last job.
I don't think you understand.
The comment was basically "nobody gives a shit about apple stuff".
This comes off as very "I am a main character post" on your part.
We are all “main characters” of our own stories. If we keep the focus on ourselves, and what we have learned, from our own experiences, then we’re likely to be writing about stuff we know.
I have had decades of experience with people saying “I hate you” because I write software for Apple systems, so I’m not imagining it. I also know that I’m not alone. It’s not exactly a “cutting edge” mindset.
Personally, I’m offended. I think that it’s shallow. I have plenty of other fine qualities to hate.
I’m always tempted to project motivation and intention onto others, but I’m not very good at it, so I keep it to myself.
[flagged]
I mean, as long as Apple continues to support ObjC, you can use any language that has an ObjC interface. I've shipped native AppKit stuff in Rust before, people have done Ruby, etc.
ObjC is one of the greatest "glue languages" to have existed IMO.
Yup, I've been writing in C# for Apple platforms since 2018. The tooling is a bit clunky, but great experience otherwise.
We used to write algorithms in C++. The UI was ObjC, though (or C#, for Windows).
> Or empowered by its association with Apple.
If your response to "Swift is being limited by Apple" is "well at least Apple hasn't killed it yet" then yeah, you're proving their point. Assuming you're right, and Swift is being empowered by Apple, then what is the language without Apple's support? Another .Net situation. They control the vision, the pitfalls of Swift as a language are the result of Apple's discretion. You can't blame the community for refusing to do Apple's dirty work pro-bono.
And honestly, Apple shouldn't be unhappy with where Swift is at right now either. They got exactly what they wanted from it, having third-party language stakeholders was never part of the equation for supporting Swift. A best-case scenario like Mono for Dotnet wouldn't be worth it, and Apple devrel is already in the toilet to boot. Might as well just go mask-off and run the whole thing like any other iOS library, but that's just my $0.02.
My view is that languages don't matter only libraries and engines. If you want to make an iOS app then Swift is for you. If you want to make an Unreal Engine game then C++. If you want to make a website then JavaScript. If you want to play with Bevy or Servo libraries then Rust. If you want to play with Blender or do anything with AI then Python.
I think that argument is on increasingly shaky ground these days as the barriers are starting to come down in a lot of ways.
First in the sense of hand crafted interop solutions that modern languages provide.
Take Dart for example as something that has a (by comparison) very small package ecosystem.
However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head.
Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem.
So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
I am not sure but your comment seems to make the point of the person you're answering to.
Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production.
Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages.
Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for?
So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.
This is purely a vibes based answer and is actively wrong on a number of fronts. I don’t know what caused you to answer so confidently.
Care to elaborate?
Why would they need bindings for Qt? They already have something much better: Flutter.
There's at least 2 bindings for QT in Dart (in general, darts a pretty big pond, there's been a strong steady uptake of Flutter that's not delineable enough in a way to concisely update impressions it's small)
You mean the 5 years old 1 person's experiment [0] or the more recent 1 year old POC [1].
Would you build a product with either of these things and sell it and put your name on it? I wouldn't.
[0] https://github.com/therecipe/flutter
[1]: https://github.com/KDABLabs/dart-qtbindings
Yeah, and I agree with you, I would think its nuts too. A couple years ago I didn't have any experience to tell me otherwise and would never have done that -- I'm only up for it now because I've had a great and literally painless time wrapping ONNX, llama.cpp, and a couple other C++ libraries using generated bindings.
I agree strongly on that it is good to make software architectural decisions, involving business, based on if you have a bunch of other people with the same problem shape as you.
And on specifically the idea that Darts not exactly hosting multiple UI frameworks, even though it theoretically could. (I don't know enough about Qt to know who uses it and why, my understanding vaguely is Linux UI. Canonical is all-in on Flutter, for whatever reason, so I discount the probability that Dart would naturally gain Qt bindings, if it was non-small)
There is a circular dependency — the language strongly influences what libraries/engines can and will be written.
Bevy and Servo wouldn't exist without Rust. Unreal probably wouldn't succeed without C++.
Languages may also matter for other reasons than just their feature set. Node.js got traction specifically because it was JavaScript.
Even though Fortran had state-of-the-art numeric libraries, Python enabled numpy to have the sweet spot of usability with good enough speed.
The killer libraries need years of effort to build them. That won't happen if users don't want to use the language, or the language isn't good enough for the task.
For Swift to have killer libraries, users must first choose Swift to build them. Catch22.
They chose Swift if they want to get money on Apple's ecosystem.
Spot on, for a long time, the project and platform dictactes the languages I use, not the other way around.
Being a YXZ Developer trying to fit YXZ into every domain, means that for many scenarios one ends up yak shaving until the foundations are in place for the actuall work one is supposed to do.
And even then, the tooling (IDE, debugging, build, libraries) will fail short from the platform native experience.
My motto is to always be curious and learn what is out there just in case, however in what concerns production work, only what is directly supported out of the box by the platform matters.
Typescript is maybe the exception, then again it is really a JavaScript linter in practice, the team has learned not to add additional language features.
Swift also doesn't have a mark&sweep GC, and uses reference counting, which makes its memory footprint much smaller than GC-based runtimes.
It also means it's easy to create reference cycles that never get deallocated. Especially in callback anonymous functions.
After coding in swift for ~5 years at job - 1, I can count on one hand the times I had to deal with a reference cycle, and in each instance it was obvious in context that there was going to be a cycle so I used “weak” in anticipation. Zero times did I ever accidentally forget to use a weak reference.
A simple rule of thumb is that if anything has a parent/child relationship, the child should use the weak keyword (or even “unowned” if you’re certain about object lifetimes) when referring back to the parent. That and things like hand-rolled doubly linked lists, but the standard library already has that so who cares.
Also for all the hate Xcode deservedly receives, it comes with some really great tooling in the Instruments package that, among other things, makes it trivial to detect leaked memory when it does happen. And from my own experience developing in Obj-C and Swift for 15 years, I agree that it’s really not the big issue that anti-reference counting people make it out to be.
Well kinda; even in a tracing GC language like C# you have things like WeakEventManager (https://learn.microsoft.com/en-us/dotnet/api/system.windows....) to prevent memory leaks when using callbacks as event handlers. It is definitely not exclusive to ref counted languages.
In C#, these aren't the exact same as a reference cycle, but the end result is the same, a memory leak: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/...
The tooling around finding these references cycles (Instruments) is 2nd to none imo.
True, but it only works on Apple systems, which makes Swift far less appealing on non-Apple systems. This adds weight to the point the GP comment makes about Swift being held back by its association with Apple
Agreed. However, if Jetbrains were to provide a Swift IDE that's free for non-commercial use...
They used to. AppCode was excellent. Fleet kind of supports Swift well enough.
AppCode was abandoned because Apple is impossible to work with and never provided up to date semantics and language definitions for Swift, keeping everything under wraps and making every single Swift release a race to suddenly implement whatever new keyword they made up this week.
Fleet is more of a VSCode. Probably using the LSP these days, and it's good enough if a simple text editor is what you need.
Swift is literally developed in the open, so I don’t think your argument makes sense.
I think the reason they abandoned it was trouble keeping up with new iOS SDK features getting shadow dropped as part of new Xcode betas and iOS devs wanting to immediately prepare their apps to use those features, not anything to do with Swift language releases. Also things like having to recreate interface builder, then support auto layout in it, and then later SwiftUI previews, etc. Again all iOS platform stuff, not Swift language stuff.
The issues it has around circular data structures is almost, though not quite, as bad as rust.
But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.
Have you seen the benchmarks? Swift code is 40% faster than Java in that instance.
I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better:
1. They had experience on the type of app and you tend to do things better when you do it the second time.
2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
> I don’t think anyone actually believes that the language change is what made the difference in that post
They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference.
Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance.
In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.
> They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage.
Yeah the startup costs are an active problem. I do think though that if they weren’t running an old runtime they wouldn’t have had the same GC issues.
I have indeed,
https://github.com/ixy-languages/ixy-languages
No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
Qt have announced they’re doing Swift bindings recently https://www.qt.io/blog/about-the-new-qt-bridging-technology
Afaik someone on this site shared a repo url that has the early bindings using Swift C++ interop.
Looks like it’s only for Quick and not Widgets, which I’m sure is still useful but kind of a bummer.
When I write code, I always start with the platform, which drives and limits the language choices. I don't say I want to write in C++, I say I want to write for web, or for iOS, or Windows, or whatever. If I'm writing for web, I'll reach for TypeScript. If iOS, then ObjC. If Windows, maybe C# if I'm being threatened. Using Rust to build a web app is like pulling teeth.
If many people think the same way, then yeah, there's no good reason to reach for Swift unless you're writing an iOS or Mac app and don't want it to be cross platform for some reason that I almost can't imagine in 2025.
Very few languages have quality Qt bindings because Qt is a pain to bind to, so that might not be a particularly good benchmark.
In addition to the Adwaita bindings listed, there’s also autogenerated plain GTK bindings (https://github.com/rhx/SwiftGtk).
I'll interpret a bit. But I think the remark is more did we have a cross platform and complete gui library for swift.
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
What you've enumerated are also applicable to Dlang with potential of even faster compile and execution time than C++ or even the venerable Fortran [1].
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
>Swift seems like a really nice language that's held back by it's association with Apple.
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
Replace Apple with MS and Swift with C# and all of this is still true but makes my heart ache even more.
or embracing complexity as C++. It used to be very simple and pragmatic language. that stopped with Swift 3. Remember Protocol based Swift - better than OOP - but now it seems a bastard child of C++.
Swift at one point could've been Golang with better C++ interop. A better Rust since it's memory safe without the gymnastics.
I don't think anyone cares about Apple here. Swift solved a problem that people outside iOS/macOS didn't have. Then it took ~10 years to make Swift more seriously general purpose and multi-platform, it's simply too late to be compelling when other languages have progressed too.
Re: easy to write, I'm not sure, Swift's recent explosion in complexity makes it a hard sell vs Rust, even if the learning curve might be slightly less steep. At the end of the day, Rust's DX wins in almost every dimension, people are willing to learn slightly more complex semantics if it saves times everywhere else: tooling, libraries, build tool and package manager, ... I believe even compilation speeds don't compare favorably.
Of the opposite.. there’s soo much hate against Apple and all their contributions. But somehow Google, Meta, annd Microsoft are better represented.
Swift solves a problem that is still there. It was also released before the final release of Rust.
It’s just that people seem to think that because it’s from Apple, it’s only meant for iOS/macOS.
I love swift, it combines so many things, and Apple is really good get pushing the language forward with its compilers/warnings.
I’m also using it for shell scripts and small utils, and it’s really great. I made https://github.com/jrz/container-shell to improve the experience of scripting cli tools in Swift.
They deserve it. Look, Microsoft and Meta and Google are all evil companies too, but all of them actually make good-faith contributions to Open Source projects. Meta maintains React.js and Zstd, Microsoft does tons of open work on Typescript, VS Code and the Linux Kernel. Google handles the AOSP, Blink Engine, Go, Angular, JAX, Grpc... the list goes on. They're brimming with genuine, self-evident goodwill, even when their businesses detract from humanity.
So; what exactly are Apple's big, selfless contributions? XNU is Source Availible but unusable without buying proprietary Apple hardware. iBoot is mysterious and has to be reverse-engineered to use it like UEFI. Open standards like Vulkan are ignored for political reasons, CUPS is basically derelict, WebKit killed KHTML because sharing was too hard, and APFS and Metal are still both undocumented despite promised transparency. CoreML is proprietary but can't compete with CUDA, iPads can't use QEMU despite supporting it in-hardware, all the Apple Silicon DeviceTree code is private, competing runtimes like Corellium get sued and security researchers get ignored. Swift, as an offering to the Open Source community, is a punch line at the end of a 20 year long gag.
Apple does genuinely nothing to advance the wellbeing of common computing for mankind. Apple leaves behind no charitable contributions to anything that does not ensure their absolute preservation as a business. Combined with the proven anticompetitive damages that the App Store incurs on the burgeoning mobile market, they are unequivocally a net-negative force and aren't hated enough for their parasitic influence on global software production.
You make a convincing case.
And yet, they make the best damn computers out there with hardware second to none, make the single best consumer-level AI computer, are better at product design than basically anyone in the world, and have defined at least four different product categories, while donating billions of dollars to truly charitable causes and being more clearly committed to sustainability than any of their other large tech giants.
I think I can handle their stance on software,
Well, your first three claims are subjective and your second two claims are something both Meta, Microsoft and Google have all done themselves. I was focusing more on what made Apple unique, not why people want to exonerate them so desperately. Your could use the same defense to protect Facebook and nobody could objectively disprove you.
Cause like... we could start judging companies based on how many carbon credits they buy. But that wouldn't make Microsoft or Apple or Google any less evil, so it's a non-sequitur. Apple can simultaneously mass-produce the most desirable hardware in the world while creating anticompetitive market conditions that debilitates fair choice and destroys legitimate value. The United States threatened to break up Microsoft for the same overreach.
I'm fairness, when Swift was first released it was basically Apple devices only. It took forever for Foundation to get ported to other platforms (and good luck writing anything useful without Foundation).
Yes this exactly. People are also conveniently ignoring or forgetting that Apple kept changing the ABI for Swift binaries - it wasn't until 'v5' did they lock it down. Objective-C is 30+ years old and only once had this issue with the ObjC 2.0 release. Really, Swift v5 was the real v1.0 release because it was at that version Swift was truly ready for primetime.
When C#/.NET was first released it was basically Windows devices only, too. First release: 2000, cross-platform and opened up in 2014, if I’m reading Wikipedia correctly.
When Android was first released it was basically Android devices only, too. Still is.
Lots of folks are looking for a sweet spot that combines most of Rust's upsides with a less restrictive model. I'm working on a game in Swift (using Godot bindings) for that reason.
Meh, I could've been curious about playing with Swift if it wasn't so Apple-centric. Just like I could've been curious about playing with C# if it wasn't so Microsoft-centric.
I don't feel C# is that Microsoft-centric anymore - not after the release of Roslyn.
It works well on Windows, macOS, iOS, Android and I suspect Linux as well (but I never use Linux, hence I can't be sure). And if you want a multiplatform UI there's some decent options like Avalonia UI [0].
---
[0]: https://avaloniaui.net/
When Microsoft ported C# to Linux, they actually held off on releasing it because Linux ran C# applications better than Windows OS. They took time to refactor the code so Windows OS and Linux where on par. I cannot remember the source video where Microsoft employees talking about it is. The video was right after the .NET Core initial release.
That being said. Microsoft does not want a cross-platform C# that works on Linux. This is why their .NET MAUI does not support Linux and a 3rd party framework will be needed.
Only reason I would choose C# for non-Windows is because of existing / legacy code base. Any new application would use language and libraries that fit the problem versus trying to fit C# as the solution to all.
Mono actually is the primary project that greatly improved the C# world and evolved the latest .NET infrastructure, not Microsoft. Mono developers actually cleaner APIs. Even Microsoft Visual Studio for Mac is just Mono Developer with the Linux supporting bits removed.
I think the evolution of C# beyond Microsoft is overplayed. The entire tooling around the language remains a Microsoft product, with all the attendant Microsoft nonsense. It has opt out telemetry, even on Linux, and like every other MS product is currently having AI force-fed down its throat. It's only a matter of time until a compiler update automatically uploads all your code to Microsoft Azure Recall .net Passport Hotmail ft. the Copilot dancers.
If you're developing Windows apps or Windows games, C# is a fine choice; much as Swift is a fine choice for Apple apps. But no one worried about Apple's control of Swift should be pointing people to C# with a straight face.
Microsft management cleary doesn't want VSCode to have feature parity with VS, and C# DevKit is also under the same license as VS Professional.
This routinely pulls the carpet under the .NET team effort to widespread .NET adoption.
Is it that Apple made it and puts resources into it that makes it Apple-centric? If so, is that truly important?
I wonder why LLVM isn’t also considered Apple-centric by the same thought process.
To be fair, LLVM wasn't an Apple-initiated project, but one Apple noticed and decided to adopt later on (they hired Chris Latner in 2005; LLVM began in 2000, and had its first public stable release in 2003).
Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020).
If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.
It's not that Apple puts resources into it. It's that, yes, Apple made it, and its only raison d'etre is to replace Objective-C for Apple platforms.
Well since this is about the web site redesign, I’ll leave my opinions on the language to myself and just say that I like the color gradients and how the trail of color coming off of the mascot bird acts as a separator as you scroll down the page.
It’s a fresh change from your typical modern website.
The inclusion of "Embedded" on the front page when all the documents say it's experimental and not supported in public releases "yet" does make me curious if they will announce more at WWDC.
The big hopes for me this year of WWDC would be a Swift port of the Foundation DB record layer, from Java, along with a decent http server package. It's underappreciated just how useful it is in golang having a production capable http server in the standard library.
> Apple's Secure Enclave processors run software written in Embedded Swift, as was announced at WWDC last year. Apple shipped 225 million iPhones (just iPhones) in 2024, so that's a very large deployment by any industry's standards.
https://forums.swift.org/t/redesigned-swift-org-is-now-live/...
Released on a single architecture, hand in hand with the builders of them architectures that happen to also be the builders of Swift.
Working on a dozen architectures with only 10 000 units sold each would be a better proof of it being a valid option for embedded development, but I guess the industry standards are whatever we make up today.
They need sideline embedded until they release a proto board and a compute module with Apple Silicon SoCs running Linux or Darwin. If Apple drops support for the embedded variant of Swift then it would be up to enthusiasts to carry on and I don't see that happening. This is also why the other OEMs like Nordic and STMicro are more likely to support Micro/CircuitPython than Swift.
I know a lot of people don’t like extensive stdlibs, but I’m not among them. As long as the stuff in the standard library is actually decent, I’m all for including more.
The fewer dependencies I need, the better. It’s one of the reasons why I’m still a big fan of developing for Apple platforms despite the recent drama: it’s a very batteries-included experience, which means it’s not just feasible but pleasant to develop top-class apps with a dependency list that can be counted on one hand. That’s amazing for not just the dev process itself but also for long term maintenance.
I find the golang http server very basic, though. Like no content negotiation based on http headers by default, or any CORS by default. Also maybe writing headed after body does nothing since writing the body sends the response and it’s too late by then.
It does work, but I don’t find it ready for production without a lot of conf and extensions first.
I would like to work with a Swift version with reduced functionality (IMHO over time Swift became the same monstrosity as C++) but the embedded version cannot be used with “normal” operating systems only embedded ones. Why this artificial boundary? Apple…
> Swift is the only language that scales from embedded devices and kernels to apps and cloud infrastructure.
Most people would disagree with this line…
I think the site is good overall, but I also found this particular language to be annoying.
It feels more like Apple(-esque) marketing than anything.
That also doesn't seem to match reality. Extraordinary claims require extraordinary evidence, and in this case I just don't see the evidence. Which is not surprising since it's a lie, at least for the "only language" part (the fact that Swift actually scales in this way is up to debate imo)
There are at least to issues on github about it right now. I filled one of them.
This language did stick out to me even though I prefer Swift over Rust.
Official post: https://www.swift.org/blog/redesigned-swift-org-is-now-live/
I noticed that Go's and TypeScript's websites are massively more complicated than they were 10-15 years ago, much harder to find basically anything without google, which Swift's feels close to. But Lua's site remains as easy to use as ever.
to your point, i've often suspected Python caught on because of the clarity of its documentation.
The book about Lua (Programming in Lua) is a masterpiece, and one of the essential programming books.
If I could write that well in my first language I could probably triple my income. To do it in a second one is just incredible.
I’m definitely going to get that then. Thanks for the tip
https://www.lua.org/pil/contents.html
I just can’t ever see Apple not treating developers like shit and it makes me want to have nothing to do with Swift.
Even Chris Lattner was treated like shit by Swift core team, that was a shocking read to me: https://forums.swift.org/t/core-team-to-form-language-workgr...
That is truly awful, and does reflect badly on the stewardship of the project as a whole, which is a shame. It really is amazing how toxic programming language arguments become.
Swift the language itself is incredibly good though.
That's a very debatable viewpoint.
From the horribly slow typecheck that gets exponentially worse every time anyone adds a protocol extension to <very common type>, the debatable choices made with concurrency/async/actors/swift6, the only-very-recently-stable ABI, the regular titanic undertakings needed for bumping any major version that are almost unheard of in most other languages, etc.
Swift is an alright language today. Good even. But for a 10 year old language ? It aged horribly, going through senseless breaking changes just to fit Apple's needs. It's fine if you're locked in on Apple's platforms, but any other language doing that would have been set on fire already. Look at how painful the python2/python3 split was: Swift did worse than that, _four_ times.
> the only-very-recently-stable ABI,
You mean 6 years ago? https://www.swift.org/blog/swift-5-released/
MSVC was laughed at for only providing a stable C++ ABI in 2019. Swift is not immune to the same criticism, and has even fewer excuses for it: we knew for a long time stable ABIs are critical for interop.
(And interop with Swift is still laughably bad)
I love Indian food, but I still don't want to live in India.
You don’t have to? To clear out of the analogy Swift is available on all major platforms, no strings attached to Apple (except you have to download Swift from them oc).
Frustrating that you're being down-voted, because this is a very valid point.
There is something incredibly weird about people associated with Apple. I don’t know what it is but I think people are not wrong to describe it as a cult like mentality sometimes. But they notoriously do not like any criticism no matter how polite or how valid.
Halfway through I thought you were describing Linux fanatics like myself, and so had to reread the comment a couple of times.
I imagine that being within the thralls of a $3T company could be very comfortable.
Eh. Google are the exact same. Pick your poison.
Kotlin, the Android language, isn't owned by Google. it's from Jetbrains. Picking Kotlin is one of a few great decisions Google has done for Android IMO.
Yeah, now they have their own .NET. /s
They actually are not. Take a look at say the two most popular languages to come out of Google being Go and Dart… none of those communities ever really feel hard done by, the tooling is great, the documentation is amazing, it runs everywhere, it’s fast, it’s easy to work with, has excellent cross language interop and they are just generally well supported.
I think you’re just going on vibes here but it’s kind of bullshit when you think about it for more than a moment.
People that have been around Dart long enough absolutely felt hard done by. That project burned so much community good will on the way to finally getting slight traction with Flutter.
I’m actively a part of that community for the past 5 years and I have zero idea what you’re talking about. It’s one of the most loved languages out there when you look at surveys of its users and for good reason.
5 years is not a long time in Dart. It first appeared in 2011.
Half a decade is more than enough time for me to be able to say with a really high degree of confidence and authority that I’m positive that the situation with Google and Dart is in fact not at all like the situation with Apple and Swift as the OP was implying.
Also the Android and iOS development experiences are vastly different. Android is much more pleasant to work with. Android Studio exists but you don’t need to use it, unlike XCode. I’m very happy writing Android apps using vim and adb.
I develop for both platforms and don’t agree at all. The Android dev experience has a lot of potential to be good, but it’s dragged down by the unmitigated messes that are Gradle and ProGuard, both of which regularly cause more pain for me than their iOS counterparts (Swift Package Manager and clang’s code stripper).
It’s also only been relatively recently that Google has decided it’s ok to be opinionated and provide happy paths for devs to follow in their UI library with Compose. Android Framework was/is notorious for having 5 ways to accomplish any given task and none being “right” or the only one capable of doing what you need being deprecated.
And then there’s Kotlin, which is so close to being a great language but dies on weird hills ideologically (e.g. please just give me “if let” syntax, “.let {}” is ugly and automatic unwrapping fails just enough to not be useful).
Freedom of editor is nice but doesn’t make up for the rest, at least for me.
I find it interesting the call out windows apps specifically, but not mac apps, and from what I understand, the new tools for compiling to Android are getting quite good.
The last few days, I've been wondering if our commitment to building our mobile app in Swift was a mistake as the only member of our team that wrote swift is no longer with us.
Has anyone got experience with Android apps written in Swift? Thoughts?
I can't speak much for Android, Windows or just generally non-MacOS apps written in Swift, but it looks like they're trying avoid a Dart situation, which from what I've heard is quite a nice language but at this point lives and dies by Flutter. Intellij are doing a similar thing with Kotlin (and with great success too)
Some companies these days write majority of platform independent code in Kotlin and just a thin UI layer for iOS in Swift. So perhaps that is a smarter approach.
I can't tell from experience myself but talked with people who do this and they're happy with this way of working.
Anyone using Swift for web backend?
I looked into Vapor but it seems much slower than it should be for a compiled language.
https://www.swift.org/blog/swift-at-apple-migrating-the-pass...
I tried seeing how it ranks on the 2025 tech empower benchmarks: https://www.techempower.com/benchmarks/#section=data-r23&l=v...
And up against C#, Go and C++, Vapor could not make the top 70.
Even just compare Swift vs PHP and its a really poor showing for vapor: https://www.techempower.com/benchmarks/#section=data-r23&l=v...
Probably a bad benchmark. I see that a recent blog post on the swift site discusses a migration of a large service from Java to swift using vapor.
It gets worse results than Laravel which is something.
The speed is less correlated with the language it’s implemented in, and more with the amount of man hours spent building and optimizing it.
Vapor is a very small project, and thus is slower then other larger more mature projects.
I'm using it on my most recent projects and have had a great experience. It doesn't have the ecosystem of a language like Java, which can be frustrating, but it certainly handles 90% of my needs out of the box. I've never had a performance issue with Vapor. Compile times can be a bit slow if you have a lot of dependencies, but runtime performance has been great.
I've used vapor as a side project API. For anything new and only on Apple ecosystem, its simpler to just go with SwiftData and CloudKit though.
How is this possible? Here they say it's fast: https://www.swift.org/blog/how-swifts-server-support-powers-...
Cool. If only some of this effort went into improving Swift Package Manager.
Yes I'm sure the people responsible for the website front end will get right on that.
I would love to try Swift for things other than iOS if it had nice development tools. I don't ask for much. A decent LSP and code formatter are all I want. I refuse to use Xcode, so being able to code Swift in my code editor of preference would be great.
Good news! https://code.visualstudio.com/docs/languages/swift
Concur. This is a pretty good setup.
Caveat: I'm using Swift for command-line software.
What about a formatter? I recall having to figure out which library to install as binary just to do formatting. What do you do?
That's built in now -- the default VSCode "Format Document" / "Format Selection" commands work with just the Swift extension installed.
It has both of those. I use them from Emacs comfortably.
I'm not a Swiftie, but there's this if you're already on a Mac:
https://extensions.panic.com/extensions/pixelfoundry/pixelfo...
I think if you were already on a Mac and wanted to use Panic Nova, you'd be better off using Icaras:
https://extensions.panic.com/extensions/panic/panic.Icarus/
The one you linked to looks like it's just syntax highlighting; Icarus has that, but also has LSP, building, and debugging support.
I hope the website’s focus on non-Apple platforms coincides with an actual project focus on them.
I find Swift fascinating, but the software I want to write is not software locked into Apple platforms. The low level stuff looks particularly interesting, as the common low level languages all have their peculiarities.
Swift is usable (on Apple operating systems) if you use the add ons that Apple provides (like SwiftUI). Other than that… forget about it. Tried to use Swift for CLI apps (on macOS) and it failed miserably. The reason: after reaching a certain code size the Swift compiler is reporting vague syntax errors without line numbers. Unacceptable in 2025.
I can’t speak to the errors you’re seeing, only that my experience is different. I’ve written well over a hundred CLI apps on macOS, of all sizes. I consider it a very good language for it too (also for scripting). A nice thing is that you can leverage the whole of AppKit/Foundation/Carbon/etc in CLI apps allowing for uniquely powerful tooling & integration.
I’m happy for you and everyone else who has had the same experience as you. I’ve saved my Swift CLI apps, so I might try it again when a new version comes out, hopefully they fixed such behavior.
Slightly off topic, but the sheer size of the ToC of the Mixing Swift and C++ page[1] makes me think I'm better off just learning and using C++.
https://www.swift.org/documentation/cxx-interop/
If that kind of complexity frightens you then you probably want to stay away from C++ entirely.
What I mean is, if I'm going to learn complexity, I might as well go all-in on one unified language.
I've got no experience, but I imagine you don't have to interface with C++ too often, and when you do it's probably unlikely someone haven't written a wrapper library already. That's how the entire Python ecosystem works, either someone has made a wrapper, you make a wrapper or you use subprocess if the library has a CLI and you're not in a performance sensitive part of execution.
Any language that makes programming easier is good. Modern C++ is also quite good, but I feel like there are more "nice to haves" in other languages. Reflection is one, for serializing things without boilerplate and his uncle. And just reflecting on types in general can be nice.
Quite frankly, this isn't even that large. There are entire books about topics like JNI (Java <-> C) or Swig (Python <-> C); this page is fairly short given the broad scope of Swift's C++ integration.
Really hard to imagine a use case for Swift outside of Apple platforms. It's a good language without much library support anywhere other than Apple platforms.
The site being discussed prominently mentions
- “Tools for Linux, macOS, and Windows”
- “Run performant services on Linux and deploy to the cloud”
- “Develop efficient, reliable firmware for devices like microcontrollers”
- “Reuse existing C/C++ drivers and SDKs with zero wrappers or runtime glue, integrating in minutes.”
The site has examples for running Swift code on a Raspberry Pi Pico W, an ESP32 microcontroller and a PlayDate.
That doesn’t mean Swift is the best tool for doing these things, but “really hard to imagine a use case for Swift outside of Apple platforms”?
Example code after 2 Page Down hits. So they beat Rust on this metric!
Actually the new site looks quite cool.
Are the compile times still terrible (worse than templated C++).
Not a good design, where is the search bar? Why is the site's footer area so vertically large? And why do you need two birds at the top limiting you to just a single sentence? Also the first page examples are undocumented
[dead]