Are you considering having an app tracker built for fitness and health purposes in both iOS and Android? Today we will look at how these ideas can be implemented using two available frameworks.
With the rise of health awareness, application developers are constantly finding new and innovative ways to satisfy the growing demand for health standards.
An active role in promoting such movements is played by two giants, Apple and Google, who developed their frameworks known as HealthKit and Google Fit, respectively. These services play very similar roles, acting as health data ecosystems; however, as we will learn, their strategies differ in numerous ways.
Although the products serve a similar purpose, Apple offers far less compatibility than Google. Both frameworks can be used for smartphone app development; however, Apple does not offer support for tablets as of yet.
Moreover, users can launch Google’s native app, known by the same name as the framework, on both smartphones and tablets, with a web version of the app also available. However, Apple’s product is limited to smartphones and the later generations of iPod Touch. Many also believe Google might eventually add compatibility for iOS, something that Google has practiced previously with Google Maps and Gmail.
If your app is going to work with non-standard data types, it is important to understand how it will be supported in the platforms.
Google Fit, as the name suggests, offers mostly sports-related data by default. Its Terms and Conditions, it state that the app is not intended to be used for medical purposes, a path Apple does not follow. Although the developer may create custom data types, this data may only be seen by the app that defines it. The developer is not limited to a list of available custom datatypes—for example, it could be a level of saturated fat.
Apple, in turn, provides a broader list of already available data types such as gender, fitness, nutrition data, food, sleep patterns, etc. However, at the same time, the developer may not create custom data.
Every app that is going to use either platform is going to have to ask for permissions. The difference is in approach. While both companies value their customers’ privacy, Apple takes a much stricter and more defined approach to this aspect of their platform.
For HealthKit, the app will have to request permission for every type of data to be read or written, whether it is sugar levels or heart rate.
Furthermore, it is of great importance to be descriptive when requesting to read data that is not written by your app since you will not know if you have been denied access to it—it will simply appear as if there is no data to request. This would prevent the developer from alerting the user that the app lacks access to essential information due to denied access.
For Google Fit, the app may have to ask for up to three permissions—activity, location, and body—a more lightweight approach when compared to its rival.
In this department, Apple again puts more emphasis on security, having all user health data stored locally on the user’s device. This is as opposed to Google Fit, which has its data is stored on Google’s cloud.
As an added bonus, Apple offers their users an additional choice: if desired, the user may back up his locally stored data to Apple’s iCloud.
We have reviewed some of the major differences between these two platforms. Of course, there are more hidden obstacles to fitness apps integrated with these frameworks.
You are welcome to review our recently produced prototype apps for both iOS and Android:
Our specialists at DB Best can develop apps of this nature as well as suggest solutions and alternatives. If you are interested in more of our products, visit our portfolio.