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. Yet, 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 bookmarket 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, though, 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, the 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.

Not long ago, when Apple’s WWDC conference dates were announced, a slow trickle of registrations would occur as developers consulted with spouses, bosses, and co-workers to determine, in their own sweet time, whether or not they would attend. There was never any rush, because the conference never sold out. Weeks after the announcement, developers who had not registered might even receive a personalized telephone call from Apple, urging them to make a decision. Seriously kids, this is how it used to be.

Over the past several years, demand increased such that at last, those telephone reminders from Apple were no longer necessary. By 2008, the conference sold out for the first time, in a matter of months. By 2010 it took eight days. Last year it took less than 2 hours, and this year? Less than two minutes. I was one of the lucky ones who got a ticket. A few minutes later, as I witnessed my colleagues bemoaning their missing the boat? I cancelled my order.

The conference has room for at most 5,000 developers. According to Apple’s job stimulus statistics, there are 275,000 or more registered iOS developers alone. Let’s assume for the sake of argument that Mac developers add only 25,000, bringing the total to 300,000. Every year, 5,000 attendees are selected from the qualified pool, meaning just 1 out of 60, or 1.5% of potential attendees will have the chance to attend.

What are the goals of WWDC, anyway? For Apple, it’s primarily a chance to educate developers and to encourage them to contribute to the growth of Apple’s platforms. By teaching developers the latest and greatest technologies, they leverage developer efforts to differentiate Apple and to make its platforms more competitive.

For developers the main goal is to get a leg up on the persistent challenge of developing great software for these platforms, even as they are constantly changing. A side-benefit is the opportunity to commune with like-minded developers who are trying to do the same. Ideally with folks who share similar visions for how software should be developed and how the end product should behave for customers.

As the sheer number of Apple developers increases, the capacity of WWDC remains the same. The goals of the conference both for Apple and for developers are increasingly unmet as the number of developers who would like to be educated, indoctrinated, and communed with far outweighs the number of developers who actually can be.

Over the years people have made plenty of flip suggestions for how Apple can solve the problems that plague WWDC: get a bigger venue, charge more money, split it up into multiple conferences. But any of these would be a very small band-aid on a very large wound. WWDC is flat-out busted, and can’t be fixed by any of these analog solutions.

The whole point of the conference needs to be rethought, and the goals addressed from scratch using new approaches. As the greatest challenge for WWDC is in scaling to meet demand, I think it’s obvious that the rethought WWDC should be considered in terms of digital solutions. Call it WWDC if you like, but it needs to take place 365 days a year instead of 4. It needs to serve 300,000 developers, not 5,000. And it needs to take place online, not within the cramped confines of a small convention center in San Francisco.

Apple has effectively headed down this course with their laudable offering of free videos of conference sessions. The high-level goal of merely educating developers is largely met by these. But what of the other goals? The vast majority of benefits that Apple and developers see in WWDC could be achieved online using more effective digital materials that are available to, and more importantly, that scale to the vast number of developers eager to learn about and promote Apple’s platforms.

Instead of a week each year when a developer must enter a lottery for a chance at talking directly with a knowledgable Apple engineer in the labs, beef up the existing Developer Technical Support process and workflow so that vexing issues can be driven to the point of resolution, and so that the fruits of those discoveries can be shared with others. For every “lifesaving” tip a developer has received in the WWDC labs, how many others continue to struggle in anguish because the effort was never made to codify that wisdom in the form of a developer technote or other reference material? It doesn’t make sense … it’s a bug, if you will … that so many Apple developers feel that their only opportunity to solve a problem is by meeting in person with an Apple engineer at WWDC.

Instead of asking Apple’s engineers to spend weeks every year preparing, rehearsing, and delivering sessions in San Francisco, ask them to spend a reasonable percentage of the year consulting with and assisting in the development of long-term interactive, iteratively improved video documentation. Start with the last 3 years of WWDC talks on a given subject and condense it down to concise summary of the most pertinent instruction, tips, and demos. It would be ridiculous for Apple to maintain separate text documents for each year, and for developers to be told “Oh, that was addressed in 2011′s NSTextView documentation, go back and look it up.” Yet that’s what developers are forced to do when trying to extract gems of knowledge from past WWDC sessions. (Cough, it’s regrettably true that Apple’s “Release Notes” sometimes serve as a similar kind of decentralized documentation authority).

And what about the community incentive for developers? Isn’t it important to have an opportunity to meet with and catch up with developers from around the world? Yes, it is important, or I should say it would be if it actually worked any longer at WWDC. The very small fraction of developers who are admitted, combined with the unpredictability of whether you or your friends will make the cut, make it essentially useless as an annual catching-up venue. Look to smaller conferences for this ambition. While some of them are similarly challenged in meeting demand for attendance, many are more fine-tuned both in teaching style and in topic choice. They each have a special feel of their own, which naturally attracts a repeat audience whose members are more likely to find fellowship with one another than in the comparatively giant, rotating petri dish of this year’s random WWDC ticket winners.

I have loved the times I’ve attended WWDC, and I may yet end up enjoying it again, but its time has past. It’s time to move on. In 1983, 1993, and 2003 it was the right tool for the job because it largely fulfilled the objectives for both Apple and developers. In 2013 it’s a strangely exclusive, rotating club with arbitrary membership rules, and increasingly dubious advantages. It’s a source of annual stress and uncertainty for would-be attendees, and has just delivered a whopping blow to thousands of developers who didn’t make the cut for this year’s show.

I would miss many things about WWDC, but the things I would miss could easily be offset by superior, scalable solutions. And I would be happy to leave behind the increasing number of obnoxious aspects of the yearly ritual. It’s time for something better. It’s time to end WWDC.