The Gang’s all Here: Astoria, Islandwood, and Westminster

So there’s been a bit of a haze lately about Microsoft allowing for a few new ways of getting apps onto Windows 10 Mobile. (Code-) Namely, Astoria, Islandwood, and Westminster. Or, Android apps, Objective-C, and JavaScript apps.

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.

Westminster (JavaScript) apps are another access point for web apps. By making a Westminster app, you allow your web app to access COM items (like local storage) if you choose. Really, you’re adding a portal to the store when you use this. FireFox did something similar with Open Web Apps. Again, this just allows one more means of bringing apps to the store.

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.

The other concern I’m hearing is that these apps will flood the store. Harrumph. First: These bridges will only allow access to Windows 10 Mobile devices (sub-8″ screens). Not desktops. The exception is Westminster apps, but JavaScript apps already were a thing (natively) under Windows 8.x. Quite frankly, Windows Phone is an under represented platform as it is. Lots of groups ignore it with their phone apps, but now that could change.

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.

This entry was posted in .NET, Windows 10 and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s