Planning for iOS8

Image by Apple

Image by Apple

There have been questions raised about the upcoming iOS 8 release. Has anyone heard of any potential issues, gotchas, best practices, etc. that should be accounted for with this new version?

—Erik, program manager

Updates are a tricky thing. New software presents opportunities for added features, extended functionality, and refined experience—and may potentially break older systems, workflows, and layouts. On the heels of this week’s Apple conference, projekt202’ers began discussing the ramifications of Apple’s latest mobile operating system, iOS8. How might it affect our work already in production? What known glitches or problems might exist? What should we be concerned about going forward with future projects?

An office-wide email thread circulated, capturing the thoughts and concerns of the projekt202 team. The chain is reprinted below — hopefully it sheds some light on our internal discussion processes and how we assess the potential pitfalls that come with new technologies.


I’m surprised that it took a whole day for this question to pop up!

From an app perspective? Having the (proto) widgets could be a shift if you feel the app benefits from one (not always needed and with iOS8 they’re in the notification center, not the home screen like Android). The actionable notifications will change things the most from a interaction perspective – you’ll now be able to take actions directly on a notification instead of launching the application – which is awesome.

From a responsive Web perspective? I’d say you have more potential breakpoints with the new sizes coming out, but being responsive, the design should still change based on maths, so nothing more challenging than when another Android manufacturer puts out a phone or tablet at an odd size. In terms of JavaScript performance, Apple is now allowing 3rd party browsers to have access to the Nitro system, so the speed of all the browsers on iOS8 will be the same, which is good news as speed is quickly becoming the hot topic as more and more Web tech takes a responsive-by-default-mobile-first approach.


I think Erik is specifically asking about browser content rendering, and like William found – everyone is talking about the web views having access to the full speed of Safari. Some googling, the release notes have a couple items:

WebKit Notes

  • Subpixel rendering is now on by default for all web content. Websites or in-app web views with extremely tight design constraints may render differently. Solutions for each issue will vary, but use Web Inspector to adjust position, border thickness, and width or height of elements.
  • The minimal-ui viewport property is no longer supported in iOS 8.

Known Issues

  • The window.outerWidth and window.outerHeight DOM properties always return 0. Other DOM properties will need to be used instead. This may affect websites that use leaf.js.
  • Third party apps that use WKWebView will not be able to participate in Kerberos Single Sign On reliably. To work around this issue, use UIWebView instead.
  • So, not much. But with the VERY quick adoption of iOS versions, I’d add a iOS8 device to QA ASAP – but, sounds like everything should pretty much render the same as it does today.
  • Anyone else see anything on the browser side?


Also, is anybody on this list actually using iOS8? Or just reading about it?

(Disclosure: I’m just a reader.)


I compiled an OMM app for iOS8 and tested it in an iOS8 beta using the Xcode simulator, but not on a device. Besides a few new deprecation warnings everything worked the same. OMM is a native Objective-C app.


I did a lot of exploring back when iOS7 was new. But I haven’t renewed my Apple dev account to access iOS8 yet. I’d be more than happy to if we had some tests we wanted to run or something.

In terms of responsive websites, if we’re designing and building them correct (content-first, adaptive approach, focus on structure, and so on), we should feel quite confident that new form factors will not break things. Though there may be a need to do some touch-up work here and there. But designing to be flexible, and only introducing breakpoints when necessary goes a long way.