[JackYoustra]

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.

[atombender]

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.

[rTX5CMRXIfFG]

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.

[teunispeters]

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.

[maksimpiriyev]

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

[waffletower]

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.

[cosmic_cheese]

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…

[jabwd]

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?

[groundzeros2015]

The memory management is almost broken. They decided not crashing was better than mashing memory.

[heavyset_go]

What's the issue if it allocates virtual memory?

[saagarjha]

Is it something you can share the code to?

[lelanthran]

There's no valgrind equivalent, I guess?

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.

[dfabulich]

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.)

[alwillis]

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.

[1]: https://notepadexe.com

[2]: https://notepadexe.com/news/#notepad-14-linux-support

[behnamoh]

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.

[mort96]

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"...)

[frizlab]

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.

[truncate]

LSP support isn't great. It keeps improving however. Used to get quite a few crashes. And I think background indexing still doesn't work.

[wolvoleo]

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.

[teaearlgraycold]

What company is using Swift outside of Apple-specific development?

[hn-acct]

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.

[willtemperley]

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.

[hn-acct]

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.

[ElFitz]

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.

[cosmic_cheese]

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.

[JackYoustra]

Xcode (and as of a couple years ago the vscode spm integration) tends to have difficulty when scaling this solution.

Being explicit with types is very disruptive when used in SwiftUI or TCA.

[h4x0rr]

Using explicit types is less fun though

[plagiarist]

SPM is fine for most Swift and then fully enraging when you have a slightly divergent use case. IME of course.

[stackghost]

FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.

[fluffybeing]

Can you share your configs or link to it? Would love to learn how you did it?

[blueprint]

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.

[jayd16]

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.

[cosmic_cheese]

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.

[andoando]

Weird the little Ive used it I completely hated it.

Errors everywhere with horrible messages that leave you no idea whats wrong

[peyton]

+1 blows the pants off anything else I’ve touched with zero config fiddling. Great stuff.

[jtrueb]

Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.

[mrcwinn]

Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.

[doawoo]

+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.

[lawgimenez]

Hours ago I was setting up Xcode Cloud on Xcode and it kept crashing whenever I edited the workflow. Smh

[latexr]

> Xcode

You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.

[Imustaskforhelp]

> You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.

when you mention terminal editor, I think you are a Neovim user right?

[crowbahr]

I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025

[ks2048]

As someone who basically only uses Emacs and Xcode- why is Xcode so bad?

[andrekandre]

  > imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module

i've noticed this too... i wonder if doing scoped importing helps with this for example:

  import struct MyModule.MyStruct

[JackYoustra]

iirc you can't do this for extensions which being a huge amount of compiler constraint resolution time

[easeout]

The main problem I have with the language is compile times. Rust is good at many things, but not that.

Xcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.

[hota_mazi]

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.

[hn-acct]

https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/exploring-the-swift-sdk-for-andro... ?

[ks2048]

I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?

[Imustaskforhelp]

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)

Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730

[hboon]

I remember that in early Swift, I had a 1-2 line dict/array literal and it caused the file/project build to be 30 minutes.

[jbverschoor]

Well same for typescript

[geooff_]

Xcode truly is terrible.

[monster_truck]

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.

[fragmede]

And the licensing agreement. How do I do it on Linux with no Mac or iOS?

[JackYoustra]

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).

You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool

although, at this point, just use expo!

[snickell]

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.

[bjtitus]

Swift has builds for Linux: https://www.swift.org/install/linux/

The license is pretty much Apache 2.0

[hedora]

My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.

My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.

This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.