iOS Design Guidelines

These guidelines describe how to design apps that follow the official HIG for iOS by Apple, not what you can do with custom controls. Sometimes it makes sense to break the rules. The purpose of this document is to guide you, not to provide solutions for complex and unique design problems.

Digesting WWDC: cloudy

I’ve spent the last couple of days sifting through the announcements at WWDC. Apple claims 4000 new APIs, and it certainly feels like it. Apple has been busy. But setting aside all the normal incremental improvements, there are a couple of interesting strands. 

First, Apple is continuing the steady process of removing restrictions on what developers can do - but doing so in a very specific way. Almost all of these restrictions are necessarily trade-offs - on a smartphone more flexibility is ipso facto less security and less battery life. So multi-tasking was permitted only once Apple had created a way to do it while preserving control. The same now comes with Extensions. Apple has a model to allow apps to connect to each other and add functionality to other apps - but with clearly defined attach points and a clear control model. Like multitasking, the idea is to gain most benefits of being open while preserving most benefits of being closed. Rather than giving any app system access, you open up specific use cases - a new keyboard, for example, while controlling it tightly (no network access for that keyboard without permission) and dismissing other use cases entirely (no third party SMS apps). The same applies to the fingerprint scanner - apps can now ask for authentication but don’t get the print data - they only get a ‘yes/no’ response back from the system. It’s sandboxes all the way down. In addition, Apple is backing off the ‘no documents’ rule, which seems to have been a vision of a simpler and easier to use approach that was just too forward-thinking. Hence Cloud Drive, which is amongst other things an argument that DropBox really is just a feature (and in the new MacOS there are APIs specifically for file syncing services, addressing some of the heavy lifting OS hacking that Dropbox or Box have had to build themselves). The practical effect of these moves is that a lot of the specific use cases that might draw high-end users to Android (custom keyboards, say) get sliced off. 

The second theme, and a very interesting one, is cloud, the big Apple weakness. The whole of WWDC is full of cloud. A very large proportion of the new user-facing features touch the cloud in some way, as a conduit or as storage. And the ones that don’t use what you might call the personal cloud - the Bluetooth LE/Wifi mesh around you (such as HealthKit or HomeKit). So edit a photo and the edits are on all your devices, run out of room and your photos stay on the cloud but all but the previews are cleared off your phone, tap a phone number on a web page on your Mac and your phone dials it. But none of this says ‘CLOUD™’ and none of it is done in a web browser. Web browsers are for web pages, not for apps. Hence one could suggest that Apple loves the cloud, just not the web (or, not URLs). This is obviously a contrast with Google, which has pretty much the opposite approach. For Google, devices are dumb glass and the intelligence is in the cloud, but for Apple the cloud is just dumb storage and the device is the place for intelligence. And it’s built a whole new set of APIs, CloudKit, to enable this for developers, which it is (for the first time, I believe) dogfooding, building the photos product on it. 

There’s a release cycle question in here. A phone that’s refreshed every year or replaced every two can iterate and innovate much faster than a TV, car (or fridge, or, perhaps thermostat) that may be replaced only every five or ten years. So it seems like the place for the intelligence should be in the phone rather than the TV. But the extension of this is that a cloud product can iterate every day. This is the killer advantage of enterprise SaaS over on-premises software - you can improve things all the time. And Apple updates its OS once a year and, so far, the same is true for the cloud products it builds for developers, where Google can update all of its products every week. 

You can see this dynamic clearly in smartphones: for the last couple of years, Apple has done an annual release (of both hardware and software) and taken the lead for 6-9m months, and then Android (Google and the OEMs collectively) catches up and overtakes for 3-6 months until the the next Apple release. It’s a game of leapfrog. Is this a disadvantage for Apple? Again, there’s a tradeoff, embodied in Facebook’s old internal slogan, ‘Move fast and break things”. If you’re Google and your products are mostly black boxes to the outside world then iterating fast is fine, but if you have millions of developers building on those APIs, changing things every week isn’t necessarily a great idea. That is, there’s an optimum API refresh frequency. (One could also point out that though Google refreshes Android frequently, the average Android user gets a new version of Android only every two years, when they replace their phone, where the average iOS user gets the new version once a year as it is released). 

