Why do development devices give you more resources than a typical device?

Question

I have created an app that works on my 4th generation iPod Touch and my company's 5th generation iPod touch.

We were about to release, when we found a crash that occurs after any non-developer device runs the app*.

The notion came up that a device registered as a 'developer device' gives your app more resources to use. This doesn't seem right to me, since I couldn't think of any reason that would exist - I feel like it is more likely an issue with building or provision profiling.

However, that prompted a discussion. Why do devices such as game console development kits, devices that have more capabilities than the target platform, exist in the first place? Of course it is nice to stress test a program, but wouldn't a more accurate representation of the target platform make more sense?

TL;DR - Why do development kits have more resources than target platforms?

*With a non-developer device being any >3rd gen. iOS device that downloads the app from our server, not directly from a computer with the app & xcode installed.

_{Note there is another question that reads similar, but it is actually different, because that other question is asking about simulator, and I understand that there are massive differences between using a simulator and an actual device.}

Answer 1

The development environment (for anything - be it a stand alone java application, or a mobile environment, or embedded device) typically has the ability to do remote debugging, enhanced logging and other types of introspection of the enviroment (one typically doesn't want to add all the hooks for a logic analyzer on a production embeded device).

These additional things take additional resources. Opening up a remote debugger against a vm or other remote enviroment takes some resources on the other end. In the severely limited realm of mobile, it is possible that these additional resources will put it over the limit granted to a standard application. Thus, more resources are given to the development environment so that it won't hit the resource limit when it starts doing additional logging or debugging.

This goes further to the point that you always need to test something in a mirror of the production environment. Trusting that it works on the developer's machines with all their tweaks and different variables isn't sufficient to verify it works correctly in production.

Answer 2

It allows you to create a resource-greedy proof-of-concept which you can later optimize.

It makes no sense in crashing an app because it's 5 bytes over the memory limit (which can be solved by setting the optimizer to conserve space in release but you are running a debug version),

having a warning pop up in the log when you go over the consumer limit while testing will be nice here.

Answer 3

It's partly a matter of "trust." Developers are assumed to know what they're doing, and are therefore given unfettered access to the device and all of its resources. This can be a big help to small companies and development teams, where unused resources are wasted resources.

In a larger corporate environment, or especially the general public, this kind of access becomes a liability, due to security concerns and the need to play well with other applications that also need resources.

This isn't really a new idea. I have two machines at work. On my developer machine I have administrative access, but it is isolated from the internet. My other machine, which I use for email, Office and Internet access, doesn't even give me the ability to install programs.

This is why you have to test your application on a non-developer device before you deploy it, to make sure that it is well-behaved. :)

Answer 4

With iOS, a device enabled for Development allows you to directly run Debug builds, which may contain a different set of compiler bugs than a Release build, as well as run apps under a debug nub, which may subtly change thread timing and memory usage, which can also show/hide various threading and leaked memory bugs.

A development device would not be of much use without a debug capability, and a user device with debug capability would present a (more) severe app and app data security problem.