Wrestling with Status Bars and Navigation Bars on iOS 7

While updating Riposte and Whisper for iOS 7, one of the recurring problems I had was getting our view hierarchy to layout correctly. The most troublesome APIs are those for the system status bar and UINavigationController. The API documentation is woefully inadequate as of this writing. The following is, to the best of my knowledge, essential information for any developer struggling with status bars and view controller containment on iOS 7:

  1. There is no way to preserve the iOS 6 style status bar layout. The status bar will always overlap your application on iOS 7.

  2. Do not confuse status bar appearance with status bar layout. The appearance (light or default) does not affect how the status bar is laid out (frame/height/overlap). It is important to note as well that the system status bar no longer has any background color. When the API refers to UIStatusBarStyleLightContent, they mean white text on a clear background. UIStatusBarStyleDefault is black text on a clear background.

  3. Status bar appearance is controlled along one of two mutually-exclusive basis paths: you can either set them programmatically in the traditional manner, or UIKit will update the appearance for you based on some new properties of UIViewController. The latter option is on by default. Check your app’s plist value for “ViewController-Based Status Bar Appearance” to see which one you’re using. If you set this value to YES, every top-level view controller in your app (other than a standard UIKit container view controller) needs to override preferredStatusBarStyle, returning either the default or the light style. If you edit the plist value to NO, then you can manage the status bar appearance using the familiar UIApplication methods.

  4. UINavigationController will alter the height of its UINavigationBar to either 44 points or 64 points, depending on a rather strange and undocumented set of constraints. If the UINavigationController detects that the top of its view’s frame is visually contiguous with its UIWindow’s top, then it draws its navigation bar with a height of 64 points. If its view’s top is not contiguous with the UIWindow’s top (even if off by only one point), then it draws its navigation bar in the “traditional” way with a height of 44 points. This logic is performed by UINavigationController even if it is several children down inside the view controller hierarchy of your application. There is no way to prevent this behavior.

  5. If you supply a custom navigation bar background image that is only 44 points (88 pixels) tall, and the UINavigationController’s view’s bounds matches the UIWindow’s bounds (as discussed in #4), the UINavigationController will draw your image in the frame (0,20,320,44), leaving 20 points of opaque black space above your custom image. This may confuse you into thinking you are a clever developer who bypassed rule #1, but you are mistaken. The navigation bar is still 64 points tall. Embedding a UINavigationController in a slide-to-reveal style view hierarchy makes this abundantly clear.

  6. Beware of the confusingly-named edgesForExtendedLayout property of UIViewController. Adjusting edgesForExtendedLayout does nothing in most cases. The only way UIKit uses this property is if you add a view controller to a UINavigationController, then the UINavigationController uses edgesForExtendedLayout to determine whether or not its child view controller should be visible underneath the navigation bar / status bar area. Setting edgesForExtendedLayout on the UINavigationController itself does nothing to alter whether or not the UINavigationController has a 44 or 64 point high navigation bar area. See #4 for that logic. Similar layout logic applies to the bottom of your view when using a toolbar or UITabBarController.

  7. If all you are trying to do is prevent your custom child view controller from underlapping the navigation bar when inside a UINavigationController, then set edgesForExtendedLayout to UIRectEdgeNone (or at least a mask that excludes UIRectEdgeTop). Set this value as early as possible in the life cycle of your view controller.

  8. UINavigationController and UITabBarController will also try to pad the contentInsets of table views and collection views in its subview hierarchy. It does this in a manner similar to the status bar logic from #4. There is a programmatic way of preventing this, by setting automaticallyAdjustsScrollViewInsets to NO for your table views and collection views (it defaults to YES). This posed some serious problems for Whisper and Riposte, since we use contentInset adjustments to control the layout of table views in response to toolbar and keyboard movements.

  9. To reiterate: there is no way to return to iOS 6 style status bar layout logic. In order to approximate this, you have to move all the view controllers of your app into a container view that is offset by 20 points from the top of the screen, leaving an intentionally black view behind the status bar to simulate the old appearance. This is the method we ended up using in Riposte and Whisper.

  10. Apple is pushing very hard to ensure that you don’t try to do #9. They want us to redesign all our apps to underlap the status bar. There are many cogent arguments, however, for both user experience and technical reasons, why this is not always a good idea. You should do what is best for your users and not simply follow the whimsy of the platform.

Accompanying Stack Overflow answer available here.

|  17 Sep 2013




Another Reason to be Bullish About App.net

Horace Dediu from an interview posted this morning (emphasis added):

An internet business is the arbitrageur who takes advantage of the inability of each market to price the other. History shows that arbitrage markets tend not be stable as information begins to leak across markets. Therefore what would blow the internet up is if consumers could become wiser about what they are giving up and advertisers would become wiser about aggregating consumer data. I imagine a system where each individual would allow bids on their consumption and a market mechanism where bidders competed for that data. This of course depends on users taking control and ownership of their own data.

[…]

It would create a new era which will have political dimensions. I imagine we’ll need an internet citizen’s bill of rights or some such movement which will reset expectations. Economically, could bode well for those who position themselves as protectors of the individuals and be a crisis for those who take advantage of consumer ignorance.

Note that this would be a structural difference, not a difference of technological capability. In other words, Facebook, Twitter, and Google could not copy it without destroying their established businesses. Isaac would have to sacrifice Abraham.

|  17 Sep 2013




Swipe To Go Everywhere

Swipe To Go Everywhere:

Jordan Cooper (a.k.a @blenderhead on App.net) invited Jamin Guy and I to his podcast this week to talk about the future of App.net, embarrassing oneself in eighth grade history class, offending family and friends with demonstrably funny jokes, location-aware apps for pot enthusiasts, and more.

|  27 Aug 2013




How Will We Know if iOS 7 is a Success or a Failure?

Depending on whom you ask, iOS 7 is either a hero or a villain. It’s a spring-cleaning of the cobwebs from an outdated visual style, or it’s an over-correction based on an inflexible system of dubious rules. It’s Apple once again breaking free from the constraints of the past, or it’s Apple showing up unfashionably late to the newest fad.

These opinions can’t all be right, but can any opinion be right? How will we know when iOS 7 can be judged a success or a failure? What does “success” even mean for an iOS update? What role does interface design play in this success?

A good place to start is with Apple’s own attempts to draw an outline around iOS’ impact on the mobile OS landscape. In this years’ WWDC Keynote (beginning around 69:40), Tim Cook approached iOS from several angles: install base, usage, and customer satisfaction.

If success is defined by the percentage of in-use devices that are updated to the latest OS, then iOS 7 is probably going to be the most successful iOS version to date. According to Cook, ninety-three percent of iOS devices are using iOS 6 (with six percent running iOS 5). This is most likely a testament to the ease of installing over-the-air software updates, as well as Apple’s efforts to support older devices still in widespread use. These factors are not changing in iOS 7, so I would expect to see similar numbers at next year’s Keynote.1

iOS device owners use their devices more often than other mobile device owners. According to Experian, iOS devices are used 75 minutes a day, on average, compared to 45 minutes a day for Android.2 If these usage times tip in favor of Android, it could mean that the changes in iOS 7’s design are making customers less willing to spend time with their devices. This seems an unlikely scenario to me. The “offensive” changes in iOS 7 are mostly superficial. The key differences between iOS and Android devices3 — tight integration of hardware and software, the richness of third-party apps, etc. — won’t change from iOS 6 to iOS 7.4

The primary metric that Apple uses to objectively measure iOS’ success is customer satisfaction scores — or “customer sat” as Cook referred to it during the Keynote. He proudly noted that the iPhone has been ranked number one in customer satisfaction by J.D. Power nine consecutive times — a first for any product. ChangeWave found that overall satisfaction was 97 percent for iOS device owners, and that 73 percent of them characterized themselves as “very satisfied.”

Of all the metrics used to measure iOS’ success, I think that customer satisfaction is the one to watch most closely. If customers find something distasteful about iOS 7, I would expect to see a drop in both overall satisfaction and in the number of people who claim to be very satisfied. Or perhaps the opposite might happen. Either way, customer satisfaction is the best measure we have. The other metrics compare iOS to Android and other mobile operating systems. The data are influenced by too many external factors to be a good measure of the iOS 7 user experience itself.

Another measure of success will take longer to notice. Over the next two or three years, as contracts begin to expire and customers head out in search of device upgrades, what kind of devices will they choose? Will iOS sales growth taper off as customers choose alternatives?

Standing in an AT&T store recently, the only smartphone in the store that didn’t have a “flat” design aesthetic was the iPhone. Windows Phone’s app tiles swooped around in a delightful way, with no drop shadows or gradients to distract me. The Android lock screens were hard to distinguish from the iOS 7 test device I’d brought with me in my pocket. The build quality of some of the Samsung, HTC, and Nokia phones was comparable to the iPhone. Their screens were bigger and more pixel-dense. The HTC One felt more like a miniature iMac then a smartphone. It felt great to heft it around. Standing there, absorbing all of the options available to me, and with AT&T staff more than happy to sell me an Android device as easily as an iPhone, I wondered why anyone chooses an iPhone at all.

If the appeal of the iPhone, all the years it’s been on sale, is in part due to the little visual details — a notepad icon that looks like what it does, an unlock slider so easy to grasp than even babies figure it out on their own — then iOS 7 could be spoiling the key ingredient to the success of its predecessors. Time will tell.

  1. There are still a lot of iPhone 3GS devices in use, which will not be supported by iOS 7. However, with the steady growth in the smartphone market overall, and the likely introduction of lower-cost iPhone models in the fall, I expect that by June 2014 any impact on the iOS 7 install base by iPhone 3GS devices running iOS 6 will be more than compensated for by sales of newer iOS devices. ↩
  2. That’s a time difference of only thirty minutes. Since iOS devices are generally more power-efficient than their Android counterparts, it is not implausible that the Android deficit is a side-effect of battery life. If Android devices with better power-consumption are released, then Android usage numbers could improve without implying anything negative about iOS 7. ↩
  3. Some people argue that there are also differences between iOS and Android device *owners*. I won’t make such an assumption here. If there is any truth to this notion, it could plausibly account for usage differences, too. But if personality drives usage, then iOS 7 isn’t going change anything. A software update can’t make you a thinner, overzealous bore. ↩
  4. Cook also presented data on mobile web usage on tablets, but these data also aren’t likely to change with iOS 7, since the underlying causes will remain the same. ↩

|  26 Aug 2013




Delight is in the Details — By Shawn Blanc

Delight is in the Details — By Shawn Blanc:

My internet pal Shawn Blanc has released a new book today: Delight is in the Details, a book for craftspeople about the practice of sweating the small stuff. The exhortation from the announcement email was great:

Now, go forth and make something delightful.

Spoken like a true Protestant. I look forward to reading his book this week.

|  6 Aug 2013