XPost: misc.phone.mobile.iphone   
   From: marianjones@helpfulpeople.com   
      
   Your Name wrote:   
   >>> Q: So why do you think every IPA is tied to your Apple ID on iOS?   
   >>> A: The embedded Apple ID prevents redistribution of the IPA!   
   >>>   
   >>> Notice everything is harder on iOS when you simply want to back up and   
   >>> re-use an IPA. No other operating system makes something this simple,   
   >>> that hard.   
   >>   
   >> You don't get how apps are installed on iOS. At all. LOL!   
   >>   
   >> ...   
   >   
   > I think you meant to type "You don't get anything at all", which be far   
   > more accurate for that braindead idiot   
      
   Hi Your Name,   
      
   Happy New Year!   
      
   I will ignore you calling me a brain-dead idiot" for simply explaining on   
   an Apple ng how iOS IPAs work, which, let's be clear, no other operating   
   system in history (not even macOS!) locks up an installer like iOS does!   
      
   Nor does any other operating system embed your identity into every app.   
      
   iOS has never treated an IPA as a portable installer. What Apple delivers   
   to your device is not the developer's signed package. Apple strips the   
   developer signature, re-signs the binary with an App Store distribution   
   certificate, encrypts the executable with FairPlay, and injects metadata   
   that ties the package to your Apple ID and to the class of device that   
   requested it.   
      
   When iTunes used to let us "save" IPAs, the file we saw on disk was not   
   a portable installer. It was a container holding an encrypted Mach-O   
   binary plus a receipt proving we were entitled to download that version.   
   The encryption keys needed to decrypt the executable were never inside   
   the IPA. They were delivered separately by Apple to a specific device at   
   install time. Without those keys, the binary inside the IPA is useless.   
      
   This is why an IPA copied from iTunes could not be installed on another   
   device unless that device was authorized by Apple for our Apple ID. The   
   kernel level subsystem AMFI (Apple Mobile File Integrity) refuses to run   
   any code that is not signed for that device. The FairPlay layer refuses   
   to decrypt the binary unless the device has the correct per-device keys.   
   Both checks must pass or the app will not launch.   
      
   During device migration, even in the old iTunes era, the IPA was not   
   transferred to the new phone. The new phone contacted Apple, presented   
   our Apple ID and the receipt from the IPA, and Apple issued a fresh   
   encrypted build targeted for the new hardware. That is why restoring an   
   older version only worked when Apple still allowed that version to be   
   reissued. The IPA on disk was never the thing being installed. It was   
   only proof of entitlement.   
      
   iCloud backup does not change any of this. Whether we use iTunes,   
   iCloud, or device-to-device transfer, the app binaries themselves are   
   never copied between devices. Only app data is transferred. The apps are   
   always re-downloaded from Apple and re-encrypted for the specific device   
   that requested them.   
      
   Bottom line: even when we could see the IPA file in iTunes, it was never   
   a portable artifact like an APK, EXE, DEB, or RPM. It was always tied to   
   our Apple ID, always required Apple's cryptographic authorization, and   
   could only be executed on devices Apple approved. The only thing that   
   changed is that Apple stopped showing us the IPA file. The underlying   
   security model has been the same since day one.   
      
   Nobody does this but Apple, and, even then, only with iOS (not macOS!).   
   Why do you think that is the case, Your Name?   
   --   
   The difference between intelligent people is that only the brightest can   
   see through the (rather brilliant) propaganda that Apple marketing spews.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)