[gregoriol]

This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift that current developer tools won't read, ...), and worst of all, it stores the full repositories of all the dependencies with their full history on your machine and downloads them every time when you do CI properly, which often means GBs of data.

[rTX5CMRXIfFG]

I don’t know, I’ve never had those problems and my codebases reach 600k+ LOC. I’ve certainly had plenty of errors to deal with Cocoapods and obsolete frameworks though, though those projects also tend to use pretty much every third-party lib that gets attention on Medium.

Modularizing an Xcode project with local Swift packages has been the best productivity gain in my experience. Doing something similar with Cocoapods is a headache.

[gregoriol]

Local Swift packages are indeed improving the experience a little bit: better version management, less xcode crashes, slightly more explicit errors, but still highly troublesome. It really feels like Apple's teams are not using any of SwiftPM themselves.

[ninkendo]

> It really feels like Apple's teams are not using any of SwiftPM themselves.

They probably never will, at least not for anything that ships with the OS. For Apple, binary size is very important, and it’s essential that they have only one of every library (“project”) installed on the device, and that they use dynamic linking everywhere.

SwiftPM uses static linking to the core, and if Apple were to use it, binary sizes would balloon (not to mention there would be potentially mutually incompatible versions of things.) You could fix this by ignoring version specs in the package file and building just one of every project/framework, and changing it to use dynamic linking everywhere… but at some point you’re just contorting swiftpm to become a big mono-build system, which only Apple would really be using as such.

[cosmic_cheese]

SwiftPM been little trouble for me, with the most complex project involving a number of external packages and a couple of local ones. No crashes or anything like that.

It’s been way, way less trouble than CocoaPods was before I switched several years ago. CocoaPods was so bad about screwing itself up that I’d just check in its dependencies in a building state and avoid upgrading anything unless I absolutely had to, because inevitably when doing updates or even just resolving my project would somehow hit some number of the many edge cases that’d cause it to blow up.

In contrast with SwiftPM I keep most dependencies pretty close to current because it’s painless to do so.

In fact it’s been good enough to me that I wish it were possible to replace the awful mess that is Gradle with SwiftPM (or a 1:1 JVM counterpart) on the Android side. I need approximately none of Gradle’s flexibility and bells and whistles that make it such a pain in the rear, so something with SwiftPM’s simplicity would be a serious QoL improvement.

[meisel]

Yeah, I’ve hit many pain points over the years with SwiftPM. Its restrictions on compiler flags is also problematic.

[atommclain]

My biggest criticism with SPM is that there doesn't seem to be a way to use it with git worktree since the package cache is centralized as opposed to being at the directory/project/workspace level.

[wahnfrieden]

Can you elaborate on the use case? I've started putting my local package dependencies into Vendor/ submodules in the repo I'm using them. I can't use worktrees with this setup?

[kiliankoe]

If you're looking for an outdated command, maybe this works for you? https://github.com/kiliankoe/swift-outdated/

Disclaimer: I wrote this (a while back)

[gregoriol]

I'm using it, thanks so much for making it :-) It should have been part of the swift base tools, it is very useful.

[kiliankoe]

Oh fantastic! And yes, I very much agree. I have some ideas for improving it a bit, maybe that'll make it worthwhile to PR into SwiftPM itself (:

[tomaskafka]

Sounds like Microsoft’s “Embrace Extend Extinguish” approach that everyone hated (and some successfuly sued) has found a new home at Apple.

1 take over the thing 2 succeed at it as a platform owner 3 not put in resources to do it well

[secretsatan]

Yeah, no, cocoapods was a nightmare compared to SPM, every ios update supplied a new unsolved issue in one pod or another that required dark incantations.

Managing a local pods caused issues so great engineers quit

[gwbennett]

100% agree!

[wahnfrieden]

Tuist

[richrichardsson]

In spite of search engines being a thing, this comment could have done with a bit more information. I assume you're talking about this: https://docs.tuist.dev/en/

[wahnfrieden]

Yes. There's no ambiguity, no other project uses the name

[MobiusHorizons]

It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)

[wahnfrieden]

Glad we've cleared it up

[johnisgood]

> I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)

That is on you, though.

[adastra22]

Another non-iOS developer here. It was absolutely not clear what you meant with a single word reply, and one that honestly looked like a typo or some kind of insult (short + -ist) I didn’t get.

[MobiusHorizons]

I completely agree with you that if I had wanted to I could have put in the effort to decipher the meaning of the post. However, the post left me with absolutely no desire to decipher it's meaning, so I did not. If instead the author had written simply "I use tuist for that" the meaning would have been immediately clear for someone like me, and I would have been much more likely to look up the product.

I don't mean to imply that there is some sort of "should" to this. The author is not required to want their meaning to be understood, even though I'm not really sure what other purpose they would have for posting. But I do think that this class of miscommunication is both common and reasonably avoidable by building up a bit of a mental model of the intended audience. I was trying to provide anecdotal evidence to build up that mental model.

[myko]

I will never start another Apple platform application without Tuist. If I start work on one I will do my best to get buy-in to switch.

[wahnfrieden]

It is also the only good way to use LLMs to manage projects/workspaces

You can use it for non-Apple platforms btw. Swift on Linux, Android, Windows, WASM. Projects like https://swiftcrossui.dev (with major contribution from Miguel de Icaza recently) and https://skip.tools for instance make this all the more productive

[myko]

Neat, I may check that out.

For my Swift backends running on Linux I have just been using SPM and when working on macOS open the manifest directly. I haven't really done anything with a non-web UI with Swift outside of blessed platforms.

[SoKamil]

Have you worked with Bazel before? Do you have a comparison to Tuist?

[myko]

I haven't earnestly used Bazel but my limited experience with it is that it does work fairly well and if your project is multiplatform it might be a better choice than Tuist for the Apple specific pieces. But if your project is all Apple and you're deeply into the ecosystem Tuist would be my recommendation - instead of Bazel's DSL you just write Swift to describe your project.