Foreign article analysis: iOS and Android on Windows

A bridge that can carry a billion users, but the destination it leads to is... Android and iOS? !

At the Build developer conference held last week, Microsoft released a series of development announcements about the Windows platform, one of which was even explosive: the Windows system will support applications developed for iOS and Android.

At first glance, this is an extremely dangerous move. Windows is not the first platform to want to include other applications in its support. IBM famously promoted OS/2 in the 1990s as an operating system that was "more Windows than Windows," touting it as being able to run all existing Windows applications with better stability and performance. More recently, BlackBerry 10 has also implemented support for Android applications, licensing them through the Amazon App Store as a shortcut to Android-compatible software.

Yet neither OS/2 nor BlackBerry 10 have lived up to their promise. There are two main problems with supporting other applications on a niche platform. The first is convenience: it removes the reason for developers to bother learning the native features of the target platform. Investing time and energy in learning a niche platform is a gamble in itself, and telling developers "Oh hey, you can just use your existing Win16 or Android programs...", as IBM and BlackBerry did, actually sends a very unfavorable message - "Don't bother learning our platform or writing native applications for it, it's not necessary."

As it turned out, both platforms suffered the same fate. Although developers did write some real OS/2 apps—the same thing happened on the BlackBerry 10 platform—they were very limited in number and scale. Let's be clear about this. If IBM planned to invest so much resources in making Win16 apps run well on OS/2, and if these Win16 apps could be sold to OS/2 users as well as Windows 3.1 users, why would developers bother writing pure OS/2 apps in addition to Win16?

This capability comes with a huge loss of control. To make third-party applications work in our environment, we have to adapt our APIs and add new features to the third-party platforms. This was a real pain for OS/2: while IBM was busy promoting OS/2's superior performance running 16-bit Windows applications, Microsoft was focusing its time and energy on encouraging developers to create new 32-bit Windows applications, thereby driving end users to buy Windows 95, which supported 32-bit applications. The new world of 32-bit software was clearly not something OS/2 could achieve, so IBM's marketing efforts touting OS/2's key features were worthless. OS/2 did succeed in some niche markets, but it ultimately failed.

Supporting Android apps carries a similar risk. If Android software becomes a major part of a platform’s software ecosystem, any changes in Android (such as new APIs or other features) will improve apps and put pressure on the other platforms that support them. But the poor Android update situation is a little less worrying. After all, most Android phones don’t match the latest Android features or system versions, so most Android software doesn’t have these new features. This means that the Android compatibility platform can distance itself from Google’s cutting-edge design ideas for a year or more while continuing to have good support for Android apps.

But this situation does not apply to the iOS camp. To be compatible with Apple's applications, the Windows platform must always keep up with the development pace of iOS, because Apple's developer community will never accept any form of functional compromise.

With all of this in mind, it's easy to see why supporting Android apps on Windows is seen as the beginning of something of a mess, and why the tech industry has been so negative about it since the news broke last year. It seems like Microsoft is simply making the same mistake that others have made before it -- hoping to give its mobile platform a last-ditch effort.

Microsoft didn't promote Android and iOS specifically when it presented its Android and iOS support proposals at Build last week. Project Astoria and Project Islandwood -- the code names for Android and iOS app support, respectively -- were only highlighted in their respective keynotes. One could argue that Android and iOS app support will be a solid foundation for Windows 10's universal Windows App development strategy across a wide range of hardware. But from a developer's perspective, it's much more cost-effective to develop apps for other platforms and port them to Windows than to develop native Windows apps.

Clearly, Astoria and Islandwood are two projects that could potentially lead to a lack of interest in native Windows apps. This forced support is similar to IBM's efforts to make OS/2 compatible with Win16 software, or BlackBerry 10's embrace of the Amazon App Store. But it must be admitted that the two are not exactly the same. Although it is not certain at this time, we may find that under Microsoft's guidance, the situation will go in a different direction than IBM and BlackBerry did.

Astoria Project in-depth analysis

Astoria and Islandwood look very similar on the surface, but the underlying technologies and implementations are very different. For developers, Astoria may be more intuitive. Windows has long had the ability to support multiple API systems using so-called subsystems. The Win32 API is used by almost all Windows software (including general-purpose Windows applications), and it is also one of the most influential and well-known APIs. In modern versions of Windows, it is actually the only API left. But historically, there have been many API families on Windows. Among them, the first version of Windows NT included an OS/2 subsystem that supported a certain set of OS/2 applications. But this is just a historical episode, a remnant of Microsoft's collaboration with IBM to develop operating systems.

