> He's right, but he's almost too right: absolutely everything he says is a problem with bitcode applies to normal app store distribution and all other centrali

> He's right, but he's almost too right: absolutely everything he says is a problem with bitcode applies to normal app store distribution and all other centralized cloud-powered OSes and apps. Therefore I don't see this as a good argument against bitcode -- not using bitcode does not prevent anything he says from occurring since anything that can be done to bitcode can be done to machine code. Not true. Not using bitcode allows you to select optimization options and have a "receipt" on what CPU:s your code will run, by providing those slices. Now, Apple can also (in theory at least) change endianness of the target code. Instead of users being unable to install the app (a bad idea), they will install an app that breaks (an even worse idea). Endianness is one example. Optimizations another. There can be more. Hiding even MORE stuff from a developer who in turn is responsible to a customer and to users can only raise the development cost (because maintenance contract is usually a part of development cost), not lower it. I do not need MORE hidden issues and LESS control over the work I put my face on.