iOS 7 Predictions.

What about an article on iOS 7 that’s based on fact and research instead of wishful thinking? You’re welcome.

XPC and UIRemoteViewController

Let’s start by introducing the two technologies that will be the basis for the entire discussion.

XPC

What is XPC? In the OSX docs, Apple defines it like this:

The XPC Services API, part of libSystem, provides a lightweight mechanism for basic interprocess communication integrated with Grand Central Dispatch (GCD) and launchd. The XPC Services API allows you to create lightweight helper tools, called XPC services, that perform work on behalf of your application.

In other words, it’s a framework you can build daemons with. XPC is responsible for spawning your daemon every time you need its services, shutting it down when it’s no longer needed, and providing a protocol you can use to talk to it.

They go on and mention how this, combined with sandboxing, can be used to improve the security of an app - in other words, adopting privilege separation:

With traditional applications, if an application becomes compromised through a buffer overflow or other security vulnerability, the attacker gains the ability to do anything that the user can do.

To mitigate this risk, OS X provides sandboxing—limiting what types of operations a process can perform. In a sandboxed environment, you can further increase security with privilege separation—dividing an application into smaller pieces that are responsible for a part of the application’s behavior. This allows each piece to have a more restrictive sandbox than the application as a whole would require.

You would split your app in multiple components with different privileges, that safely communicate via XPC, so if one gets compromised the damage done will be limited.

This OSX technology, as it turns out, is also part of iOS 6.

Remote View Controllers

I first learned about Remote View Controllers reading Ole Begemann’s awesome three part article. If you want the nuts and bolts, go read it now - I’ll wait for you.

_UIRemoteViewController and _UIRemoteView are two new private classes in iOS 6, and they’re built on top of XPC. They basically allow one process/app to seamlessly create a view controller whose contents are managed by another process/app, without changes in the presenter code.

As far as we can tell, the remote app will just have a normal View Controller and draw to its view as usual, but the contents of that view will be streamed in a secure way to a host view in the presenter app, instead of being displayed directly.

They are conceptually similar to Android’s Activities, but a Remote View Controller:

  1. Will always run in a separate process
  2. Won’t necessarily take over the whole screen/window, or take you out of your app
  3. Is presented like any other View Controller

And these features are really important. The first one is great news for security. The second allows you to avoid using the awful browser-style “back” mechanism to navigate between apps (and OS views), and gives the presenting app control over the flow. The third one makes it seamless for developers, and allows Apple to replace existing VCs with RVCs without breaking any apps.

So What?

Apple is already using these technologies internally on iOS 6; you might call it a private API. Let’s see how these new technologies are used today and how they could be used tomorrow, both by Apple and third-party developers.

Applications, Current and Future

System View Controllers

In iOS 6, the system mail composer (MFMailComposeViewController) is a Remote View Controller. It works exactly like it always has - including respecting your UIAppearance directives -, and the API to invoke it is the same, but it runs in a separate process.

Other presentable system controllers - the contact picker, photo picker, message composer, etc. - aren’t… yet. My theory is that Apple is field-testing these technologies with iOS 6, to ensure everything works as expected. They’re also dog-fooding them to their own developers to ensure the public APIs, once available, will be robust and easy to use.

New System View Controllers

I think RVCs will allow for at least one new system view controller to be built: the infamous in-app browser. Thousands of apps have their own, and I’m sure more will after iOS 7 comes out - and they are really inconsistent, and they miss a lot of Safari functionality. Not to mention all the time spent by developers to recreate the basic browser functionality.

This new controller will look basically like Safari, but it’ll just have the page title and a “Done” button on the navigation bar - no address box or search box. No tabs. It would be presented modally by default (i.e. will slide up from the bottom of the screen, just like the mail composer). And of course it would have Add to Bookmarks, Reading List, Reader, Nitro, and all that Safari goodness. Maybe even iCloud tabs!

Bonus feature: all WebViews will be RVCs, which means they can run Nitro with no security concerns.

The remote WebViews theory has been confirmed by recent findings in iOS 6.1. It also appears that full-screen iAds will be displayed using a remote web view controller. We’ll see if Apple decides to add an in-app browser to the mix.

Default Apps

Why can’t you choose a default web browser, or mail client, in iOS? If you think about it, those two “apps” are deeply tied into the OS. Any app can invoke a mail composer, or host a WebView. But at least it’s Apple code that gets invoked, so you kind of have to trust it - they’re also making the sandbox, so if their code is broken, the entire security model falls apart. If they let any app respond to those events, it would mean running two third-party apps in the same process, which of course is a hole in the sandbox.

There’s also the matter of having more stuff to configure which isn’t very iOS-like, but you can easily solve that by hiding this somewhere deep in Settings where only dedicated users will find it. Or only having that section appear if you have already installed an app that claims it’s a mail client or browser, in the same way an app can claim it’s for routing.

