1

Why doesn't Xcode let you link a dynamic link a dynamic target of a Swift Package without embedding it?

I.e. is this just a UI glitch or is there some technical reason behind it?

In our app we have defined some small dynamic library targets using Swift Packages. Whenever we try to link these to our existing Xcode project frameworks in the app, they show up as "Embed & Sign" by default, and if you set them to "Do Not Embed" in the UI, then they vanish from the list of linked libraries.

The only workaround we've found is to manually edit the .pbxproj file to remove the Swift Packages from the embed step. (However, if we do this, then it mysteriously breaks SwiftUI previews, although the app will work fine. I reported this as a bug to Apple yesterday.)

However I'm very reluctant to use Embed & Sign to embed the same dylibs into multiple targets within our app, since that seems like it would lead to duplicated symbols. However doing this seems to be the only way to get our SwiftUI previews to work.

Also, regardless of whether we link these dynamic Swift Packages as "Embed & Sign," or "Embed Without Signing," or "Do Not Embed" (by editing the .pbxproj file)... now we have a problem where we cannot build the app in "Release" configuration because it will complain about one of these dynamic SPM targets not having been built with bitcode. However there's no clear way to enable bitcode because there's no UI around the build settings and it's totally unclear how one would do this.

The result is that because we've used SPM now the only way to build the app in Release configuration for a device is to use Xcode's "Archive" option.

I feel like I must be not understanding something here.

Is there something I'm missing? Or is it just that SPM is basically beta software that has a lot of bugs, at least in regards to using it with Xcode?

1 Like
2

I think it's been stated before that it's just a limitation of the feature in Xcode and could be fixed either by making Xcode smart enough to figure out when to dynamically link dependencies automatically, or allowing the user to set the linking directly.

Now, whether it ever gets fixed is a matter of resource allocation within the Xcode team. Given that the SPM integration is essentially unchanged between Xcode 11 and 12, I don't hold out much hope of the situation improving any time soon.

3

I wonder how we (app developers) could impress upon Apple how important SPM is, so that they prioritize this higher?

In my organization we have a single app over a million lines of code, worked on by a bunch of different teams in five cities. Each team is typically responsible for at least one module within a our monorepo, however there are also some shared modules.

In a project the size of ours, Xcode project files are a major source of consternation and headaches. Up to now, each of our modules is a dynamic framework, defined by an Xcode project. However, we universally loathe Xcode projects with a heated passion because they represent everything using random GUIDs inside a nested .pbxproj file.

Xcode project files are evil because:

  • they add lots of noise to code reviews
  • if two developers make the same exact change independently of one another, it always causes a merge conflict because the random GUIDs will be different and/or Xcode will put things in a different random order
  • git often misidentifies non-conflicting single-line changes to .pbxproj files as conflicting because it groups lines together for no reason
  • when (not if) someone resolves a merge conflict incorrectly in .pbxproj files—which is easy to do—it causes project-file corruption that can break the build (or worse, not break the build, but just cause a crash)

TLDR: we want to switch to using Swift Package Manager to define all our internal modules going forwards because that way, we can never deal with Xcode project files, ever again.

Obviously the app itself will have an Xcode project file, but that's OK, since this would hardly ever get touched as everyone just works in the modules.

However, we would even love it more, if the app itself could also be a Swift Package!

Note: all of our locally-defined Swift Packages will live in the same repo, and we'll be using Carthage to build binary XCFrameworks that will be imported to the various packages.

It's not feasible for us to adapt all of our modules to packages in a single PR, so we'll have to do it one-by-one. However some of the bugs we've found when working with Swift Packages in Xcode have been preventing us from really committing to this, and it's kind of painful to think that Apple might not be prioritizing improving how SPM is integrated with Xcode.

But basically the main holdups for us are (with Apple bugreport IDs):

  • Xcode Previews fail when using a dynamic Swift Package dependency that's not embedded in the framework that the preview is defined in (FB8955594)
  • Removing a dynamic library Swift Package from "Embed Frameworks" in Xcode UI also removes it from "Link Frameworks and Libraries" (FB8914251)
  • Remote swift package dependencies sometimes fail to resolve and take too long to resolve (FB8944736)
  • @testable doesn't work in Swift packages when using an Xcode configuration with a name other than "Debug" (FB8914293)
  • cannot build and run app in Release configuration with bitcode enabled if it has locally-defined Swift Package dependencies that define dynamic library targets and Deployment Post-processing is enabled (FB8956614)
  • Swift Packages don't allow for custom configurations with user-defined names (not really a bug but something we're hoping to make a proposal about)
  • You can't add locally-defined Swift Packages under "Swift Packages" when editing an Xcode project (kind of a counter-intuitive state of affairs)

It would also be nice to have Xcode's GUI for managing targets, inherited build configurations, and build settings get updated to work with Swift Packages instead of .xcproj files. Because as much as I love editing Package.swift files, it's not like there's an enumeration for all the possible settings keys nor are incorrect entries rejected by the compiler—leading to a situation where it's not really clear how to specify certain settings for a Swift package (like is "ENABLE_BITCODE" a SwiftSetting or a CXXSetting?). Plus, developers are accustomed to working with the existing GUI.

2 Likes
4

The scalability of Apple's tools, especially when it comes to Swift, has always been an issue. It is occasionally prioritized or improved when there is a focus on other issues (compiler performance improvements help everyone) but there has never been any sort of priority given to such things outright. AFAIK (this is all speculation), there is no team within Apple dedicated to fixing such issues. At most a "responsible individual" or two may be designated who could work on such things for a given amount of time, but even then they may not be able to spend all of their time on the issue.

We saw that relative prioritization with compiler diagnostics after SwiftUI launched and everyone complained about the terrible error messages. Someone was assigned, refactored the diagnostic engine, and improved things. But once it was good enough, efforts diminished and improvements largely stopped, as there's no dedicated diagnostics team. So we're left with an improved, though still not great, diagnostics system that's still rather easy to trip up.

As to how we can get Apple to generally care more about fixing things the community cares about? I really have no idea. Personally, I'm not sure they're structured in a way that would support such a thing. Apple's teams are surprisingly (I would say sometimes shockingly) small, and they seem to allocate features by individual, not team, so it's hard for them to scale to solve large problems. So it seems unlikely they would ever solve the issues by scaling up, dedicating teams to problems areas, and continuing to iterate on solutions past a single product cycle. People have been trying to get some focus on these areas for years. If you figure it out, let us know.

2 Likes
5

Interesting, thanks for the insight.

Certainly not surprised if that's true—any company wants to operate as efficiently as possible. Certainly not expecting them to have a full team always dedicated to community requests or something.

That being said, hopefully they will see the value and importance of making SPM a more central player within Xcode, and fixing the current issues, considering they do officially support it and I would imagine that Apple themselves also has similar pains around Xcode project file conflicts etc. (Since I'm guessing they use it for a lot of internal projects.)

I have had pretty good luck with them fixing things when I've been able to supply an example Xcode project etc. so, will keep my fingers crossed.