Does this package really need so many dependencies? 🤔

[Jeehut]

I just considered adding this lib to my recommended list of packages for every app, but when I added it and looked at the Git diff, I was shocked to see that this library adds 9 packages in total!

While it might be possible that there's no way around it, I can't recommend a 3rd-party lib with so many dependencies to everyone, so I decided against doing so. And I would just like to know: Are there ways this library could become less dependent? Or is there maybe a way to use the "core" of this library (I mostly need user defaults and in-memory) that has less dependencies?

In any case, thank you for your amazing work and I'll be playing around with this for sure.

[mbrandonw]

Hi @Jeehut, can you explain in concrete terms what your fear is with Swift Sharing having transitive dependencies on our own libraries? If you are willing to depend on Swift Sharing, why wouldn't you be willing to depend on our other libraries? If Swift Sharing is actively maintained, then it certainly means the transitive dependencies are also actively maintained. And would anything tangibly change if we literally copied and pasted all the code from those libraries into Swift Sharing?

To me, the situation with Swift Sharing doesn't seem much different from people depending on FlineDevKit. They add your one dependency only to find out they are actually depending on 5 of your other libraries. Do you feel that people using FlineDevKit should have the same concerns that you have about Swift Sharing?

And I would just like to know: Are there ways this library could become less dependent?

The only transitive dependencies that stand out to me are Combine Schedules and Swift Clocks. These come from Swift Dependencies, and so technically we could make a DependenciesCore module that does not depend on those libraries, and then Dependencies would use them.

We certainly can do that, but would reducing the number of dependencies by 2 have real, tangible benefits?

Or is there maybe a way to use the "core" of this library (I mostly need user defaults and in-memory) that has less dependencies?

The "core" of the library uses all of the dependencies, so that would not help.

[Jeehut]

@mbrandonw Thank you for your quick and thorough reply. I'm happy to answer your questions and explain my concerns.

It's true, I'm very hesitant to add 3rd-Party dependencies to all my apps and even to recommend them as generally useful for all apps, mostly because of maintenance concerns. But as you might have noticed, I already have your IdentifiedCollections package in my list and that's because I did make an exception for libraries from you guys, because you do have a track record and I trust you to actively maintain your libraries. And you are very right that most dependencies are your own ones, and that's exactly the same as for FlineDevKit itself, where most are mine. So that's not the main point I worry about. On that point, I just wanted to know if you maybe added a few libraries only for specific features, which you said is not the case.

So my main concerns are not maintenance, but the following:

1. Checkout time
2. Build time
3. App size
4. Confusion

In short, I am concerned about developer experience. Because I know that many developers are reluctant to add dependencies that make their developer experience worse. And it can really be annoying when you quickly want to fix a bug in one of your apps you haven't worked on for a while, or maybe you only switch to a branch to review code that has different dependency versions, which often leads to new checkouts or clean builds. And, of course, if you have a small simple SwiftUI app and are used to your app size being below 5 MB, adding a lot of dependencies can have a big impact.

I have to say, I haven't measured any of these yet. But I remember from times when I was using TCA that all three were affected to some regard. And that didn't even rely on swift-syntax, which like Stephen told himself on the Swift forums has very slow builds times (repeated by others recently) and can also be a nightmare of a dependency hell.

To give you another use-case, I'm thinking about switching to this lib to fix this bug report in my FreemiumKit SDK. In short, there's a bug in SwiftUI environment, and I had the idea that maybe migrating from the environment to in-memory sharing could resolve the issue. But that would also mean, that everyone who adds my FreemiumKit SDK to their app is going to see that 9 dependencies are added to their list of dependencies in the left sidebar. That number alone is a reason not to use this lib for that use case. I can already see people sending support tickets and asking "What are all these dependencies?".

So…

And would anything tangibly change if we literally copied and pasted all the code from those libraries into Swift Sharing?

Yes, it would actually make a big difference. Why?
Because it communicates "swift-sharing is what we actually need, don't worry about the rest, no need to learn about them" and therefore reduces the shock of "what are all these dependencies 😱".

To me, the situation with Swift Sharing doesn't seem much different from people depending on FlineDevKit.

