Please tell me what facts in that post were wrong or hyperbolic and I'll apologize. I'm just speaking from personal experience. Our enterprise app has a ton of local packages now, but it's been a regular source of build problems that have required ugly hacks to work around.
For example, Xcode 12.5 added a "feature" where if you don't specify ".dynamic" or ".static" then Xcode will decide which one to use automatically. This was supposed to be a solution for the bug where if multiple targets in the same package depend on the same other target in the same package, you get "unexpected duplicate" errors because Xcode will only use static linking between targets in the same package even if they're each declared as dynamic.
However not only did removing explicit ".dynamic" not fix that duplicate target issue, it made it far worse by removing your ability to specify whether to embed a dynamic Swift library product in frameworks that link to it, resulting in App Store submission failures due to many copies of the same package automatically being embedded everywhere.
So we've had to implement a build script that goes back through the build folder and cleans out all these package frameworks. What the actual F.
To make matters worse, dynamic library framework bundles generated from Swift packages don't get a "Headers" folder like normal frameworks made from Xcode projects, even if they contain @objc Swift code. That has led to a situation where importing a Swift package in an Xcode project framework's Obj. C headers always breaks the build. This is frankly an inexcusable bug that should have never made it to prod had Apple used TDD to make sure package frameworks aren't malformed.
Another issue is that these auto-created package frameworks have bizarre names like NetworkStuff_157B50DE_PackageFramework.framework, and they always get put in a subfolder of the normal built products directory called PackageFrameworks. And there's no way to override this. Why? This is a minor annoyance, granted, but if you don't realize it and don't add special framework search paths to account for this, then you might spend quite some time trying to figure out why your Xcode projects cannot import Swift packages even when you link everything correctly.
And that's just the tip of the iceberg of what we've had to deal with since starting to use packages for local modules.
Should I also tell you about how if you use an unsafe flag in a local package to hack a solution to a problem like packages' inability to be linked to non-system binaries, now you cannot link that package to an Xcode project at all? This is clearly a bug, because "unsafe" is only meant to protect you from a foreign package being able to do bad things on your computer (since a package manifest is actual code that gets run when Xcode opens)—but "unsafe" was not supposed to affect what you can do with local packages. Yet another bug with Xcode's SPM implementation that should never have reached prod had the Xcode team used TDD to make sure that using a local package would be functionally equivalent to using an Xcode project to accomplish the same ends.
Or should I tell you about the intentional limitations of Swift packages, like their inability to handle mixed-source targets? Their lack of support for customized build configuration names? (Woe be unto you if you use any build configuration not named "Debug" or "Release.")
Or perhaps you want me to explain the horrific way that asset catalogs were implemented for SPM where other modules cannot see the bundle or catalog? Compounded with the other bugs mentioned above this makes local Swift packages useless for managing assets in mixed-source targets because you will wind up with two copies of the same catalog, one for the package that serves them to Swift and one for the packahe that serves them to Obj. C.
Maybe there is some other hack workaround for the assets issue, but that's not the point—the point is it doesn't just work. So you wind up wasting a lot of time.
So have we. Maybe for some small or medium projects, especially if they're all Swift, and especially if you are also using SPM to manage all your third-party dependencies, it might not be so bad, especially if you have bandwidth to implement a DI scheme like the one you mention. I love DI so I'm not gonna say that's an invalid approach.
But if, like many codebases:
- you still have a lot of Obj. C code
- you use shared .xcconfig files to avoid having to re-specify the same build options everywhere
- you don't like writing hacky build scripts to make your app submittable
- you have any Xcode configurations with custom names
- you use .xcconfig files
- you still use CocoaPods or Carthage because that's what works with your CI pipeline's dependency cacheing solution and you don't want your workspace to take 30 minutes to open for anyone who hasn't opened it before
- you want the flexibility to be able to override any build setting without referring to LLVM's source code repo
- you don't have time to be a beta tester for buggy software that receives pretty low priority by its developer relative to their other concerns
... then I stand by my recommendation that people should not bother with using Swift Packages for local modules.
Xcode projects give you a lot more flexibility and control, they have a nice UI that lets you edit ALL settings, they support an unlimited number of customizable build configurations (not just "Debug" and "Release" like SPM) they and they just work.
If this comes off as "aggressive" that's your opinion, not mine. I'm not trying to attack anything or anyone. I'm just trying to do someone a favor by hopefully saving them the frustration that I personally went through.
If you're someone who works at Apple or works on SPM, I'm not saying SPM is bad. I just don't think SPM was designed for the local module use-case except for local development of a distributed package. SPM/Xcode integration is also not built around the use case of Swift packages as local modules. This aspect still needs a lot of work.
I hope Apple prioritizes it more. I would like to see them resolve to fully replace Xcode projects with SPM, but that doesn't seem to be where they are headed—Xcode 13 just intro'd a new Xcode project format. Why do that if you're going to get rid of them?