|Peter Rogers, Cognizant Mobile Guru|
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.
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:
- 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.
- Split View displays two side-by-side apps, letting the user view, resize, and interact with both of them.
- Picture in Picture lets a user play video in a moveable, resizable window that floats over the apps onscreen.
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.
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:
- On Demand Resources
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.