The 4 Forces Applied: Why Microsoft's Conversion Tool Won't Entice iOS Developers To Windows

Microsoft’s newly announced conversion tool for bringing iOS code to Windows will not be compelling enough to move developers over. The 4 Forces help explain why.

The 4 Forces are a lens used to look at why people decide to change their behavior to use a new product or service. It is a wonderfully helpful way at looking at what factors drive us toward (positive forces) and away from (negative forces) a switch. For a more in-depth discussion, I highly recommend the excellent work of Bob Moesta and Chris Spiek at jobstobedone.org and especially recommend attending one of their Switch Workshops.

Here’s a brief primer on the The 4 Forces:

Situational Push (positive) – This is the force that pushes us toward the new solution. What are the things driving us to want to change our behavior and switch?

Pull of the New Solution (positive) – This is the magnetic force pulling us toward the new solution. What are the new abilities we hope to acquire from the product/service? What will life be like afterward that makes us really want to make the switch?

Anxiety (negative) – What are the risks we see in switching? What do we fear getting wrong?

Habit (negative) – When we adopt a new product/service we are changing behavior. Habit is a strong force to overcome because it requires something to change. What are the parts of what we’re doing now that make us want to stay with the current solution?

Let’s apply this thinking to the Microsoft announcement and see how it illustrates the difficulties Microsoft faces:

Situational Push

Microsoft would hope to have something here with their 1.5 billion users split across (mostly) desktop PCs and Windows Mobile – with Xbox and even Hololens thrown in for a rounding error. All those people represent potential paying customers, so the marketing goes. Why wouldn’t that be appealing to developers?

The truth is the push here is pretty minimal. First off, half of those users are on a PC owned by and locked down by a corporation. They might not even be able to install your app. Second, they are easily reachable by a web app which will almost certainly be a part of the plan anyway and which developers are likely to be far more confident in and comfortable with than a conversion tool that was just released. Charles Arthur did an excellent job raising most of these points in his piece about how this is a technical solution to a business problem.

Pull Of The New Solution

Here is where the forces in favor of Microsoft are at their weakest. What exactly is the amazing new world we will be a part of when we adopt this layer and develop for Windows? The only real selling points I can think of are: better IDE and using our existing code on a previously inaccessible platform.

As far as the IDE is concerned, give Microsoft credit. They are consistently mentioned with praise and admiration by most of the great developers I know who have even dabbled with .Net. And I can honestly say that “complaining about Xcode” is a pastime enjoyed by every great iOS developer – see TextFromXcode for fun and proof. But that doesn’t mean that this will be felt as a strong pull. IDEs are the developer’s workshop and it is no small deal to throw out all of your tools and start fresh. In addition, most of our complaints are nitpicks or related to other problems (e.g. code signing is awful, but that’s mostly an Apple/IOS problem rather than entirely Xcode’s fault). Now 3 or 4 years ago? Xcode was very unstable and there might have been enough concern to justify it. But give Apple credit, they’ve matured Xcode significantly since then. In addition, we’d still be working in Xcode for delivering iOS projects. This means that it can’t be a full replacement, which also means I’d now have to operate often in two totally different workshops.

That leaves the languages problem – how much of a pull is it to use Obj-C on a new platform? The first awkward technical note is that Apple is actively pushing forward Swift, a language seen as an eventual replacement for Obj-C. So why start porting based on a language you probably will move off of anyway? But even setting aside that concern, languages are never a core problem in the decision matrix. I learned Obj-C because I wanted to be coding for iOS and it’s pretty easy to see that I’m not alone in that fact. We engineers are tinkerers at heart: if there’s a roadblock to something we want to do, we learn our way around it. Taking a short path might be nice if everything else was in place, but it’s not that strong of a pull by itself.

Anxiety

Anxiety is where Microsoft begins to struggle mightily. There is a tremendous amount of anxiety in using any tool to port code meant for one platform to another platform. Engineers are well aware of the dreaded corner cases that always show up. Pesky, time consuming gaps in the promise of easy reuse and the reality of necessary polish. Even if Microsoft’s technical execution is stellar (and I assume it will be), there will always be fundamental concerns around how things want to be used on a specific platform that will make things messy.

But a far bigger concern for developers is maintenance. Maintenance is a strong pit of anxiety, combining the least fun parts of a project with the least rewards (no one pays for bug fixes), and the most risky and time consuming efforts. Adding the complexity of a conversion framework on top of that for a platform you (likely) don’t personally use means you’ve got a lot of anxiety to deal with. There had better be a really strong reason to jump into this thing, because it’s a giant engineering red flag.

Habit

The last force is obviously the specific issue that Microsoft is hoping to overcome – habit. Developers are not currently developing dedicated Windows-platform (Phone or otherwise) apps but rather staying with the dominant iOS, Android, and Web. Habit is a powerful force and it’s hard to see major changes that will act to disrupt it in this case.

Even in areas where habit might be a strong pro-Windows force, such as large corporate environments, this is working backwards. Most likely these are .Net developers currently building out for Web. In that case, the tool with habit on its side is actually Xamarin, not Microsoft’s new tool. I’ve long thought it made sense for Microsoft to really hit this hard with an acquisition of Xamarin. It would give them a strong case for enterprise: build your cloud/API, web and client code all from the same stuff using the same tools that you’re already familiar with. That combination might be incredibly compelling for a .Net-dedicated enterprise to adopt based on force of habit alone, but so far there hasn’t been much movement on that front.

Note: Microsoft also released a compatibility layer for Android as part of a similar effort. This piece is focused on iOS since the tools are different in approach – iOS is a conversion tool, while Android is a compatibility layer on top of Windows.While some of the motivations and specifics are different, I also believe it is doomed by much of the same analysis.