Windows also included a POSIX subsystem. POSIX is an IEEE-standardized API that essentially defines the Unix API. Solaris, Linux, OS X, and AIX are among the many operating systems that have POSIX or similar implementations. Windows NT included POSIX support because it was mandated by U.S. government regulators. Unlike the OS/2 subsystem, the POSIX subsystem was maintained and even expanded over many years, first by a third party (Inetrix) and then by Microsoft itself. Microsoft later acquired the Interix tools and renamed them Services For Unix (SFU) and Subsystem for UNIX Applications (SUA).

Since Windows 2000, the OS/2 subsystem has been officially thrown into the dustbin of history. The POSIX subsystem has only been available as an optional component in the recent Windows 7 - and in Windows 8, its support has completely bid farewell to the stage of history. However, the underlying operating system components used to support the subsystem have been retained in the new version and are still able to play a role - this is why the Astoria project has emerged. It introduces a new Windows subsystem: the Android subsystem.

This Android subsystem implements a subset of the Android API combination on Windows. The subsystem can provide various Android-style APIs, including file system access, graphics processing, sensor and camera access, process and thread creation, security, and networking, etc. All these core services will be delivered through the Windows kernel.

Microsoft has not yet announced or set the specific categories of supported APIs, but the final list is likely to consist of the following three major parts - they also directly reflect the way the Android system is built. Android has a Linux kernel and a series of open source native libraries, which are used to support the normal operation of native code applications; a set of open source Java APIs to support the normal operation of Java applications; and a set of dedicated Java APIs that are tied to various Google services and are collectively called Google Mobile Services (GMS). The first two categories are also included in AOSP, the Android open source project, but the third is unique to the commercial Android system.

In terms of open source, Microsoft can in principle use these open source codes with its implementation mechanisms to provide applications with the Java APIs they need to run - but they will be redirected to Windows services as appropriate. For example, Android shared APIs can be directed to the Windows shared system. For GMS, Microsoft will not use the source code related to it. Instead, Microsoft has decided to provide alternatives for at least some of the GMS APIs. For example, GMS contains APIs for implementing in-app purchases and location services, and Microsoft has developed similar mechanisms supported by its own services.

This new subsystem will be pre-installed as a built-in component of Windows Mobile - yes, the name we once knew very well has been changed this time, and it is once again the name of the Windows version on mobile phones and small-screen tablet devices. It only supports ARM processors, and other versions of Windows have not yet incorporated it into themselves.

When developers use Astoria, their experience is very similar to that of ordinary Android developers. Developers will be able to continue to use Android development environments, such as Eclipse or IntelliJ, and they can also continue to build Android application packages, that is, APK files.

If the application only uses the AOSP API subset, that is, the part supported by the Windows subsystem, then in principle its content does not need to be changed. In fact, all existing APKs distributed to Android users should be able to run smoothly on the Windows platform without recompiling or modification. Applications that use the GMS API require some adjustments, so they need to replace the original Google code with the same mechanism provided by Microsoft.

Microsoft will also provide some special Windows APIs to ensure that Android applications can access Windows-specific features such as live tiles. Of course, developers also need to make corresponding code changes to make these APIs work. However, this change is very limited, and Android applications themselves will not access all underlying Windows functions.

Microsoft does not plan to support the Amazon App Store on Windows like BlackBerry does. Instead, Android developers will need to submit their APKs to the Windows Software Store, where Microsoft will identify the unsupported APIs contained in them and then repackage the APK as a Windows AppX package.

#p#

Set foot on the new world of Islandwood

One might think that the technical mechanisms required to run iOS apps on Windows are similar to those required to run Android apps on Windows. The subsystem approach used for Android support is nothing special, and the existence of APKs and other normal Android development processes means that Android developers can easily make a Windows version of their apps if they want to.

But Islandwood is nothing like Astoria. Islandwood apps don't have their own subsystem. They're regular Windows apps that run using the regular Win32 subsystem. But what's even more surprising is that they're not written in the traditional Windows programming languages, like C++ or C#. Instead, they're written in the language that still dominates iOS development: Objective-C.

