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 experienced a similar problem, and upon further investigation, I discovered that it occurred in the parts of the code where Swift and Objective-C are bridged. The problem seemed to stem from either the bridging or an issue within the Objective-C code itself
Perhaps try again and analyze for reference cycles between objects. I agree that ARC has painful subtleties. It existed prior to Swift, being introduced in Objective-C, and is definitely not a perfect memory model.
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…
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?
- it adds locking to almost every line of code using classes
- anytime you start holding complex references to classes you get cycles which will not be released
- it’s extremely hard to debug. You have to capture memgraphs at runtime and track dependencies
- it coexists with old systems like auto release pools so resources are still not released when all references go away
Try to implement a linked list in swift and you’ll get a sense of how absurd this is. And remember linked lists are a special case of graphs.
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.
Awesome, can you also grab a memgraph or something when it’s leaked a bunch of memory (and maybe put it in a GitHub issue)? I can try it but I don’t really use CircleCI so I’m not confident I can reproduce the issue.
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.
I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.
Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.
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...
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 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"...)
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.
>I t's a bit like using c# or powershell on Linux… but I wouldn't consider it a first class citizen.
C# is very very much a first class citizen on Linux. It may not be native, but you can run binaries on Linux without needing the runtime when you compile it to target the platform.
I wrote a couple of monoservices on my Mac using c# which ran perfectly on my Microk8s cluster on Linux.
I have nearly a decade of experience building .NET C# solutions on Linux and lately also on Mac, with almost everything hosted on Linux via Docker. I’m not sure what’s still missing for it to be accepted into the "first class citizen" club by the Linux elite.
> 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
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.
> I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.
It's not unusable, but it's not that great either. When I have a project that requires Xcode I certainly don't look forward to it the way I do such as wehn I have a project that doesn't need any specific IDE.
As a sidenote; I recently (1 year ago, maybe?) did a C project in Eclipse, and was blown away but just how snappy, quick and, utlimately, enjoyable it was compared to VS Code.
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!
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).
As your app scales, you're going to want to break out different parts into their own packages in order to keep compile times in check, so you're gonna be forced to go through SPM unless you use tuist or bazel.
I'm just talking about having some mechanical sympathy for the compiler such as understanding where the constraint solving problem space gets very large.
I wasn't saying use explicit types everywhere, but giving the compiler a hint every now and then to make things faster just makes sense. The Swift compiler is very complex and of course there are edge cases where it struggles with legal syntax, such as large expressions with many operators.
With SwiftUI it's arguably more important because view builders already put a lot of strain on the compiler.
You can't really easily use explicit types in much of idiomatic SwiftUI. The expression that the compiler is trying to solve is really complicated, I agree, but the solution to that is either changing how SwiftUI is architected or restricting how the language built on SwiftUI infers types.
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.
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.
I mostly work in games where Xcode is an all too common chore to pick up from time to time because Apple changed the rules on something or other to get an iOS build out. Usually I find that xcode isn't helpful at all in solving these problems. You need to dig through guis because it will not just trivially point you to the text file like VS or Jetbrains would.
It's certainly not a pleasant treat to pick the short straw.
Beyond that, I work with plenty of folks who have dabbled in xcode for mobile or on the side and it's just not seen in that great a light.
Meanwhile, I find that people who love xcode are all in and don't really give alternatives a chance at all (because when you have to use xcode, there isn't an alternative).
Even in this comment chain, we're rejecting other's opinions outright instead of talking about killer features xcode has that others fail at.
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.
+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.
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.
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)
SwiftUI is straight up the worst thing Apple has ever shipped. Absolute fucking pile of dogshit. They should be ashamed of themselves. Steve would have fired everyone and I mean that.
It remains the only UI framework I've prototyped something in where I've had to respond to a well paying client with a list of what it (still!) can't do, doesn't do well, and a long list of documentation that does not match the code. I have a sense of integrity so I do this work honestly. There are plenty of devs out there that will happily tell you xyz can be done just so that they're paid to make something they know will be subpar.
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.
The funny thing about the low effort parent comments is the truth - wikipedia lists that there are more release builds of swift of linux than for macOS. Granted they were bug fixes but still.
- 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.