> It massively expands the attack surface, since Apple is running untrusted IR input through LLVM, server-side.
Apple already runs your binary through a bunch of binary analysis tools, I'm not sure why LLVM is significantly different. A remote exploit is a remote exploit, and LLVM doesn't need escalated permissions to compile things. Besides, it's probably safe to assume Apple sandboxes all of this stuff.
> Apple's shipping a binary that the developer can't trivially verify by comparing against their local build
Who actually does that? I've never heard of anyone even trying to do this before. Besides, if you are that concerned about Apple tampering with your binary, it's a very small step to believing that Apple would still serve you the original binary and only send the tampered version to a limited audience, thus making any such verification meaningless.
You don't know how large the existing attack surface is. I suspect that it's already large enough that adding LLVM to the mix isn't terribly meaningful. Especially once you assume that all this stuff is sandboxed anyway.
> Anyone that debugs an issue in their shipped code.
You're going to have to do better than that. Speaking as someone who's been developing iOS apps since the moment the app store opened, and who knows a lot of other iOS developers, I've never heard of anyone downloading an un-DRM'd version of their app store app for debugging purposes. The closest I've come to that is verifying what entitlements file the App Store version was built with (but this was done with iTunes Connect, not actually downloading the ipa).
The only benefit that you can get from downloading the binary is inspecting the assembly, which itself is only useful if you're hitting an optimizer bug, but even then, you'd actually want to work with a non-app-store build because you can't debug app store builds. So you won't actually be downloading the app store binary anyway, you'd just use the existing archive you uploaded to begin with, or even build a new one from the source.
Which means that, given all that, the only case here where you'd have a legitimate reason to want to download the app store version is if Apple manages to introduce an optimizer bug when recompiling your bitcode that you can't reproduce yourself. Not only is this likely to be extremely rare to get such a bug, you should still be able to reproduce it yourself if it happens because any new optimizations should be made available in the latest Xcode.
> Anyone doing security research.
Irrelevant to the topic. The case here was a developer verifying their own product. Bitcode changes absolutely nothing with regards to people downloading other developers' apps.
> I've never heard of anyone downloading an un-DRM'd version of their app store app for debugging purposes.
That is because it has never been necessary before, because up until now you have always had a binary copy in Xcode -> Organizer -> Archives. Please think.
Also note that I am refraining from judging you or anyone you know on the telling account that neither you nor anyone you know have, for years, had the need to understand your binaries.
If your binary has a chance of functioning differently on someone else's device than on your testing devices, then you should care. But then again, your business may not depend on having an app that works, but on producing a lot of apps.
If you are religious in trusting Apple's decisions despite all your years as an Apple developer, then you should at least acknowledge that some developers and their companies may have different (less faith-based) values than yourself.
You've crossed the line from making wild unsubstantiated claims to being rather offensive (and, it appears, deliberately so). This is quite unacceptable.
Apple already runs your binary through a bunch of binary analysis tools, I'm not sure why LLVM is significantly different. A remote exploit is a remote exploit, and LLVM doesn't need escalated permissions to compile things. Besides, it's probably safe to assume Apple sandboxes all of this stuff.
> Apple's shipping a binary that the developer can't trivially verify by comparing against their local build
Who actually does that? I've never heard of anyone even trying to do this before. Besides, if you are that concerned about Apple tampering with your binary, it's a very small step to believing that Apple would still serve you the original binary and only send the tampered version to a limited audience, thus making any such verification meaningless.