First, let’s look at what these individually mean, and then I’ll let you know what I think about the whole brouhaha.
Islandwood (iOS) apps are often said to be apps dropped from the iPhone into Windows. This is only partially true. You see, the Islandwood project actually centered around making Objective-C a native language for Windows Mobile development. It also entailed getting Xcode projects to load in Visual Studio. As a result, Microsoft has, effectively, increased the number of developers. Further, an iOS app won’t (necessarily) just work. It likely will need some code tweaking, so don’t expect an incredible flood of new apps (though there will be some). This is merely reducing the barrier for companies to bring their existing code to Windows 10 Mobile.
Astoria (Android) apps are a different beast than the others. Here, you really are wrapping your Android app for use in the Windows Store. The reason is that the wrapper will intelligently redirect some services on Windows 10 Mobile. That means that, in some cases, the app will work differently and may require a lot of tweaking. This is different from Islandwood, since that uses a native language and has no smart re-directing (ie. more re-writing code). As a result, simple Android apps could simply be dropped in the wrapper and just work.
So, most of the negative things you hear about these bridge options are that it removes the need for native development. Pshaw. Two of the options are native development. Objective-C is a native language for Windows 10 Mobile, and accessing the COM items will require new code for Westminster apps. Arguably Astoria apps are different, but unless they’re bog simple those apps will require some new code.
So, these bridge solutions only affect mobile devices, two of three are native, and all will require extra coding to work properly. As far as I’m concerned, this is a great thing.
Now let’s work on getting the other platforms to open their doors.