The new main version of the Apple’s iOS is with us, along with the new iPhone 5 and the iPod Touch fifth generation. As every big change, lot of new stuff is available for HTML5 developers and -as always- no much official information is available.
The new iPhone 5 -along with the iPod Touch 5th generation- has only one big change in terms of web development: screen resolution. These devices have a wide 4″ screen, WDVGA (Wide Double VGA) 640×1136pixels, 326 DPI -Retina Display as Apple called it. These devices have the same width as iPhone 4/4S but 176 more pixels-height on portrait mode.
Usually, if your website/app is optimized for vertical scrolling, you should not have any problem. Same viewport, icons and techniques for iPhone 4/4S should work properly. Remember, when updating the iOS, you are also updating the Web View: that means that all the native web apps -such as PhoneGap/Apache Cordova apps- and pseudo-browsers such as Google Chrome for iOS are also updated. However if your solution is height-dependent, then you may have a problem. Just look at the following example of the Google Maps website on iPhone 4 and iPhone 5. As it is talking the height as a constant, the status bar is not hidden and there is a white bar at the bottom.
Google Maps on different heights on iOS
Be careful if you’ve designed for an specific height as Google Maps. As you can see (right caption is from iPhone 5) there is a white bottom bar and the URL bar can’t be hidden as there is no enough content.
If you are using Responsive Web Design you should not have too much trouble as usually, RWD techniques are using the width and not the height for conditionals.
At the time of this writing there are no iPhone 5 on the street yet. However, as far as every test I could check, there is no way to detect iPhone 5 server-side. The user agent only specifies an iPhone with iOS 6, and the same exact user agent is being used for iPhone 4S with iOS 6 and iPhone 5.
Mozilla/5.0 (iPhone; CPU iPhone OS 6\_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
Therefore, the only way to detect the presence of a 4″ iPhone device is to use JavaScript and/or media queries, client-side. If you need to know server-side, you can plant a cookie from client-side for next load. Remember that these devices have 1136 pixels height, but in terms of CSS pixels (independent resolution pixels) we are talking about 568 pixels-heightas these devices have a pixel ratio of 2.
isPhone4inches =(window.screen.height==568);
Using CSS Media Queries and Responsive Web Design techniques,we can detect the iPhone 5 using:
For Home Screen webapps the problem seems important. I’ve reported the problem while in NDA without any answer from Apple yet.
Basically, when you add a website to the Home Screen that supports apple-mobile-web-app-capable meta tag, your webapp works only in iPhone 3.5″ emulation mode (it’s not taking the whole height) as you can see in the following example from the Financial Times webapp.
Financial Times App on iPhone 5
The letterbox black bars you see here are not a problem in the image. That is how a full-screen webapp is being launched by default on iPhone 5 and the new iPod Touch.
While it’s a good idea to not add more height to a webapp if the OS is not sure about it’s compatibility on a wider screen, as far as I could test, there is no way to define that our webapp is 4″ compatible. I’ve tried as many combinations as I could think about, and if you provide an apple-touch-startup-image of 640×1096, the iPhone 5 takes your splash screen but it’s being resized to 640×920, at least in the Simulator for the GM compilation (almost the final version).
UPDATE 9/20: Solution found, thanks to some guys that were pointing to some solutions I;ve found the trick. As weird as it sounds, you need to forget about the viewport with width=device-width or width=320. If you don’t provide a viewport, it will work properly. The same if you use other properties than width; if you don’t want your viewport to be the default 980px, the way to do it is:
<metaname="viewport"content="initial-scale=1.0">
Even if you use a viewport for an specific size different than 320 letterbox will not be present.
<metaname="viewport"content="width=320.1">
Instead of changing all your viewports right now, the following script will make the trick changing it dynamically:
The startup image has nothing to do with the letterbox as some developers were reporting. Of course, if you want to provide your launch startup image it has to be 640×1096 and you can use media queries to use different images on different devices. Some reports were saying that you need to name the launch image as in native apps “Default-568h@2x.png” but it’s not true. You can name it however you want. The sizes attribute is completely ignored.
You can use media queries to provide different startup images:
If you want to provide an alternative version for low resolution devices then you can use the -webkit-device-pixel-ratio conditional too. If you are wondering why 568px and not 1136px remember that we are using CSS pixels and in these devices the pixel ratio is 2.
The trick is the viewport. Why? I don’t really know. For me, it’s just a bug. But it’s the only solution I’ve found so far.
The other problem is with Home Screen icons that you are already have before buying your new device. iTunes will install the shortcut icon again from your backup and it’s not clear if we are going to have a way to upgrade the compatibility. Even if you change the viewport, if the icon is already installed before the change you will get the letterbox.
iOS 6 is available as a free update for every iOS 5 device but not the iPad first generation so we will see this version browsing the web really soon and the iPad market is being fragmented for the first time. The following findings are useful for all iOS devices that are talking the iOS 6 upgrade. As always -and unfortunately- Apple is giving us just partial and incomplete updates on what’s new on Safari and I -as always- enter the hard work of digging into the DOM and other tricks to find new compatibility.
Finally! Safari for iOS 6 supports a file upload input type and with HTML Media Capture partial support.
A simple file upload as the following, will ask the user for a file, from the Camera or Gallery as you can see in the figure. I really like how Safari is showing you screenshots instead of a temporary filename after selecting your image.
<label>Single file</label> <inputtype="file">
We can also request multiple files using the HTML5 new boolean attribute. In this case, the user can’t use the camera as a source.
We can access the camera and gallery using file uploads
There is no way to force the camera, as using capture=”camcorder”. However, we can specify if we want to capture images or videos only, using the accept attribute.
There is no support for other kind of files, such as audio, Pages documents or PDFs. There is no support for getUserMedia for live camera streaming.
What you can do with the image or video after selected?
Send it using multipart POST form action (old-fashion upload mechanism)
Use XMLHttpRequest 2 to upload it using AJAX (even with progress support)
Use the File API that is available on iOS 6 that allows JavaScript to read the bytes directly and manipulate the file client side. There is a good example of this API in action on HTML5Rocks.
HTML5 game developers should be happy! Web Audio API appears on a mobile browser for the first time. This API allow us to process and synthesize audio on JavaScript. If you have never played with some low level audio, the API may seems a little weird, but after a while is not so hard to understand. Again, HTML5Rocks has a great article to begin with the Audio API.
Website or native app? If we have both, now we can join efforts and connect our website with our native app. With Smart App Banners, Safari can show a banner when the current website has an associated native app. The banner will show a “INSTALL” button if the user doesn’t have the app installed or a “VIEW” button to open it if installed. We can also send arguments from the web to the native app. The case is to open the native app on the same content that the user were seeing on the web site.
To define a Smart App Banner we need to create a meta tag, with name=”apple-itunes-app”. We first need to go and search for the app we have on iTunes Link Maker and take the app ID from there.
We can provide a string value for arguments using app-argument and if we participate in the iTunes Affiliate program we can also add affiliate-data in the same meta tag.
The banner takes 156 pixels (312 on hi-dpi devices) at the top until the user click on the bottom or on the close button and your website will get the full height for you. It acts like a DOM object at the top of your HTML but it’s not really on the DOM. On iPad -and more on landscape- it seems a little space-wasting.
Smart App Banners in Safari
With Smart App Banners, the browser will automatically invite the user to install or open a native app
During some seconds, the banners shows a “loading” animation while the system is verifying that the app suggested is valid to the current user’s device and App Store. If it’s not valid, the banner hides automatically; for example, it’s an iPad-only app and you are browsing with an iPhone or the app is available only on the german App Store and your account is in US.
CSS 3 Filters a set of image operations (filters) that we can apply using CSS functions, such as grayscale, blur, drop-shadow, brightness and other effects. These functions will be applied before the content is rendered on screen. We can use multiple filters using spaces (similar to transforms).
You can try a nice demo here. A quick example of how it looks like:
iOS 6 start supporting some of the new CSS Image Values standard, including the cross-fade function. With this function, we can apply two images on the same place with different levels of opacity and it can even part of a transition or animation.
Besides the chrome-less home screen meta tag, now the iPhone and iPod Touch (not the iPad) supports a full-screen mode when in landscape. This is perfect for immersive experiences such as games or multimedia apps. There is no way to force full-screen mode and it needs to be launched by the user (last icon on the toolbar). However, we can invite the user to move to landscape first and press on the full-screen icon to activate our app. If we mix this with some touch event handling we can hide the URL bar and provide a good interface until the user escape from the full-screen.
Fullscreen navigation on iPhone and iPod Touch
You will always find two or three overlay buttons at the bottom that your design should be aware of, that’s the back button, the optional forward button and the cancel full-screen.
You can use the onresize event to detect if the user is changing to full-screen while in landscape.
Game developers, again, you are lucky. iOS 6 supports Animation Timing API, also known as requestAnimationFrame, a new way to manage JavaScript-based animations. It’s webkit prefixed, and for a nice demo and more detailed explanation check this post from Paul Irish.
This is not part of any standard group yet. It’s a new image function, called image-set receiving a group or images with conditions to be applied. The only compatible conditions right now seems to be 1x and 2x for low density devices and high density devices. With this new function we don’t need to use media queries to define different images for different resolutions. The working syntax is:
-webkit-image-set(url(low.png) 1x,url(hi.jpg) 2x)
It’s working on CSS, such as a background-image. I couldn’t make it work on the HTML side, for the src attribute on an img element or the new proposed picture element. With this new syntax we can have more clear multi-resolution image definition, as we don’t need to use media queries and background-size values.
Passbook is a new app in iOS that works as a virtual container for all your passes, ticket, discount coupons, loyalty cards and gift cards. As a web developer you may want to serve the user with a discount coupon, a ticket to an event, an e-ticket for your next flight or a loyalty card.
Apple allow websites to deliver this kind of passes from a website without the need of a native app.
To deliver the pass on your website you just need to use the MIME type application/vnd.apple.pkpass or send it through email
Apple provides a tool that you can install on your server to package and sign customized passes on the fly that may include current user information
To pass file is just a JSON meta-data file and a couple of images. We need to package the file and sign it. Unfortunately, to sign the pass we need a signature from Apple and that means that the web developer needs an iOS Developer Program account ($99/year). If you receive the pass already signed, you can just insert it on your own site.
One of the great features of passes is that once installed you can provide some web services on your end and through Push Notification Services, the operating system will call your web services to update the information on the pass.
No, there is no new storage API available. There is no support for IndexedDB yet. However, there are some changes you should take in consideration:
Application Cache limit was increased to 25Mb.
Chromeless webapps (using the apple-mobile-web-app-capable meta tag) now have their own storage sandbox. That means that even if they are served from the same domain, the web app from the Home Screen will have its own persistent Local and SQL Storage. Even if you install the icon many times, every icon will have its own sandbox. While this is good news for apps, it may be also a problem on some apps if you are passing information from the website to the home screen widgets through storage. Credits for this finding to George Henne on his post.
There is a new undocumented meta tag that can be used on any website (having the apple-mobile-web-app-capable meta tag or not) that allow us to define a different title for the Home Screen icon. As you may know, by default Safari takes the document’s title and crop it to 13 characters. Now we can define an alternative title for the Home Screen using:
I’ve also found a meta tag called apple-mobile-web-app-orientations accepting the possible values portrait, portrait-upside-down, landscape-right, landscape-left, portrait-any. Unfortunately, I couldn’t make it work. If you have any luck feel free to comment here.
On Web View (pseudobrowsers, PhoneGap/Cordova apps, embedded browsers) JavaScript now runs 3.3x slower (or let’s say that Nitro engine on Safari and Web apps is 3.3x faster). Be careful about the 3.3x, that is just the different of running SunSpider on the same device, on Web View and Safari. However, SunSpider is not covering all possible kind of apps and your total rendering time is not just JavaScript, so this doesn’t mean that your app runs 3.3x slower.
We can find some other good news:
Remote Web Inspector for webapp debugging
A new supressesIncrementalRendering Boolean attribute that can eliminate the partial rendering mechanism. I believe this feature is useful to reduce the perception of loading a web page instead of being an app.
A new WebKitStoreWebDataForBackup info.plist Boolean feature where we can define that we want localStorage and Web SQL databases to be stored in a place to be backed up, such as in iCloud. This problem has appeared in iOS 5.01, now it’s solved
Changes in the developer agreement: it seems that the restriction of using only the native WebView to parse HTML and JS has gone. It will be good if someone from Apple can confirm this. The only mention to the internal WebKit engine is that it’s the only engine capable of downloading and execute new code, while in the same app expected behavior; that’s the anti-Chrome statement. You can use your own engine but only if you are not downloading the code from the web. This may be opening a door… such as delivering our own engine, for example, with WebGL support.
I’m keeping this topic at the end. Because it’s a huge change for web developers. For the first time, Safari on iOS includes an official Remote Web Inspector. Therefore tools, such as iWebInspector or Weinre will become obsolete since this version. The Remote Debugger works with the Simulator and with real devices via USB connection only.
To start a remote inspection session you need to use Safari 6 for desktop. Here comes the bad news: you can only debug your webapp on a Mac desktop computer. It was a silent change, but Safari for Windows is not available anymore, so it’s stuck in 5.x. Therefore, only with a Mac OS computer you can make web debugging session on your iOS devices (at least officially for now).
For security reasons, you need to first enable the Web Inspector from Settings > Safari > Advanced. The new Inspector means that the old JavaScript console is not available anymore.
The new remote debugger in iOS 6
You can start a debugging session with:
A safari window on your iOS device or simulator
A chrome-less webapp installed on your iOS device or simulator
A native app using a Web View, such as Apache Cordova/PhoneGap apps.
When talking about native apps, you can only inspect apps that were installed in the device by Xcode (your own apps). Therefore, there is no way to inspect Google Chrome on iOS websites for example.
Teh remote inspector
If you are used to the Webkit Inspector -Safari 5 or Chrome-, you are going to see a completely redesign version of the inspector in Safari 6 based on Xcode native development UI. You will be lost for a while understanding the new UI. With the inspector session, you can:
See and make live changes on your HTML and CSS
Access your storages: cookies, local storage, session storage and SQL databases
Profile your webapp, including performance reports for Network requests, Layout & Rendering and JavaScript and events. This is a big step in terms of performance tools.
Search on your DOM
See all the warning and errors in one place
Manage your workers (threads)
Manage JavaScript breakpoints, and define Uncaught exception breakpoint.
Access the console and execute JavaScript
Debug your JavaScript code
Touch to inspect: There is a little hand icon inside the inspector that allows you to touch on your device and find that DOM element on the inspector.
Well done Apple, we were waiting for this on iOS for long time. Apache Cordova users should be also happy with this feature.
Apple claims to have a faster JavaScript engine. And it seems to be true. On the SunSpider test I’m receiving 20% improvement on JavaScript performance on the same device with iOS 5.1 and iOS 6.
Google Maps is not available anymore on iOS 6; Now http://maps.google.com redirects to the Google Maps website and not the native app. there fore there is a new URL scheme, maps, that will open the native new Maps applications. The syntax is maps:?q= and query can be just a search or latitud and longitude separated by comma. To initiate a route navigation, the parameters are: maps:?saddr=&daddr=.
XHR2: Now the XMLHttpRequestProgressEvent is supported
The autocomplete attribute of the input is officially in the DOM
Mutation Observers from DOM4 are now implemented. You can catch a change in the DOM using the WebKitMutationObserver constructor
Safari no longer always creates hardware-accelerated layers for elements with the -webkit-transform: preserve-3d option. We should stop using it for performance techniques.
Selection API through window.selection
element
Canvas update: Now the createImageData has one parameter and now there are two new functions that the name suggest to be prepared to provide High Resolution imageswebkitGetImageDataHD and webkitPutImageDataHD.
Updates to SVG processor and event constructors
New CSS viewport related measures: vh (viewport height) vw (viewport width) and vmin (minimum between vw and vh)
CSS3 Exclusions and CSS Regions were available on beta 1 but they were removed from the final version. It’s a shame although they were too new and not mature enough.
iCloud tabs. You can synchronize your tabs between all your devices, including Macs, iPhones and iPads. So the same URL will be distributed through all devices. Be careful on your mobile web architecture!
There are a couple of things that we still need to wait for a next version, such as:
IndexedDB
FileSystem API
Performance Timing API
WebRTC and getUserMedia
WebGL -still there and still disabled-
Orientation Lock API for gaming/inmersive apps
Integration with Facebook and Twitter Accounts native APIs, so we can use current OS user’s credentials automatically instead of forcing the user to log in again.
Safari on iOS 6 is a big step for HTML5 developers; debugging tools, new APIs, better JavaScript performance. However, I must say that Apple is still forgetting about documentation updates and properly communication with web developers. There are almost no answers on the discussion forum, no updates on the Safari documentation (some docs are really too old right now).
I believe Apple must do a better job supporting web developers.
Did you find any other new stuff? other problem or bug? Anything else you were waiting for? Feel free to comment in the section below or contact me by twitter.
by Maximiliano Firtman
