iPad Pro

For several months now rumours have spread that a new type of iPad will be released this year  - the iPad Pro. Variously sized at 12 or 13 inches, compared to the iPad Air's 10 inches, it would extend the iPad lineup further into larger dimensions. 

All the rumours have focused on size, but Apple integrates both hardware, software and services, and to me the really interesting areas are the latter. What software and services should a 'Pro' device come with?

Clearly Apple could tailor existing iOS apps such as the iWork and iLife suites to larger screen sizes. But other apps could be ported from MacOS too - most notably, software development tools such as XCode or a sandboxed, stripped back Terminal with tools for scripting apps. After all developers are one of the largest groups of 'Pros'. I'm not suggesting that Apple will open up root permissions directly to the iPad - instead each app is likely to be a containerized and perhaps only have access to other data via iCloud. 

iCloud itself could play a much larger role in a Pro device. It would enable each app to access a common document store, synced from iCloud. That enables a text document, image or video saved in one app to be opened up again in another one. 

iOS itself could see some changes. A 13 inch device has 70% more screen space than the iPad Air - so could we see a window manager, enabling apps to be worked side by side? Lack of tiling apps has to be one of the major outstanding barriers to productivity on iOS. One way to do this might be to require applications to work in both full screen and iPad mini sizes. 

An iPad Pro with the features above would be a great tool for professional use and a massive competitor to traditional PCs. It would also open up App Store to a new market and new possibilities. Much worthier of the Pro label than just a bigger iPad Air. 

Purchasing in the browser

One of the real benefits of App Stores versus the web is that purchases are so much easier - all you have to do is click on a link (and type your password to validate). Contrast that with the web, where every site has a detailed form to fill out - and sometimes you have to fill it out all over again, if "Verified by Visa" has anything to do with it.

Would it be possible to streamline procurement on the web? I think it could, using a browser-based "account store":

• Browser stores account details and exposes API for giving them to web page
• When web page calls API, the user is asked for confirmation (and can select which account to use). E.g. "This site wants to know your account details for a purchase - give them? If so, which account? Type your password to confirm"
• Account details are sent to page in standard format and used to automatically fill out form

This approach is simple and would work easily with existing sites, automatically populating all the fields. What's more, it allows the browser to help the user out - for example, listing all sites that have been granted access to their account details.

Unfortunately, once account details have been given out, it's difficult to control what the site does with it - they could be passed on to a bad guy, whether intentionally or not.

Here's a better approach:

• Banks could generate a new unique account number with each purchase. This account number would only work once and also has a brief expiry time, e.g. 1 hour.
• When a site requests your account details, the browser automatically requests your bank for a new account number, which is then given to the vendor. The vendor cannot then re-use the details or leak them to anyone else.

Mobile operating systems

We’ve gone from mobile operating systems not mattering, to everyone wanting one of their own: Google – Android; Samsung – Bada; Microsoft – Windows Phone; Nokia – Symbian, Meego; Intel – Meego; HP / Palm – WebOS; Apple – iOS. Compare that with the number of desktop operating systems!

This is a gold rush into the new markets opened up by the iPhone. There are two reasons to have your own mobile OS:

• Differentiation from other manufacturers – providing a unique interface and features to go with your hardware
• App Stores – make money by establishing your own App Store, selling apps along with the phones

So what happens next? Obviously, consolidation. In fact this is already happening in some areas – for example, Linux and Webkit are the foudation of many of the above operating systems.

Manufacturers will always have a need for software differentiation; they’ve learnt this through years of having to using Windows. But I don’t think they can all have App Stores with different development environments. Developers will simply not learn more than two or three.

The most obvious way to overcome this problem is to make the development platform be web standards (HTML, JS and CSS), which developers already know. This tactic is likely to be deployed by the weaker platforms, both to gain a foot up and also to undermine their more successful rivals with a common standard. It’s already been pursued by Palm with WebOS, and now Nokia are also using it with Symbian. I would expect only two or three development environments to survive that are not primarily focused on web standards: Apple’s iOS, Google’s Android (ironically, given that companies’ supposed focus on HTML5), and maybe one more.

This is likely to lead to even faster development of browser engines in the next couple of years, as mobile investment pours in. The net effect will be that the browser becomes as powerful as any native app – and, ironically, app stores will simply become websites that cost money.

One more prediction – Firefox on Mobile will be surprisingly successful. It’s had a very slow start; in fact it’s been written off in favour of webkit by almost everyone. What’s more, it will only be available on Android and Meego for the next year or two. But it’s got one major advantage: it’s not just a browser engine, it’s the chrome as well.

The current state of mobile browser chrome is terrible – features that are standard on the desktop (such as automatically remembering passwords, or auto-completing the address bar as you type based on browser history, or blocking adverts, or allowing add-ons) are completely missing on mobile, even though they should be even more important in that environment to help manage limited screen size. So I expect Firefox to take advantage of other’s complacency and inexperience and make a real impression, just as it did initially against Internet Explorer. This will likely happen over a period of two or more years as native browsers lag, then finally notice they must invest to catch up.

In a few years, then, the mobile market will have evolved substantially. Common standards based on the web will unite the weaker players against the top two or three platforms. App stores will become more like websites that cost money. And, after a hiatus, browser design will re-establish it’s importance.