This week’s posts feature case studies from Cooper Hewitt’s Digital Collections Management Project, a conservation survey of born-digital and hybrid objects in the permanent collection. The two-year project was coordinated by an in-house team of conservators, curators, and registrar, and was conducted by digital conservation specialist Ben Fino-Radin and his team at Small Data Industries.

Acquired by Cooper Hewitt in 2013, Planetary is an iOS app for the iPad, designed by Bloom Studios.This case study takes a close look at the acquisition and aging of iOS apps, and proposes a program of care and maintenance to ensure their ongoing functionality.

Planetary has been described as a “visual music player”—an interactive visualization of a user’s music library. Practically speaking, Planetary presents users with an interactive rendering of a galaxy: a visualization of the iTunes library on the user’s iPad. Stars represent artists, planets orbiting the stars represent albums by the given artist, and moons orbiting the planets represent the tracks on the album (the speed of their orbit, and thus duration of one lunar orbit correlates to the length of the track). It was written in the programming language C++ using the open source library Cinder as a framework. The app was created specifically with the iPad in mind, written for iOS version 4.3 in an Open Graphics Library (Open GPL) Application Programming Interface (API) that renders 2D and 3D images and interfaces with the user’s music library.

Planetary is quite unique in Cooper Hewitt’s collection—at the time of this writing it is the only iOS app to have been collected, as well as one of very few born-digital, software-based collections objects, and the very first acquisition to involve source code as a material. Perhaps the 2013 blog post about the acquisition of Planetary says it best:

“…reticence to collect digital objects stems from deep uncertainties as to how to preserve and present such objects to future visitors and future scholars. But for Cooper-Hewitt these uncertainties have been a strong driver to experiment.” —Seb Chan, Former Director of Digital and Emerging Media

The acquisition of Planetary was indeed experimental. Fundamentally, there were four things that were collected, or produced, by the museum as preventive preservation measures at the time of acquisition.

  • first and foremost was the source code—the museum collected the entire Git version control repository for Planetary’s source code
  • two iPads were provisioned with the functioning software,
  • the source code was printed on archival paper in a font optimized for machine readability, as a backup for physical storage (image)
  • a large collection of screenshots, videos, notes, and production assets, as well

as an offline backup of the Planetary website, were collected as archival documentation

Archival version of Planetary in collections storage– DIG001, center left (image from 2013 blog post)

Perhaps the most experimental aspect of Planetary’s acquisition was the fact that the museum released the source code online with an open license, allowing anyone to copy the code and modify it and adapt their copy to suit their interests. The intention of open-sourcing the code was to open the door to passionate fans of Planetary so they could aid in its long-term preservation and maintenance. 

Condition Assessment: At the time of this writing, Planetary’s source code is completely incompatible with the contemporary iOS. This means that when the iPads collected by Cooper Hewitt fail, the museum will have no way to exhibit a functional version of Planetary. You are probably aware from your own experience that smartphone and tablet apps are constantly updated to keep them functional—to keep up with new developments to hardware, firmware, and web protocols, software must be in a continual state of evolution. As these new developments occur, older programming tools are deprecated—this means that they can still be used, but they are considered outdated and will soon cease to function.

Let’s get technical: A thorough analysis of what precisely would need to happen in order to allow Planetary to be run on current-day iPads, revealed two fundamental roadblocks:

  1. Apple changes how things like touch input, iPad orientation, multitasking behavior, and code interfacing with the music library are referenced in code (using the API). This is a tedious albeit relatively trivial issue, and one that any experienced iOS developer deals with on an ongoing basis as Apple changes the ground beneath their feet. The change in how the music library API works is of course of central importance, but will have the added challenge that since Planetary’s development, iOS devices have added the ability to store music in the cloud. A plethora of deprecations and additions are created in each major iOS upgrade.
  2. OpenGL, the 3D rendering engine that Planetary relies on for drawing the look and feel of the software is being phased out. This is a big issue as, unlike the API issue, it is not merely syntactical—OpenGL deprecation impacts the look and feel of the entire application. It is, however, an issue that is not specific to Planetary, and so finding a developer qualified to remedy the issue should not be hard.

So, what is a viable strategy for bringing Planetary to current iOS frameworks? It would take months of a developers time to upgrade the app from iOS5 to the current iOS (12.2, as of March 2019). To do this, they’ll need access to the source code, but that’s not all.

Just how useful is having the source code? The process of building or compiling source code requires external code, libraries, frameworks, compilers, and operating systems. Just as software often is only compatible with specific hardware, source code can only be understood and manipulated with the correct development environment fully intact.

For this reason, moving forward, when acquiring software, Cooper Hewitt needs to work with designers to collect the following components, which would make future conservation efforts easier: the source code, compiled binaries, documentation on how to compile/build the source code, and a snapshot of verified working development environment (in the form of a disk image).

What have we learned?: Small Data collaborated with former Bloom Studios developer Tom Carden to retroactively assemble a “period specific” development environment for iOS 5, and have encapsulated this development environment inside of a virtual machine to allow Cooper Hewitt to run Planetary in an X Code simulator, when we next decide to display it.  But this is only a temporary fix: the same issues of deprecation of existing standards described earlier will require “retreatment” in the near future. In the X Code simulator, the music library is a simulation, and while it can be fully navigated just as with the original app, the songs cannot be played. In order to work in the way it was designed, the entire source code needs to be examined and updated by a software developer.

Planetary’s original acquisition strategy was clearly identified as “experimental”—and the perspective we now have, years later, is invaluable. This experiment has shown us that open-sourcing software and hoping for a community to steward that software is not a substitution for institutional conservation and investment of care, time, and resources.

Going forward: the future of iOS conservation: What would a sustainable program of care and maintenance look like? With iOS apps, obsolescence is completely inevitable, and with each passing year the effort required to return an app to a functional state is compounded exponentially. Additionally, when years pass, allowing an app to sink deeper into obsolescence, the museum is also passing up the opportunity to capitalize on contemporary iOS developer knowledge that is required to remedy the iOS version changes that happened that year. The ongoing care and maintenance of iOS apps at the Cooper Hewitt could be made fundamentally more sustainable by shifting away from a mentality of preventive conservation, and later intervention to repair damage, and instead toward a model of conserving digital artifacts that entails annual upkeep– which dramatically changes the costs of acquiring these works. Rather than something fixed which will remain more or less the same in storage, software based works, particularly those designed for iOS or other mobile frameworks, require constant change to allow their preservation.

Ben Fino-Radin is founder and lead conservator at Small Data Industries, a lab dedicated to supporting and empowering people to safeguard the permanence and integrity of the world’s artistic record. Before founding Small Data, Ben served as a time-based media conservator at MoMA, and Rhizome.

The Digital Collections Management Project was made possible with the generous support of the Collections Care and Preservation Fund of the Smithsonian Institution.

Leave a reply

Your email address will not be published. Required fields are marked *