The Complexity and Modular Design of Apple’s Health App

Mary Margaret Herring

In the readings from last week, Arthur elaborated on the concept of combinatorial design. He argued that new technologies were simply novel combinations of existing technologies (Arthur, 2009). Apple’s health app seems to exemplify this principle of combinatorial design by collecting data from a number of existing technologies and displaying it in a novel way. Apple markets the Health app as a repository for health data from a user’s iPhone, Apple Watch, and third-party apps that enables the user to “view all [their] progress in one convenient place” (Apple, n.d.). On the most basic level, the Health app uses the iPhone’s accelerometer to track steps (Capritto, 2019). However, users can extend the app’s functionality by connecting a number of other devices. Simply by adding the Apple Watch, the Health app measures things like the amount of time a user was active to their active and resting heart rate (Apple, n.d.). Even non-Apple products ranging from posture trainers to UV sensors can be paired with the app (Sawh, 2020). Finally, the app also accepts data from third-party apps such as MyFitnessPal or Lifesum which helps users track their daily nutrients (Capritto, 2020). The data collected from these devices is then displayed in graphical charts so that users can explore health trends in one place.

The Apple Health app's

Figure 1. The highlights page on Apple’s Health app (Apple, 2019).

According to Irvine (n.d.), modularity allows for the design of complex structures by dividing the system’s functions into separate, interconnected processes. The highlights page (Figure 1) simplifies the complexity of the system by displaying activity data collected from a number of sources in intuitive graphs. The phone, wearable technology, or third-party app supplies data to the Health app. The app then displays this information in a way that is intuitive to the user. It can also compare a user’s current activity levels or health data to past metrics and display this in an easy to understand chart.

In their characterization of modularity, Baldwin and Clark write that modules have “interdependence within and independence across modules” (2000, p. 63). To some extent, the Health app depends on the data collected by the accelerometer, third-party apps, and wearable accessories. However, the app can exist independently without input – although many of the functions would be lacking. The Health app also functions as a medical ID so that medical responders can access a user’s medical information if they are in an accident. But, like the activity and nutrition tracking features, this does not work without input from the user.

I have one question about this week’s readings. Baldwin and Clark discuss abstraction, information hiding, and interface when explaining modularity (2000, p. 63). I’m not entirely sure that I follow this line of thinking and would appreciate it if we could apply this to a concrete example in class.


Apple. (n.d.) “Health: A more personal Health app. For a more informed you.” Apple.

Apple. (2019). [The highlights page on Apple’s health app displayed on an iPhone] [Photograph] Apple Support

Baldwin, C. Y., & Clark, K. B. (2000). Design rules. MIT Press.

Capritto, A. (2019, April 18). The complete guide to Apple’s Health app. CNET.

Irvine, M. (n.d.). “The logic of managing complex systems with re-implementable models of interconnected components and abstraction layers.” Introducing modular design principles. Manuscript in progress.

Sawh, M. (2020, July 11). Apple Health guide: The powerful fitness app explained. Wareable.