Why would you need to patch the binary? If you're pushing out an update to fix the issue, the update may as well push out a rebuilt app than a binary diff.
I had been involved in a really hairy service interruption that involved hardcoded urls into an sdk (http://a.com/b.js), and a.com was remapped to a brand new web service / target which no longer had the file.
As if it's not enough, the server returned 301 permanent redirect with 60 day ttl to http://c.com. Our traffic dropped 40% because of that mistake (not 100 because in previous couple releases i have changed that url to be something that's widely used and had no risk of getting messed up, but old clients still had the urls embedded).
As if that is not enough, the IOS library for some reason had implemented "hand rolled "caching with a lot of hardcoding.
To fix the issue... i made c.com homepage also serve b.js at the bottom.
There is no way in hell this would be committed and tested within qa timelines of either a.com set up or c.com setup.
It's rather complex to fully explain without giving more context on what it is but when traffic drops 40% and you are generating 5M$/day.... You do whatever to bring it back.
I might have misunderstood your previous comment. You were saying that for this specific incident with Apple they wouldn't need to do binary patching, right?
