Google launched a preview software developers kit (SDK) for the Google Fit fitness app platform at Google I/O earlier this year. Similarly, Apple launched their new Healthkit API at Apple’s WWDC 14 — and clearly healthcare will be a big focus for Apple with their Apple Watch. Developers are now able to create and test health and fitness apps for Android and iOS 8.
Both platforms facilitate the integration of your various fitness apps and wearable fitness devices. It does so by storing data outside of the app. Each health or fitness app can access and modify the data with the user’s permission. Third party health apps can store data in specific types related to health and fitness (such as heart rate). With these universal data types set, the apps can read stored data and get a broader picture of a person’s health than the app could have found alone.
With such personal data, there are obviously major privacy concerns. Apple is attempting to address this by banning app developers from selling HealthKit data or storing it on iCloud. Google insists that the user is in control of health data as apps cannot access it without the user providing permission.
Both APIs make life easier for app developers. The APIs take care of a lot for the app developer. Using Apple as an example, if a health app or device records your blood pressure, it communicates this with HealthKit, and that data is stored in a standard blood pressure format. It enables a level of uniformity for storing patient data.
If you want to use blood pressure data, you just ask Healthkit for that data type. Healthkit can give you the historical data as well as give you new blood pressure data as it comes in. This provides a couple of advantages. First, the app doesn’t have to repeatedly convert raw data into something that can be easily used for blood pressure purposes. Second, as a universal blood pressure data type, every app can recognize the stored data as blood pressure. Therefore, all apps can recognize blood pressure data types, read stored data, and listen for new blood pressures. Google Fit works the same way.
Again — this level of uniformity when measuring patient health metrics is a big deal.
Because Healthkit and Fit take care of so much, developers can focus on the unique benefits their apps provide. The app may want to display a graph of blood pressures over time, setup alerts for poorly controlled blood pressure, suggest lifestyle changes, or anything else the app developer thinks will be useful.
The difference between Google and Apple lies in Apple’s Health app. iOS 8 has the health app built in to graphically display and explore all of the data handled by Healthkit. Using a single app, users can look at all of their health data. For example, they can look at a chart of blood pressure over time or individual data points such as total steps taken without opening a separate app.
Unfortunately, Google Fit has stopped a step short. They have left the development of a central interface to third party app developers. Where Apple has put forth their vision of how the data should be centrally displayed, Google has left it completely open.
The argument can be made that leaving it open creates a greater opportunity for the development of a better interface. The problem with that argument is that opportunity is still available on iOS. The difference is that Apple has hit the ground running.
Google needs to present their vision for the best user interface for centralized data. It should be the core of Android — not something other manufacturers add (e.g. Samsung S Health). Google needs to step up, not only for their users, but to push Apple.