The different ways to get an application installed on an iOS device.
iOS devices enforce code signing of all executable code run on the device. If the code in question is not signed by Apple's certificates then the OS will refuse to run the code. However, developers needs ways to run their code on real devices, without submitting to the AppStore each time. So there are a number of ways to get applications installed on iOS devices.
A developer can plug their personal devices into the mac running Xcode and build and run the code directly onto the device.
This requires that the developer first take the devices UDID (unique device ID) and register that device ID with Apples servers as being a development device. Apple's developer website then allows you to download a provisioning profile which you can use to sign and run any code on that particular device. These profiles can be limited to specific application bundle ID's. However, developers also have the ability to create wild card * ID's that can sign any application bundle.
The result is that developers themselves, for their personal devices can run any code on their phones.
Limitations
These development provisioning profiles can only sign applications to run on the devices registered with the developers account.
The development profiles expire after 1 year, at which point any installed apps signed with it will stop launching.
The number of devices that can have their IDs registered is limited. It used to be 100 devices, now it is 100 per device type (100 iPads, 100 iPhones, 100 Apple TVs...).
(There is also now a non-developer account signing, just using a normal Apple iCloud account, to encourage people to start learning to develop. The signing and provisioning from those is automatically managed by Xcode and expires after 30 days)
This is a continuation of the previous signing situation. Developers can create Ad hoc Distribution certificates and provisioning profiles which allow them to send out a release build and install (including directly from a link in Safari) the app on devices. However, these devices must still have their UDID's registered in the developer account as development devices. So the same limitations apply.
Note
Registering the UDID doesn't imply any ownership of the device, a device can be added to multiple different developer accounts, and as this was the only way to do beta testing, before TestFlight, it is quite normal. It is simply required for Apple to generate the signing keys required to allow you to sign code to run on that device (without Apple counter signing it like in the AppStore).
If a company wishes to distribute applications internally to its employees it would not want those on the AppStore, but the 500 device limit would be too limited as well. The solution is an enterprise distribution certificate. This allows a virtually unlimited number of devices to install the enterprise profile on their devices, at which point they can download an install apps signed with the companies enterprise certificate.
This allows companies to distribute applications in a way that bypasses the AppStore entirely. Allowing companies to maintain effectively internal private AppStores of internal apps.
As well as for internal apps (major tech companies frequently have internal chat apps, company directories and even things like lunch ordering apps) this provides a way for large companies to distribute beta builds internally to a large number of people.
However, this is only for distributing internally within an organization to employees and contractors. Several companies have recently gotten in trouble with Apple and had there certificates revoked (including Google and Facebook) for using their enterprise distribution certificates to bypass the AppStore and distribute betas and experiments to the public.
TestFlight used to be a company, like hockey app, that managed beta testing via the ad hoc distribution signing. However, after Apple bought them, Apple turned it into a mass beta distribution platform built into the AppStore/iTunes Connect infrastructure.
You upload a release build signed for upload to the AppStore. Once the build has been accepted into iTunes Connect you can then take the build and use it for a TestFlight beta, or submit it for app review and release onto the store.
TestFlight does not require devices IDs be registered to the developers account. Instead all the developer needs is their email address, and the tester can accept the invite from their personal AppStore account. There is even the ability to produce a public link where users can sign up to the beta themselves.
The external tester user account (not device, a user can have multiple devices) limit is 10,000.
TestFlight has 2 categories of people, internal tester and external testers. Internal testers are users on iTunes Connect who:
up to 25 members of your team who have been assigned the Admin, Technical, App Manager, Developer, or Marketer role to test your app. Each member can test on up to 30 devices. Internal testers can access all of your beta builds available for testing.
The first build sent to external testers requires going through an app review first.
The primary way applications are meant to run on an iOS device is via the AppStore. After being signed by a developers signing certificate and uploaded to iTunes Connect, Apple also signs the application bundle and puts it on the AppStore. Applications signed by Apple do not expire after 1 year and can run on any iOS device.