The iOS 7 Power User Challenge

That the growth in iOS has been phenomenal hardly needs to be stated any more. To people like me, though, who have been Apple users since the Mac Classic, it's been an amazing ride.

In 2008, after the launch of the iPhone 3G, I wrote:

If you haven't got it already, it's time to move your head to this place: iPhone OS is Apple's mainstream platform for 2012 and beyond.

That's the world we now live in.

I am and have always been obsessed with software. While the media obsess over new hardware, I've always been far more interested in the capabilities of software. Better hardware - generally - just saves me time. A faster iPad will be great, but what shall we do with it?

What iOS Hath Wrought

Three times in my career, Apple has shipped software that conventional wisdom said basically couldn't be done. The first was the Carbon layer of Mac OS X: most of the Mac toolbox running on a preemptively multitasking, protected memory Unix kernel. The second was Rosetta: PowerPC apps running unmodified and, for the most part, perfectly well on Intel processors.

iOS was the third. Conventional wisdom said that you couldn't possibly get a desktop OS running on a phone. Conventional wisdom said that you couldn't get rid of a user-visible filesystem. Conventional wisdom said you couldn't require all software on the platform to come through a first-party app store.

Right now, just before WWDC 2013, I think it's important to take time to appreciate exactly what iOS has achieved.

iOS broke the tyranny of the hierarchical filesystem as a user interface. A concept so complex that possibly the majority of computer users never achieved any level of real competence in its use. A far larger proportion certainly never achieved any kind of mastery.

iOS turned the purchase and installation of third-party software from a great opportunity to destroy your computer into something that people do for fun. People of very low technical ability are now perfectly safely and competently administering their own computers. This is a revelation and, in my opinion, a big part of the IT backlash against iOS.

iOS solved the virus problem. The conventional wisdom of the PC years was that Windows got viruses because it was vastly more popular than the Mac. In the post-PC years, we have hundreds of millions of people using iOS and, so far as I know, zero viruses.

There are other achievements I could list, but the point is that iOS broke through a lot of conventional wisdom about how computers should appear and operate.

The State of the iOS Union

If I were running Apple, I would milk the Macintosh for all it's worth — and get busy on the next great thing. The PC wars are over. Done. Microsoft won a long time ago. - Steve Jobs, February 1996

So where are we today with iOS? We have a powerful mobile operating system with excellent APIs that enable a broad range of powerful applications to be developed. Despite that, some of the fundamental design choices in iOS are limiting the growth of the platform.

The chart that I use to explain the appropriate deployment of smartphones, iPads and desktop computers uses two axes: task duration and task complexity.

iOS does a wonderful job in the lower-left corner of the chart. Right now, though, I think iOS needs to attack the upper-right corner of this chart. There is an opportunity to completely eliminate the desktop computer for some and drastically reduce its importance for many more.

What does such an attack look like? Well, there are various sources of complexity in the use of a computer for a task and some of them still either overwhelm iOS or simply become too awkward to tolerate.

Let's look at some of them.

Moving Data and Documents Between Apps

One source of complexity is having to use multiple tools to achieve the result you want. On the desktop, the common transport for doing this is the filesystem: save a file from one app, open it in another. iOS needs to support the user in that task without breaking the filesystem abstraction that has been so valuable in making iOS approachable for less technical users.

The current mechanism of "Open In...", which allows an app to copy a file to another app, is enabling some decent workflows but has the drawback of littering each app's sandbox with a copy of the file. It's also difficult to move large files this way.

If I want to take a PDF stored in Evernote, edit it with PDF Expert and save a modified version back into the same Evernote note, I simply can't do it today. The fact that so many iOS apps have built in direct support for Dropbox is testament to how weak the Dropbox app itself is. This is no criticism of Dropbox; they're doing all they can, given the design of iOS sandboxing.

