The “Backwards” Windows Platform Bridges: The Business Problem
This post exists to build consensus in the Microsoft developer community around the idea of a ubiquitous .NET client application development model. Show your support by voting for this idea here:
Building a Bridge
Lately I have gotten into a “discussion” with a Windows Platform Developer on their blog regarding what I consider to be a “backwards” iOS Bridge being touted by the Windows 10 marketing machine. I use the word “discussion” loosely as since the Windows Blog does not use Disqus (and their blog’s notifications system is broken — can we get a tester here, please?), I have been having to go back there periodically and check to see if a reply (if any) has been made, taking up to a day or two between replies. Hardly efficient (and exactly why I recommend Disqus).
I figure if we are going to spend a few days taking turns with our replies like an old-skool lovebird couple writing love notes through standard horse-and-buggy mail (love you, bro!), I will spend a few hours here and get my thoughts organized around the matter and save myself typing down the road to boot. Let’s just say that I have explained this problem more than once and I am happy to preserve it here now.
What is Backwards Now?
Now there is a new set of bridges that is being provided to Windows 10 developers, and these bridges — in particular the business problem they present — are the topic of this article. Since the Windows Platform Blog post that started this post was about the iOS bridge, I will be using the iOS bridge as the example throughout this article.
There are two ways (or perspectives) of looking at what Microsoft is doing with the Windows 10 Bridges strategy: one is of a technological perspective (impressive) and the other is a business perspective (not-so-impressive). What the Windows group is promoting is the technological feat of being able to essentially emulate iOS on the Windows platform. This is indeed impressive, and I do not want to take away from this accomplishment. This is definitely what everyone is excited about and I have no problem with this aspect, and am actually impressed myself with it. It is also a way of obviously promoting Windows and endorsing good (cross-platform) will to the other technology giants. Again, this is a win for Microsoft. However, once we start looking from the other perspective, we then see that this excitement should find some reason to pause.
This other perspective is the business perspective. If I am a business or ISV, I am going to look at this bridge to find out how it will benefit me most in my line of business. In my case, I want to build a simple application and go to market with that application, reaching as many people as possible with as little effort (cost) as possible. In doing so, I want to maximize my return on investment (ROI) towards building that application and minimize my total cost of ownership (TCO) throughout the application’s lifetime.
I start my market analysis by determining the total possible market, and by ascertaining the maximum market reach I can achieve with as little effort (cost) possible. We’ll start with some recent news articles to size things up. With iOS/Apple, it has been reported that 1B active devices are now in the market running under its platform. With Universal Windows Platform, its platform is growing and is currently accepted to be at around 200M installs (about 16-17% of Apple’s).
The curious dynamic here is that now if I want to build an application and maximize my market reach while minimizing TCO, the only choice I have is to develop an iOS application (via Objective-C or Swift — a first class fully supported technology by Apple), as this is the only first-class supported technology from either major technology giant that now works on both the Apple and Windows Store. Or, as seen with a graph:
I cannot build a Universal Windows Platform application and reach the Apple store. I can do that with a Xamarin application (as discussed below), but now I am using a 3rd-party technology that while is under a partnership with Microsoft, it is not a first class, mature, and fully supported technology stack like what Apple offers with Objective-C and Swift. Remember, I am speaking from the perspective of the _business/ISV_ here and I want to mitigate risk (possible cost) as much as possible. In this case, the more supported and mature platform wins my money.
From the business perspective, the choice is pretty clear to a business/ISV here. As one of these businesses, I would ultimately save (or protect my) money by hiring an iOS resource and building an iOS application which I then host in the Apple Store (1 billion installs), and then host (backwards) into the Windows Store (200 million installs).
Because of this, the value of the iOS developer is higher to me (and the marketplace) as I only need one developer (or rather one code base) to reach 1.2 billion devices. On the flip-side, the value of a Windows developer is reduced to me (and the marketplace) as they (or the code base they create) can only reach 200 million devices. Because of this dynamic, Microsoft has essentially reduced the value of their own developers in the marketplace by providing a first-class supported technology in its Windows 10 iOS and Droid Bridges.
Now, there might be a time that Windows 10 reaches 1 billion installs (and it should, Windows 10 is pretty awesome), but even in that case, I as a business/ISV cannot reconcile hiring a Windows developer, as I am still having to hire (and manage) two resources (and code bases) to maximize my hypothetical market reach of 2 billion total devices — adding to my total cost of ownership. From a TCO perspective, I would still choose to hire an iOS developer as I can reach 2 billion devices with one developer and one code base.
What About Xamarin?
Now, a savvy and informed Microsoft technologist will look at my issue above and point out that I can also use Xamarin (or to be more exact, Xamarin.Forms) to build a bridge out to iOS (and Droid). However, in addition to what I outline above of only being a 3rd-party partner (and an immature product when compared to Objective-C/Swift) and not a first-class, supported and endorsed technology stack offered by Microsoft (as Universal Windows Platform is), it does suffer from some drawbacks that I have found in the course of using it and exploring its strengths and weaknesses.
First, I would like to say that I am a fan of Xamarin. I went to their Evolve 2014 (on my own dime, at that!) and had an absolute blast. It is a great company with lots of promise, full of talent, and I am a big fan of their partnership with Microsoft. There is lots going on with Xamarin and I support them in their efforts. However, as with any company (even Microsoft :)), there are some things that Xamarin does great, and some things that need improvement. I have mentioned these aspects in various places throughout the interwebs, but now I will put them here to preserve my sanity and save some keystrokes in the future. Let’s start with the good:
Xamarin is great with their toolchain and their cross-platform API provision and support. Their compilation and integration with Visual Studio is fantastic and that is where they really shine (and in my opinion should assist Microsoft with a ubiquitous .NET client application development model offering). Xamarin Studio should also be commended as it is also providing access to .NET development in a cross-platform manner. When I think what Xamarin excels at and its true value proposition, it is tooling and APIs. I think it’s smart to charge for this value (it might be a smidge high, as I explore below — but smart nonetheless).
Also, Xamarin is at present the premiere client technology innovator of the .NET ecosystem. Really, if it weren’t for the Azure group, they would be the bastion of innovation in the Microsoft empire. This is of course ironic as again they are a 3rd party partner, not an internal division. They saw the open source and cross platform market before anyone else, and now they own the market in this area (much to Microsoft’s chagrin at the moment, I can only imagine — only further complicating the current marketplace climate). After spending my time in Evolve 2014, it was clear that this company feels and sounds like a younger Microsoft, full of ideas, talent, and promise. In fact, a tweet I made shortly after reflected as such.
After Evolve 2014, I spent a lot of time with Xamarin.Forms and its code. I have to say I was really excited about Xamarin.Forms when I learned of it. Fanatical, even. However, after a few months of use and analysis, several detractors started to emerge and I will aim to list them all here. These are also issues I have arisen in various interweb locations so it is nice to get them all organized in a list, so here they are:
- Adaptive platform approach. We’ve seen how a consistent user experience quality is desired for a ubiquitous .NET client application model. We’ve also seen how Xamarin.Forms at present does not satisfy this quality. Although it is a novel approach (and it should most definitely be recognized!), it does pose some problems (mentioned below). Also, as we can see with other technologies, we are starting to see consistent cross-platform user experience becoming the norm. Here is a list of known technologies that provide a consistent user interface experience:
- Closed (internal), enum-based rendering API. Not as critical, but it will help explain the next point. The internal rendering system is completely closed and not extensible in any fashion. If you want to design your own renderer (for, say, WPF or HTML5), you have to decompile their (closed-source as I describe below) assemblies and reverse engineer from there. Hardly a flexible offering or a worthy value proposition (not to mention legal). Additionally, if you look in their platform API, you will find things such as the Xamarin.Forms.TargetPlatform enumeration. To me, I would expect to see a platform profile object, full of capabilities and properties. Instead, you see a lot of switch-cases in the API code, which is not a desired way to design an application.
- Control vendor design friction. Due to the design of their rendering API and adaptive platform approach, there is a strategical flaw in how they allow controls to be designed for their platforms. If you are a control designer, you have to create a renderer for each and every platform that Xamarin supports. This is cumbersome and expensive. If Xamarin adds support for a new platform (and it should definitely have the mindset that a new platform is always on the horizon), the onus is on control designers to retroactively build a renderer for each and every one of their controls to support that new platform. This is unfair to the control vendor. Ideally, the onus for such design should rest within the platform itself. That is, adding a control from a control vendor’s point of view should be seamless, and much like building an application on the platform, the focus/thought/effort should be on the problem area/concern that the control solves, not lower-level concerns such as drawing/rendering.
- Internal Xaml system. This is probably the biggest issue to me, personally. Xamarin uses its own flavor of Xaml parsing, and while it does some things well (Xaml 2009 specs, horray!), it has some major limitations and oversights, the biggest being the lack of XamlServices parity and tight coupling of its parser to the BindingObject (also note that this bug is considered closed/answered when it is very much still an issue). There are other known issues, such as not supporting the design-time d: prefix and a bunch more (you can see how each of the items I have reported have been dismissed or ignored). A lot has happened in the past year, so it would be great to see if Xamarin will help shape the next version of .NET Core Xaml.
- Not Open Source. This is really surprising and confusing to me, especially since it is a company that is founded on Mono, which is considered to be (from what I understand and please feel free to correct me in the comments) the origin of the Microsoft open source movement. A push to open source Xamarin.Forms is also one of the top asks on its UserVoice at the moment. How can a company based on a product that is considered the flagship vehicle for the open source movement in the Microsoft community be closed source? Inconceivable!
- That price thing. This really doesn’t bug me (and I honestly hesitate to list it here) as I try to be business-minded and understand business models. However, Xamarin’s price tag is mentioned at every turn whenever it is brought up, especially on forum posts and blog comments. It is even mentioned in the Visual Studio vote for a Cross-Platform UWP. In my view, this is more of a stigma and issue of perception than anything, and Xamarin should put some (clever) cycles into combating it. Maybe offer the first year at ultimate level for free?
It might seem like I am a hater from the above list. But, keep in mind this is for Xamarin.Forms (a product that is only a few years old) and not Xamarin as a whole. I am definitely a fan of Xamarin and hope to continue to strengthen their relationship with Microsoft. Also, this is all based on current design and available knowledge based on current Xamarin offerings. I am certainly looking forward to Evolve 2016 and will be excited to learn what is unveiled there at that time. Is it possible a new ubiquitous .NET client application development model offering will be unveiled?
In case Xamarin doesn’t announce the next greatest technology advancement since Silverlight at Evolve 2016, please take a moment to visit Visual Studio’s UserVoice and let them know you would like to see a ubiquitous .NET client application development model offering by clicking our vote button here: