After reading numerous beta testing strategy guides for iOS I'm still confused about if it's permitted by Apple's Developer Program to distribute an app for external beta testing without getting it approved by them and using TestFlight. For example, is it allowed to create an AdHoc signed app and use a 3rd party tool (Crashlytics, HockeyApp, others) to beta distribute to external entities. External in this case meaning not within your organization. Within an organization, there are other means that can be used like Enterprise Distribution, which have no restrictions but are not allowed to be used externally. The question is: does Apple allow external beta testing for a non-Apple signed app? (non-Apple as opposed to TestFlight which would indeed sign it for external testing via iTunesConnect submission).
UPDATE: after looking into AdHoc and going to the Apple Developer page, it shows this (note the Pre-Release warning in that image) which seems to point to what I suspected - per Apple's rules, you cannot let external folks test your ad hoc app:
So if this is true, I don't see how there's any way around TestFlight for public external betas.
Yes, using Ad-Hoc distribution with external testers is perfectly fine and has been used like that by thousands of developers world wide for years.
Quoting Apple's App Distribution Guide:
Testers don’t need to be team members or iTunes Connect users to run the app, but their devices need to be registered in your developer account.
According to the current Apple Developer Program agreement (bolding of text is mine):
7.3 Distribution on Registered Devices (Ad Hoc Distribution)
Subject to the terms and conditions of this Agreement, You may also distribute Your Applications
for iOS, watchOS and tvOS to individuals within Your company, organization, educational
institution, group, or who are otherwise affiliated with You for use on a limited number of
Registered Devices (as specified on the Program web portal)
See also section 7.3 parts A and B where they clearly allow external testing via TestFlight. Based on that it seems to comfirm that external testing is only allowed via TestFlight. Internal testing can use TestFlight, Enterprise Program-signed apps or Ad Hoc.
HockeyApp do support app distribution by using an Ad Hoc profile.
You need to buy an apple dev program, then you need to create the profiles and use the profile in your projects, then you need to create a new app in your dashboard on HockeyApp(https://rink.hockeyapp.net/manage/dashboard) and integrate our SDK in your build, you could integrate the SDK by following steps in this KB:
https://support.hockeyapp.net/kb/client-integration-ios-mac-os-x-tvos/hockeyapp-for-ios
After these you need to upload the build, profile, symbols to HockeyApp.
We recommend use our interactive SDK integration wizard in HockeyApp for Mac(https://www.hockeyapp.net/releases/mac) which covers the steps of integration SDK and upload files to HockeyApp.
For more information about distribution please see here:
https://support.hockeyapp.net/kb/app-management-2/how-to-organize-development-and-production-apps-for-distribution#hockeyapp-offers-four-pre-defined-release-types
Related
I just received an email this morning that testflightapp.com will no longer be active as of 2/26/2015, and that I should be using the iTunes Connect TestFlight service instead. This is fine and dandy for app store apps, but most of my projects are enterprise apps, and that is not supported in iTunes Connect. On top of that, iTunes Connect TestFlight requires iOS 8, and a good chunk of Enterprise users are still on iOS 7.
Does anyone have a solution outside of TestFlight for deploying Enterprise iOS apps to a set of registered users? I am hoping there is an easier solution than setting up my own MDM, but at this point I think that may be the only option.
Tesflight is not available for iOS Enterprise development. See "If you’re distributing your app outside the store, you follow a slightly different process. You don’t have access to iTunes Connect and some app services so can skip those steps." at https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html
Also see Apple discussion at https://forums.developer.apple.com/thread/9229 where it says "Enterprise apps can be tested internally using Ad-hoc distribution" if one wants to only have the app available to registered test devices.
From Apple's beta testing site:
Internal Testers
Get feedback quickly by sharing your beta builds with up to 25 members of your team who have been assigned the Technical or Admin role in iTunes Connect. Each member can test on up to 10 devices.
External Testers
Once you’re ready, you can invite up to 1,000 users who are not part of your development organization to beta test an app that you intend for public release on the App Store. Apps made available to external testers require a Beta App Review and must comply with the full App Store Review Guidelines before testing can begin. A review is required for new versions of your app that contain significant changes. Up to 10 apps can be tested at a time, internally or externally.
Only external testers are subject to the app store review and guidelines.
TestFlight Beta Testing
You can use the "download over the air" functionality that TestFlight uses. Apps like BetaBuilder (http://www.hanchorllc.com/betabuilder-for-ios/) will generate the HTML and manifest file for you, you just then need to upload it to some web space of your choosing and then provide a URL to your clients. There is a requirement of the app being hosted on HTTPS now.
I'm in the same situation as you. Multiple apps that need to be distributed with the enterprise cert so that QA and the like can access them.
Guess might have to update/check hockeyapp to see if it works fine with IPA's. We use that for our Android apps and it works well, so, ...
TestFlight was very convenient. OTA isn't hard, but access (i.e. internet access vs. intranet access) is what we need and getting another service ok'ed might be a fun thing.
It will be interesting to see the different answers here.
My company has developed an iOS application for an external client. They have done some initial testing with us distributing the app via our testflight account. They now want to test it on a wider audience. They have decided to use their own TestFlight account and handle all the logistics of giving iPads to users and managing the distribution/testing of our app.
Is it possible for me to give them my .ipa file that they can in turn sign with an Ad Hoc apple certificate they create/mange then use their testflight account to distribute.
In short my company does not want to give away our source code nor burden the client with installing/learning xcode just to compile the app with their certs over ours. They are not developers but feel comfortable using an apple developer account and testflight. They would prefer not to set up and use xcode.
Thanks!
I'm developping an App in my company. We want to distribute this App to our customers but without using the AppStore from Apple, is it possible?
I heard about MDM (mobile device manager) but I'm not really sure if it will cover this need?
I heard also about Enterprise developer license for in house deployment but if I'm understanding correctly it means the App can be deployed only inside my company and not to our customers, is it correct?
Thanks for your clarifications.
Seb
If you are trying to get apps to customers without the App Store, you have options, but none of them are awesome.
There are many choices for over the air distribution of the binary, that really isn't the complicated part. You've got MDM solutions, HockeyKit, TestFlight, Manual server manipulation - all are fairly easy and well documented.
Where things get nasty is in the signing. If you definitely do not want to participate in the App Store environment (no app store, no Volume Purchase Program), you only have two real options:
Ad Hoc - Limited to 100 Devices. Devices must be explicitly added to a provision.
Enterprise - No device limit, devices do not need to explicitly added to provisions. In effect, these builds will run on any device; the caveat, you are not legally allowed to distribute these builds to anyone outside your company.
If you intend on developing an application for some other company and their employees, then your only viable option is to sign the final build with a signing certificate attached to said company's development account. The enterprise signing route is a really great approach, if you can get the company to sign all the paperwork to get their own developer account, owned by them.
For stock iOS devices, you really have only 4 choices:
1) Ad Hoc distribution to up to 100 total max devices per iOS Developer enrollment (including wireless Ad Hoc via manifest file & SSL.)
2) Enterprise distribution for distribution to employees of corporations with a D&B rating.
3) Apple's iTunes App store if your app is approved by Apple. (This includes the B2B program and account/password protected apps.) (This now also includes up to 1000 people using Apple's new Testflight service.)
4) Unlimited distribution to other people who have their own individual, company or enterprise iOS/Apple Developer enrollments. The distribution can be either as an Xcode project with source code or a pre-compiled library, or as an ipa or archive file that the customer can (re)codesign with their own Developer certificates. For applications priced at well over $99 per customer, the cost of this annual developer program enrollment might only be a slight additional cost to the customer (and given appropriate legal authorizations, might even be handled as an annual paid service.)
4 b.) ADDED UPDATE: As of Apple's release of Xcode 7 (in late 2015), anyone with just a free Apple ID can use Xcode 7 on their Mac to install apps from build-able Xcode projects directly to their own tethered iOS devices this way, with no need to pay $99 to Apple to enroll. See this answer.
This essentially allows unlimited distribution to anyone with physical access to a current Mac and who knows how to run Xcode.
Options (1), (2) and (4) do not require going through App store approval. There are no other options for distributing apps to stock OS iOS devices.
You could take a look at https://testflightapp.com/.
We use that a lot for customers that only need a app for testing doing the development phase and for apps that are used for conventions (limited time, limited number of units).
Testflight is very easy to use for both developers and end-users, but it is not very well suited for apps that are going to be used on a large numbers of devices, since all devices that are installed to needs to be in your provisioning profile which has a limited number of slots.
EDIT
The testfligt approch is no longer valid. You can now use the TestFlight integrated into itunesconnect. Alternatively you could integrate crashlytics.com, at use their distribution system. It works pretty weill
I have created an application for a company that I need to deploy. The application is for internal use only so it will not be available on the App Store. Do I need a UDID for each individual on whose device the app will be installed? That would be impossible since there are 500 employees. Does anyone have a good documentation or experience on deploying the iOS iPhone application using the Enterprise Developer Program only.
With the Apple ENTERPRISE Developer Program you can NOT distribute an App in the Apple AppStore.
Its purpose is to collaborate an In-House App in your own company.
The Enterprise account does not necessarily need the UDID of your target devices. You can for instance also use a link which remotely installs the app directly on the device.
You can find more details here: https://developer.apple.com/programs/enterprise/
If you are trying to deploy applications to customers/users on a production/long term basis, you can deploy an applications outside the apple store in three ways:
manually via iTunes
directly via iTunes Configuration utility
via weblink (sent via mms, email, webbrowser etc.)
In order to distribute an application this way, the application must have a special corporate signature, and each device must have a matching corporate signature installed manually.
The best overall explanation for the process is available at this link.
If you're just testing on a handful of test devices, then you I would suggest two approaches:
a dev release to a test device follow step by step instructions here.
Or you can use a helper application to deploy a beta release: testflightapp.
You can do distribute your iOS app to only a particular set of people (in your case, your company employee), by following these procedure
Get a apple enterprise developer account
Create a distribution certificate and provisioning profile
(In-House) using your enterprise developer account
Archive the ipa file using the created certificate and
provisioning profile
While saving the ipa, click on the check mark. So, the plist file
is also created.
Host the plist and ipa file in your server
Include a download html file with a href tag with src
"itms-services://?action=download-manifest&url=https://mydomain.com/apps/MyInHouseApp.plist"
Now when you click on the link from your device the app will get downloaded.
I don't agree with the previous answer. Check this document page 26.
MDM servers can deploy both App Store apps and in-house enterprise
apps to devices over the air. Both paid and free App Store apps can
be managed by an MDM server using Volume Purchase Program (VPP)
managed distribution.
Once you have VPP and Enterprise Developer account you could be able to install apps in the app store or company owned apps into the managed devices.
Further for just deploying the in-house app you could follow this 9 step process.
If you need to deploy to many devices i suggest AirWatch. I've used it many times, it can be a bit frustrating to set up but once you have it working its very nice to have.
Testflight still requires udid and the limit is 100 for 1 year before you can reset. Enterprise deployment is best method for in house apps.
TestFlight offers over-the-air beta distribution of iOS apps (on non-jailbroken devices). How can this be done? Is this an iOS feature, or a vulnerability exploit?
This article showed how Apples OTA implementation works and can be used outside enterprises as well: ios wireless app distribution
The complete process is documented by Apple.
Apple also published documentation and sample code for registering devices and get the UDID by using profiles, so your website can detect which device is calling.
Some additional solutions with different strenghts:
iOS Beta Builder, a Mac Application to create the website by using a build. Simply upload the resulting files to your webserver.
Diawi: Simple Web service. Upload your IPA file, optionally set a password and send a link to your testers.
AppSendr: Web service for beta build hosting, similar to Testflight, but does not include the device registration process. But provides deployment utilities to automatically upload new versions.
HockeyKit: Open source project for hosting beta versions on your own PHP5 server with additional functionalities like an client for In-App-Updates, automatic device specific web sites and handling multiple applications. Completely file and directory based.
HockeyApp: Web Service for beta build hosting, In-App-Updates, Statistics, and including device registration, invite and recruitment. Also provides server side crash report collection, symbolication (for all threads) and crash grouping for beta and app store apps (iOS + Mac). SDKs are open source, using HockeyKit, QuincyKit and PLCrashReporter (which is the only safe solution on how to do crash report collection on iOS, see this article.
Note: I am the main developer of HockeyKit and QuincyKit, and one of the developers of HockeyApp.
This was possible before TestFlight rolled out a service. The technique stemmed out of the enterprise distribution mechanism. Since 4.0 devices have supported install from web.
Remember - you still need to sign the beta distribution for a select set of UDIDs you can't just willy nilly install it on any device. All they are doing is taking the email the IPA step out of things.
See:
http://www.alexcurylo.com/blog/2010/08/27/wireless-ad-hoc-distribution/
Update: I want to say that Test Flight is one of the most helpful tools I've used when developing though. Just taking the IPA emailing out of the picture was an understatement- I was just trying to call out the technical mechanism. They do a fantastic job managing the whole beta process. Getting new devices enrolled. Notifying users etc.
Testflight basically uses the normal Ad Hoc as already stated.
For this to work, you need the UDID for every device in order to add it to the Ad Hoc profile, re-compile the app with the new profile an redistribute the new build.
You can get the UDID with the help of the OTA Authentication Request. This is actually a step that is done in MDM before the actual profile is rolled out to the device. It basically asks the device for further information about itself and send it back to a self specified server.
The first step is documented here: Apple OTA Configuration
I guess Testflight uses this right after the registration process to collect the UDID, phone name, ...
Yes this is a core feature of iOS for Enterprise Customers who wish to distribute OTA.
Presumably you would pass your UDID over to TestFlight along with the app and they use their Enterprise Licence to send the app to you. I'm sure I'm missing a lot of the technical details but if you want to know more, Apple has a video on this from WWDC 2010.
Login to developer.apple.com, go to WWDC 2010 Videos and use the link to get to the vidoes. The video you want is "Session 108 - Managing Mobile Devices". It is very informative about what is possible with OTA and the steps you have to take to do OTA provisioning.
Stock iOS devices are "vulnerable" to running the user loading Ad Hoc apps from any developer who has that device's UDID, and registers that UDID among their 100 allowed devices on Apple's developer portal.
OTA distribution is just another way to install an Ad Hoc beta test distribution from an enrolled developer.