Exchange's Evolving Mobile Email Device Strategy

Microsoft's announcement of Outlook Web App (OWA) for Android on March 31, 2014, fulfilled the company's goal of providing a Microsoft email client on all major mobile devices (i.e., smartphones and tablets). That is, of course, if you consider coverage of Apple iOS and Android as covering "all major mobile devices." Given that IDC data for Q4 of 2013 shows that iOS and Android combined represent nearly 96 percent of smartphones shipped in the quarter, this assertion seems reasonable.

Two questions come to mind from these developments. The first is why Microsoft chose Apple iOS as the debut platform (July 2013) for its OWA for Devices strategy, and the second is why no OWA for Devices variant is available to satisfy the 3 percent or so of the market, including myself, who consider Windows Phone to be the superior mobile operating system. Let's explore what lies behind the answers to those questions and the strategy Microsoft is pursuing as it develops email clients for mobile devices.

Solving Some Problems with iOS

The answer to my first question—Why Microsoft chose iOS as the debut platform—lies in a mixture of policy and technology. Until 2012, Microsoft's strategy was to sell Exchange ActiveSync (EAS) protocol licenses to mobile device vendors and leave the vendors to incorporate the necessary EAS code to communicate with Exchange into their mail apps. The strategy was wildly successful and every major mobile device vendor licensed EAS; however, although some vendors did a nice job with EAS, others were less successful. Apple was firmly in the latter category. The implementation of EAS within the iOS mail apps, particularly in iOS 6, was problematic. And that's about as kind as I can be in describing the effects of problems such as calendar meeting hi-jacking and transaction logs growing wildly.

To their credit, after the iOS 6 fiasco, Apple and Microsoft realized that they shared a major problem and have since worked together to ensure that the iOS mail app uses EAS correctly. On the server, Microsoft bulletproofed EAS to make sure clients follow the rules and can't take liberties with mailboxes. The result of this effort is evident in the success of the introduction of iOS 7.1, which occurred without any problems related to Exchange.

Even though we now have good iOS mail app code and a server that stops malfunctioning clients from doing bad things, Microsoft realized that EAS is probably coming to the end of its lifecycle. The first version of "direct push" EAS was introduced with Exchange Server 2013 SP2 in 2005 and was last refreshed in Exchange 2010. However, many of the capabilities incorporated into the latest EAS protocol are simply ignored by mobile device vendors. This might be because a capability is no longer required (when was the last time you needed policy control over how devices use infrared ports?), but it's more likely that the vendors want mail clients to interact with Exchange at a fairly rudimentary level to process email, calendar, tasks, and contacts. Thus we have a wide variety of EAS implementations, particularly on Android, all of which handle the basics of mail and calendar processing but few of which do much else.

In the meantime, OWA received a thorough redesign for Exchange 2013. One of the goals was to make OWA work well on devices that use different form factors rather than being focused simply on PC screens. The outcome was a morphing user interface that can accommodate tablet and smartphone screens, which is fine if you're happy to run OWA in a classic sense by firing up one of the browsers that support its premium interface (Internet Explorer, Chrome, Firefox, or Safari). Some might argue that the redesigned OWA lost functionality when compared with its predecessors. This is true, but the feature deficit is being addressed as new cumulative updates appear, and a fair case can be argued that the gain in UI flexibility was worth the short-term drop in functionality.

Taking Control on iOS

Coming back to iOS, Microsoft recognized that it had no control over the mobile email app people used to connect to Exchange—but if anything went wrong, Microsoft was usually the first port of call for support rather than the device manufacturer who wrote the code. Users saw Exchange as the fulcrum for their mailbox; when bad things happened, the fault was heaped on top of Exchange. No matter how closely Microsoft worked with Apple, the situation would never change because Apple controls the code for the iOS mail app.

Introducing Microsoft's own email client for iOS provided several benefits. Microsoft develops the mail client and therefore controls the end-to-end connection between the client and Exchange. In addition, Microsoft controls how and when new features are introduced. Instead of making changes to facilitate a new feature and then waiting for mobile device vendors to decide to support the feature by updating their mail apps, Microsoft can update OWA for iOS and make the new version available through iTunes. The strategy Microsoft launched with OWA for iOS delivered a lot of benefits with no apparent downside.

But not everything went smoothly. The initial release of OWA for iOS wasn't a snappy performer (much like its big brother on PCs). Microsoft has improved OWA performance since the initial release, and the most recent updates are better—especially on the latest iPhones and iPads.

Another issue was that Microsoft launched OWA for iOS with support for Office 365 customers only. In fact, almost everything worked when you connected the client to an on-premises Exchange 2013 server. At a technical level, processing the push notifications that are used to inform devices of a new unseen count for email was the sole problem because these notifications are handled by an Apple service that accepts updates only from trusted sources. After the Apple service accepts the notifications, it transmits them to the devices for the app to display to the user.

Every company running on-premises Exchange is unlikely to go through the necessary steps to become a trusted source for Apple just to make unseen counts for email work. This issue remains a problem unless you run Exchange 2013 in a hybrid environment, in which case you can follow the steps published by Microsoft to enable push notifications to iOS clients via Office 365.

Long term, Microsoft plans to improve the mechanism used to notify iOS devices about new messages and other important events by leveraging changes made in iOS 7 to facilitate better background multitasking. (The article "iOS 7 Tutorial Series: What's New In Background Multitasking" explains the basic principles.) Essentially, when OWA receives a new push notification with a new unseen count, the app will wake up and perform a brief synchronization with the server to receive data. This approach will allow OWA to display more information than a simple unseen count, such as the name of the sender and the subject of new messages. The same approach will be used by OWA for Android.

