It is with great sadness that I find myself penning the hardest news post I’ve ever needed to write here at AnandTech. After over 27 years of covering the wide – and wild – word of computing hardware, today is AnandTech’s final day of publication.

For better or worse, we’ve reached the end of a long journey – one that started with a review of an AMD processor, and has ended with the review of an AMD processor. It’s fittingly poetic, but it is also a testament to the fact that we’ve spent the last 27 years doing what we love, covering the chips that are the lifeblood of the computing industry.

A lot of things have changed in the last quarter-century – in 1997 NVIDIA had yet to even coin the term “GPU” – and we’ve been fortunate to watch the world of hardware continue to evolve over the time period. We’ve gone from boxy desktop computers and laptops that today we’d charitably classify as portable desktops, to pocket computers where even the cheapest budget device puts the fastest PC of 1997 to shame.

The years have also brought some monumental changes to the world of publishing. AnandTech was hardly the first hardware enthusiast website, nor will we be the last. But we were fortunate to thrive in the past couple of decades, when so many of our peers did not, thanks to a combination of hard work, strategic investments in people and products, even more hard work, and the support of our many friends, colleagues, and readers.

Still, few things last forever, and the market for written tech journalism is not what it once was – nor will it ever be again. So, the time has come for AnandTech to wrap up its work, and let the next generation of tech journalists take their place within the zeitgeist.

It has been my immense privilege to write for AnandTech for the past 19 years – and to manage it as its editor-in-chief for the past decade. And while I carry more than a bit of remorse in being AnandTech’s final boss, I can at least take pride in everything we’ve accomplished over the years, whether it’s lauding some legendary products, writing technology primers that still remain relevant today, or watching new stars rise in expected places. There is still more that I had wanted AnandTech to do, but after 21,500 articles, this was a good start.

And while the AnandTech staff is riding off into the sunset, I am happy to report that the site itself won’t be going anywhere for a while. Our publisher, Future PLC, will be keeping the AnandTech website and its many articles live indefinitely. So that all of the content we’ve created over the years remains accessible and citable. Even without new articles to add to the collection, I expect that many of the things we’ve written over the past couple of decades will remain relevant for years to come – and remain accessible just as long.

The AnandTech Forums will also continue to be operated by Future’s community team and our dedicated troop of moderators. With forum threads going back to 1999 (and some active members just as long), the forums have a history almost as long and as storied as AnandTech itself (wounded monitor children, anyone?). So even when AnandTech is no longer publishing articles, we’ll still have a place for everyone to talk about the latest in technology – and have those discussions last longer than 48 hours.

Finally, for everyone who still needs their technical writing fix, our formidable opposition of the last 27 years and fellow Future brand, Tom’s Hardware, is continuing to cover the world of technology. There are a couple of familiar AnandTech faces already over there providing their accumulated expertise, and the site will continue doing its best to provide a written take on technology news.

So Many Thank Yous

As I look back on everything AnandTech has accomplished over the past 27 years, there are more than a few people, groups, and companies that I would like to thank on behalf of both myself and AnandTech as a whole.

First and foremost, I cannot thank enough all the editors who have worked for AnandTech over the years. There are far more of you than I can ever name, but AnandTech’s editors have been the lifeblood of the site, bringing over their expertise and passion to craft the kind of deep, investigative articles that AnandTech is best known for. These are the finest people I’ve ever had the opportunity to work with, and it shouldn’t come as any surprise that these people have become even bigger successes in their respective fields. Whether it’s hardware and software development, consulting and business analysis, or even launching rockets into space, they’ve all been rock stars whom I’ve been fortunate to work with over the past couple of decades.

Ian Cutress, Anton Shilov, and Gavin Bonshor at Computex 2019

And a special shout out to the final class of AnandTech editors, who have been with us until the end, providing the final articles that grace this site. Gavin Bonshor, Ganesh TS, E. Fylladitakis, and Anton Shilov have all gone above and beyond to meet impossible deadlines and go half-way around the world to report on the latest in technology.

Of course, none of this would have been possible without the man himself, Anand Lal Shimpi, who started this site out of his bedroom 27 years ago. While Anand retired from the world of tech journalism a decade ago, the standard he set for quality and the lessons he taught all of us have continued to resonate within AnandTech to this very day. And while it would be tautological to say that there would be no AnandTech without Anand, it’s none the less true – the mark on the tech publishing industry that we’ve been able to make all started with him.

