Distributing Beta App to Remote Users
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.
- http://hockeyapp.net/features/
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.
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.
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