Software development is at a weird crossroads: there are too many ways to make good software. Or, I don't know, maybe it's not a crossroads. Maybe it's just a road.

Microsoft just announced its "Universal Windows Platform Bridges," in anticipation of Windows 10. The promise is that you can take an iOS, Android, web, or classic Windows app, make some Windows 10-specific tweaks, and ship that app for Microsoft's wild and rapidly expanding range of Windows 10 platforms, including PC, phone, tablet, HoloLens, Xbox, and Raspberry Pi.

I decided to talk with Ankur Vashi about this development. He's a self-confessed former Microsoft fanboy (he even had a Zune!), and he currently is developing the Android version of the Karma app.

Ankur's excited about Microsoft Bridge, but he also sees the hidden "gotcha" in all this.

"Nobody wants to release an app on an app store and let it die," Ankur says. "You want to maintain a good image for your company. Microsoft is trying to get people in the door, and then say, 'While you're here, you might as well devote some resources to it.'"

The Bridge process starts off simply enough: just swap your iOS, Android, or web-specific APIs (hardware or software services like camera access and geolocation) out for Windows 10 APIs, and leave the rest of your code untouched. But to get the "full" Windows experience — Cortana, Xbox, HoloLens — you'll obviously have to do some more work.

This whole process actually reminds Ankur of Microsoft's old internal motto, "Embrace, extend, extinguish," a motto that got them into a bit of trouble with the U.S. Department of Justice a while back.

Embrace the standards of the industry, extend those standards in proprietary ways, then shove out competition once you have lock-in. Microsoft isn't really in a position to do any "extinguishing" these days, especially in mobile, but it's worth keeping mind.

Of course, the worst-case alternative to "extend," a necessary predicate to "extinguish," is a sort of lowest common denominator of functionality. Like the web, for instance.

The possibilities on the web have grown by leaps and bounds in the past decade, but they're still typically a few steps behind what's possible with "native" apps. Native apps are, by their very nature, "extended" with the native capabilities of the particular platform, while web apps have to work with whatever's widely available on the generic web platform.

"If there's anything that's going ever to win out, it's probably going to be web," says Ankur. "The theory is that eventually we won't have a computer with an intense CPU in it, apps are just going to be 'web pages'."

Of course, this is the idea behind Google's Chrome OS, and the functionality built into Windows to run web apps. But, as Ankur points out, Chrome OS is actually bringing Android apps to the desktop now. "And if you look at the future like HoloLens," adds Ankur, "...are our web apps ready for that? The real simple stuff can run on the web, but I don't ever see there being one solution. There's always going to be one guy that does something different."

"There's always going to be one guy that does something different."

Speaking of different, the web folks are now coming up with new ways to use web technology in native apps. Instead of bundling up a whole website, they're using JavaScript (the programming language of the web) to build backends for apps with platform native UIs.

The big news in this space is Facebook's React Native. React is a JavaScript library already used widely at Facebook and elsewhere to drive web interfaces. React Native brings that library to iOS (and eventually to Android), allowing developers to use the same paradigms and programming language they use on the web to build native apps. Contrary to the typical motto of "Write once, run anywhere," the React Native motto is "Learn once, write anywhere."

Google is actually building something similar to React Native for its Dart programming language (targeting Android and iOS as well), which could give developers yet another way to write native apps.

Where's Apple in all this? Well, they're in the comfortable position of a market leader, with little intention of "embracing" anything from outside the company. Apple recently launched its own Swift programming language, but with none of these cross-platform dreams. Swift is simply the new Apple-approved way to build Apple-targeted software.

So, where does this leave developers? Which languages and platforms should they learn? Where does this leave users? Which platforms should they adopt, and what technologies should they expect to power them? I'm not really sure. I think this is an exciting time for software. We're discovering new ways to build it, and some of the barriers between platforms are crumbling. But, sure enough, new barriers are emerging. Do you want your app to run on Chrome OS, Apple Watch, and HoloLens? You have some hard choices to make. Ultimately, developers have to pick the technologies that are best for their users.

As for Ankur, he likes learning: "I love changing languages and trying something different." It seems there will be plenty of opportunity.


About Paul Miller

That guy who left the internet for a year