Going back to this ‘Apple view of the cloud’, though, there’s a deeper and older dynamic starting to come into play now. Apple invented the smartphone as we know it 7 years ago and since then the concept has been built out. All the stuff that really should have been there has been added step by step by both Apple and Google, and the pace at which essential improvements are made is starting to flatten out. But as that happens, the two platforms start to converge. Copy & paste is copy & paste, but iBeacon is a very Apple sort of idea, just as Google Now is a very Google product. That is, as the core features are built out and commoditised, the changes are coming more and more in ways that reflect the very different characters of Apple and Google. I’ve described this before by saying that Apple is moving innovation down the stack into hardware/software integration, where it’s hard for Google to follow, and Google is moving innovation up the stack into cloud-based AI & machine learning services, where it’s hard for Apple to follow. This isn’t a tactical ‘this’ll screw those guys’ approach - it reflects the fundamental characters of the two companies. Google thinks about improving UX by reducing page load times, Apple thinks about UX by making it easier to scroll that page. 

One effect of this is that it might get harder to make essentially the same app on both platforms. If a core, valuable thing you can do on one platform has no analogue at all on the other, what do you do? Ignore the stuff that isn’t on both, and get a lowest common denominator product? Or dive into those tools, but end up having quite different experiences on iOS and Android? Things like Metal and Swift only accelerate this issue. 

Another aspect of this issue is the stuff that Facebook announced at F8, especially deep linking. Facebook would clearly like, on some level, to put together a sort of meta-OS that sits on top of both iOS and Android, driving connections and engagement between apps and acting as a social plumbing layer. But it’s not clear that that’s its place in the stack. Apple’s Extensions offer another and very compelling way to drive people between iOS apps. And in addition, Apple has quietly announced, as part of Cloudkit, its own identity layer. You can sign a user into your app using their iCloud account, and (with permission) use iCloud to see which of their friends are using the same app. And that would use the fingerprint scanner.  Looking at the address book is a major driver of growth bethink many social apps on smartphones - Apple is trying to co-opt that, with less friction but also with total user privacy built in. And privacy was a very, very common theme throughout all the developer sessions. You could build an entire multi-player game in Cloudkit, and possibly even a social messaging app. So ‘cloud’ things become iOS things. But only for iOS. 

And yet, on the other hand, all of the new extensions give Google and Facebook new places to embed their services within iOS.  

This brings me to the macro point: Everything Apple does is about selling devices. Definitely iOS devices, and possibly an Apple TV or a wearable of its own. But for now, the device is the centre point. And that’s a $600 device. Apple has a lock on the majority of this super-premium segment, with Android’s attempts to break into it plateauing at about a third of the segment. This means that Apple sells about 10% of all the phones on earth and Android takes the next 50% or so, and that gives Apple perhaps a third of run-rate app downloads and the majority of the actual value. This is a now pretty stable situation, unless a premium alternative to Samsung emerges or the subsidy environment changes radically. But the only way for Apple to break out of that segment and sell 20% or 30% of the phones sold on earth is a cheaper phone.  Until then the annual leapfrogging with Android will continue. 

Fertile Ground

One of my favorite patterns in our industry is when the old and established are wiped out by disruption, irrelevance, or changing fashions. Like a forest fire, clearing out the old is very destructive and shouldn’t be taken lightly. But what’s left behind is a clean slate and immense opportunity.

I don’t think we’ve ever had such an opportunity en masse on iOS. After what we saw of iOS 7 yesterday, I believe this fall, we’ll get our chance.

The App Store is crowded: almost every common app type is well-served by at least one or two dominant players. They’ve been able to keep their leads by evolving alongside iOS: when the OS would add a new API or icon size, developers could just add them incrementally and be done with it. Established players only became more established.

iOS 7 is different. It isn’t just a new skin: it introduces entirely new navigational and structural standards far beyond the extent of any previous UI changes. Existing apps can support iOS 7 fairly easily without looking broken, but they’ll look and feel ancient. Their developers are in a tough position:

• Most can’t afford to drop support for iOS 6 yet. (Many apps still need to support iOS 5. Some unlucky souls even need to support 4.3.) So they need to design for backwards compatibility, which will be extremely limiting in iOS 7.
• Most can’t afford to write two separate interfaces. (It’s a terrible idea anyway.)
• Most have established features or designs that won’t fit well into a good iOS 7 design and will need to be redesigned or removed, which many existing customers (or the developers themselves) will resist.

