Recently, Microsoft discontinued the Microsoft Band SDK, and removed Microsoft Band from its online store. "Band" (as the fitness band was known) was Microsoft's entry into the fitness wearables market, and the entire product stack consisted of the following pieces:

1. The physical band.

2. The Microsoft Band SDK, a Windows Phone SDK targeted at the Band. The SDK was primarily used to write apps for Band, or to integrate Band data with external applications.

3. Microsoft Health Platform. This is the data store and tools to access it. Microsoft health and fitness products – primarily through the Microsoft Band App – report data to the Microsoft Health Platform, where it is accessible to app developers.

4. The Microsoft Band App for phones (formerly Microsoft Health App). This is the link between the Band Data and Microsoft Health. It also allows local analysis of users’ Microsoft health and fitness data – from Band, or several Windows phone platforms.

5. Microsoft HealthVault. While Microsoft Health is a data store for health information from Microsoft devices, Microsoft Health Vault supports a wide selection of other devices, and can include a wider selection of information relevant to overall health than Microsoft Health supports. Finally, HealthVault is promoted based on its ability to share information with your doctor. Since the use of Microsoft Health Vault is optional, and the user has to actively configure the link between Microsoft Health and Microsoft Health Vault, we will not discuss it much in this article, except as an alternative location for apps to target.

At the time of this writing, only the physical Band and the SDK for writing apps targeting it have been discontinued.



For those developing explicitly for Band, this is a rude awakening. While any code developed for Band to date will work with the installed based, Band's discontinuation means the end of any opportunities (financial or otherwise) that developers may have hoped for going forward. Their investment in the product will have been mostly for naught. While the APIs for accessing the Microsoft Health data store are still online, and Microsoft indicates they will remain online, there is the question of the longer-term implications now that Band -- one of that data store's primary inputs -- is going away.

The current version of Microsoft Health is integrated with the Microsoft Band phone app, which can track some things, like steps, without a wearable device. This data is then reported to Microsoft Health, and is available to those who integrate with Microsoft Health via the API. This same data can be sent to Microsoft HealthVault if the user chooses, and developers can target Microsoft HealthVault with its larger set of possible inputs.

We reached out to Microsoft for more information, specifically asking what this meant for the future of Microsoft Health and to clarify what devices are capable of reporting to Microsoft Health. According to a Microsoft spokesperson, not much: “We continue to invest in the Microsoft Health platform, which is open to all hardware and apps partners across Windows, iOS, and Android devices. There is no change to the Microsoft Health platform, which will continue to support Band as well as connect users to Cortana, HealthVault and third party services. If interested in learning or developing for the Microsoft Health platform, please visit https://www.microsoft.com/microsoft-health/en-us.”



Since Microsoft renamed the Microsoft Health App to Microsoft Band just a few weeks ago, we asked about that change and if it meant anything for the discontinuation. A Microsoft Rep told us:

The “Microsoft Health” app has been renamed “Microsoft Band” to better reflect what the app is primarily used for today – setting up and updating the Microsoft Band. There is no change to the Microsoft Health platform, which will continue to support Band as well as connect users to Cortana, HealthVault and third party services.

While that does help clarify a bit, it appears to us that Microsoft HealthVault would seem to be a more viable option because it can pull data from the existing Microsoft Health data and from a wider range of devices (though not the two biggest competitors).



We asked Microsoft about the migration of Band developers, and the same spokesperson responded “We have been working to redirect developers to Microsoft Health.” While for some developers this is probably a usable answer, for those that were using real-time data, or targeting the Band UI to communicate with the wearer, it is not a useful solution.



This brings up several more general issues though. While rumors of Microsoft Band’s demise have been around for a while, the risk of investing a lot of effort into an API or SDK and having it become somehow limited or non-existent is very real. The best way to plan for this possibility is to know a competing API or SDK and what steps you would have to take to implement it.



Depending upon the APIs or SDks, and what you are getting from them, this type of planning can reveal some serious issues with replacing a vendor. To some extent, mobile apps often mirror the APIs or SDKs used to build them. When the API returns certain data, the app utilizes that data, often causing design changes in the app to conform to data available via the API. Developers often run into the issue where the data they want is not available from an API. Or, in contrast to such a dearth of data, sometimes extra data is returned from a third party API, giving developers ideas for additional enhancements.



Those changes to how an app works based upon API responses can make moving to a different API (or APIs) an onerous task. App developers often tie the end-user experience to the capabilities of the underlying APIs. As with many categories of products and services, there are no standard schemas for representing the health data that's collected by the many fitness bands on the market. So, to the extent that developers have tied the U/X of their apps to the underlying capabilities of an API or SDK whose contract is essentially breaking through product retirement, it's not as simple as just swapping another product and it's API in. The app, its U/X, and any data workflows found within the app's logic may have to be rebuilt from the ground up in order to take advantage of a substitute API. So how can developers avoid situations like this one?



The short answer is that it is impossible to pick an API or SDK that is guaranteed to be around for the life of any given application. There are good bets in large markets – the likelihood of Google Maps going away is slim, for example. But even this indicator would have failed for Band. Microsoft is no small organization, and the Microsoft Band App is still available on both Android and iPhone stores. While the Apple App Store does not indicate number of downloads, Android is showing hundreds of thousands for the Band App, so it would have been tough to determine that this had limited life before the rumors started in July or August, since most installations of the Band App were for Microsoft Band.

Normally it is easier to judge viability than in this case, but takes a bit of legwork. Just like purchasing an application for corporate use, it is worthwhile to understand the viability of the vendor, the vendor roadmap, and the state of their market. As it is your app being built on it with your investment in resources, making certain you know the strengths and weaknesses of those that control the APIs you're depending upon is an important survival instinct.

In this case, the above would have checked out fine. The only note of caution that could have been sounded would be Microsoft’s history in the small device space, which definitely shows varying levels of commitment over time. But the reception for Microsoft Band was resounding enough that it would have been reasonable to develop to the Band architecture. So that wouldn’t even have been much help.

What can developers do to avoid this type of problem in the future? Write to aggregation APIs instead of individual vendors when dealing with IoT and wearable spaces. While any given product and its supporting infrastructure may come and go, aggregation APIs will be significantly less impacted by those changes. In the case of Microsoft, HealthVault (a separate product from Microsoft Health) is an aggregator that takes input from several Microsoft and non-Microsoft sources, including Microsoft Health. By working with the APIs for HealthVault instead of the APIs or SDKs for any specific source of data to HealthVault, developers are afforded some protection in the event that a product drops out of the ecosystem. As fitness ecosystems go, Google Fit is similar in this capacity to serve as an aggregator for multiple devices and serves developers through Google's Fitness API. Our own directory can help you find aggregators you trust. While this is good advice for aggregated data from several sources, it is not useful for specific use APIs and SDKs. For those cases, your best due diligence will have to do.



Luckily, most of us were not impacted by this particular change, but it does give us reason and opportunity to reflect on the dependencies we’re building in to our applications every day. Make certain you know your API vendors, and their commitment to your space, because your app and your business just might just depend upon it.