3 Replies
      Latest reply: Jan 3, 2018 7:30 AM by hrdm33 RSS
      hrdm33 Level 1 Level 1 (0 points)

        We have an app that will ultimately deploy the app store build via MDM. We're currently not in the app store but are in Testflight and would like to deploy via MDM.

         

        Is that possible?

         

        How does Testflight restrict what users can run the app?

        • Re: Is it possible to deploy a Testflight build via MDM?
          hrdm33 Level 1 Level 1 (0 points)

          Our app is intended for enterprises but not our enterprise. SInce its not intended for users within our company, it doesn't qualify for "enterprise distribution". We're planning to generate an IPA for app store distribution but distribute it via MDM at customer sites so that a config file can be included that is unique for each customer.

          We don't have the app in the appstore yet and are using Testflight for testing. It would be nice to be able to distribute an ipa via MDM so that it can include the config file. Can't be adhoc because we have too many devices. Can't be enterprise because the app is not ultimately intended for our company's use. We're using Testflight now for testing but the config file can't be deployed.

          So... the question is, can a Testflight ipa be deployed via MDM with a config file. How does it associate the user and ipa to know who is allowed to run the app. Is is something in the ipa itself, such as a provisioning profile, or is there some other wrapper. What is the internal mechanism Apple is using to restrict who can run the app? Can anyone run the app if they have a redemption code? Can a redemption code be used to get an IPA that can be run anywhere? Curious how the mechanics work.

            • Re: Is it possible to deploy a Testflight build via MDM?
              NotMyName Level 4 Level 4 (865 points)

              "It's intended for enterprise distrubution on someone else's enterprise account."

              Once upon a time, you could tell Xcode to not sign the executable, and then have the a second party sign the executable using their own signature.  You should investigate if that's still true, instead of the horrible kludge you're describing.

               

              Failing that, signing the appropriate contracts with the client enterprise so you can just build and sign the app for them would be the next logical step to try.