Here we are on the brink of a new iPhone OS product introduction and developers are facing yet another crunch with device IDs for Ad Hoc testing.
Apple currently lets each iPhone developer, whether a company or an individual account, assign 100 devices for testing purposes. A large chunk of those available devices get used by employees with multiple devices. We also have a valuable group of external testers that we use for Ad Hoc beta testing. Many of these individuals buy the latest and greatest hardware, so each time there is a new product introduced, we use up more devices from our list.
On April 3rd, almost everyone on our beta test list will be buying an iPad and want to run Twitterrific on it. Unfortunately, some of these testers are going to be out of luck because we don’t have enough devices left to allocate. I have no idea what we’re going to do if the next version of the iPhone OS is introduced before our iPhone Developer account gets renewed.
As a developer, I never like turning a valuable tester away from my product. But that’s what we’re doing now.
To be clear, I think Apple’s policy is justified. Developers were abusing the system, so something had to be done. The problem, in my mind, is that the throttling valve is being put on the wrong piece of pipe.
As developers, we want to maintain a pool of testers, not devices that they test on. Devices are ephemeral: they change as new hardware is introduced and replaced. The thing that remains constant are the people who test our products.
A tweet from Mike Piontek crystalized this thought: the limitation for Ad Hoc provisioning should be based around individuals, not the devices that they own. It makes more sense to regulate Apple IDs rather than UDIDs. I want John Gruber to be able to run my apps on whatever devices he currently owns. I want to put my own name on the provisioning list and enable the five iPhone OS devices sitting on my desk. All that Apple cares about is that are only 98 other people besides Gruber and me.
(I suspect that Enterprise IT has similar problems and would welcome a solution based on employees rather than the hardware they own. I can only imagine the headaches of managing thousands of devices.)
Of course, there’s a huge amount of infrastructure around verification based on UDIDs: the Program Portal, device firmware, and our own internal processes would require changes. But I think it’s a good goal to work toward, because the current system isn’t scaling well and will only get worse as Apple introduces new products.
Updated April 13th, 2011: It’s been over a year and the situation just keeps getting worse. Please take a moment and duplicate rdar://9255432. Thanks!