Blog

A Web Developer’s Wishlist for iOS 5

With Apple’s Worldwide Developer Conference 2011 just a few weeks away, we thought it would be a good time to think about what they might announce at the sold-out event. Like many, we’re assuming that the company will be making some significant improvements to its iOS platform, and we will watch excitedly for things like wireless sync, cloud-based music, the mythical near-field-communication (NFC), and the like.

Given the Sencha commitment to the success of the web, we thought we also should take a special look at what we’d like to see added to the iPhone’s and iPad’s web browser in coming years.

Mobile Safari was a seminal web browser when it was launched as a flagship application of the first generation iPhone an astonishing 4 years ago. It opened an industry’s eyes to what was possible on mobile devices: a silky user interface, smooth viewport scaling, touch gestures, and hardware graphics acceleration that is still barely matched today by other platforms.

“Here are eight things we would love to see announced for the iOS browser at Apple’s WWDC keynote in June…”

In recent years, iPhone and iPad developers have generally focussed on creating native apps, and have often forgotten the potential of the platform’s web browser. But Apple has quietly continued to increment its capabilities — most recently accelerating its JavaScript engine significantly in iOS 4.3, making compelling web apps as viable as ever.

In 2011, we think that mobile web technology is firmly back in play, and an area of renewed attention for many developers. We think Apple has a great opportunity to build again on the platform’s original prospect of first-class web applications.

With that in mind, here are eight things we would love to see announced for the iOS browser at the famous keynote in June:

Camera Access (and more device APIs)

The mobile web becomes a very exciting place when browsers provide access to underlying device capabilities. Yes, the standardisation process is taking time, and yes, many should require users’ approval — but device APIs have a disproportionately positive effect on making the web a first-class medium, and web apps ever more indistinguishable from their native brethren. Accelerometer support in iOS 4.2 was a glimpse of the future, but we relish the possibilities that media capture, messaging, calendar and contact access might bring. Some sort of File API would be excellent, but even <input capture="camera" /> would open up huge potential for new and novel applications.

WebGL

The current iOS DOMAPI shows a glimpse of support for more powerful graphics, with the presence of a mysterious WebGLRenderingContext class, so we think there’s a good chance this is coming. WebGL would suddenly provide JavaScript developers with an opportunity to create rich, graphic-heavy games, simulations, and other applications. If nothing else, we’re looking forward to being able to run our PhiloGL demos in the palm of our hand. As it happens, <canvas> is already used by a number of web-based games for iOS, so we’d be encouraged to see that element’s performance being a focus as a whole.

CSS Improvements

There is a cottage industry of JavaScript hacks to overcome the lack of a few critical CSS properties — in particular position:fixed and overflow:scroll. Sencha Touch makes it easy to develop apps with fixed tool bars and inner scrolling, but having native browser support for these properties would be useful, especially if done in a way which plays well with viewport and orientation changes. And is grid layout a possibility for building applications that adapt to different screen sizes?

Viewport Improvements

Conversely, some apps (particularly games) are often designed to be used only in one orientation or another. Unlike native apps, there is currently no way for an iOS web application to prevent viewport rotation, and the ability to enforce this would be a welcome addition to the web runtime. Also, viewport settings currently have to be prescribed in markup, and we’d like to see them overridden in vendor-specific CSS, where they probably always belonged.

Hybrid App Support

We love the concept of hybrid apps: those built with web technology and still distributable via the App Store through the use of a native wrapper or bundling tool. But at some point we hope to see this concept supported by Apple themselves, perhaps with tighter integration of web technologies into the Xcode developer environment, and of course in conjunction with more native JavaScript APIs.

We’d also like to see the ‘Add To Home Screen’ concept given more prominence, perhaps making it easier for HTTP-based apps to indicate or mandate that they require a full-screen, native-like runtime context. Oh, and we hope to see the performance benefits of iOS 4.3’s Nitro JavaScript engine coming to home screen web apps too!

Web Workers & Notifications

We’re not exactly sure if our iPhone needs a prime number generator, but it would genuinely be fantastic to be able to have parts of a mobile web application running independently of the user-interface, or in a way that continues even when the user switches away from the browser. Of course there needs to be consideration for battery consumption, but being able to poll and compute in the background would allow web apps to become ever more pervasive. Imagine web apps that can generate system notifications when messages or social interactions arrive, that can hook into enterprise workflow systems, that detect asynchronous changes to the device’s environment, or that even just augment a device’s calendar or alarm clock functionality.

Native Drag-and-Drop

Enough said: when your users have a beautiful touch-based device, it feels like they should be able to move things around on it. Of course Sencha Touch provides a drag and drop library in the meantime, but we would like to see a standard implementation in the browser itself.

Browser UI Improvements

After all this talk of application runtime support, it seems parochial to talk about the browser’s user interface itself. But why not? We’d like to be able to open more than 8 tabs on the iPhone, for example. It would be nice not to have them automatically refresh when re-opened, particularly when the device knows it’s offline. And how about a unified address and search bar? More important than all of this would be more a more powerful debugging environment for the browser: perhaps with a remote web inspector as part of OS X Safari or Xcode.

So that’s our wishlist. Yes, we know a few of these are still going through the standardization process — but that process goes hand-in-hand with browser innovation, and Apple does a great job of pushing this particular envelope. The potential of HTML5, CSS3 and JavaScript — especially with frameworks like Sencha Touch — means that using web technologies for rich user experiences is now as viable as ever. We believe that the iOS browser will show the way, and are looking forward to hearing all about it next month.

What improvements would you like to see in the iOS browser?

