> you are not yet familiar with the process of how this works

That is true, I'm not, certainly not with the details. I hire people to do audits and pen-testing for me. But in order to be able to distinguish people who are competent from snake-oil salesman, I have to have a pretty good grip on some fundamentals, and I believe I do. So even though I have not used a modern decompiler, I certainly know that they exist, I know the fundamentals of how they work, and I know their limitations. I know, for example, that information is lost in the process of going from source code to object code to decompiled code, so the process of auditing decompiled code is necessarily strictly more difficult than auditing source code. I also know that the relative sizes of the source, object, and decompiled code is more or less linear. (A few things deviate from this, like C++ templates and unrolled loops, but it's true to first order.) So using a linear approximation to get an estimate of the amount of work required to audit a binary blob is not entirely unreasonable, particularly since the only question I'm trying to answer is whether or not it is even plausible that iOS could be effectively audited by an unauthorized third party given its size. (Note that even if the answer to that turns out to be "yes", that still doesn't demonstrate that iOS actually is being effectively audited.)

So:

> It is not necessary to look at every byte.

I never said it was. Nonetheless, unless some auditing technique is effective enough to change the (first-order) linear relationship between source code, object code, and decompiled code, or effective enough to introduce a radical linear multiplier (i.e. eliminate 90% of the code from consideration) the fact that not every byte needs to be examined is irrelevant. My first-order estimate will still be good enough to provide a plausibly correct answer to the question I'm asking.

> In fact, for the most serious level of analysis, one should go directly for the binary, as who knows how the source code actually corresponds with what binary actually gets shipped.

Yes, exactly right. Nonetheless, this process is easier if you have the (purported) corresponding source. More information is always better.

There is one more important point that you seem to have missed (along with everyone else): there is a big difference between trying to find a vulnerability that is the result of an inadvertent bug, and one that has been introduced deliberately by a competent adversary. Finding the latter is vastly more difficult than the former. Decompilers operate on heuristics. Heuristics can be fooled. One of the things that a competent adversary would do if they were trying to hide a back door would be to put it in a form that causes it to be hidden by decompiler heuristics. So this entire discussion about reverse engineering techniques is actually totally moot. Writing a decompiler that did not have this problem would require solving the halting problem, so even though I don't know the details, I know they have this shortcoming. Not only that, but I know how I could identify the specifics of this shortcoming, and I know how I could write code to take advantage of this shortcoming to conceal a back door. And if I know these things, then there are certainly people at Apple who know these things.

This is the reason that I am quite confident in my position despite my ignorance of the details of modern reverse engineering techniques. The halting problem gives the advantage to the attacker, and no technological advance is going to change that. It's like a second law of thermodynamics for security. I don't need to know the details of contemporary technology to know that, all else being equal, the person trying to hide a back door in a 1.6GB binary is very likely to beat the person trying to find it. And the problem is not just technological. As I've pointed out elsewhere in this thread, even if someone does find it, that knowledge will be extremely valuable. It is far from clear that anyone who succeeds in finding a back door in iOS would use that knowledge for the public good, particularly when you consider the personality types and economic circumstances that lead people to pursue a career in reverse-engineering in the first place.

This situation is ridiculously complex, and that complexity extends far beyond the size of the iOS binary. Anyone who is quibbling over my 1-byte-per-second estimate, or my personal proficiency with radare, is missing the point rather badly.