Tuesday, July 21, 2015

iOS 9 - The Challenges and Facts Developers Must Know

Our resident mobile expert and guru Peter Rogers shares his insights on the challenges presented by iOS9 in this guest article.  Enjoy!
Peter Rogers, Cognizant Mobile Guru
Web and App developers often live in fear of the latest iOS release because of the challenges it will bring to porting their software.  This time, however, iOS 9 really has outdone itself. This article will focus on the core changes that developers are going to need know and address.

Apple has spent a lot of time focused on the interoperability between Apps and Safari. A key deliverable of this is the new Safari View Controller. The idea is that all HTML content rendering requests are literally handed over to Safari, as opposed to using UIWebView or WKWebView (which never reached its true potential and remains largely unloved). How this impacts PhoneGap who struggled to implement WKWebView will be very interesting to see.


This web interoperability theme is continued with the ability to use universal links that securely lead users directly to a specific part of your App from a website link. This is achieved by means of a signed shared web credentials file in JSON format that has to be stored on your server. The net result means a seamless interchange between web and App environments that bypasses Safari, of which developers will want to take full advantage. There is also an extensive Search API that exposes mobile and web data seamlessly.


The controversy arrives in the form of downloadable Safari extension Apps that can be used amongst other things to offer mobile Ad Blockers. This is something that Purify aims to take full advantage of and the end result is amazing for web users but terrible for advertising agencies. The panic has already started to spread and I predict we will see typical strategies of “beg to whitelist” and “in content advertising” which offers solutions in the desktop space.

Swift 2.0 has been released but it is interesting to see that a lot of developers have not adopted Swift 1.0 due to lack of tooling support. There are also standard updates to HomeKit, HealthKit, CloudKit and MapKit. CloudKit offers a new web interface using CloudKit JS that can be used to share your Cloud data between Mobile Apps, Desktop App and Web Apps. The Games support has been massively overhauled and Metal continues to offer the lowest overhead access to the GPU, spurning OpenGL portability for raw performance. The News App is also worthy of note because it may mean similar Apps get blocked from publishing on the App Store if they are too similar. We also have Application Transport Security which forces HTTPS and declarations of network connections.


The second piece of controversy arrives in the form of multitasking on Tablets. Suddenly every Tablet App can be run in a multitasking context which could support a secondary App taking up half the screen and a third video App running Picture in Picture. The problem for developers is that the onus is on them to deliver a constrained application that has been fully tested in a multitasking environment. This means that suddenly System Testing – in particular Performance Testing – and Non-Functional Requirements become more important and that of course adds to the cost.

The options available are as follows:
  1. Slide Over provides a user-invoked overlay view on the right side of the screen (or on the left side in a right-to-left language version of iOS) that lets a user pick a secondary app to view and interact with.
  2. Split View displays two side-by-side apps, letting the user view, resize, and interact with both of them.
  3. Picture in Picture lets a user play video in a moveable, resizable window that floats over the apps onscreen.
“From a development perspective, the biggest change is about resource management. Every iOS app—even one that opts out of using multitasking features—needs to operate as a good citizen in iOS 9. Now, even full-screen apps don’t have exclusive use of screen real estate, the CPU, memory, or other resources. To participate effectively in this environment, an iOS 9 developer must carefully tune their app’s resource usage. If an app consumes too much time per frame, screen updates can fall below 60 frames per second. Under memory pressure, the system terminates the app consuming the most memory.”

An application can opt out of appearing in the Slide Over selector bar or being available for PiP as long as there is a good reason. If you are submitting Apps to the Apple App Store then you are most probably going to have to include this feature if you do not want to be rejected.  Here is the major rub though…you cannot stop another application from being run at the same time as your application in Slide Over, Split View or PiP. That means you have to make sure your App is a well behaved multitasking citizen and that means a lot of System Testing on actual devices. You need to watch your framerate, memory consumption, handle window based resizing as opposed to screen based resizing (Autolayout helps here) and handle system state events (such as temporarily being put in the background and releasing memory intensive resources).

The following can happen even if you opt out of multitasking in your application:
  • A user adds a Picture in Picture window that plays over whatever else is onscreen (including a full-screen app), while the app that owns the video continues to run in the background.
  • A user employs Slide Over to use a secondary app. While it is visible, the secondary app runs in the foreground.
  • A user invokes a keyboard from a secondary app in Slide Over, thereby obscuring a portion of the primary app.
One key challenge here is automated testing. Often the devices are remote and accessed through some Cloud based testing set up like CloudBees, DeviceAnywhere or Xamarin Test Cloud. This means that remote device testing vendors now have to offer the ability to run three applications on a remote iPad and provide performance and memory logs. If such vendors do not offer these capabilities then you have to acquire the devices yourself and run the tests manually and that adds to the hardware costs for the project.

If that wasn’t enough we also have the third and final controversy: App Thinning. In order to help developers streamline their Apps for the new multitasking environment and to handle Apple Watch, Apple have introduced three new concepts that come under the banner of App Thinning:
  1. Slicing
  2. Bitcode
  3. On Demand Resources
Slicing is the process of creating optimal versions of the application for specific target devices. For example rather than have one Universal App that covers all the tablet and mobile code then you could deliver two Apps. In fact rather than have legacy code for iOS 7 and iOS 8 then why not just deliver three dedicated Apps each for iOS 7, iOS 8 and iOS 9. Why stop there? Why not look at screen sizes and offer precisely the resources that a certain screen size needs. Welcome to Slicing.

The creation side of things is handled by Xcode 7, and the new ability to specify target devices and provide multiple resolutions of an image for the asset catalog. Xcode also allows you to test the local variants of the application on a simulator. You then create an archive of the App and send it off to the App Store. The App Store actually handles the deployment side of things offering up the precise variant of your App to iOS 9 App Store clients. The question remains how this works for Enterprise App Stores but that one is for a later article.

Bitcode is an intermediate representation of a compiled program. By supplying bitcode in your application then it allows Apple to re-optimise your App binary in the future automatically. I can only assume that it is impossible to introduce errors in this process or there would be a large outcry.

On-demand resources are those that can be fetched when required, as opposed to being bundled with the application. The reason why this does not work so well in Android is because of the Java Heap meaning that often memory gets lost in the process. The App Store hosts the resources for you on Apple Servers and manages the download for you. The operating system purges on-demand resources when they are no longer needed and disk space is low. If you use an Enterprise App Store instead of the Apple App Store then you must host the on-demand resources yourself and that is again something worth exploring in future articles here.

Hopefully when your customer asks you for a quick iOS 9 update then you will at least be prepared now.

Kevin Benedict
Writer, Speaker, Senior Analyst
The Center for the Future of Work, Cognizant
View my profile on LinkedIn
Read more at Future of Work
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.