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.


4 Answers 4


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.

  • 1
    Yes, QA always needs to test in an end-user environment and not a development environment.
    – 17 of 26
    Commented Aug 28, 2013 at 15:56
  • Some years back, I was involved with a project that had to develop two completely different CPU boards. The hardware engineer who did the board I was heavily involved with put a bunch of test connectors on his board, taking out insurance for debug phase, to make certain we could probe anything. He took a lot of static for wasting real estate and money. The other guy didn't waste any such money and real estate. Funny thing: We never needed the connectors on our board. Integrating the other board was reportedly an absolute nightmare, because NOTHING COULD BE PROBED. Think "insurance". Commented Aug 28, 2013 at 18:10
  • @JohnR.Strohm For a development one, probing is good. All I'm trying to say that if it was designed to have a production board that is different than the development board, then one would also need to test again with the production one after succeeding with the development one (and probing if necessary).
    – user40980
    Commented Aug 28, 2013 at 22:04
  • This makes a lot of sense for a typical 'dev kit'. Out of curiosity, in the case of iOS any iDevice can be used as a 'developer device'. How can there be a difference with two pieces of the same hardware? Commented Aug 29, 2013 at 15:58
  • 1
    @Katamaritaco just because it is the same physical device doesn't mean that the application has the same permissions within iOS. The ability to do things such as remote debugging may change what resources an application has access to.
    – user40980
    Commented Sep 8, 2013 at 5:48

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.


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. :)


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.