Open Radar

 
Summary:
When the status bar of an iPhone is 2x height (either because your mic is in used, you're in a phone call, or are tethering), and you launch a new app, the Default.png is pushed down by 20px and the bottom if it is cut off. 

The Issue:
This can make for a rather jarring launch experience (when, say, tabbar icons are cut off, and then the app finishes launching and the tabbar moves up 20px).

The Request:
It would be nice if there was a way for developers to gracefully handle this scenario.

Potential workarounds:
There are a few ways to handle this (that I can think of):
I. Allow developers to have another set of Default.png's for apps that target iPhone, that are 20px shorter.
II. Allow developers to specify a point in which the next 20px would be cut off, in Info.plist (per supported orientation) that is chopped off from Default.png as needed. Ex:

<key>UIStatusBarClippingRange</key>
<dict>
	<key>UIInterfaceOrientationPortrait</key>
	<string>150</string>
	<key>UIInterfaceOrientationLandscape</key>
	<string>45</string>
</dict>

III. Allow developers to specify a list of ranges (that add up to 20px, per orientation) that are chopped off from Default.png as needed. This is slightly better than a flat 20px range to chop off, because, it will let people with patterned background images keep more of the overall design, instead of having to choose a big chunk to remove. Ex:

<key>UIStatusBarClippingRange</key>
<dict>
	<key>UIInterfaceOrientationPortrait</key>
	<array>
		<string>150-160</string>
		<string>205-210</string>
		<string>250-253</string>
		<string>273-274</string>
	</array>

<!-- or maybe something like this -->
<key>UIInterfaceOrientationLandscape</key>
	<array>
		<dict>
			<key>start</key>
			<number>44</number>
			<key>length</key>
			<number>10</number>
		</dict>
		<dict>
			<key>start</key>
			<number>260</number>
			<key>length</key>
			<number>6</number>
		</dict>
		<dict>
			<key>start</key>
			<number>272</number>
			<key>length</key>
			<number>4</number>
		</dict>
	</array>
</dict>

Potential workaround problems:
I. App size increases. Default.png's are usually one of the larger assets in the app, and, nearly doubling the amount of Default.png's isn't too good.
II. App launch time might slow down slightly, as UIKit has to chop up an image and render it back into a context for display. (Or maybe not. Theres a lot about the rendering pipeline that I don't know about.)
III. See #2, with an even longer delay, since you can't make it a quick chop and will have to iterate over more pixels and and stuff.

Other random thoughts:
I really like solution II. It feels like a good compromise -- avoids doubling the # of Default.png's, and, isn't the most complicated solution to implement (or understand). Also, I don't think the app launch time will be slowed down by a noticeable amount of time on newer devices.