This also applies to chunks of data that are not files: URLs, strings, photos. A great recent example: I like to use Flipboard and Flipboard recently introduced a new feature where you can create "magazines" from web pages. I normally use Instapaper for caching stuff to read that passes by on Twitter, which I read with Tweetbot. Tweetbot supports a few read later services, including Instapaper, Pocket and Pinboard. It doesn't support Flipboard, and there's nothing I can do to make it support posting links to Flipboard apart from begging the Tweetbot developers to add it. The burden of inter-app integration should lie with the destination app, not the originating app.

If iOS had a generalised "send this piece of data to apps that claim to handle it" service - yes, like Android does - all the work to allow posting a link to Flipboard from Tweetbot would be in the hands of Flipboard and not Tweetbot. Similarly, the common workflow of saving an image to the Camera Roll and later extracting it in another app leaves behind data detritus that could be avoided if direct communication were easier.

Moving Data and Documents Between Devices

The TL;DR of this section is: iOS should support AirDrop, and it should be available as an "Open In..." target. Moving data between two iOS devices without using a Dropbox-like service, email or, worse, a Mac has always been annoying. Apps like iFiles leverage Open In... to work around the problem but, again, you end up with a copy of your data in iFiles' sandbox as well as the originating app.

There is another compelling argument for supporting WiFi Direct: Apple TV. The challenge of mass deployment of Apple TV on networks are well documented. What if a future Apple TV could receive AirPlay streams without the need to even be on the network? That would be a Very Big Deal.

Of course, this requires additional support in the WiFi chipsets built into iOS devices but there's no inherent reason it can't quickly become a standard capability.

Dealing with Big Personal Data

One of the bigger limitations of iOS has always been that, every so often, you'll try and do something that's "too big" for an iOS device to do. As the hardware itself becomes more powerful, these situations grow fewer but they still remain. In particular, they tend to persist in areas that involve handling a large chunk of data.

Examples include: trying to import a video from the Camera Roll into an app, opening a large Keynote file, applying a complex set of adjustments in iPhoto. Using Open In... can sometimes fall over if the file is large.

To some extent, these things are hardware-dependent. As CPU, memory and storage levels increase, these issues should diminish but there are clearly some aspects of these that are OS-dependent.

More Granular iCloud Restore

iCloud backup is really great. You set it and you forget it but, increasingly, I see a need for more granular access to the backup. Restoring your entire device just to get one missing file back is quite a drastic step, particularly when you have made other changes to data on the device since the file was lost.

Right now, iCloud backup is a brilliant disaster recovery mechanism. You lose or destroy your iOS device and you can be back up and running in a very short time. What it is not, currently, is a great user-error-recovery mechanism. If you screw up, you're staring a whole-device restore in the face.

Password Management

The current situation with internet passwords on iOS is, put simply, crazy-making. I use 1Password and, short of making it my main browser, it is maddening to have to keep switching between Safari and 1Password to get logged into a site.

The fact that I have a bookmarklet on my Safari toolbar whose sole purpose is to open the current URL in 1Password tells its own story.

I don't know exactly what the solution to this is. Giving mobile Safari the ability to run extensions isn't quite enough unless those extensions can communicate with an app also installed on the system. Regardless, this is becoming highly frustrating. The entire mechanism of usernames and passwords is out of date. It'd be great if Apple could lead the way on building in platform level support for 2-factor authentication. I'm not enough of an expert on this to comment much further but this needs to get easier.

Typing Enhancements

The iOS keyboard is good, but it could be better. I haven't spent a lot of time with the alternative keyboards on other platforms but they are said to be ahead of iOS. I think more work could be done to make autocorrect more predictable.

My main complaint though is about the text selection interface. We now know from some experience with gestural interfaces that interactions requiring tap-and-hold just plain feel slow, whether they actually are or not. The iOS text selection gestures depend heavily on tap-and-hold to precisely place the insertion point loupe.

Wrist Protection APIs

I do not think that iOS needs to embed deep stylus support. Nonetheless, there are increasingly good digital ink apps for various applications: art, drawing, PDF annotation and so on.

Many of these apps have built their own wrist protection systems. Some are better than others and none of them behave exactly alike. In addition, none of them play particularly well with the iOS four-finger multitasking gestures.