Microsoft has added support for Objective-C in Visual Studio. The entire development environment can import Xcode projects and understand Objective-C source files, and it also has color coding, auto-completion, and other features that developers often use in the development environment. Its compiler supports Objective-C and can compile it into a regular Windows executable file.

Objective-C programs built in Visual Studio get all this from the compiler. This support for Objective-C is mainly implemented by the open source Clang compiler, which is part of the open source LLVM toolchain and exists in Microsoft's existing C++ compiler system. The reason why it is so important is that this C++ compiler architecture does most of the core work. It can output debugging results in a format that Visual Studio can recognize, and it can magically achieve various interoperability between C++ and .NET. It is also responsible for collecting the results of running security checks to detect loopholes that programmers accidentally leave.

This means that the compiler will support all the hardware platforms that Microsoft's C++ compiler can handle. At present, there are three major platforms - 32-bit and 64-bit x86, plus 32-bit ARM. It is said that Microsoft will add support for a fourth platform - 64-bit ARM later this year.

An application targeting iOS is being edited in Visual Studio 2015.

What about the support for Apple's other development language, Swift? It is said that relevant work is still in progress.

Of course, code compilation is only a small part of this grand tool. Simply being able to build Objective-C code is not enough, because if developers had to rewrite every API call, then all of the above would be lost. To this end, Microsoft has implemented a subset of the iOS API on Windows. This includes a lot of low-level Objective-C functionality, such as automatic reference counting and blocks, foundational libraries such as CoreFoundation, graphics libraries such as UIKit, CoreAnimation, CoreGraphics, and CoreText, 3D support using OpenGL, and other services such as StoreKit and Notifications. Just like in Project Astoria, these capabilities are integrated into Windows itself, and the facts prove that it really works. For example, the StoreKit in-app purchase mechanism will be mapped to the same functionality in the Windows Store.

This API support library will be bundled with Islandwood applications.

One notable thing about Islandwood is that Microsoft has been keeping quiet about it. Astoria was announced almost immediately after its creation a year ago. But Islandwood appears to be the product of an acquisition; a startup called Inception Mobile has a similar approach to porting iOS apps to other platforms. Inception Mobile co-founder Salmaan Ahmed showed up at the Islandwood environment at Build, and his LinkedIn information shows that he has been working for Microsoft since August last year.

Even with the Islandwood project as a backing, porting iOS apps to Windows still requires far more effort than Android apps. While some Android apps are 100% compatible with Astoria, Islandwood is a bit more passive. There are a lot of fundamental differences between the platforms that need to be addressed—Android and Windows Phone have back buttons, for example, but iOS doesn't—and developers have to adapt their code accordingly.

[[133841]]

The first result of the Islandwood project - Candy Crush Saga.

The actual effect of this influence on different applications also varies. King's Candy Crush Saga for Windows Phone has begun to use the technical results of the Islandwood project, and the code content adjustments are said to be only "a few percent" of the entire project. The Windows Phone version of Candy Crush Saga supports many features, including in-app purchases, which is naturally helped by the StoreKit API mapping mechanism. However, as a game, its user interface is still heavily customized. After a deep understanding of UIKit, the application results should still make more efforts to ensure that Windows users can get the interface effects that meet their expectations.

On the other hand, these apps are pure Windows apps. They can access any Windows API, even if those APIs don't have equivalents on iOS, such as live tiles and NFC. Also, these apps are not limited to Windows Mobile platforms; Islandwood apps can run on any Windows 10 platform. Because they use the same standard Windows compiler architecture, they can support multiple programming languages. For example, a developer can choose to implement live tile support in C# - even if the rest of the project is written entirely in Objective-C.

#p#

Similar to OS/2 and BlackBerry, but not identical

Whether to use Astoria or Islandwood is the fundamental difference between Microsoft and IBM and BlackBerry. Astoria and Islandwood both require developers to make some commitment to them, while developers who write Win16 applications do not have to consider OS/2 at all - they just write Win16 applications. Occasionally, some OS/2 users will buy a watered-down version of Win16 software to prove that they will use it on OS/2, but these developers obviously don't feel it at all.