Despite all the work done since July 2013, Microsoft can't get past the fact that Apple is never going to remove its mail app from an iOS device nor will Apple allow another app to become the default mail handler. Users end up with two mail apps on an iPad or iPhone and must choose between them. In fact, given the number of email apps available for iOS, it's conceivable that a user might have four or five apps from which to select.

Android

Users face the same choice between OWA and native mail apps on Android smartphones. Despite Android's undoubted success in the market, Android devices run a variety of different versions of the operating system. The same variety is seen in the email apps available for Android. However, it's true that Android email apps haven't caused the same number of high-profile problems for Exchange as iOS has. Perhaps this says a lot about the popularity of iOS as the preferred device for people working in large enterprises. More likely it's because Android email clients have avoided the pitfalls in calendar manipulation that caused problems for the iOS mail app.

Microsoft opted to wait until Google released KitKat (Android 4.4) for one important technical reason: KitKat changed the WebView control used by OWA in the Android app to be powered by Chrome rather than the original Android browser. This change was important for any developer hoping to cover both PC and mobile platforms because it means the script and rendering engine are the same on both platforms. It's also true that Chrome performs better than the now-aging Android browser, possibly because Chrome receives far more development effort due to its importance to the Google ecosystem than the Android-specific browser will ever get.

Android allows different mail apps to be used to process messages. If you click a mailto: link in a message or on a web page, Android presents a list of known mail apps that can process the link. OWA is included in this list; you can opt to use OWA Just Once or Always. Selecting the Always option makes OWA the default mail app for mailto: links. In this respect, Android is friendlier to third-party mail apps than iOS is.

Where OWA Is Going

At the recent Microsoft Exchange Conference, the Exchange team made it very clear that they will be introducing new features such as "Clutter," "people view," and better search capabilities in OWA first. These features will show up in Office 365 by the end of 2014. Just when these features might turn up in an on-premises release is open to debate for now. However, it seems clear that over time, a wider gap will open up between the basic mail and calendaring available to applications built with EAS and the functionality available in OWA.

OWA is obviously much more important to Microsoft now. In the past, OWA just provided a browser interface to Exchange and was regarded as a second-class citizen when compared with Outlook. Now, OWA provides the way to expose and deliver new features and functionality to users in a manner that matches the rapid cadence of development for Exchange Online (Office 365). PC clients such as Outlook can't evolve as rapidly because of the engineering work that's necessary to integrate new features into their user interfaces, but making a change to OWA is relatively simple. In addition, whereas Outlook users often protest changes (remember the uproar about the introduction of the ribbon in 2010?), OWA users are accustomed to the gradual and ongoing introduction of change. Google proved that this model of constant innovation in web mail clients works by keeping Gmail in what seemed to be perpetual beta for years after its launch. And what we see now in Office 365 is that Microsoft is using the same approach to deliver new features through OWA. Competition is a wonderful thing.

All of this means that if you want to run the most functional email client on iOS or Android smartphones or tablets and need to connect to Exchange, you should use OWA. However, if you don't think you need access to business-oriented features such as Data Loss Prevention (DLP) prompts or Outlook apps, the built-in email apps available in iOS or Android will continue to provide the basics of email and calendaring. The gap in functionality between OWA and the standard apps can be expected to grow over time because of Microsoft engineering investment to deliver new features through OWA and because of a lack of support for extended features in the EAS protocol used by the standard apps.

Windows Phone Clients

The second question I posed is why Microsoft doesn't provide an OWA for Devices app for Windows Mobile. The answer is "it's complicated." Outlook Mobile, the standard email app provided in Windows Phone, uses EAS. In fact, Outlook Mobile does an extremely good job of managing email, calendar, tasks, and contacts. Given that it's a Microsoft client, it isn't surprising that Outlook Mobile developers have taken full advantage of the EAS protocol in a way that third-party vendors haven't.

Will Microsoft leave its own application to atrophy and become an also-ran to OWA? The answer is that in the immediate future Microsoft has no plans to provide an OWA for Windows Phone package, possibly because Outlook Mobile does such a good job—and possibly because the market share of Windows Phone doesn't demand further intervention. You can run OWA using IE on Windows Phone and get access to extended functionality through that route. This is an acceptable option for one-off access, but using OWA through IE isn't a particularly elegant solution for Windows Phone.

All indications are that for the immediate future Outlook Mobile will continue to be based on EAS. My feeling is that over time the functionality gap between Outlook Mobile and OWA will only increase and Microsoft will eventually have to bite the bullet and move Outlook Mobile away from EAS to use HTTP.

Long-Term Strategy

Microsoft's strategy for mobile email clients for Exchange seems pretty clear. As I explained in "Exchange ActiveSync to be replaced by Outlook Web App on mobile devices?" OWA is the fulcrum for development and the delivery of new features, at least in the foreseeable future. EAS is now the "reach" protocol, popular with mobile device vendors because it's relatively easy to implement, it's stable, and it's well sorted—albeit with some acknowledged shortcomings such as the way EAS is happy to wipe a complete device rather than just its data (as Windows 8.1 Mail shows, some care in the implementation of an EAS client makes it possible to manage user data in a more granular fashion).

EAS clients will remain enormously popular and will continue to serve users well if they're content with basic email and calendaring. OWA is the premier mobile client and will evolve to match or surpass the features available to classic Outlook. Developments in this space over the next few years should be very interesting.

Follow Tony @12Knocksinna