Some system level mechanism for doing wrist protection alongside the multitasking gestures would go a long way to easing this problem.

Remove 50MB Limits on Cellular

Power users are often also highly mobile users. One of the main reasons I use a third-party app over the Apple Podcasts app is that, with Instacast, I can download a podcast of any size but Apple's app continues to enforce the 50MB download limit on cellular networks.

This limitation made sense in the early days of iOS, where everyone was on unlimited data connections. Today, most people are on metered connections. We pay for every byte, so we should be allowed to choose exactly how we spend those bytes.

Of course, a warning would still be useful. Some people are on metered contracts which, after a cap is reached, impose astronomical charges. Along with this change, I think a system-wide governor on mobile data usage would be useful. You can imagine, though, how Apple might be reluctant to build in such a feature and then undoubtedly face a rash of "Waah! Apple cost me thousands in data charges!" headlines every time someone doesn't understand how the feature works.

Choose Default Apps

The question of changing default apps has been a contentious one at times in the life of iOS. Until recently, I had not seen many examples of compelling replacements for Safari and Mail. Today, though, that's vastly different.

There are really good alternative browsers now, in the form of Chrome, Dolphin and others. The official Gmail app is lacking in some ways but its a perfectly good alternative for Gmail users. On the iPhone, I have been using Mailbox since the day I got to the head of the queue and would love to set it as my default mail app.

I don't think a generalised UI for changing every protocol handler in the system is necessary at this point. However taking two baby steps by allowing the user to choose their browser and mail client (and perhaps a third in choosing their maps app) would be a good start.

I would like to see some policy around preventing apps from setting themselves as default handlers. The user needs to remain in control of this.

Deeper Keyboard Support

I'm not a regular Bluetooth keyboard user but I do use one occasionally. The apparently increasing popularity of Bluetooth keyboard cases suggests that people do like to regularly use a keyboard with their iPad.

To better support this, I would like to see a few enhancements to the Bluetooth keyboard support in iOS. In particular, a method of keyboard-navigating the multitasking bar would be very welcome. I imagine this as a Command-Tab keystroke opening the bar and subsequent strokes highlighting successive apps which can be chosen by hitting return.

The Way Ahead

That's all I have for now. There are certainly more things that could be added. I have focused here specifically on the issues that are limiting deeper adoption and utilisation of the iOS platform for the 'power user'. There are certainly other concerns that a casual user or a beginner would have.

My broader point, though, is that iOS does NOT need a ground-up rethink, nor does it need to become more like our existing desktop OSes, in order to satisfy more of the needs of the power user. This conceptually small set of changes would go a long way to pushing iOS deeper into that high complexity/long duration section of my chart above.

Moving a Mac App: Viewfinder for iPad

Viewfinder for iPad shipped a couple of weeks ago. It's been insanely busy since then but I finally found some time to reflect on the process of moving a Mac OS X application to iPad.

Mission Statement

In most talks you hear from Apple employees about designing for iPhone and iPad, they always suggest that you develop a 'mission statement' for your app. On Mac OS X, Viewfinder's mission statement was simply:

Easy photo search and download for Mac OS X

For the iPad version, that statement was radically overhauled to say:

Easy photo search and download for iPad

The entire point of Viewfinder has always been to solve the problem that it's way too hard to find and use good quality, correctly-licensed photos on the internet.


When moving an application or its general concept to iPhone, the rule has always been "find the core functionality and translate that to the iPhone". It's still true of the iPad but the difference is that the iPad increased processing power and screen size invites you to bring a much larger feature set.

As I was working on bringing the core functionality of Viewfinder to the iPad, I took a three-step approach:

  • Eliminate the features that are impossible to translate
  • Simplify the features that can be done, but in a reduced manner
  • Focus on a polished, native experience for the rest

Eliminate the Impossible

As it stands, Viewfinder on Mac OS X is a fairly tightly focused application. It doesn't contain a lot of superfluous features, but there were a few features that couldn't be brought to iPad because of the limitations of the iOS platform.

