And yet we all do it because it also has its benefits. 🤦🏻♂️😂
That article is a realistic and practical look how the dependencies affect your app in terms of app launch times, app size, and build times. It compares Swift Package Manager 🤓, Carthage 🤷🏻♂️, CocoaPods 😬, manual dependency management 🥺, and Git Submodules 🤮.
I still have a dream of zero dependencies 🤩, but I know it’s not realistic in a complex app. 😑
Error handling makes everything more complicated. Ugh! What do you do if a network call times out (pretty common)? Or you’re trying to save an image and there is no disk space (less common but can happen)? Or that thing that’s never supposed to happen happens (occasionally happens)?
I mean, you have to do something, right? Ugh. 🤦🏻♂️
Here are some tips. Thanks to Swift By Sundell for giving this topic some attention.
Feature flags are a great way to selectively introduce new features. it allows you to experiment and commit incrementally.
The only down-side to feature flags all the extra code, and in particular going back later together rid of all the crusty flag code flagging you feature on or off. This kind of tech debt can really pile up over time.
Apparently Uber uses feature flags in the thousands and without remorse. So they came up with this automatic way to wipe out your stale, disabled code. Perfect name, too!
Most of us developers know can we can should abstract the network layer to support mocking, unit testing, and just to produce a more flexible design.
While lots of us know this, in practice it seems to get overly complicated and not always done well. A good design should simplify things, not complicate things. This is why I like this post focusing on using protocols to simplify network requests and improve testability. It even gets into decoding responses to give you a useful end-to-end flow.