I don’t think most developers of mature, non-trivial apps are going to have an easy time migrating them well to iOS 7. Even if they overcome the technical barriers, the resulting apps just won’t look and feel right. They won’t fool anyone.

This is great news.

Apple has set fire to iOS. Everything’s in flux. Those with the least to lose have the most to gain, because this fall, hundreds of millions of people will start demanding apps for a platform with thousands of old, stale players and not many new, nimble alternatives. If you want to enter a category that’s crowded on iOS 6, and you’re one of the few that exclusively targets iOS 7, your app can look better, work better, and be faster and cheaper to develop than most competing apps.

This big of an opportunity doesn’t come often — we’re lucky to see one every 3–5 years. Anyone can march right into an established category with a huge advantage if they have the audacity to be exclusively modern.

I’ll be invading one as soon as I can. Here’s hoping I’m right.

Source

Thoughtful critique of iOS 7 from Frank Chimero:

This morning, I watched the videos of the iOS 7 interface again, and I saw a bunch of rushed designers unable to stabilize an uneven interface. It’s worth remembering that Ive took over Human Interface only 7 months ago, and they redesigned the whole phone in that time. Straight up: seven months is a ridiculous deadline. Source

To see full article click here.

Jonathan Ive is not a Graphic Designer

Jony Ive, at a talk I was fortunate to attend a few years ago (sorry, no linkable write-up exists):

One of the things that’s interesting about design [is that] there’s a danger, particularly in this industry, to focus on product attributes that are easy to talk about. You go back 10 years, and people wanted to talk about product attributes that you could measure with a number. So they would talk about hard drive size, because it was incontrovertible that 10 was a bigger number than 5, and maybe in the case of hard drives that’s a good thing. Or you could talk about price because there’s a number there.

But there are a lot of product attributes that don’t have those sorts of measures. Product attributes that are more emotive and less tangible. But they’re really important. There’s a lot of stuff that’s really important that you can’t distill down to a number. And I think one of the things with design is that when you look at an object you make many many decisions about it, not consciously, and I think one of the jobs of a designer is that you’re very sensitive to trying to understand what goes on between seeing something and filling out your perception of it. You know we all can look at the same object, but we will all perceive it in a very unique way. It means something different to each of us. Part of the job of a designer is to try to understand what happens between physically seeing something and interpreting it.

I think that sort of striving for simplicity is not a style. It’s an approach and a philosophy. I think it’s about authenticity and being honest. Not just taking something crappy and styling the outside in an arbitrary disconnected way.

Over the last week the Internet has been aflutter with rumors about an Ive-driven iOS design overhaul. Nearly all of the conversation has been focused on the visual aesthetic, and that’s not surprising. To use Ive’s words, that is “easy to talk about.”

But the overhaul of iOS is certainly more than skin deep.

• A purely visual overhaul would not have a WWDC deadline. iOS 7 is not expected to be released until the fall, and betas could use old visuals until then. The fact there is a WWDC deadlines suggests there are real functionality changes that developers need to know about.

• Ive does not lead visual design. He leads Human Interface design. Perhaps this sounds pedantic, but the distinction between graphic design and interface design apparently escapes a lot of people. One of the more asinine quotes I saw last week came from Maggie Hendrie, the Chair of Interaction Design at the Pasadena Art Center, in Wired:

  The very fact that we’re talking about who’s going to design the icons…is a little bit of a concern. Because that’s not innovative.

  Perhaps the problem is the talking?

• Ive himself wouldn’t stand for simply making a new skin. Look again at that quote: he derides the very idea of separating what is on the surface from what the product actually is.

As with most such debates, “skeumorphism” versus “flat” is devoid of crucial context. When the iPhone came out, nobody used touch devices.¹ The signaling benefits of skeumorphism were very useful,² especially since most iPhone buyers were buying their first iPhone.

Today, as the premium smartphone market moves towards saturation, an increasing portion of iPhone users are buying their second device. The context is changing. And, likely, so is iOS.

Source

Evolution of Apple in 3 Minutes. Source

Some iOS interface ideas and experiments.
More about the concept here: http://ntl.tf/MSCSQ4