October 5, 2017 6:08 am

Microsoft Edge for iOS and Android: What developers need to know

By / Principal Program Manager Lead, Microsoft Edge

As you may have read on the Windows Experience blog, Joe Belfiore announced today that Microsoft Edge is coming to iOS and Android, bringing the best browsing experience on Windows 10 to more pockets around the world.

Joe’s post has everything you need to know about availability and features of the preview app experiences. Here, we want to talk a bit about these new apps from a web developer point of view.

Photo showing Android and iOS devices running Microsoft Edge

Getting the preview apps

As any developer can appreciate, testing and learning is a crucial part of launching a new product. It’s something we don’t take lightly. As such, we are beginning with a limited preview to get feedback and learn.

The iOS app is available today for a limited audience in Apple’s TestFlight system, and the Android app will be available shortly via Android’s Play Store Early Access. Consistent with our engineering approach for Windows 10, we’ll be listening to feedback throughout our preview and will update the apps regularly with fixes and new features. When our telemetry (and feedback) shows that the quality is great, we’ll make the apps available for public download – our goal is to do so later this year.

Engines and Platforms

One of the most common web developer questions we’re expecting is – what engine are you using? Did you port EdgeHTML to iOS and Android?

Our choices are directly related to how we think about the goals of the EdgeHTML engine itself on Windows 10.

A web platform is a complex piece of technology that in many respects duplicates aspects of an entire operating system in a single app. Part of our strategy with EdgeHTML is to build an engine that, instead of replicating (and, in some senses, competing with) the underlying platform, integrates and works with it to deliver the best possible security, accessibility, battery life, interactivity, just pure raw performance on that platform. We are proud of the work we’ve done with EdgeHTML on Windows 10, all while driving the web forward with new capabilities and supporting interoperable standards. We are fully committed to continuing to do so into the future, across the full spectrum of Windows 10 platforms and form factors.

Taken in that light, it should then not be a surprise that we have chosen to adopt the core web platform technologies on each of the app platforms we are announcing today.

On iOS, we are using the WebKit engine, as provided by iOS in the WKWebView control. That means that from a compatibility perspective, Microsoft Edge for iOS should match the version of Safari that is currently available for iOS.

On Android, we are using the Blink rendering engine from the Chromium browser project. This approach gives us more control and better performance than using the Android WebView control, but means that we are shipping our own copy of the rendering engine in the app. Much like other Android browsers based on Chromium, we expect to keep up with Chromium releases. You can expect that, from a compatibility perspective, Microsoft Edge for Android will match the version of Chrome that is currently available for Android.

User Agent String

A highly related question is – how can I detect Microsoft Edge from my site?

In most cases, you shouldn’t need to do anything different for your site to just work in Microsoft Edge for iOS and Android. But, we know that in some cases (for example, for analytics, or for choosing the right text in an onscreen instruction related to the browser experience), you might want to know that the user is using Microsoft Edge on an iOS or Android device.

Right now, the apps are using User Agent strings that exactly match the strings used by the primary browser on that platform.  Very soon, we will update the preview apps to include a new token in their user-agent strings, as below:

Microsoft Edge for iOS user agent string

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Mobile/14F89 Safari/603.2.4 EdgiOS/

Microsoft Edge for Android user agent string

Mozilla/5.0 (Linux; Android 8.0; Pixel XL Build/OPP3.170518.006) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.0 Mobile Safari/537.36 EdgA/

A few notes:

  • The app/OS identifier is chosen so that it does not contain the string “Edge.” This is to avoid triggering any existing UA detection logic that might accidentally decide that these browsers are Microsoft Edge for Windows 10, resulting in a desktop site or something equally confusing.
  • The version number “41” is the app version number aligned across all current versions of Microsoft Edge (note that for simplicity, the app version number is not currently exposed in Microsoft Edge for PC; only the EdgeHTML engine version number is exposed).
  • The sub-version number is a platform-specific version number that internal version number of the app on that platform.

Stay tuned

We are excited to be releasing these preview apps, bringing the Microsoft Edge ecosystem to the devices in your pockets with the features you expect, and plenty of unique new features to come.

Stay tuned to this blog (or follow us on Twitter) for more updates on Microsoft Edge, and be sure to try out the preview apps for yourself and let us know what you think. Help us build the best browsers we possibly can!

You can find out more about the preview apps on the preview site.

– Sean Lyndersay, Program Manager, Microsoft Edge

Updated June 28, 2018 7:29 am