MWC 2014: Ian Cutress, Anand Lal Shimpi, Joshua Ho

I also want to thank the many, many hardware and software companies we’ve worked with over the years. More than just providing us review samples and technical support, we’ve been given unique access to some of the greatest engineers in the industry. People who have built some of the most complex chips ever made, and casually forgotten more about the subject than we as tech journalists will ever know. So being able to ask those minds stupid questions, and seeing the gears turn in their heads as they explain their ideas, innovations, and thought processes has been nothing short of an incredible learning experience. We haven’t always (or even often) seen eye-to-eye on matters with all of the companies we've covered, but as the last 27 years have shown, sharing the amazing advancements behind the latest technologies has benefited everyone, consumers and companies alike.

Thank yous are also due to AnandTech’s publishers over the years – Future PLC, and Purch before them. AnandTech’s publishers have given us an incredible degree of latitude to do things the AnandTech way, even when it meant taking big risks or not following the latest trend.  A more cynical and controlling publisher could have undoubtedly found ways to make more money from the AnandTech website, but the resulting content would not have been AnandTech. We’ve enjoyed complete editorial freedom up to our final day, and that’s not something so many other websites have had the luxury to experience. And for that I am thankful.

CES 2016: Ian Cutress, Ganesh TS, Joshua Ho, Brett Howse, Brandon Chester, Billy Tallis

Finally, I cannot thank our many readers enough. Whether you’ve been following AnandTech since 1997 or you’ve just recently discovered us, everything we’ve published here we’ve done for you. To show you what amazing things were going on in the world of technology, the radical innovations driving the next generation of products, or a sober review that reminds us all that there’s (almost) no such thing as bad products, just bad pricing. Our readers have kept us on our toes, pushing us to do better, and holding us responsible when we’ve strayed from our responsibilities.

Ultimately, a website is only as influential as its readers, otherwise we would be screaming into the void that is the Internet. For all the credit we can claim as writers, all of that pales in comparison to our readers who have enjoyed our content, referenced it, and shared it with the world. So from the bottom of my heart, thank you for sticking with us for the past 27 years.

Continuing the Fight Against the Cable TV-ification of the Web

Finally, I’d like to end this piece with a comment on the Cable TV-ification of the web. A core belief that Anand and I have held dear for years, and is still on our About page to this day, is AnandTech’s rebuke of sensationalism, link baiting, and the path to shallow 10-o'clock-news reporting. It has been our mission over the past 27 years to inform and educate our readers by providing high-quality content – and while we’re no longer going to be able to fulfill that role, the need for quality, in-depth reporting has not changed. If anything, the need has increased as social media and changing advertising landscapes have made shallow, sensationalistic reporting all the more lucrative.

Speaking of TV: Anand Hosting The AGN Hardware Show (June 1998)

For all the tech journalists out there right now – or tech journalists to be – I implore you to remain true to yourself, and to your readers' needs. In-depth reporting isn’t always as sexy or as exciting as other avenues, but now, more than ever, it’s necessary to counter sensationalism and cynicism with high-quality reporting and testing that is used to support thoughtful conclusions. To quote Anand: “I don't believe the web needs to be academic reporting or sensationalist garbage - as long as there's a balance, I'm happy.”

Signing Off One Last Time

Wrapping things up, it has been my privilege over the last 19 years to write for one of the most impactful tech news websites that has ever existed. And while I’m heartbroken that we’re at the end of AnandTech’s 27-year journey, I can take solace in everything we’ve been able to accomplish over the years. All of which has been made possible thanks to our industry partners and our awesome readers.

On a personal note, this has been my dream job; to say I’ve been fortunate would be an understatement. And while I’ll no longer be the editor-in-chief of AnandTech, I’m far from being done with technology as a whole. I’ll still be around on Twitter/X, and we’ll see where my own journey takes me next.

Gallery: AnandTech Over The Years

To everyone who has followed AnandTech over the years, fans, foes, readers, competitors, academics, engineers, and just the technologically curious who want to learn a bit more about their favorite hardware, thank you for all of your patronage over the years. We could not have accomplished this without your support.

-Thanks,
Ryan Smith

After upgrading to OS X 10.10.x, I noticed that pushing the volume buttons didn’t produce a noise like they had before. I liked having that feedback sound, as it gave me an idea of how loud my volume was.