Viewfinder on Mac OS X can automatically add a downloaded photo to the current Keynote document. This feature is implemented on Mac OS X using Automator, which doesn't exist on iOS, so it couldn't be brought over. There's no equivalent cross-application automation technology on iOS, so it had to go.

Similarly, the feature that allows Viewfinder to set the Mac OS X desktop picture directly is also not possible on the iPad. There's simply no API to do this on iOS. Gone.

Finally, Viewfinder supports a "Search in Viewfinder" service on Mac OS X. As with the other features, Mac OS X services have no analogue on iOS so the feature had to go.

Similar but Simpler

Developing for iOS devices is developing a highly resource-starved environment. Many fewer, slower processor cores; slower graphics hardware, dramatically less RAM and, on 3G, much slower and less reliable networking. I find it a source of constant wonder that we squeeze the performance that we do out of these devices, and often wonder why Mac OS X machines feel so slow by comparison.

Viewfinder is an application designed to show large numbers of photos. Without care, this is potentially a difficult thing to do. Photos are some of the largest data blobs an iOS app will handle, so it's important to manage that precious memory carefully.

On the Mac, Viewfinder has a dynamically-resizable thumbnail view. It responds to the user's intention by automatically loading ever-higher resolution images as the thumbnails grow. The internal architecture of this feature is something I'm really proud of, and I think it's a great feature.

The idea of transparently hitting the network for ever larger images doesn't translate well to the iPad. Particularly in this new world of mobile data caps which are "unlimited*" - the asterisk being the international symbol for "if you take this literally you're a sucker" - being more conservative with data usage is important.

So, for Viewfinder on the iPad, I built a thumbnail view with similar core functionality only simpler. The thumbnails are fixed at a maximum width or height of 100px and, instead of zooming them to a larger size, you enter a full-screen mode similar to the built-in Photos application.

Another feature that I personally love in Viewfinder for Mac OS X is the ability to filter the search results by the size of the largest available version. This is a really important feature on the desktop, where you may be looking for photos to fill a 27" display or a high-resolution document.

On the iPad, I decided to leave this feature out. I left it out for two reasons. One is that using the original full-size image on the iPad is often difficult because of the incredibly large file size that some modern DSLRs produce. Secondly, you don't need a massively high-resolution image for most purposes on the iPad. The screen is only 1024x768. Viewfinder still supports searching by the full range of Creative Commons licenses.

Polish The Rest

So, what's left in Viewfinder? There are a core set of tasks that make the application:

  • Set search options
  • Begin a Search
  • View a set of thumbnails
  • View a larger size
  • Download photos
  • Inspect and copy information about the photo

Too many iOS applications aspire to "brand" themselves. It's sometimes appropriate, of course, but I took my inspiration from two system apps that Apple provides: Safari and Maps.

The thing I most love about Maps is that there is almost no UI. It's an incredibly powerful application that delivers everything through a small number of UI elements:

  • A toolbar with two buttons and a search field (two fields in Directions mode).
  • A popover with details about locations
  • A page-curl view to set options
  • An alternate full-screen UI for Street View

The rest of the display in Maps is given over to the main function - showing a map. Viewfinder endeavours to be similarly minimalist.

Not the iPhone

The typical approach to bringing an application to the iPhone was really three steps:

  • Identify the core functionality of the app
  • Remove everything else that isn't essential
  • Polish the user experience

I think the iPad is different. I've written before that I believe the iPad is a true productivity platform and not just the "content consumption" toy that some lazily claim.

Instead of looking for some kind of barebones set of core functionality, I decided to see how much of the desktop app I could bring to the iPhone. I'm delighted with the result and I encourage my fellow developers to push the iPad as far as it can go.

For the rest of you, why not visit the App Store and check out Viewfinder for iPad?

Of 3G iPads and MiFis

Today I asserted on Twitter that a 3G iPad is far superior to a WiFi iPad paired with a MiFi device. To save myself answering the "why do you say that" question twenty times, here's the tl;dr version.

