So... some problems.

[hmlongco]

Probably missing something obvious, but I tried adding this to a project using SPM in Xcode and it only presented with an option to add the main library and not the plugin without which nothing will work.

Since I can't get it fully working yet I'm not positive on this but do you have to define a class, then the class dependency, and THEN build the project such that said dependency now exists on the container. And then, and only then, can the reference on the container now be referenced in the code?

Also appears to suffer from the MainActor cascade. Once you marked the entire container class as requiring MainActor then the dependent classes needed to be marked that way, and so on until you can't even create a SharedContainer() unless you too are within a MainActor.

Also has a bit of a problem with adding dependency conformance via extensions as you can't provide the needed initializer unless your class is marked final. Ran into that issue myself awhile back playing with a successor to Resolver.

[valentinradu]

1. Interesting. I never add libraries via Xcode but directly in Package.swift. Will have a look/update docs if needed.
   Indeed, that's the way it works.
2. Actually, you don't even need to build in my experience, SPM/Xcode is smart enough to generate the extensions incremental each time the file changes. But yeah, worst case scenario you build.
3. That's something I need to think about. It's the way Swift concurrency works tho. Any ideas welcomed!
4. Yeah, a language limitation (and for good reason). I usually mark my classes final and build wrappers for those that I can't mark then provide conformances to those wrappers. A bit convoluted, but I don't think there's a way around it right now.

Closing this in favour of #3