This capability cedes a lot of control. By being
dependent on apps developed for a third-party
platform, you give the owner of that third-party
platform the power to choose how to evolve its
APIs and add new features. This bit OS/2 hard:
while IBM was busy promoting how well OS/2
could run 16-bit Windows applications,
Microsoft was busy encouraging developers to
create new 32-bit Windows applications and
end-users to buy the 32-bit capable Windows
95. This new world of 32-bit software wouldn't
run on OS/2, and so the big OS/2 feature that
IBM heavily marketed was rendered semi-
useless. OS/2 found some niche success, but it
was ultimately a failure .
Supporting Android apps creates similar risks.
If Android software constitutes a major part of
a platform's software ecosystem, any changes
to Android (new APIs or capabilities, say) that
Android software expects to be able to take
advantage of have to be replicated. This is,
however, tempered by Android's uniquely poor
update situation. Most Android phones don't
have access to the latest and greatest version
of Android or the latest and greatest Android
features, so most Android software has to
refrain from demanding such capabilities. This
means an Android-compatible platform could
trail Google's cutting edge by a year or more
and still be highly compatible with Android
apps.
This is less true of iOS. A platform striving for
compatibility with iOS will have to aggressively
keep pace with Apple's developments, because
Apple's developer community demands nothing
less.
These concerns are why the idea of Android
apps on Windows was met with what can at
best be described as confusion when it was
first rumored last year. It seemed like Microsoft
was simply preparing to make the same
mistakes others had made before, one last-
ditch effort to prop up its phone platform.
The way Microsoft presented the Android and
iOS support on stage last week wasn't
particularly encouraging. The way that Projects
Astoria and Islandwood—the codenames for
Android and iOS app support, respectively—
were promoted in the keynote presentation, one
might think that the Android and iOS support
were pretty solid substitutes for the Universal
Windows Apps that are native to Windows 10
on all the hardware form factors it will support.
It seemed like porting apps from those
platforms would be an effective alternative to
any plans to develop native Windows
applications.
The risk that Astoria and Islandwood will
further diminish native Windows development is
certainly real. The repercussions of this support
could be every bit equivalent to IBM making
OS/2 compatible with Win16 software, or
BlackBerry 10 promoting the Amazon App
Store. But the situations are not completely
equivalent. While it's certainly not certainty,
one can see how things might turn out
differently for Microsoft than they did for IBM
and BlackBerry.

O.Y.O