Thus, in general, performing heavy lifting along the main thread will block the application user interface. The OS is looking for the DidFinishLaunchingWithOptions application to return in a reasonable amount of time. If this is not the case, it will kill your application and give you the exception code 8badf00d. Look at your past tense; more than 20 seconds! I got 8badf00d to run in less than 5 seconds.
And, obviously, you cannot get this error on all devices all the time. If your setting is dependent on your Internet connection (like mine), you can get it on a device that is trying to connect to Edge or in a shadow Wi-Fi connection. If you make a ton of heavy graphics, this can also lead to a load time threshold. Perhaps the only reason you see it in iOS5 is because Apple has reduced the maximum download time limit for iOS5 devices (better hardware, better software, boot time should also be better, one could make an argument). I would prefer to start tuning in the background thread. If this setting is an integral part of your application, first download your splash screen with a download indicator and delete this view after the setup is complete. From the user's point of view, they just see the splash screen at startup, as usual, and then maybe an activity indicator or something appears, and then when it disappears, they have a fully configured setting.
Other parameters will optimize the output from your download code so that this happens in less than a few seconds. But if you are now in 20 seconds, I don’t see that this optimization is possible.
UPDATE: From apple docs:
The most common cause of a watchdog timer timeout failure in a network is the application being a synchronous network in the main thread. There are four factors: synchronous network. Here you make a network request and block the pending response. main stream. The synchronous network as a whole is not perfect, but it causes certain problems if you do this on the main thread. Remember that the main thread is responsible for launching the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive. long timeouts. If the network just leaves (for example, the user is on a train that> enters the tunnel), any request waiting for the network will not work until some time out. Most networks timeouts are measured in minutes, which means that a blocked synchronous network request for the main thread can support the user interface does not respond for several minutes at a time. Trying to avoid this problem by reducing the network timeout is not a good idea. In some situations, it can take many seconds for a network request to succeed, and if you always start early, you will never make any progress. watchdog timer - for the user interface to respond, iOS includes a watchdog mechanism. If your application does not respond to some user interface events (start, pause, resume, end) in time, the watchdog will kill your application and create a watchdog timer reporting a timeout failure. The amount of time that the watchdog gives you is officially documented, but it is always less than the network timeout. One difficult aspect of this problem is that it is highly dependent on the network environment. If you always test your application in your office, where the network connection is good, you will never see this type of accident. However, as soon as you start deploying the application to the end, users who will run it in all kinds of network environments will fail as it becomes common. A warning. To summarize, if you make synchronous network calls to the main thread, your application will suffer from a watchdog timeout deployment failure for a wide range of users.