A similar situation exists with BlackBerry 10. Developers can submit their apps to the Amazon App Store simply because they are interested in Amazon's tablet devices (or phones, for that matter). In fact, some BlackBerry 10 users do download these apps, but this is neither related to nor known to the developers.

But now with Astoria and Islandwood, developers have to take that first step. It may not be a huge step - potentially all they need to do is ship an APK that hasn't been tweaked for Windows - but it's important for every developer to realize that their app will be available to Windows users from here on out. Windows still can't be their go-to platform, but they can't ignore it either.

This, in turn, will make developers more cautious about how their applications run on the Windows platform. If they cannot use Windows-specific features such as Xbox achievements or live tiles, then these applications will become very bad in terms of appearance and first impression. In short, developers will be clearly aware that these applications are launched specifically for the Windows customer base.

Islandwood makes all this more acute, as developers will need to recompile their work and tweak parts of the code, a process that requires dedication to make these apps work, at least somewhat similar to developing a pure Windows app.

In this sense, Microsoft's approach of requiring developers to port their application experience to Windows should be more sophisticated than its predecessors who have failed in history.

It stands to reason that Microsoft's plan is unlikely to hinder the trend of native app development. The limitations of Astoria preclude it from truly replacing native development activities, and those who worry that these restrictions will eventually be relaxed should not be nervous - at least not for quite some time. Astoria apps will work on phones and small tablets, but they will still be a barrier to the broader Windows platform (such as laptops, PCs, Xbox One and even the future HoloLens). To land on these, developers, bring out your native apps.

Of course, this limitation is not without its negative effects. Windows is in a completely different market position than OS/2 and BlackBerry 10 were. Although Windows has never reached the popularity Microsoft had hoped for in the field of smartphones and tablets, it is still the first choice for most users in the laptop and PC market. Microsoft said that it hopes to increase the number of users of Windows 10 to 1 billion within two to three years of its release. It is for this reason that Microsoft will sell Windows 10 to Windows 7 and Windows 8 users half of the time as a free upgrade. Microsoft does not want its platform to be overly fragmented; the idea is that every device runs Windows 10, and every device can run universal Windows applications.

Even if the final goal is only half of the expected value, 500 million users is still a huge base, and of course there is considerable potential economic benefits. Astoria applications will certainly not ignore this pie. Microsoft has taken the current mechanism to ensure that the project does not completely kill the development of native Windows applications on mobile phones and small tablet devices. Although the project Astoria will be a very effective springboard, Microsoft is betting that developers don't want to limit their applications to mobile devices. They should be willing to expand their application results to the entire Windows camp, and to do this, developers must write real Windows applications.

But if it turns out that developers aren't interested in the broader market, things could get tricky. Developers interested only in mobile platforms will simply abandon Astoria apps. While such apps may not be perfect, they may be good enough for developers, especially if they never consider developing a true Windows version.

What about Islandwood? It's even trickier. Islandwood apps will be a vulnerable group like traditional Windows apps. They will be special Windows apps written in strange languages ​​that require a large code base to translate their API calls into a form acceptable to Windows, and that means they have the same problems as other Windows apps - they contain a lot of content that can only work smoothly if it relies on Windows-specific code. It can be said that they will not pose any threat to native development work, because they are completely another way of native development.

Once again, Microsoft's strategy does face risks. If the software giant can't get developers to focus on the broader Windows market, Astoria could have a net negative impact on Windows smartphone development. In addition, Microsoft will surely communicate to its developer community that, while there are risks to this strategy, they are not guaranteed to happen. All in all, this kind of talk is completely open to interpretation.

Of course, all of this assumes that Android and iOS developers will at least be interested in Astoria and Islandwood. Considering the widespread influence of the iOS platform, Islandwood's ideas may be more easily accepted by people, but this also requires Microsoft's efforts to promote it. At present, many developers have used C# and .NET with the help of Xamarin to develop applications for Android and iOS platforms. These applications should be able to be ported to Windows 8 and Windows Phone relatively easily-of course, the premise is that developers have the leisure to do so.

If this habit of direct disregard continues unabated, then neither Astoria nor Islandwood will have any significant impact on Windows -- for better or for worse. But if they gain widespread attention, and if mobile developers are convinced that Windows users are worthwhile and easy to win over, then Astoria and Islandwood will give a tiring Windows a shot in the arm.