0

My question is different than other similar questions because the similar ones were asked during a time that the Apple Developer Portal was down due to hacking.

Is there a way to automate the addition of new UDIDs to a provisioning profile?

I work for a company with a beta app that has a slow-rollout of a 20 thousand user private beta for existing customers. In other words, I don't want to manually add 20K UDIDs with the ADP over the next 6 months. Keep in mind, I need to ask a user for their email address, send them an email in a beta manager, get them to open an email to click a link so I can get their UDID, then I need to manually open the ADP to add it. All of this needs to be done before I update my profile in Xcode, then archive a build to deploy to them. In the interest of sanity and using time efficiently to fix bugs that beta users report, this whole process seems insane. We've already added 50 this way and it's driving me nuts.

I thought that Fabric Beta might handle this nicely for me, but it doesn't.

Is there a command line interface for adding UDIDs? Or, is there a way to invite users via email, and if they open the email on their device, they can install our beta app without me needing to add their UDIDs manually in the ADP first? Does upgrading to an Apple Enterprise account fix this?

So far, I'm hitting dead ends everywhere. I read that Fastlane might handle it, but I haven't found any legitimate reviews from developers confirming this. Please Stack Overflow... work your wonderful magic.

jungledev
  • 4,195
  • 1
  • 37
  • 52
  • Read your developer contract with Apple. Private beta to 20,000 customers is most definitely not something you should do if you want to keep your developer license. – gnasher729 Jul 15 '16 at 22:25
  • 1
    If you have a standard developer membership you can only add 100 UUIDs per year and only have 100 UUIDs active at any time. If you use an enterprise developer account then you don't need to add any UUIDs. You can just distribute the app directly – Paulw11 Jul 15 '16 at 22:51
  • You are looking for something like TestFlight, which allows you to do public betas. The problem is that I believe TestFlight is limited to 2,000 beta testers. For the scale you are trying to do, I think you're going to have to build a login page where you will have to maintain a datebase of your 20,000 emails. and verify the user is part of the beta when the first launch the app. Shouldn't be too hard to do, but not something iTunes Connect was meant to handle. – wottle Jul 16 '16 at 13:19
  • @gnasher729 this is a legitimate scenario. It's a production app, with over 300k users, and our new version with new components that work with the app will be slowly released to a limited group of existing customers. We need to do this while we ramp up manufacturing of our components so we can improve the user experience before we make our components available for all 300k+ users to purchase. This is NOT in violation of a dev license. – jungledev Jul 18 '16 at 20:03
  • @wottle your suggestion clearly won't work for me. There is no point to creating a login per your suggestion. – jungledev Jul 19 '16 at 21:14
  • @Paulw11 or gnasher, do you know if I can distribute the app with the enterprise dev account to devices that my company doesn't own? It's really hard to find an answer for this in the docs. Have either of you used the Apple B2B App Store which allows you to release apps privately? Which one should I use? – jungledev Jul 19 '16 at 21:17
  • 1
    Ask understand it, the terms of the enterprise program are meant to be for company devices, but many organisations use BYOD, so it is possible that the company wouldn't own all of the devices they want to distribute to. There is no enforcement of device ownership; you can install,on any device that has access to the installation URL. B2B is used when the person/company developing the app is different to he customer company. It could work for you too, but typically require that the target devices are managed by an MDM to distribute the app – Paulw11 Jul 19 '16 at 21:20
  • Yes, you can distribute the app to devices your company doesn't own. I would not charge for the use of the app, because in essence you would creating a paid app store to compete with Apple's and they certainly would not like that. – wottle Jul 19 '16 at 21:35
  • Also keep in mind the maintenance of an enterprise distribution profile app. The profile will expire after a year, so I would build in a way for the app to check for updates and download new versions along with the new provisioning profile automatically as needed. It's a pain to force 300,000 users to all go to a web site to download a new version of the app when the current one crashes unexpectedly on launch (when the profile does expire, the app will simply crash on launch) – wottle Jul 19 '16 at 21:36
  • Also,@jungledev, I don't think you understood my suggestion. Why not control the beta users within the app through an invite system. **Many** other app developer have rolled out an invite only beta this way with much success. And it would avoid the headaches of having a provisioning profile that will expire within a year. If it won't work for you, please specify why, as it is not clear to me. – wottle Jul 19 '16 at 21:38
  • @wottle because it's not in the app store and we don't want to put this version in the app store. We push updates to it daily, and don't want to deal with the app store guidelines *yet* while needing to do updates. It will be in the App store before CES 2017. It's a hugely profitable company- the provisioning profile expiration and need to renew is trivial. – jungledev Jul 20 '16 at 18:30
  • Ok, those details would have been helpful in the original question. So it seems like your answer will be the enterprise provisioning profile. If you work for a company, it should be trivial to apply for and get the enterprise account in addition to the regular development account. – wottle Jul 20 '16 at 22:51

2 Answers2

2

The way to run an app on an iOS device without individually registering the device ID into a profile (which wouldn't work for you anyway, since there is a 100 device limit per account) is to use an Enterprise Distribution profile. With an app signed with an enterprise profile, it can run on any device.

The users will need to "trust" the signing identity, which involves going into settings. That trusting of the signing identity is a one time thing, however. This can be something you can include in the instructions to your beta testers.

In order to create an enterprise profile, you will need to sign up for an additional enterprise developer account here. It is $299 per year in addition to your regular developer account. Once you have this, you will create a new enterprise distribution profile and use that in your build settings to build / sign the app.

Note that the enterprise profile expires a year from when you generate it, just like a developer profile. The cert should last 3 years. If you plan to have users continue using the app over the time when the profile expires, it is best to build in a simple update check into the app that will prompt the users to update the app a month or so before the expiration. Once the profile expires, just like a standard dev profile, the app will simply crash on the users device with no explanation of why.

wottle
  • 13,095
  • 4
  • 27
  • 68
  • I don't think the enterprise account is the solution because we don't own the devices and the users will not be only employees of the company. Even if Apple doesn't really investigate enterprise use/abuse, our company is too big to accept the risk of getting caught doing that. It looks like our only two options are to launch it with TestFlight, accepting the 2000 user limit and the 60-days-per-build test duration limits, or just simply launch it as a new app in the app store, and only allow logins for users that are included in the beta. – jungledev Jul 29 '16 at 18:40
  • 1
    Yes, if they are outside the organization, you would run the risk of Apple blocking it. Although, for testing, I think it would potentially fit into the intended use, as long as you are not trying to actually release the software. As for launching in the app store, here's an article by a kickstarter campaign where they worked around the issue by releasing to the store and requiring a login for uesrs to get to the full functionality: http://www.sixtostart.com/onetoread/2012/distributing-3000-copies-of-an-ios-game/ I believe the Mailbox app did something similar. – wottle Jul 29 '16 at 19:48
0

I finally figured it out.

Based on this question, and too much wasted time trying other solutions beforehand, I've decided the only reasonable way to accomplish this without violating Apple's terms of service (which you would be doing if you distribute apps to non-team members via the Enterprise developer portal) is to use TestFlight, create multiple apps in TestFlight (each of which need to have separate app names + bundleIds) of the same app and run multiple External beta sessions simultaneously. If you automate this with Fastlane, you can change the app name + bundleId for each version all at once, and upload them all to TestFlight all at once, to prevent one from going insane by needing to do the same thing many times over.

Each time you have fixes in a new build that you want to update the beta with, just set up Fastlane to automate bumping the build number and deploy it to TestFlight- then this will effectively reset your 60 day beta session.

Community
  • 1
  • 1
jungledev
  • 4,195
  • 1
  • 37
  • 52