After some research, here’s how to get the volume button noise back:

1. Open System Preferences.

2. Go to the Sound preference pane

3. Click on the Sound Effects tab.

4. Check the Play feedback when volume is changed checkbox.

To test, tap a volume button on your keyboard and you should once again get a feedback noise.

Two weeks ago, The Omni Group announced an app called OmniKeyMaster aimed at letting customers migrate from Mac App Store licenses to standalone ones that supported upgrade pricing:

OmniKeyMaster is a simple app that finds App Store copies of Omni apps installed on your Mac, then generates equivalent licenses from our store – for free. This gives Mac App Store customers access to discounted pricing when upgrading from the Standard edition to Professional, or when upgrading from one major version to the next. Another benefit: since they don’t have to wait in an approval queue, our direct releases sometimes get earlier access to new features and bug fixes. OmniKeyMaster lets App Store customers access those builds, as well.

Today, The Omni Group had to remove the app, presumably after pressure from Apple:

My apologies: I’m afraid we will not be able to offer upgrade pricing to our Mac App Store customers after all. So long as we continue to sell our apps through the Mac App Store, we are not allowed to distribute updates through other channels to apps which were purchased from the App Store.

This is strange, because a number of similar tools (made by other independent developers) already exist on the Internet and they have been letting customers generate standalone licenses for several months. Perhaps Apple just didn't like that a name such as The Omni Group had found a way to make the process so easy? Was The Omni Group's tool built in such a way that it broke some Apple rules? Did The Omni Group think OmniKeyMaster would be okay because other solutions existed? Is Apple going after similar solutions as well?

Stephen Hackett argues that The Omni Group should have foreseen this, but that the Mac App Store is, overall, good for most third-party developers:

While The Omni Group is probably big enough to walk away from the Mac App Store, a lot of developers are enjoying a level of success in the Store that they couldn’t enjoy without it. Apple shouldn’t use that to strong-arm developers from trying to workaround the system. That puts both Apple and third-party developers in a pretty crappy spot.

I see both points. The Mac App Store is good for some developers and end customers, but it could be improved in so many ways. Is it a surprise that, after an initial rush to sell apps on the Mac App Store, more and more developers of apps above the $2.99 threshold (read: not games and utilities) have gone back to selling both App Store and “regular” versions?

The Omni Group wanted to do the right thing and offer upgrade pricing for customers who bought an app on the App Store. Apple doesn't like the idea and leads by example with a new version of Logic Pro sold as a new app, without upgrade pricing. If my assumption is right and Apple is behind OmniKeyMaster's premature demise – how could they not be? – that's really sad.

Apple shouldn't put pressure on developers who tried the Mac App Store model and didn't like some parts of it. Instead of burying their head in the sand and pretending that developers who want upgrade pricing don't exist, they should work with those developers to resolve their issues. The App Store launched in January 2011 and these aren't new problems. If Apple doesn't really care about upgrade pricing, it seems curious – to me, utterly wrong – that they're going after a clever tool like OmniKeyMaster.

And if you think that it's in Apple's right to shut down OmniKeyMaster¹, then I guess it won't be a surprise if more developers will keep offering standalone versions of their apps in the future, possibly even eschewing the Mac App Store if necessary.

Most people don't have time to care about these issues, because they like the convenience of the Mac App Store. But I do, and therefore, whenever possible, I try to buy Mac apps from a developer's website. It's worth the extra effort.

Ron Amadeo

Android 4.3 was released to Nexus devices a little over a month ago, but, as is usual with Android updates, it's taking much longer to roll out the general public. Right now, a little over six percent of Android users have the latest version. And if you pay attention to the various Android forums out there, you may have noticed something: no one cares.

4.3's headline features are a new camera UI, restricted user profiles, and support for new versions of Bluetooth and OpenGL ES. Other than the camera, these are all extremely dull, low-level enhancements. It's not that Google is out of ideas, or the Android team is slowing down. Google has purposefully made every effort to make Android OS updates as boring as possible.

Why make boring updates? Because getting Samsung and the other OEMs to actually update their devices to the latest version of Android is extremely difficult. By the time the OEMs get the new version, port their skins over, ship a build to carriers, and the carriers finally push out the OTA update, many months pass. If the device isn't popular enough, this process doesn't happen at all. Updating a phone is a massive project involving several companies, none of which seem to be very committed to the process or in much of a hurry to get it done.

