Broadly agree but, as is most things, the devil is in the details!
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.
I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
I agree, but I think that it's difficult to spot memory leaks in SwiftUI because it's such a high-level abstraction framework. When working with the Cocoa and Cocoa Touch libraries, it's so much easier to find.
And of course, Apple's UI frameworks != Swift the language itself.
hunting dangling references in a reference counted system is like that.... that's all I can guess is going on here. Good hunting! I wonder if there's a resource debugger? So far when I have really had to look, xcode was suffiicent... but there's likely better out there for finding this kind of thing.
I mean, even if valgrind ran on MacOS, it may still not give anything meaningful because the debug symbols are probably not going to be the same as that generated by GCC, and even if they were the same, there's still gonna be a bunch of symbols "missing" because of internal swift name-mangling, and even if that wasn't the case, the emitted code might just not be ABI compatible with C anyway.
Personally I avoid using SwiftUI except in bite size chunks like collection view cells. It’s great for that kind of use case but doesn’t scale up well.
I wasn’t of the mind that AppKit/UIKit really needed replacing in the first place, though…
It does not count under private memory, so I assume mapped but unused. The last time I asked Claude, it said confidently it was a bug in Swift's networking stack, which I doubt.
That’s the great thing about indiscriminately scraping the internet for knowledge.
I’ll bet Claude was channeling some Reddit guru dripping with swagger born from knowing their understanding of coding is far more advanced than most big-shots in the field— especially impressive because they only wandered into /r/LearnProgramming for the first time several months prior.
I'm sorry but what exactly are you doing? This is the first time I've ever heard any of this type of reasoning, and well, the fact that you're using AI makes me think you have no clue what you're actually talking about.
If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.
please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?
If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
There'a great indie app called Notepad.exe [1] for developing iOS and macOS apps using macOS. You can also write and test Swift apps for Linux easily [2]. It also supports Python and JavaScript.
If you hate Xcode, this is definitely worth a look.
So wait this thing is real? Calling it notepad.exe gave me the impression that it's just an elaborate joke about how you can code any program in Notepad...
I would avoid it for Linux and Windows. Even if they are "technically supported", Apple's focus is clearly macOS and iOS. Being a second- (or even third-) class citizen often introduces lots of issues in practice ("oh, nobody teenaged that functionality on Windows"...)
Even if you're developing for macOS you can skip xcode. I've had a great time developing a menubar app for macOS and not once did I need to open xcode.
I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)
Unless you’re doing Apple-specific development, you don’t need Xcode.
Why would you bother using Swift if you're not targeting Apple? I can imagine wanting to use it for something cross-platform that is primarily an ios/macos thing.
But if you don't want to include those I wouldn't pick a language that's under control of a company I don't use.
It's a bit like using c# or powershell on Linux. Yes it can be done and it's helpful for cross platform with windows but I wouldn't consider it a first class citizen.
I was talking about this at a party this afternoon (yes, I do go to the most interesting parties, thanks) and while Scheme is acceptable the Common Lisp is not because it's not OK to go without boolean primitives. Types are a good idea, if you have types the simplest is clearly the boolean, so start there.
I believe firmly that there should be a single true value, which we might reasonably name true, and a single false value, false, other values aren't booleans, so it's no more reasonable to ask whether an empty string is false, than to just forget to close the quote marks on a string. What we wrote isn't a correct program.
Common Lisp is actually a great language. The SBCL implementation has a good compiler that produce reasonably fast code, and it's under active development.
The only real drawback to common lisp is the fact that the library ecosystem is practically non-existent.
Agreed. People use any thread mentioning swift to dunk on Apple for X number of reasons with vague details and regurgitated dogma. I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.
Yeah, so I tried XCode with a couple of years ago. Within 2 hours of working on my very first project, it somehow corrupted either my project's metadata and/or its own internal preferences so badly that it would no longer launch - it would just crash to Desktop instantly. Literally the most unusable application I've used in recent memory!
> What company is using Swift outside of Apple-specific development?
Skip allows to "Build truly native iPhone and Android apps with Skip" so technically skip runs swift on android which is outside of Apple-specific development.
They also recently got open source from their closed source model prior from what I can tell
Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
I'm also wondering how big their programs are that the compile times are an issue. I'm seeing fantastic build times with Xcode 16 and Xcode 26.2 with swift 6.2 it's even better. SPM is also better with the newer version. Most issues can be solved or exposed by closing the window and reopening or going to the package with issues and pressing cmd+s.
Trying to make a .xcframework from SPM is "fun". And getting the Objective-C that are generated, but treated as intermediary artifacts discarded is a bit of a pain.
But I guess the issue here is that .xcframework is an Apple thing, not a Swift thing.
The whole "won’t build if the product / target has the same name as one of its classes" is absolutely ridiculous on the other hand.
Experience with SPM might vary depending on how many dependencies you’ve got. A lot of Apple platform apps are quite thin on third party library use, in which case SPM is probably not a large source of trouble.
My problem with it is that I want to use C libraries. And I would (like) it to handle that as much as possible. But SPM can't use vcpkg packages or call CMake stuff (at least, not trivially), so it's extremely hard to use on non-Apple platforms. Which honestly is it's killer for me. It's still so, so Apple focused.
What is a CMake-built swift package to begin with? You're mixing build systems and expecting them to co-exist or what is the exact problem? I've done a lot of weird swift things so might be able to point you in the right direction.
E.g.: referencing a vcpkg-built package (without pkgconfig because not all packages have those files). Or telling SPM "Hey, I have this package which uses the cmake build system, and I want you to link to it and auto-generate module maps for it, and get the include directories from cmake". Things like that. So for me anyway it makes using swift painful. The same thing goes in reverse: using SPM packages from cmake (although this is more a cmake issue).
It's been a while since I've Swifted but it was mostly with combinations of nested generics, lambdas, and literals. Annotating the type of the variable those were assigned to could improve performance a lot.
You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.
+1 I went out of my way to set up a skeleton project that just uses shell scripts to build an app bundle. I really dislike Xcode but Swift itself is actually fun to write.
I also wish to ask given that uv from Python learnt from cargo,npm and other things. Can it be possible for SPM to have an alternative similar to how uv got made for python too?
(I am not familiar with swift which is why I am asking this question if there's a really big difference between Swift package manager and cargo in the first place to warrant a uv like thing for swift ecosystem. I think someone recently posted a uv alternative for ruby)
I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.
I can't say you hear a lot of folks on other OSes with other IDEs saying "I wish I had Xcode". There was a minute when MonoDevelop was trying to emulate Xcode but that must be over a decade ago.
How many of those people who spend their time using other IDEs on other OSs (where Xcode doesn't run) spend any amount of time using Xcode and therefore have the requisite experience to be able to know that it's generally excellent?
And when you say "you hear", you really mean "you", not "me". I hear it a lot.
Hasn't everybody at least tried everything significant just because? Even the most non-apple developer must have at least checked it out on a friends laptop or something just to be informed of the state of their own business.
If there are developers who are that incurious, all I can say is I don't understand them.
> Hasn't everybody at least tried everything significant just because?
No, not in the slightest. I would call this one the most dangerous and unfortunate fallacies that so many intelligent people have ever accepted and been cheated by. If it were true, you'd know everything important there is to know, and be a master of philosophy, and would have many answers to some basic questions which most people have been told have no good or concrete or verifiable answers.
Personally speaking I don’t get the hubbub around Jetbrains and MS IDEs. Like they’re not bad by any means but they have their own sets of idiosyncrasies and bugs… it just depends on which set you happen to run up against most often in your day to day.
What version did you use? What errors did you see? Don't get me wrong, I've spent 20 years with it, and there was a learning curve - but isn't that the case with many good tools? Again, don't get me wrong, I have some feedback for Apple, and there's a reason why we affectionately call it a harsh mistress. But that doesn't mean it's somehow not one of the best designed, best functioning, and most powerful suites for programming with certain other incidentally very well engineered SDKs etc. And yes, things may have gone downhill a little bit, especially at the scale they're at now. If we could talk about Xcode of, say, 2014, it'd be a less ambiguous conversation.
Not mentioning the fact that Swift is nonexistent outside of the Apple ecosystem, and worse, Apple is explicitly not supporting it outside of the Apple operating systems.
You can develop Swift without it. I assume you mean SwiftUI / apple's sdk, which is what most people assume (a note, I'd say, to advocates of Swift who wish not to address SwiftUI: it's the biggest target, and its poor performance on it should speak volumes about the language).
Swift is available for Linux, license is Apache 2.0. There's even swift bindings for some linux ecosystem libraries, e.g. adwaita-swift for writing gnome apps and qt bindings for writing kde apps.
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.