Update for iOS7.1 Mar 12, 2014: the iOS7.1 release happily fixes almost all of the web problems in iOS7.0 that we describe in this blog. Read our recent blog entry describing the HTML5 improvements in iOS7.1.
iOS 7 Bugs & Features
“We recommend that organizations standardized on HTML5 development, hold off on upgrading to iOS 7 until an update fixes these issues.”
In addition to these decisions, right and left swipe gestures within about 10 percent of display edge are always grabbed by iOS and treated as a forward/back request, and not passed to the browser. Furthermore, if you’ve built back/forward behavior into your app using history push-state, then accidental swipes will load the previous state as if it was a prior web-site. This will probably be unexpected behavior. Chrome for Android was the first browser to introduce this behavior, but has now removed it based on feedback from web developers. We hope Apple follows suit quickly.
In our own testing, we discovered a number of additional bugs in the iOS 7 runtime.
- On iPad, an orientation change when an input is focused shifts content unpredictably, and causes screen rendering artifacts.
- Launching and quitting the same home screen app several times can hard lock the device requiring a hardware reboot.
- requestAnimationFrame animations do not appear to background correctly, and cause performance degradation in RAF animations on the active page. This defeats one of the major purposes of using RAF animations.
- On iPad, if the document body is set to 100 percent height, content is shifted upwards by 20px in landscape mode. This can be worked around by calling window.scrollTo(0, 0) on the orientationchange event.
- In certain cases, resizing a composited layer (an element with 3D transform) does not repaint it correctly. Instead, the cached bitmap is stretched.
- CSS Animations will sometimes fire before implicit z-indexes have been calculated, resulting in incorrect z layering during an animation.
- Scripts running within Web Workers are not suspended unless either the originating page is explicitly killed, or the Safari process is explicitly terminated. Neither switching to another tab, nor minimizing Safari, nor turning off the screen seem to stop Worker execution. This is a serious issue that allows any web page to drain the battery of an iOS 7 device and slow down performance of the whole system without a user alert.
Perhaps this is a limitation of the test in some way, but it’s certainly nothing we’