FlineDevKit is targeted toward people who are already using multiple of my libs. Everyone else will fork it and adjust the dependencies to their needs, which is super easy since it's basically just a single Swift file with few lines. So, while I do get your point, it's not true that it's the same thing as depending on swift-sharing. If you look at any of my other libs (e.g. LinksKit, ReviewKit, or HandySwiftUI), they are all not relying on anything, except maybe my "core" lib HandySwift, so they have max 1 dependency. When I only use specific parts of HandySwift, I even copy the code rather than depending on HandySwift. But I do like to depend on HandySwift, because I believe most people who check it out would actually learn a lot and some people might actually use some of it's niceties without even noticing, because many added APIs feel natural to Swift's existing types.

We certainly can do that, but would reducing the number of dependencies by 2 have real, tangible benefits?

Yes, removing Combine Schedules and Swift Clocks would also make a difference. IIRC I had run into incompatibility issues with one of those libraries in the past in particular with an Xcode update, so I would love them to get removed if they are not needed, in whatever form that is. The fewer dependencies, especially ones that feel like "implementation details", the better.

---

I don't want you to get me wrong, I do understand your reasons for doing things the way you've done, but I did want to let you know my thought process and the moment of initial shock. I'm currently still unsure if I should use this lib or not, but I am also working on another lib with macros myself that makes use of swift-syntax, so maybe I will take the time to check if adding swift-sharing impacts the checkout time, build time, or app size in a noticeable manner or not after I depend on swift-syntax myself (because I assume that has the biggest impact to all 3 aspects). If you have any insights in these regards, please let me know or point me to some docs where you already address my concerns if you have any.

[stephencelis]

@Jeehut Thanks for the thoughtful and thorough discussion. I do agree that the Apple developer community tends to be dependency-avoidant and instead embraces "not invented here" ideology.

I have to say, I haven't measured any of these yet.

I do think it's important to always measure and analyze the results before forming too strong of an opinion.

But I remember from times when I was using TCA that all three were affected to some regard. And that didn't even rely on swift-syntax, which like Stephen told himself on the Swift forums has very slow builds times (repeated by others recently) and can also be a nightmare of a dependency hell.

For what it's worth, the pain around Swift Syntax shouldn't be felt in Sharing: we make a point to not depend on any macro code. Apple is also well aware of the issues around macros and there are solutions being worked on that should alleviate things in repos that require macros, like TCA.

Yes, removing Combine Schedules and Swift Clocks would also make a difference. IIRC I had run into incompatibility issues with one of those libraries in the past in particular with an Xcode update, so I would love them to get removed if they are not needed, in whatever form that is. The fewer dependencies, especially ones that feel like "implementation details", the better.

Sharing depends on our Swift Dependencies library in order to be testable and work well in previews, and Combine Schedulers and Swift Clocks are extremely small dependencies filling gaps in Apple's frameworks and Swift's standard library. We think the work needed to isolate them is probably not worth it, and depending on how it's done could be a negative developer experience for folks using Swift Dependencies. That said, we're not totally averse to contributions that do the following:

1. Adds a DependenciesCore module to Swift Dependencies that contains just the core library types and functions.
2. Adds a DependenciesCombine module to isolate the Combine Schedulers code
3. Adds a DependenciesClocks module to isolate the Swift Clocks code
4. Re-exports all modules from Dependencies
5. Updates to Swift Sharing that imports DependenciesCore instead of Dependencies

We will probably not take the time to make such a change ourselves, as you are the first person to voice a concern here, but if you believe it's worth the effort, we are open to it!

All of Sharing's direct dependencies add direct value to the library, though, so we're not sure there's much room to prune things further.

[Jeehut]

Thanks, I will measure the impact and think about how I would like to continue from there.

Currently, I'm wondering if there any other ways of "hiding" dependencies that are "implementation details". Such as through specific kind of import access modifiers (package import?) or maybe building an XCFramework. Do you know of any of that would help reduce the visible dependencies in Xcodes sidebar?

[mbrandonw]

FWIW, we cannot eliminate Combine Schedulers as a dependency due to this, and so really only Swift Clocks can be eliminated if we go the extra mile to separate that dependency from the Dependencies target. @Jeehut if you want to take on that work we will happily merge it.