Let me say that a MiFi makes perfect sense if you have multiple, WiFi-only devices that you want to get online. If you take issue with my claim, please save yourself time and stop reading now, happy in the knowledge that I have not been Wrong On The Internet.

My computing life consists of an iMac, an iPad and an iPhone. That's all I own. I also have a 3 MiFi. Let me explain why I vastly prefer the integrated 3G in the iPad over a WiFi iPad with a MiFi (hereinafter referred to as an iPad/MiFi for ease of typing).

Reason 1: call it User Experience, or Connectedness or Ceremony.

When using the 3 MiFi, there is too much setup involved for casual use. A lot of this is down to the poor design of the 3 MiFi. Here's what you do to get online:

  • Power on the MiFi
  • Wait for it to acquire the network (20 seconds, in my absolute-best-case experience - usually much, much worse)
  • Turn on the WiFi radio - another 10 second operation
  • Turn on the 3G radio - 10 seconds to turn on, another 10 to get to 3G status
  • Unlock the iPad, get it associated with the MiFi, get an IP address - another 10-15 seconds

The MiFi will power off after a period of inactivity, so you're talking about a total of around a minute or so every time you want to connect. 56k dial-up modems didn't take that long to get you connected. When I was using an iPad/MiFi, I found that there were times when I wanted to use the iPad online but would just fall back to using the iPhone because it was already online.

Compare to the 3G iPad: you unlock it, you're online.

Reason 2: Battery Life

It's true that the iPad 3G doesn't quite achieve the stellar battery life of the WiFi model, but you'll still get many, many hours of runtime.

With an iPad/MiFi you're only working online for as long as the MiFi can stay alive - in my experience, about two hours of continuous use. With a 3G iPad, your internet connection is hooked up to the iPad's impressive battery and you're online as long as your iPad is alive.

Reason 3: Less Stuff

Perhaps a minor point but in this new world of lightweight, minimalist computing perhaps relevant. With an iPad 3G, you just keep that baby charged and you're good. With a separate MiFi, you're taking an extra charger on holiday and you've got one more thing to remember to keep charged.

Reason 4: On-board Status

My MiFi is on the 3 network and that's not a great network around here (despite what the coverage checker says grumblegrumblegrumble). The MiFi has an incredibly poor signal strength indicator: green for "good" (not, surprisingly, always equivalent to "actually working" in my experience); yellow for "not that good" and red for "bet you're glad this is Pay As You Go, sucka!". At the same time as the MiFi is fluctuating all over the place, the iPad is still convinced that it's on a super-solid five-bars WiFi network.

Tricking the iPad into thinking its on WiFi does have some benefits, though: all the "you can only download this over WiFi" restrictions from the App Store and iTunes are lifted because all of those restrictions depend on the radio status of the device itself.

The downside is that, when the network goes away, the iPad doesn't know about it. All it knows is that packets aren't coming back. Instead of failing immediately because there's no IP, apps will keep trying and trying until they hit their timeouts. This sounds trivial but it's incredibly frustrating in practice.

On balance, I prefer to have the network status up there in the status bar on the device - with more than three guesswork colours to distinguish them - and to have the OS and apps know more about the network.

Back In

Last year, I wrote a piece entitled "App Store: I'm Out", which got a little attention. As strange as it feels to be in a position where I have to explain myself, I thought I should write about why I'm again working on an iPhone OS product.

If I wanted to have to constantly twist to justify the opinions of the past, I would enter politics. As it is, we software developers have the luxury of changing our minds as time and requirements dictate.

After the iPad announcement, I wrote a piece entitled "Future Shock", which got a lot of traffic. The reason I was so sure my take was solid was that I've spent a year working through my own future shock over the direction of Apple's platforms. The first piece I alluded to was my own future shock speaking: "They can't make us submit to app review! They can't reject our apps!".

Well, Apple can and Apple absolutely is. That ship sailed some time ago and I have reconciled myself to the idea that the old indie ways on Mac OS X are never going to be available on iPhone OS.

I do not intend to argue that the problems I enumerated about the App Store have gone away. They largely remain and, in some cases, are worse than they were when I first wrote.

