I feel like I'm veering into off-topic for the original question. But my interest is piqued because for a few of our iOS apps we've really started to rely heavily on this framework for testing.
I'm not sure I know how to heed the warning because I'm not sure that I understand the warning.
... you can't not invoke at least some Apple code when you do this, because your initializer has to invoke a superclass initializer ...
Our goal is to not implement any Apple code. Our goal has been to basically "plaster over" all the Apple interfaces and effectively treat
URLSession as a protocol. I think in most cases we end up using, bordering on abusing, a combination of private underscored prefixed variables and
override to make it work. Can you expand on what I should be careful of?
I think we always new it would be brittle considering it is a library that is meant to provide "similar" behavior to a closed source library that we implement by "testing the fences" (Jurrasic Park Muldoon voice). That in and of itself does not really shock/scare me. It is as clunky as you imagine and I hate every minute I look at it. But the part that makes me stomach it is all the clunky is encapsulated in the single dependency that I don't have to repeat across projects. More over it is a single test dependency that does not ship in my production code.
URLSession implementing some protocol I'm not really sure what else to do. As an aside, if you know someone who could make that change to
One early iteration of this library we made a protocol in VHS and then made
URLSession conform to that. The problem is then the VHS library was a run-time dependency not a test-time dependency . We also prototyped the protocol in the application and then making VHS conform to the protocol . Admittedly, this was way less offensive because VHS could remain a test dependency. But now we had this protocol that lived in our application that was ostensibly only for testing. Either way it felt like we were violating separation of concerns. In the end I liked encapsulating the clunky in a dependency that I could eject in the future when a better solution arose.
I'd really love any feedback that could help me prevent long-term headache.