And now everything builds, albeit a little slowly because our live implementation is purposely taking a long time to build. The WeatherFeature framework builds instantly, and this means we can rapidly iterate on it, even on a clean build.

The SPM linker gotchas were definitely a pain, but we were luckily able to work through them. In the future Xcode will hopefully make everything a bit more streamlined here and take care of these kinds of linker issues automatically.

But let’s stop to appreciate what we’ve done here because this is really powerful. We are getting a ton of benefits all at once just by properly designing this dependency.

• First we are able to load up our screen in many different states and edge cases, such as when the API returns no data, or some data, or a failure, and even when the request just takes a long time to finish.

• And the mere fact that we can control the dependency in this way means this feature will be easy to test. We haven’t done that yet, but we will do that soon.

• And last, by pushing ourselves to properly control and separate the dependency from our application code we opened ourselves up to some nice compile time optimizations. We can now build features in isolation without building their dependencies. The only time we need to actually build a live dependency, whether it be Alamofire, Starscream, or some huge shared C++ library, is when building the full app that will actually run in the simulator or on your device.

So, there is a lot of power in extracting a dependency from application code and separating its interface from its implementation. I think a lot of people would assume that the only way to do this is to use protocols, but that’s just not true. You can do it just as easily using plain, concrete data types, and there’s even a few perks to doing it in this style.