Since it's really hard to push out an Android update, Google's solution is to sidestep the process completely. The company stopped putting all the good stuff in Android updates. It's not that good stuff isn't coming out at all, the exciting features are just not being included as part of a big Android release.

This year's Google I/O was a show of force for this new delivery concept. No new Android version was at the show, yet Google announced Google Hangouts, Google Play Games, cloud saving of game and app data, a complete redesign of Google Play Music and Google Maps, a new version of the Google Maps API, and new location and activity recognition APIs. Post I/O, we've seen seemingly OS-level features added like the Android Device Manager, a remote wipe and device tracking system, without needing to touch the base OS.

It's such a simple idea: Android updates roll out too slowly, so start releasing all the cool stuff separately. The hard part is making it actually work. But the first reason this is now possible is a little app that has finally come of age: "Google Play Services."

Google Play Services can do whatever it wants.

Calling Play Services an "app" doesn't really tell the whole story. For starters, it has an insane amount of permissions. It's basically a system-level process, and if the above list isn't enough for whatever it needs to do next, it can actually give itself more permissions without the user's consent. Play Services constantly runs in the background of every Android phone, and nearly every Google app relies on it to function. It's updatable, but it doesn't update through the Play Store like every other app. It has its own silent, automatic update mechanism that the user has no control over. In fact, most of the time the user never even knows an update has happened. The reason for the complete and absolute power this app has is simple: Google Play Services is Google's new platform.

What happens when you try living without Google Play Services.

Andrew Cunningham looked at this shortly after Google I/O, but now things are truly crystallizing. Google's strategy is clear. Play Services has system-level powers, but it's updatable. It's part of the Google apps package, so it's not open source. OEMs are not allowed to modify it, making it completely under Google's control. Play Services basically acts as a shim between the normal apps and the installed Android OS. Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break.

Play Services supports over the entire Android install base.

The reason for all the permissions and sneaky updates is best illustrated in that chart above. While the latest version of Android is on six percent of devices, Play Services rolls out to everyone in a week or two and works all the way back to Android 2.2. That means any phone that is three years old or newer has the latest version of Google Play Services. According to Google's current Android statistics, that's 98.7 percent of active devices. So at Google I/O, when Google announced their slew of new APIs, nearly every Android device was immediately compatible in a week. Play Services is a direct line from Google to the core of your phone, and, really, no one outside of Google is quite sure of just how powerful it can get.

Google Play Services takes care of lower-level APIs and background services, and the other part of Google's fragmentation takedown plan involves the Play Store. Google has been on a multi-year mission to decouple just about every non-system app from the OS for easy updating on the Play Store. Take a quick look at Google's Play Store account and you'll see a huge list of apps, many of which ship by default in Android. Gmail, Maps, Search, Chrome, Calendar, the keyboard, YouTube, and even the Play Store itself are all separately updatable.

The above list is a good representation of the current update situation in Android. Nearly everything that can be moved out of the main OS has been. The only features left that would require an OS update are things like hardware support, Application Frameworks APIs, and Apps that require a certain level of security or access (like the lock screen, Phone, and Settings apps).

This is how you beat software fragmentation. When you can update just about anything without having to push out a new Android version, you have fewer and fewer reasons to bother calling up Samsung and begging them to work on a new update. When the new version of Android brings nothing other than low-level future-proofing, users stop caring about the update.

This gets even more interesting when you consider the implications for future versions of Android. What will the next version of Android have? Well, what is left for it to have? Android is now on more of a steady, continual improvement track than an all-at-once opening of the floodgates like we last saw with Android 4.1. It seems like Google has been slowly moving down this path for some time; the last three releases have all kept the name "Jelly Bean." Huge, monolithic Android OS updates are probably over—"extinct" may be a more appropriate term.

Not having to package everything into a major OS update means Google can get features out to more users much faster and more frequently than before. Android feature releases can now work just like Google's Web app updates: silent, continual improvement that happens in the background. Your device is constantly getting better without your having to do anything or wait for a third party, and developers can take advantage of new APIs without having to wait for the install base to catch up. This should all lead to a more unified, less fragmented, healthier Android ecosystem.

Read Comments

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, 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 bookmarklet 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.