Hello.
I am confused about bitcode. I think Code Signing guarantees the executable binary *is not changed* from developer's build. And this will be contract between users and developer. But bitcode says 'Apple produces optimized binary automatically.', it seems to be contradiction.
In bitcode context, what dose 'signing' actually means?
When you sign a binary it guarantees the binary has not been changed when it arrives at apple. The resign it before dowload onto a device with their own certificate.
Dirk
That's a very good question. Signing implies that the code that was generated by your build on your development machine is intact by the time it reaches Apple. But it seems to me that with bitcode Apple now reserves the right to re-generate machine instructions from your bitcode that vary by target device. In other words, Apple is the ultimate compiler. It raises a lot of technical and ethical questions, since it leaves the ultimate performance and other nuances of your code to Apple and out of your control.
Apple should really clarify this for all of us.
I think Code Signing guarantees the executable binary *is not changed* from developer's build.
Correct.
And this will be contract between users and developer.
Incorrect. The signature that you place on your binary tells Apple that the binary came from you and hasn't been modified. The end-user (i.e. the customer downloading your app from the store) downloads an Apple-signed copy of the app; your signature never makes it to the end user (and never has; this is not new behavior). The App Store has never provided developer-signed apps.
In bitcode context, what dose 'signing' actually means?
It means the same thing that it has always meant. A binary that is signed can be shown mathematically to have come from someone with access to the private key that it was signed with.
But please explain why bitcode is necessary for app thinning. The only advantage I can see is to permit legacy apps to be ported to new device architectures without intervention by the developer, avoiding rebuilding and resubmission to the App Store, and it presupposes that Apple can optimize an app better than developers can.
Why not let developers have the choice whether or not to submit bitcode and let us make the decision whether to build for target architectures directly without requiring the middleman recompilations? Right now, it is impossible to create a phone app that includes a watchkit extension to be built without bitcode. Is that intentional?
OK, I understand standpoint of Apple.
But it sounds bit strange and delicate.
If Apple can recompile our binary, it means Apple can inject some unknown code into it. *We* cannot guarantee our executable as it is. This is why I said siging will be contract between users and developer. If Apple's codesigning dose not guarantees it, there must be some other way to do it, I think.
Signing has never been a contract between user and developer. It has always been between developer and Apple. Apple has always re-signed apps before they're deployed. That's why they don't expire on users' devices when the developer membership expires.
I agree. It kind of betrays the contract that what you are delivering is what you have tested and confirmed and implies that Apple has overlord-ship of what is ultimately delivered to the end user.
Actually, no. You have every opportunity to download and test (using TestFlight) whatever Apple ultimately provides in the App Store, just as its always been.
I don't agree with that. If that's true, you can only do end-user testing with bitcode generated binaries. Unless you can do performance/instrumented testing with generated code, that's insufficient. There are many use-case scenarios where that would be inadequate.
What would be needed to be provided to developers is a bitcode translator that is identical to the App Store's.