Previous articles in this series looked at mobile app development in terms of the raw data available from the sensors that are built into smartphones, as well as the increasing role of connected wearables and other smart external devices.
This post tackles the major topics of integrating Google Fit and Apple Health – the two most significant and widespread platforms for sourcing and contextualizing health, wellness, and fitness data.
If you are interested in creating a health-related mobile app, what do you really need to know about the two major health and fitness platforms?
The Apps: Google Fit and Apple Health
These platforms can help your app get instant liftoff. Both Google Fit and Apple Health are free mobile phone apps in use by millions of people. Health comes pre-installed on iOS smartphones and watches, and Fit is a free download from the Google Play Store. The compatibility of your app with one (or both) adds value for mobile phone consumers.
Google Fit is available for both Android and iOS smartphones, as well as for Android Wear OS watches. In addition to the features of its own platform, it can connect to Apple Health and its synced apps. The Google Play Store lists several Fit-compatible apps as well as a list of apps that work with Apple Health on Android smartphones.
Apple Health is more proprietary in nature and is not available for non-iOS devices like Android. The Apple App Store claims over 16k apps use APIs from some combination of Apple HealthKit (for Apple Health), CareKit, and ResearchKit.
While they do utilize information from smartphone sensors, much of the functionality depends on pairing the app with a compatible smartwatch or fitness tracker. Apple Health works in tandem with Apple Watches, while Google Fit works primarily with watches running Wear OS. Other trackers can sometimes be paired with each platform but may require a third-party syncing app, like Sync Solver (for Apple Health) or FitToFit (for Google Fit). The same is true for Bluetooth-enabled devices, which often require a dedicated additional app for the device in question.
Both apps provide daily dashboards and histories of items like steps, exertion levels, and the cultivation of healthy habits.
Google Fit Focuses on Specific Workouts While Apple Health Tracks Overall Wellbeing
Overall, Google Fit has its sweet spot in helping consumers develop habits to be more fit and well. Fit focuses first of all on the frequency and intensity of physical activity using point systems – Move Minutes and Heart Points. Heart Points was based on recommendations by the World Health Organization (WHO) and the American Heart Association (AHA). Other associated areas like nutrition, hydration, and sleep depend on user self-reporting or connected apps. Since Google ID is used, Fit has access to other Google Services so, for example, Google Calendar can be used to add scheduled exercise by time, duration, type and recurrence.
Apple Health has more features that relate to overall health information and tracking, including an emergency medical ID. Apple Health users can download and update elements of their clinical records from healthcare institutions.
As Wareable states, “All in all, Google Fit is more proficient at specific workouts, and may be better if you’re looking for something to regularly hit the gym with; Apple Health is better at keeping track of your wellbeing.”
These two apps have more in common than these initial highlights would suggest. They are competing in much the same space, using very similar methods, and in a changing, shifting landscape.
If a feature that you want to create in your app depends on data that is only collected via the tools of iOS or Android devices, you may decide to create only one version. Your mobile app could be designed for use on either Apple iOS or Android smartphones, or you could produce a version of each. The other option is to develop a cross-platform app with slightly different features using a development framework like React Native, Ionic, NativeScript, PhoneGap, or Xamarin.
Behind the Apps: Data Integration Hubs, SDKs, APIs
The Apple Health and Google Fit mobile apps are only the user-facing parts of much larger ecosystems.
On the back end, Google Fit SDK and Apple HealthKit are secure open-source integration platforms that collect, organize, store, and track the health and fitness data from multiple services and applications. That’s where they become interesting for mobile app development.
Both platforms were architected to make data sharing, storing, and analysis easier for developers. In addition to collecting vital user data needed for functionality, much of the development work for obtaining and sharing structured data has already been done. The platforms also process calculations, aggregates, and correlations to produce additional data points and histories – all ripe for further analysis. If your app meets certain criteria (more on that later), you can utilize the resources of the open-source software development kits and the platform APIs to support additional services.
The SDK (Software Development Kit) – or “Kit” for short – refers to the whole open-source platform that provides the tools and documentation that allow for the creation of applications. SDKs are organized in terms of intended operating systems, programming languages, and type of APIs (Android, REST) for the in-scope hardware.
- Apple HealthKit and HealthKitUI frameworks are available for iOS 8.0+, Mac Catalyst 13.0+ and watchOS 2.0+. iPhone and Apple Watch each have their own HealthKit store, but HealthKit is not available for iPad. Programming languages are specified as either Swift or Objective C. Health information is stored in the iCloud.
- Google Fit SDK includes the fitness store (a Google cloud service that stores the data from devices and apps in a secure repository), the sensor framework, permissions and user controls, and the Google Fit APIs.
APIs (Application Programming Interfaces) allow for the functioning of applications within the SDKs defined parameters and are what enable blending data from multiple apps and devices. The API is simply an interface that allows software to interact with other software, a set of public methods and properties that interact with objects in your application. Mobile apps can read data via APIs from dedicated URLs that return structured data “objects” that can interact with one another. Users decide the scope of permissions in terms of which kinds of data may be shared with specific apps and services.
Subclasses of data types define the schemas for a stream of data being collected by, inserted into, or queried. A data type can contain one or more fields, from stable data to complex data types that combine samples of data or compute aggregate values over sets of samples. Sources of data are identified, whether they are phone sensors, wearable devices, user input, connected apps and services, or data transformations on these.
Apple Healthkit vs Google Fit Data: What Data Matters Most for Your App?
What kinds of data exist or are provided for by each platform, and how are they organized?
Pro-tip: Start thinking about what services your app could provide in this kind of space:
- What kinds of data might your app require, and why?
- From what source or sources would that data originate – User self-reporting, Android and/or iOS smartphone phone sensors, watches/fitness trackers, Bluetooth-enabled external devices?
- Will the app require the use of data that is sensitive, protected or restricted? How might you use or create calculations, correlations, aggregations, interpretations?
It may be a little difficult to track through the SDK documentation on each platform. A scan of the summary schemas of Apple HealthKit and Google Fit data types at the end of this article can help you to determine whether the architected data types of either platform might provide or enable features for your health and fitness-related app.
You may be able to use very few metrics to provide a useful service, but if you are interested in building out additional value from specific kinds of activities or health metrics, there are built-in variables and ways of adding some kinds of data to both platforms.
Google Fit allows non-health custom data types, and some kinds of metadata can also be added to both platforms or within your own app. Here, you’d really need to consult with developers on best practices for utilizing the platforms.
As an illustration of the kinds of things that are possible, consider weightlifting. On either platform, a user may add a workout session under a weightlifting category, and track some basic metrics about heart rate, exertion, duration, and the like.
However, additional workout activity variables are already available to be used as structured data. Specialized enthusiasts would want to use those variables to produce more meaningful analysis, perhaps to track combinations of repetitions, sets, weights, and types of exercises toward goals. Apps such as Strong, Fitness Point, and Fitbody have taken advantage of that expanded data set and added their own features to it.
Health Data Can Be Leveraged Across Apps
In new mobile apps, nutritional information can likewise be repurposed and expanded for customized dietary plans. Water intake can be recontextualized for use cases like camping trip inventory planning, and depletion of stores. The whole health and fitness quadrant could be made a part of a more encompassing smart home dashboard keyed to each household member.
Privacy, Access, Policies: Reading and Writing Data to Google Fit or Apple HealthKit
Your app’s ability to obtain, hold, or share types of data is determined by many factors. User consent, privacy, security and other related app development guidelines are reviewed and enforced by Google, Apple, and governmental authorities. Some data is classified as restricted, protected, or sensitive. Some data can be written, but not read by other apps. Some user data is not available for use at all, and some user data is tied to the larger ecosystems of Google or Apple services.
Start With a Streamlined Approach
If your app is intended to fit into the health and fitness vertical, start with the bare minimum of metrics that you would need for your app to function in its intended way. Even with just a few data points and other features, new apps can provide valuable services.
If your app is focused on exercise, weight management, nutrition, or standard physical activity tracking, then you can drive value by articulating how exactly your app will add to (or link up with) the architectural capabilities of either platform. Fitness-related apps can provide additional value, such as balancing activity types or comparing the results of different strategies toward fitness goals. The bar is higher for medical apps, such might be used for diagnostics, remote monitoring, disease management, medication management, or personal health records.
Case Study: John Hopkins’ Corrie Health Program
Physicians at the Johns Hopkins University of School of Medicine developed the Corrie Health program to achieve remote monitoring, support, and data collection for recovering cardiac patients. For their app, they used data from Apple Watch, and from a Bluetooth blood pressure cuff that writes directly to the Health app and is shared via HealthKit to their own app. They added consent and survey modules from Apple’s ResearchKit, and tasks, contacts, and care plan store modules from CareKit (ResearchKit is intended to help researchers with enrollment, informed consent, and frequent medical information gathering. CareKit helps medical care teams stay connected with patients by making it easier for patients to record and share health data). Patients recorded daily progress on steps, heart rate and blood pressure, and were given resources for recovery on topics like diet, medication, and mindfulness techniques.
In this case, Corrie Health developers made an initial ecosystem choice: for Apple iOS devices and the Apple Health-related SDKs, including HealthKit. A second version released in the Google Play store allows their patients to use Android smartphones and substitutes Fitbit Versa in place of the Apple Watch and blood pressure cuff. Since none of the data was used for diagnostic purposes, but only for communication, encouragement, and basic aftercare, they were able to provide services to their patients without having to confront some of the regulatory difficulties involved with the use of strictly medical devices and apps. Still, this application may have been marketed in an overly medical fashion to be acceptable to Google Fit; it doesn’t appear to be integrated or compatible.
Health apps do need to categorize personal identifiers, health, and medical data differently than fitness data, in order to treat the data with a higher level of security.
Significant opportunities exist for robust apps that would do a better job of integrating or associating data from additional smart external device apps (thermometers, heart rate sensors, scales, and glucose meters) into Google Fit and/or Apple Health.
Android 4.3 (API level 18) now introduces support for mobile apps to find, query, and transmit data from Bluetooth Low Energy (BLE) devices to Google Fit, whereas Apple Health tends to restrict some external devices in terms of Apple branding and partnerships.
In the middle of a pandemic, a greater variety of robust non-contact smart thermometers would be helpful, even if that data is not used for official diagnostics. Some manufacturers like Kinsa and Vicks have built out their own apps.
Regulatory Approval Is The Barrier Between A “Wellness” and A “Diagnostics” App
One of the big problems is that without regulatory approvals from governmental entities like the U.S. FDA (Food and Drug Administration), medical devices can only be used as a “wellness” feature, and not for diagnostic medical use. Apple did get clearance to use the EKG feature of the Apple Watch as an early warning of irregular heart rhythms, but only for that scope of use.
The FDA’s Unique Device Identifier (UDI) initiative requires the assignment of a distinctive identification number to all regulated medical devices sold in the United States — from manufacturing through distribution to patient use and digital records.
General health, fitness, and wellness features that are not used to diagnose do not need FDA approval, so Apple, Google, and others are mindful about what is claimed, and how any of this is marketed.
Companies and developers must be aware, and compliant with law and policy when developing and distributing mobile apps. Both Google Fit and Apple HealthKit require fine-grained user permissions for reading and sharing data, and a multitude of security, privacy, and access policies and laws come into play for both platforms.
Apple Store review guidelines for mobile apps must be adhered to, and protecting user privacy is of utmost importance. Health data, especially those involving clinical medical records, have significant additional requirements for use. Each time your app requests incremental new permissions, the Health app displays a form to the user with all the requested data types.
For Google Fit, Google policies apply, as do policies of the Google Play Store. APIs cannot be used for regulated medical devices to perform their intended function, and any use case for protected health information must formally be approved. Their permission group categories are used to classify separate read and write privileges. Google Fit requests the corresponding permissions from the user. When a user allows an app to read one type of data, that app can view all the information data stored under that type, including data collected and stored by other apps. Your app can also write some kinds of data to the Fit platform, particularly activity segments that help contribute to Heart Points goal.
A Note on In-Progress 2021 Changes to Google Fit
Developers of new apps will want to familiarize themselves with the Google Fit Developer and User Data Policy. Changes that will affect all apps are being made to the next version of the Google Fit API and are enforceable as of April 27, 2021.
Google Fit has carved out independent, dedicated scopes for heart rate and sleep, and updated technical guidance on topics like session/data access, and incremental user authorizations for new data. Google has stopped taking new requests to write to their health data types while they review the approval policy, but verified apps can read health data with user consent. The review and verification process will also be tightened up for increased security and privacy.
Mobile apps will need to meet higher compliance requirements depending on the scope of the data they wish to read or write to the platform. Fitness API scopes for write access will be classified as sensitive, and all scopes for Google Fitness read access will be classified as Restricted. (Restricted scopes are also used by the APIs for Gmail and Drive.)
According to Google Cloud Platform Console help pages, “The applicability of this requirement to your app depends mostly on two factors: the type of user data you access—public profile information, calendar entries, files in Drive, certain health and fitness data, and so on—and the degree of access you need—read-only, read and write, and so on. When you use OAuth 2.0 to get permission from your users to access this data, you use strings called scopes to specify the type of data you want to access and how much access you need. If your app requests scopes categorized as sensitive or restricted, you will probably need to complete the verification process.”
The Changing Landscape of Health and Fitness Tech
The biggest tech companies are all continuing to develop new tools for consumers, medical professionals, and insurers as healthcare is continually being reshaped. The number of connected devices is already in the billions, increasing the need for smarter methods and platforms of interconnection. Eventually, more apps will seek medical-grade approvals.
A wide range of innovative applications are possible: integrations with hospital software, external device and services integration, AI-driven analysis, health monitoring and alerting, symptom checkers, medication management, risk of injury management, physical training effectiveness, patient locator, sleep quality monitoring, and guided therapies are only a few examples.
During the last few years, and especially as a consequence of the pandemic, the two ecosystems have moved toward one another, both in cooperation and competition. A few news items will suffice to illustrate the shifting ground.
- Apple and Google have been working together on ways to find solutions to Covid-19 pandemic problems, including contact tracing with Bluetooth technology, and an exposure notification system. Under newer data regulations in many countries, privacy and security concerns are front and center. At the same time, there is an atmosphere of widespread criticism about anti-trust issues, advertising, markets, and perceptions of union-busting and other worker issues.
- The CEO of Alphabet (Google’s now-parent company) is in the process of reviving the Google Health team and expanding on its AI research in healthcare. Since 2018, the Google Health group (Fit, Google Search, G Suite for healthcare, Google Brain, health teams from Nest Labs, Alphabet subsidiaries DeepMind Health, Verily and Calico) have been working on electronic health records, imaging and diagnostics, consumer and clinician tools, and research.
- There has been some speculation about the reasons for delayed Google iOS updates.
- Google acquired FitBit in January of 2021, which itself had recently added Premium Membership and Premium + Health Coaching subscriptions for additional health and mindfulness metrics and analysis.
- Apple Health has recently added a subscription for Apple Fitness+ for Apple Watch (Series 3+) with a catalogue of workouts and in-session metrics that sync to iPhone, iPad, or Apple TV. The subscription can be bundled into other paid Apple services.
The pandemic has highlighted weaknesses in areas such as supply chain management, data visualization, situational awareness, and telehealth that further innovation could continue to address. Technologies for better Bluetooth device integration options, additional standards, data stream analyses that are more useful to different consumers and institutions, and even public health education tools are also needed.
Can you contribute?