The lengthy app review problem has mostly been solved. It's amusing to see tweets like "my update is taking more than 5 hours, haven't seen that kind of delay in ages". A year ago it was two weeks.

The problem of approval - as opposed to review - remains. In particular, the problem that you may be removed at a moment's notice with few channels to quickly remedy the situation is a significant business risk. Few businesses can afford to unexpectedly lose a week or more of revenue and make payroll.

The problem of app rejection - the idea that you build your app and only then find out if you can sell it - remains. It must be said that the number of apps falling foul of this is decreasing. However, it is not an insignificant problem, particularly when approval is not for life and can be withdrawn at any time.

The App Store continues to represent serious risk. However, in business, risk is the currency.

So, having said all that, why am I 'back in'?

When I first wrote  about my feelings towards the App Store, it was in the  arrogant and vain hope that it might have changed something. The direction of the iPhone OS ecosystem is now clear. To stick to an opinion regardless is to see the world as you would like it to be, not as it actually is.

Down that road lies the Free Software Foundation, and I have zero interest in finding myself in 2020 a bitter forty-something man fighting the battles of a decade ago.

The second factor in this was the iPad. When iPhone OS was just that - a phone operating system - it was obvious at the Apple future would be a combination of iPhone OS devices and Mac OS X computers. Post-iPad, that judgment is far from obviously sound. Having seen the reaction to the iPad from actual potential users, the secure future of the Mac OS as a general consumer computing platform is no longer as clear to me as it once was.

Be clear: I'm not saying OS X is dead, nor that Apple has no interest in improving it. I am saying that I suspect that the days of everyone buying a MacBook to get online are soon to be over. I've already written about how I see our three-Mac family turning into a one-Mac, three-iPad family over the next hardware cycle and I imagine that scenario repeated industry-wide over time. Already the ratio of iPhone OS devices to Macs is 5:2.

This feels like the settling of the wild west. The days of rugged individualism in computing are starting to close. The freedoms we had will still be possible but as with living in remote areas hunting and trapping your own food, few will care to accept those privations in return for the absolutes of liberty.

So where does that leave the small developer? In some ways, we have to shape up a bit. I don't want to say that we have to "become more professional" because, in large part, the Mac indie scene was one of the most professionally committed around.

What I think I prefer is the aviation analogy. We are no longer playing Burt Rutan and building our own aircraft. We're building components for the Boeing or Airbus ecosystems now. Nothing wrong with that - many people do a great job and make a very good living at that. What is lost is the software equivalent of the romance of flight.

I’m Scottish. Frying things and pessimism are our two main industries. It’s worth looking on the bright side too: the iPhone OS ecosystem has in its short life, brought a few incredible things too.

It’s undeniable that iPhone OS devices are incredibly stable. Last night I spent a frustrating hour trying to get my iMac to reboot into a functioning state after it crashed. That was an hour I had planned to spend in bed. In a post-iPhone, post-iPad world such failures feel even less acceptable than before.

iPhone OS is the first mass-market operating system where consumers are no longer afraid to install software on their computers (I’m not counting read-only media software platforms like games consoles here). In a conversation recently, a friend recounted a scene that he passed by in an airport. Four fifty-something women were sitting at a cafe table discussing the latest apps they had downloaded on their iPod touches. New software can’t break your iPhone OS device and, if you don’t like it, total removal is only a couple of taps away.

Finally, the devices are incredibly cheap by comparison with traditional laptop hardware. I could buy myself every iPad that comes out over the course of a three-year hardware cycle and still spend less than I did on laptops. The software is inexpensive too. There remain great strides to be made on discoverability and trials in the App Store. Still, it’s hard to ignore the fact that there’s now a large constituency of users just venturing into their first experiences of purchasing third-party software.

Simply put, I believe, the choice is this: the iPhone OS train is leaving the station in a big way with the iPad; much more so than when it was just for smartphones. I have to ask myself if there's a train that I would rather be on. I don't see one right now, and I don't see one coming down the track.