Written by James Pearce
James Pearce heads developer relations at Sencha. He is a technologist, writer, developer and practitioner, who has been working with the mobile web for over a decade. Previously he was the CTO at dotMobi and has a background in mobile startups, telecoms infrastructure and management consultancy. James is the creator of tinySrc, the WordPress Mobile Pack, WhitherApps, modernizr-server and confess.js, and has written books on mobile web development for both Wiley and Wrox.Follow James on Twitter

Share this post:

François

My most wanted “feature”: more cache, more cache, more cache… this is the most painfull thing for webapps: reloading when re-focused after browsing other websites or apps. A basic cache management from 0 to up to (why not) 1Gb!!??

Mark Kawakami

Kenneth Christiansen

I would like support for the Fullscreen spec. I also think that the place it makes most sense to add the orientation lock would be to that spec, as it is quite useful for making real apps. Orientation can be implemented in the webapp itself using the DeviceOrientation/Motion spec.

Personally I think the fullscreen spec should have a way to enter a locked fullscreen state, like

Giulio Roggero

Eric

Not so much a developer wish, but I personally can’t stand how notifications disappear after the unlock swipe. It’s such an automatic thing to hit home button and swipe, that I often miss notifications. Keep them in screen until the user acknowledges the notification.

SmaMan

As much as I know this won’t ever happen… I want Flash. Sure, HTML5 is the next big thing, but even its own developers admit that it won’t be fully implemented for another decade or so. Until then, Apple needs to embrace Flash. It’s not going away anytime soon, and it’s the main point its competitors are embracing. Listen the next time you hear an ad for a non-Apple smartphone.

Add that and the ability to download and the iPhone will be completely irresistible.

James Pearce
Sencha Employee

James Pearce
Sencha Employee

We appreciate that native apps have been a lynchpin of third party development and a huge contribution to the success of the platform.

But we’re thinking ahead here - the wind is changing - and bullet 5 could easily be a way in which web apps (and JavaScript) become a first-class environment on the platform without disrupting that success.

a) the languages and technology used to develop apps, b) the way in which they are distributed, and c) the way in which they make money - these can in theory be orthogonal vectors.

BrianMB

Pierre Tessier

I second the “better” hybrid app support. iOS 4.3 Nitro engine made Safari awesome, but Hybrid apps still suffer. I’d like to see that engine brought into native apps that implement UIWebView to make them even slicker.

From Apple’s perspective, if the App machine is what they want, bringing in tools into XCode to quickly wrap an HTML app with a native chrome interface to be hosted and sold on the App Store makes everyone happy. The developers can get revenue (shared with Apple) and can minimize their development efforts for other platforms, and users get the “native” apps they think they want.

I would also like to see general UI improvements to the Safari interface. Not just a unified address bar, but also tabbed browsing, maybe even hints of what Chrome and Firefox are doing with the desktop and an auto-hide URL bar. This is particularly important for the tablet version of iOS.

Sébastien Blanc

Michael Galpin

By “more native JavaScript APIs” do you mean an actual API between native apps and the JavaScript runtime of UIWebViews? The current state where the only way to communicate between a UIWebView and its host controller is through ridiculous URLs is an absolute embarrassment. If you are interested in building hybrid apps, then I would expect that to be #1, #1a, and #1b on your wish list. I would suggest that they just copy how Android does this, but that would be too easy.

Steffen Hiller

In case Apple, Android & Co don’t step up their game,
plan B could be that you just make a Sencha Touch OS which basically just runs your custom WebKit engine, optimized for Sencha Touch, and which runs on every mobile device.
A Sencha Touch mobile browser (which would be easier) wouldn’t make much sense since the App Stores just reject it.

Silvio Porcellana

I think it all boils down to this: does Apple believe it can make any money from web/hybrid apps? If they embrace your vision, James, then we are in for some nice surprises (I’d expect device API to be on top of the list). Otherwise, we will be stuck with what we have for quite a long time (they might announce “great improvements” like tabbed browsing - how’s that going to improve my web app is another story…). And, given that what we have is Sencha Touch, I wouldn’t cry too much.

Ken

BrianMB

@Hector - Apple hasn’t really pushed the web platform since iOS 2. Since then, they’ve merely been updating to the latest build of Webkit. It’s little more than lip service, doesn’t even show an interest in a native HTML5 SDK.

We will probably always be second-class citizens on iOS. I hope Android can come around and offer an SDK in 2012, but I acknowledge that this is a pipe dream.

Silvio Porcellana

@BrianMB Stil, this allowed companies like Sencha to build awesome stuff like Touch, and us developers to create nearly native “web apps” that can work across a huge array of devices. Pretty cool for “second class” citizens, uh?

Tomas Andersson

malsmith

Seems like a date format <input> tag was left out completely. Likewise selector/thumbwheel UI is missing (which could cover the date data entry case as well). Actually this is a pretty glaring omission without any good work-arounds.

James Pearce

@BrianMB - rumor is that WebGL will be available for iAds. Hopefully in the browser too, but we’ll see if the tealeaves come up trumps. iOS5 beta 2 was a step forward too as well… gradually our list is getting little green ticks against it

Alex Morse

Dave Curry

In iOS 3 and 4, if you save a web-page to the home screen so that it runs in fullscreen mode, the browser loses its session every time you switch applications using multi-tasking. Also, if a fullscreen web app opens another document in a Mobile Safari window, the two will not share the session. This means that a very common use case for line-of-business applications, opening a PDF or XLS document generated on the server in a new window, is impractical. The new Safari window won’t have the session and so the server won’t have the user’s authentication which it needs to generate and serve the document securely. To add insult to injury, the original fullscreen application will have lost its session and so the server will redirect to the login screen when the user switches back.

A fullscreen web application is a second-class citizen in a number of other respects (for example, the format-detection META tag is ignored) that have real consequences when you’re trying to create a web application that offers an equivalent user experience to that of a native application.