With RVCs, any app could e.g. present a third-party app’s mail composer in a secure way. Problem solved!

I don’t think they’re gonna let you choose a default Photo app, just because no one asked for it. Additionally, with the changes I’m going to talk about in the next section, Messages will be on par with third-party apps.

Sharing

Another great addition to iOS 6 was the abstract UIActivity mechanism and its UI counterpart, UIActivityViewController. An app can now just say “I want to share an image”, and iOS will pop up a control with possible sharing destinations. iOS provides a bunch of built-in destinations, including Twitter and Facebook. Third-party developers can provide additional destinations in the context of their own app, but not to other apps.

You guessed it: with RVCs, and a couple new additions to the iOS SDK, third-party apps could expose UIActivities to the whole system, in a secure, sandboxed way. I’m thinking you would add a new “sharing bundle” to your app bundle - probably at most one per app -, with some metadata indicating what kind of data your activity supports. This sharing bundle will probably contain a full, separate application, with its own Storyboard and everything, so it launches as fast as possible and doesn’t waste resources - but hopefully, Xcode will allow some kind of easy code sharing with the main app.

What does this mean for end users? Their UIActivityViewControllers will start displaying activities for App Store apps they installed. So they can share a picture from Photos to Instagram, or a URL from Notes to Tumblr - with a consistent UI and navigational model, and without compromising the security of their device.

By the way, the Facebook sharing sheet is a Remote View Controller. The Tweet Sheet? Not yet.

Custom UIs in Settings

You’re probably familiar with Settings Bundles. What if those bundles could include a RVC in iOS 7, so you can build your Settings UI however you want? That would allow all apps to move their preferences/settings screen to the Settings app, and end the user confusion caused by how those screens are sometimes in Settings and sometimes in the app.

This of course has all sorts of problems associated with it, e.g. the Settings app might lose its visual consistency. But nothing seems insuperable - after all, there’s an app approval process for a reason.

Custom UIs in Notification Center

What if RVCs open the doors for developers to present their notifications differently? No, I’m not talking about widgets - let’s hope that will never happen. I’m talking about the standard notifications we get on iOS every day. What if their UI could be made by a third-party?

I don’t see a lot of value in changing the looks or functionality of the system “banners”, or even the notifications in Notification Center. But this could allow for some sort of “quick-reply” functionality. Say you get a banner from Messages, and there’s a button on the banner with a compose icon. You tap it and get a small Tweet Sheet-like reply composer for that message. You hit send and it just takes you back to whatever app you were using. Same thing for third-party apps.

Custom UIs in Siri

Let’s assume for a second that there’s a way for developers to teach something to Siri without disrupting the rest of its functionality, turning it into a dumb list of voice commands that you have to learn and repeat, or making the UX worse. I know it sounds silly, but bear with me.

As you know, Siri rarely takes you to an app when you ask it (him? her?) something. You usually get a “card” right there in the Siri UI. Third-party app developers will need to be able to inject a card in Siri whenever it understands that what you said has to be handled by their app. With RVCs, this becomes the easy part of extending Siri.

Speculation (Just for Fun)

Here are a few more features that might come with iOS 7. Nothing in particular suggests these features will come, so take this with a grain of salt.

More (Many More!) System Activities

More Activities with Text

I’d like to make a Note out of this email I’m viewing in Mail, or a Reminder with its subject. I want to make a Calendar event out of any piece of text containing a date. What if the Cut/Copy popup had a Share button on it?

More Activities with URLs

Make a note out of a webpage. Save a URL to your Safari bookmarks. Save a URL to your Reading List! I’m actually shocked the last one isn’t in iOS 6 already.

Keychain in the Cloud

If I had to think of one of the worst things in terms of UX that we have today, I might say logging in. Typing passwords. What if your Mac’s keychain synced with your iPhone’s? You log in once on one device, and that’s it. On the web you’d get autofill everywhere you signed in before. In apps, you would just be logged in, even just after installing.

Pasteboard in the Cloud

If you turn this on, when you copy something on one device, you could paste it on any other device, Macs included. I’d love to have this.

iPhoto in the Cloud

Wouldn’t it be great if you could just sync all of your pictures and personal videos via iCloud? Combine this with iTunes Match, and you’ll never have to sync with iTunes again. I think Apple is working on iTunes’s bloat, just not how you would expect.

I think they would have to add new and bigger iCloud storage plans to accommodate all of this data, and they’re not going to be free. But if they pull this off, iTunes as a sync backend will no longer be needed.

Conclusions

Realistically, probably not all of the above will make it to iOS 7. But if these technologies are brought to the surface, it’s still going to be a radical transformation in the OS dynamics, and a whole new experience for users - without compromising what’s good about iOS today. See you at WWDC.

P.S. here’s my new favorite Cocoa identifier: PFUbiquityKnowledgeVector