8

It seems like there is no simple solution to providing my beta iOS app to people outside of physical contact. The ways that I have found to do this WITHOUT using the App Store (which Apple explicitly says is not for Beta testing) are:

  1. Use Developer Enterprise Program; Expensive and Excessive

  2. Use TestFlight; Only up to a measly 25 "Internal" Testers allowed before extreme Guidelines put in place for more people (Why not just put it on App Store at this point...?)

  3. Give them my whole Xcode project and have the user build it in their own Xcode environment; Impossible to ask of non-tech-savvy people + I do not want to give my project to people outside my company

  4. Ad-Hoc Development; Make everyone give me their UDIDs...Huge hassle for others/ People might not want to do it outside my company

The app I am developing is going to be used by people in the scientific community to control a specific device that my company is making. There's a chance that it might never be up to Apple's standards for apps on the App Store, but could be used by more than 100 people in the near-distant future. I guess the real question I am asking is: How do I get my "sub-par" beta app to a large group of people?

2
+100

In the past you would have to choose between Hockey app and TestFlight for large beta groups - but now that Apple has purchased TestFlight and you need to go through review to get a beta out, Hockey app's beta testing framework is the best suited to your needs listed.

It helps handle the user enrollment and management of getting builds notified and served up to end users. You still are on the hook for managing your pool of test AppleID, but now that the 100 device limit has been loosened, you can do pretty broad beta testing using Hockey and Apple's normal paid developer account limits.

Long term, you will want to get the app into one of Apple's stores since "abusing" the enterprise distribution signing is both costly in time and money to set up and over time, it's not that hard to get an app through review. Yes, you might get delayed a month or two or more, but if you persist, it's a rare app that can't deploy unless you are breaking one of the rules that Apple cares greatly about like including frameworks that use private API or that run code they download after the app has been signed and submitted for approval.

Your only other option is to ship the source code to each user and have them use Xcode to build, self sign and then install their own app. That might fly for motivated users of a specialty app. GitHub or other source tools would help you push out updates, but you'd be supporting people and possibly charge for that instead of the app itself under that model.

  • So there's no way to distribute my app without previously obtaining the UDID's of every person I want to give it to? Ugh, blows my mind that I cannot just email the .ipa file to anyone and have them drop it into their own itunes – Jel Dec 30 '15 at 2:39
  • @jel - nope. You can use AppleID via TestFlight or a service that harvests the UDID for you. This is by design - iOS doesn't want to side load apps. Since June 29, 2007 that's been the standard and I don't see it changing anytime soon. Especially since iOS 9 and Xcode allow anyone to self sign "their own" apps. – bmike Dec 30 '15 at 2:43
2

You could use TestFlight for external beta testers. This will allow you to test with up to 2,500 external testers. You do not need to know their UDIDs, only their email addresses.

However, I assume you think your app won't be able to pass even the less restrictive beta app review.

In that case, you could distribute your app in a "half-baked" form. Instead of giving out the Xcode-project including sources, which you state you do not want, you could distribute your app as compiled, but not yet signed, binaries.

In order to make it easy for your customers, you would have to build or get built a simple tool that the user can run that codesigns the binaries with the user's AppleID. They wouldn't need to be registered Apple Developers.

The tool would need to alter the bundle name in Info.plist and use the "codesign" tool to sign the app:

To make the bundle name unique, just add any random identifiers to the bundle name in the plist file.

The codesign tool can be used with a command like this:

codesign --force --sign "my identity"  <path for .app file>

where "my identity" is the identity (apple-id) of the end-user.

  • You might want to mention that Apple recently asked the creators of F.lux to stop doing exactly that practice. – GhostLyrics Dec 26 '15 at 12:10
  • 2
    Yes, that's right - but the difference as I see it between this and F.lux is mainly that the F.lux group were registered Apple Developers. They were violating an agreement they had with Apple - and to ensure that their potential other apps or Mac programs wouldn't be banned, they chose to stop recommending sideloading the iOS app. In addition the F.lux app had a huge number of potential users. This sounds like specialized research equipment that might be used by a few hundred users at most. In that case, Apple probably won't show an interest in it. – jksoegaard Dec 26 '15 at 12:15
  • 1
    Well, the first two paragraphs were there to make sure you knew about the less strict rules regarding the beta app review, compared to the ordinary app review process. About the tool, I don't see why you think it is terribly complicated. It is a matter of running existing command line tools that Apple supplies. I.e. sticking an easy-to-use GUI on top of existing tools. I cannot see how that is unhelpful. – jksoegaard Dec 28 '15 at 14:18
  • I have added specifics on how to run the codesign command, etc. You can also refer to Apple's documentation: developer.apple.com/library/mac/documentation/Security/… – jksoegaard Dec 28 '15 at 14:24
1

Fabric.io is really great.

You can send an invitation by email and you will receive the correspondant UDID by email.

And the really good point of Fabric is the Crashlytics and Analytics features.

The Fabric platform is made of four modular kits that address some of the most common and pervasive challenges that all app developers face: stability, distribution, revenue and identity. It combines the services of Crashlytics, MoPub, Answers, Twitter and others to help you build more stable apps, generate revenue through the world’s largest mobile ad exchange and enable you to tap into Twitter’s sign-in systems and rich streams of real-time content for greater distribution and simpler identity. And Fabric was built with ease of use in mind. Installation takes just minutes, and most features only require a few lines of code – so you spend less time managing SDKs and more time building the best experience for your users.

http://frabric.io

0

Diawi is a great platform for what you are looking to do.

Essentially you upload your app to this platform and you get a short link you can send to your testers. When they open the link on their iOS device they are prompted to install the app.

As detailed on their website, the catch is you have to add each user's device to the provisioning profile used to install the application.

This is probably as easy as it gets for the users, without distributing via TestFlight.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .