10 ms·
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, man
by JackYoustra 8mo ago
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.
- latexr 8mo ago> 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 8mo ago> 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?
- latexr 8mo agoIncorrect. I use Helix. But the editor is irrelevant, which is why I left it out.
- fragmede 8mo agoAnd the licensing agreement. How do I do it on Linux with no Mac or iOS?
- bjtitus 8mo agoSwift has builds for Linux: https://www.swift.org/install/linux/ https://www.swift.org/install/linux/ The license is pretty much Apache 2.0
- hn-acct 8mo agoThe 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.
- JackYoustra 8mo agoYou 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 https://github.com/xtool-org/xtool although, at this point, just use expo!
- snickell 8mo agoSwift 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.
- dfabulich 8mo agoIf 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.)
- behnamoh 8mo agoEven 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.
- alex-russo 8mo agocurious what you used - I've been looking into making a menubar app and really hate xcode
- hombre_fatal 8mo agoclaude -p "Make a menubar app with AppKit (Cocoa) that does X"
- mort96 8mo agoI 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"...)
- alwillis 8mo agoThere'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 https://notepadexe.com [2]: https://notepadexe.com/news/#notepad-14-linux-support https://notepadexe.com/news/#notepad-14-linux-support
- afavour 8mo ago
- stackghost 8mo agoFWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
- fluffybeing 8mo agoCan you share your configs or link to it? Would love to learn how you did it?
- mrcwinn 8mo agoTotally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
- doawoo 8mo ago+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.
- roegerle 8mo agodon't know personally but I'm told bazel shines here.
- lawgimenez 8mo agoHours ago I was setting up Xcode Cloud on Xcode and it kept crashing whenever I edited the workflow. Smh
- blueprint 8mo agoI 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.
- junofan 8mo ago+1 blows the pants off anything else I’ve touched with zero config fiddling. Great stuff.
- jayd16 8mo agoI 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.
- blueprint 8mo agoHow 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. What motivated your comment?
- Brian_K_White 8mo agoHasn'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.
- blueprint 8mo ago> 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.
- hedora 8mo agoMy 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.
- jtrueb 8mo agoYes! 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.
- atombender 8mo agoI'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.
- cosmic_cheese 8mo agoPersonally 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…
- atombender 8mo agoSorry, I did mean AppKit here!
- heavyset_go 8mo agoWhat's the issue if it allocates virtual memory?
- atombender 8mo agoHaving my app consume 300GB of virtual memory after running for a week is not ideal.
- piperswe 8mo agoIs it actually resident or is it just mapped but unused?
- 8mo ago
- willtemperley 8mo agoMost 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.
- cosmic_cheese 8mo agoExperience 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.
- ethin 8mo agoMy 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.
- willtemperley 8mo agoYou can build Swift entirely with CMake; https://github.com/swiftlang/swift-cmake-examples https://github.com/swiftlang/swift-cmake-examples
- ethin 8mo agoSure, but I've never found examples of (say) including other swift packages. Or using CMake-built swift packages in SPM.
- jabwd 8mo agoWhat 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.
- frizlab 8mo agoI 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.
- teaearlgraycold 8mo agoWhat company is using Swift outside of Apple-specific development?
- frizlab 8mo agoNot a lot, but has absolutely no relation whatsoever to my comment.
- odo1242 8mo agoDoesn’t affect the validity of your comment whatsoever, but there was the attempt by the Browser Company to implement Arc on Windows in SwiftUI lol
- alwillis 8mo agoArc, TBCNY's browser for macOS and Windows uses Swift [1] [2]. Their newer Dia browser which is meant to be cross-platform also uses Swift. [1]: https://speakinginswift.substack.com/p/swift-tooling-windows-edition https://speakinginswift.substack.com/p/swift-tooling-windows... [2]: "How we're building the Arc Browser Windows app with Swift" -- https://www.youtube.com/watch?v=Xa_fNuaSE_I https://www.youtube.com/watch?v=Xa_fNuaSE_I
- Imustaskforhelp 8mo ago> 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 https://skip.dev/ https://skip.dev/
- wolvoleo 8mo ago
- crowbahr 8mo agoI 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 8mo agoAs someone who basically only uses Emacs and Xcode- why is Xcode so bad?
- regenschutz 8mo agoEmacs and Xcode is certainly an interesting mix. Aren't they kind of the polar opposites of each other?
- geooff_ 8mo agoXcode truly is terrible.
- ks2048 8mo agoI’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
- Imustaskforhelp 8mo agoI 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 https://news.ycombinator.com/item?id=45023730
- saagarjha 8mo agoSure but not very many people care about SPM
- hota_mazi 8mo agoNot 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 8mo agohttps://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/exploring-the-swift-sdk-for-android/ https://www.swift.org/blog/exploring-the-swift-sdk-for-andro... ?
- andrekandre 8mo ago> 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 8mo agoiirc you can't do this for extensions which being a huge amount of compiler constraint resolution time
- andrekandre 7mo agointeresting, so maybe a good recommendation would be to not go overboard with too many public extensions... hmm...
- easeout 8mo agoThe 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.
- hboon 8mo agoI 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 8mo agoWell same for typescript
- monster_truck 8mo agoSwiftUI 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.