Nothing Insightful

Mobile Safari Wishlist — What Devs Want

This years WWDC in June will hopefully bring about a new iPhone and iOS 6. But in reality, pundits are calling an October release far more likely. While Apple has been slowly closing the gap between mobile Safari and native application development, there is still a host of issues holding mobile Safari back. What a lot of it boils down to is granting software access to hardware components. Stabilising the home screen app experience. Ironing out inconsistencies.

So what do front end developers desperately want from the next version of Mobile Safari?

Home Screen App back to Safari

Fantastic! With a handfull of <meta> tags, you can turn your web page into standalone, chrome-less home screen app! But the second you click a non-ajax link (or external links) - you’ll be thrown straight back into Safari. While it’s not really a problem if you’re writing single page, MVC or AJAX centric applications from scratch; try serving an existing page-based layout to run as an app and you’re gonna have a bad time.

Workaround: A StackOverflow question along the same lines features a host of pre and post iOS5 solutions hacks.

getUserMedia/Camera/File Access

It’s currently impossible to take new (or load existing) photos without the use of some intermediary like PhoneGap or Titanium. More frustrating yet is the inability to upload anything in mobile Safari at all. I’m sure part of this stems from iOS not having an exposed file system, but it’s been notably missing for a long time now.

The new and immature getUserMedia functionality at least gives desktop websites the ability to access webcams. Because it’s only available in Opera nightly builds and the correctly flagged Chrome, Addy Osmani wrote a polyfill that no doubt uses Flash to patch support. That doesn’t do much for us on iOS.

Workaround: PhoneGap etc.

Device Orientation Lock

Speaking of PhoneGap founder Dave Johnson, I was lucky enough to catch his talk at the recent WDC12 conference in Melbourne. A spec is underway for a device orientation lock, resulting in layouts that are explicitly portrait or landscape only. This would help further bridge the gap between web and native by allowing apps to only work in one mode.

Workaround: Currently it can only be hacked together with CSS transforms triggered via media queries on device orientation changes. Undesirable.

WebGL

It’s possible to build some pretty amazing stuff in WebGL using wrappers such as Mr Doob’s mind-blowing three.js. His work on three.js has made it incredibly easy to get started building 3D scenes without having to write your own texture and lighting plugins.

Unfortunately iOS does not officially support WebGL, although it can be enabled on jailbroken devices with this recently released app. It relies on the fact that WebGL is actually installed, but not enabled for Safari.

WebGL was added to iOS 4.2 for iAds but Apple has not yet turned it on for general browsing and the like. Enabling WebGL for single applications has been done in the past but this is the first tweak that I know of that applies across the whole OS, including Safari.

navigator.connection.type, navigator.battery etc.

It seems that all the cool stuff seems to exist on the navigator object. In iOS we were already sourcing geolocation and connectivity via the navigator object, but there’s heaps more coming in the form of specs and proposals.

Android web browsers lead the way in exposing a navigator property that reveals the type/quality of the connection the device is receiving. It’s therefore possible to determine if the device is EDGE, 3G, WiFi or I guess LTE connected. Safari on iOS is only capable of differentiating between online and offline modes, exposed by the navigator.onLine property. You can also bind events that listen for the ononline and onoffline events too.

In his talk on AppCache manifests, John Allsop touched on the user experience methodology of listening for the online/offline events and enabling/disabling submit buttons respectively. Why not take this one step further by serving tailored resources and displaying spinners relative to the network speed? iOS already does it at the system level, so why can’t your app? 

Sidenote: I only stumbled across this disparity because I was trying to implement the above for a UX Lab experiment.

Double sidenote: PhoneGap founder Dave Johnson mentioned that, funnily enough, a call to navigator.battery actually decreases battery life.

Proper Resume and Suspend 

Home screen apps always start from scratch when opened.

Even if they are reopened via multitasking.

Seriously.

Workaround: Preserve the state with localStorage? I guess?

Non-binary Device Zoom 

Setting the acceptable zoom levels in the viewport meta tag is quite final. When building a native-ish application, it’s generally advised to set the zoom and min/max values to 1.0. so users don’t accidentally scroll “native” elements. But doing so completely removes the user’s ability to resize images and resources displayed within the app. Think a mobile Safari Facebook where you can’t zoom any of your friends photos.

Workaround: Hilariously bad. -webkit-scale styles bound to events.

Did I miss something? Found a factual error? Let me know in the comments.