Join the conversation

  1. I do not see the point of a glorified WebView, might as well just use the stock browser then. EdgeHTML on Android is something I would be really excited for.

  2. Ummm… but this begs the question “why?” If Edge on iOS uses the same engine as Safari, then why use Edge? If Edge on Android uses the same engine as Chrome, then why use Edge?

    • Different features, supposedly more security, and better battery life, tighter integration with Windows 10 (pushing content back and forth).

  3. If you had replaced the Safari engine I would have been excited. Now we’ll get all those bugs we are frustrated about currently in Safari 11 in addition to any Edge specific bugs. So as a developer – you got me excited when I thought you would bring all of Edge including the engine, now I have zero interest.

    • Hi Peter – Unfortunately, per Apple’s store policies, third-party rendering engines aren’t allowed in the App Store, so this wasn’t an option. We also don’t want to increase test complexity for developers by adding a new and unique permutation of the EdgeHTML engine at this time, so we focused on building a better, connected experience on top of the existing engine allowed on iOS.

      • Really? Sounds like a lawsuit not unlike other companies kept filing against Microsoft in regard to Windows and IE.

        Still need some kind of industry standard MSIL/CIL (not necessarily those) to begin replacing JavaScript. JavaScript is a cancer eating away at professional disciplined programming. The fact it’s an only-option in certain circles makes it an inoperable cancer from which it keeps sending out little cells to invade the rest of the body.

        For starters, MSFT’s languages group needs to initiate an effort toward treating JavaScript as the target “machine language” for the “HTML CPU”. Start moving toward having the .NET compilers supporting JavaScript as a “target machine language” alongside X86 and ARM. Don’t pretend (necessarily) the .NET compiler is supposed to generate “pretty” JavaScript for the programmer to edit later. Absolutely not.

        The generated JavaScript should be the most optimized potentially unreadable (if necessary) output intended for the fastest most efficient execution superior to what a human would likely code. When a compiler generates X86/ARM machine code, it does not concern itself with human readability. Indeed one of the reasons developers should switch to writing their client-side browser code in C#/F#/etc is the resulting JavaScript will enjoy all the benefits of advanced compiler optimization.

        If necessary, early versions of such compilers might limit the C#/F#/etc source code supported to that which can be readily turned into JavaScript should certain language features prove problematic. For example, perhaps certain fundamental data types like “unsigned xxx” would be errors for the time being.

        In phase#2 MSFT can generate a kind of “compact precompiled JavaScript” (CIL) alongside the JavaScript, with a scheme whereby a server can deliver the CIL instead of the JavaScript if the client (browser) signals it as an option (or looks for it first). Basically create a situation where a .NET developer gets existing industry compatible JavaScript target code that works with all existing browsers, and (phase two) with zero extra work also gets CIL that “new browsers” (lead by MSFT) can request/find instead.

        The key to getting developers to start adopting is first that writing in C#/F#/etc will generate faster smaller JavaScript code. THEN getting developers to also deploy the JavaScript alternative CIL alongside the JavaScript comes from “Why not, you don’t have to do anything extra, and full existing browser compatibility is maintained because the JavaScript is still also there.”

        The important marketing pitch for the approach is to always talk about the .NET output side as an industry-wide improvement for the future compatible with everyone’s browsers, and avoid giving the impression it is for MSFT browsers.

  4. Really struggling to see what the point of this is, or more specifically, the benefit for users. Please elaborate without marketing speak.

    • Hi Oisin – the key benefit for users is that they can roam a continuous browsing experience from Microsoft Edge on desktop to their Android or iOS devices. Previously there wasn’t a single great solution for Android and iOS users who prefer Microsoft Edge on the desktop, so those customers had to resort to a mix of other browsers or tools. They now have the option of using Microsoft Edge on both devices with the same settings, history, etc. synced across devices, and the option to share pages between the two.

      • Not relly becouse everybody ask for tab, password, bookmarks sync for even use the broswer.

        I refused to use Edge becouse its had no crossplattforum sync beetween my privat phone, work phone, pc etc with did make the Chrome, Firefox or any other broswer mutch bettre to use.

        But now when Microsoft relly start give out some crossplattform am will hang one in beta like i did with Chrome, if Microsoft do a great job am will leave Chrome for Edge but for now is still missing the basic function some is my #1 requestment for use it full time.

        But alreyd found some bugs in the Preview of Android some refuse login to Facebook etc becouse is dosent popup the keyboard.

        But do it right with Edge and you will rise marketshare.
        20th is not like 80-90th where people dont relly requriment crossplattform sync.

        My work still a bit slow upgrade frome Windows 7 PC to 10 so will still missing out crossplattform sync, but its lesser that Before Android iOS.

        So Chrome still gonna have some overtop when its comes to users some not upgrade to Windows 10 yet.

      • Yes, okay. That’s a valid reason. It’s why I’ll be using Edge once I’m forced to give up my beloved WinPhone and go Samsung. The desktop reading mode is GREAT. Having it on the phone would also be nice.

        On the small phone screen it would be EVEN MORE critical to display a reading progress indicator so the user knows how far into the article they are and how much they have left. I think a LOT of people find themselves getting into reading some article that then seems to start running longer than they expected, and they start wanting to know “how much more time do I need for this?”

        In fact here’s a cute “trick” for Edge in reading mode which it can adopt from things like application installation progress. Once the user provides some indication of having read so much of the article (like saying to turn the page, maybe scrolling, etc), then Edge starts showing a “guestimate” of how much longer the user will probably need to complete the article. It’d be an impressive user-friendly gimmick that’s also entirely useful.

  5. How come that Microsoft Edge dosent have a own section under the Community?

    Alredy found bugs in Microsoft Edge Android Preview some refuse popup the keyboard for sign in to Facebook etc.

  6. The features, especially visual effects on Edge Android are not satisfying and diverse. These make Edge look like a simple demo or a plain browser. Apart from continuing reading and syncing, Edge can hardly compare with Chrome, even if Edge’s raw performance is better. I am even not able to search history on Edge Android. That’s the UX difference.

  7. So, to sum it up – Edge on Android is nothing more than a WebView frontend? Like all the other WebView frontends (must be dozens or even hundreds) available out there?

    I had hoped for a more diveres mobile browser landscape, but it seems Microsoft chose to be a “we too” company instead of investing into their own technology.