Lack of knowledge of your dependency tree isn't really an excuse here. If you're submitting your application to an App Store -- where one of the express purposes is that customers know the application is safe -- then having an unknown dependency is not really a good argument.

How are you sure that your code gets compiled properly? Do you read the assembly generated for the processor and the source code for your compiler?

Are you sure that your machine code gets run properly? Do you test the CPU hardware and all the logical gates and whatnot so that they respond to the schemes and it passes the electric current properly?

Like xkcd 378, we could follow this logic quite deep. At some point you just have to trust, or at least assume that something is going to work, without properly verifying it yourself.

Smarter people than me have essentially dedicated their life to some extremely specific area of computing. It's not reasonable to assume that I could and should deep-dive into every possible nook and cranny just in order to build an application. I already have to do a whole lot of assumptions because of my hardware used for development, my OS and software tools like my IDE, task runners and yes, external libraries.

> It's not reasonable to assume that I could and should deep-dive into every possible nook and cranny just in order to build an application.

I don't think anyone is suggesting that you should.

Yeah... Everytime I try to use something like that and it wants to pull in 10 or 50 dependencies, it's a hard no. I would rather write something from scratch than use something and potentially debug through all those layers.

If it's in my product, I'm responsible for it, so it needs to be possible for me to audit it, even if I may not be looking too closely.