A Race Against Time: Preserving iOS App-Based Artworks

Joseph G Heinen Jr. and Morgan Kessler with research contributions from Flaminia Fortunato
Electronic Media Review, Volume Six: 2019-2020

ABSTRACT

The complexity of software-based art continues to challenge media conservators in their quest for best preservation practices. An ever-growing body of literature on case studies has been written and published underlining how often multiple and concurrent preservation strategies are needed in order to ensure the perpetuation and unfolding of these works in the future. In the last few years, institutions have started collecting iOS mobile applications. Multi-faceted in their platform dependencies and distribution systems, app-based software preservation is intrinsically linked to the breakneck pace with which mobile phone technologies and related software are released, adopted, and rendered obsolete. This process is further heightened by the reliance on the authoring and delivery restrictions enforced by Apple, which limits the control the creators have over the availability and sustainability of their iOS app-based artworks.

How can the preservation challenges of these artworks add to our understanding of software-based art? Which strategies, tools, and workflows can be applied to mitigate risks associated with iOS app-based art obsolescence?

Drawing from two recent acquisitions, this paper aims to share the findings of a yearlong joint research project between Los Angeles County Museum of Art (LACMA) and the Museum of Modern Art, New York (MoMA) media conservation and preservation departments. While the scope of the research initially included two separate case studies with different issues related to source code, platform dependency, and distribution, the research is still ongoing and at this stage, the authors can only report on one case study (LACMA). The authors will at this stage examine the challenges found in Mungo Thomson’s (b. 1969) Composition for Marimba (2016; iOS app, iPhone 6 Plus, custom music stand in chromed brass, and environmental speakers; 54 × 19 × 16 1/2 in.; LACMA; M.2016.279.1.1-.4) in an effort to speak to broader issues (and in some cases solutions) found in iOS mobile technologies: 

• Tools and methods to faithfully document the behavior of an iOS app;
• Available tools for condition checking iOS apps pre and post-acquisition;
• Strategies for the stabilization of the original source code, including software and programs employed;
• Overall consideration of annual maintenance and preservation costs.

Our hope is to continue this research in next year’s EMG Review as we explore the issues found in MoMA’s case study, Martine Syms’s (b. 1988) WYD RN and provide follow-ups to the LACMA case study given the ongoing developments with iOS technologies and relevant conservation tools.

INTRODUCTION

In the past several years, the emergence of apps on the market has been spreading at a fast pace, populating digital shelves with innovative tools that can be easily downloaded on our mobile devices. As these pieces of technology become downloadable quickly with just a click—reaching a critical mass of users for their functionality, ease-of-use and affordability—, they have also triggered curiosity and enthusiasm for artists and designers to experiment with this new medium in a variety of novel ways. Sometimes artists have employed apps as constitutive parts of multimedia installations, sometimes as integral parts of sculptures, or as application that visitors can download in the exhibition space and continue to play with at home.  All these works not only differ from one another in the way they are created and deployed for end-users/visitors, but also for their status within an exhibition setting, both as individual, unique artworks or as constitutive parts of contemporary art installations. 

In this paper, we will use a case study from LACMA to elaborate on methodologies employed for the documentation, condition assessment, stabilization, and maintenance of iOS app-based artworks. Research is currently ongoing for a work in MoMA’s collection and our colleague Flaminia Fortunato plans to report on this in a future volume.

In 2016, Composition for Marimba (2016) by Mungo Thomson was acquired by LACMA. This work consists of a mobile phone mounted on a tripod that acts as a set piece and audio-visual display device. An iOS mobile app displays a random sequence of images of playing cards, which are linked to audio files playing marimba tones and then sent to wireless speakers in the space.

A BRIEF INTRODUCTION TO iOS MOBILE APPS

Prior to the use of smartphones, the word app was employed as the abbreviation of computer application: a program that is applied to a specific use-task or application that a computer user is trying to accomplish. The first oldest and formal use of this term dates back to the early ‘80s when multiple job posting adverts were published on Computer World magazine and those included the word app. It is conceivable that, since the job posting section worked in the form of a telegram, the word application was abbreviated to app to save on characters (Hsu 2015, 6-8). From a software development perspective, an app is a piece of software that is less complex than a software program because it is narrowed to a specific task/purpose.

In the software development community, the taxonomy of apps embrace three broad categories, namely native apps, mobile web apps, and hybrid apps (Mallikarjun 2017).

Native apps are built for a specific operating system and will remain faithful to that original system. A native app developed for an iOS operating system won’t work on Android devices and vice-versa.

Mobile web apps are the web applications to render/deliver pages on web browsers running on mobile devices. They work across different mobile operating systems.

Hybrid apps are a mixture of both native and mobile web apps. This type of application has cross-platform compatibility.

Mobile app-based artworks can be inserted in the broad definition of software-based artworks (or technology-based artworks) as they constitute a complex system resulting from the combination of software and hardware components. The software is identified as the source code that allows a set of instructions to function and the hardware (the mobile phone itself) enables the app to work as the artist envisioned.

As demonstrated by over two decades worth of case studies on the preservation of software-based art, many concurrent preservation strategies should be pursued in order to assure that the artwork can remain operable in the future. Often the employed strategies are a mixture of emulation/virtualization, code migration, and/or rebuilding the software entirely if the assets were provided, relying upon a framework or script for the work that abstracts the look and feel of the original. This work is never straightforward; however, these strategies become even more complex and nuanced when dealing with mobile apps.

MOBILE APP KEY CONCEPTS

A) Xcode

Before examining the iOS mobile app case studies at LACMA, it is important to first introduce some key concepts in app creation and distribution.  Most iPhone apps are written and enabled through an Xcode project. Xcode is an Apple-based package installer and Apple-based software compiler. One of its strengths is that it ensures that software packages are properly configured during installation and aids in ongoing updates and migrations. It is also used to create experiences and interactive programs such as iOS mobile apps, created within the Integrated Development Environment (Apple 2019). Apple often privileges interface design over access to the raw encoding of its applications, such that the complex architecting is happening below the surface of the programming window. However, it further removes the user from the actual mechanics of the code and has many hidden dependencies. Swift is one programming language used within Xcode (the other option is Objective C), itself a dependency bundled within Xcode, and it is yet another proprietary language and protocol that Apple has developed for its products in order to improve upon performance. Objective C is one of the oldest programming languages and was one of the foundational languages for Apple’s early object-based technologies (Wodehouse 2015). However, regardless of whether a user built a mobile app that will successfully compile based on the programming language of choice, one still needs to be able to sign it to a device. The destination platform needs to be specified within the project, so there is an intent to write the app to a specific operating system and iPhone model. Since many of the functions of an app will have certain hardware requirements (e.g. dimensions of the screen, certain haptic functions enabled through touchscreen, etc.) the choice in a given destination iOS and iPhone model will be highly significant.

The main purpose of the Xcode project is to link source code files with all the various dependencies, including related media files, device/platform mappings, profiles/developers accounts, etc. The user interface of the Xcode project allows one to simply set paths to all these dependencies in relatively straightforward windows, settings which would otherwise be written as code in configuration files. However, this still relies on the understanding that all these dependencies will remain nested within a specific directory structure so that the Xcode project can find them; a developer needs to maintain the files as they would most forms of source code or software libraries. Be aware that this directory structure can change—such as the placement of important configuration files within the directory structure—with the different versions of Xcode.¹

B) Developer License

A further risk associated with app-based artworks is the means for distribution, namely whether it is attached to a specific developer account or if it is managed within an app store.  When creating a mobile app, Xcode requires the work to be “signed” before any deployment.  If it is signed to the artist or studio’s developer account, it will only function on the device for as long as the artist is paying for their developer license (currently $100 yearly).  Depending on the artist to maintain a license is, of course, very risky and not sustainable for the long-term preservation of these artworks.  In Xcode, you have the ability to change the signing account (assuming the Xcode files have been provided). 

In the case of the Mungo Thomson work at LACMA, the artist was able to move the app signing over to an iCloud account that LACMA can manage itself, rather than having to maintain a licensed developer account. However this still requires yearly upkeep in order for the app to continue to function and also predicates the life of the work on the existence of an iCloud account. As an aside, while Apple technically allows you to load the app onto a device with a free iCloud account, we found that this was buggy and it was much more efficient to purchase a developer account instead. This is yet another consideration in terms of regular maintenance of the work as the developer account will need to be managed along with the work itself. 

C) Deployment

Although we tend to recognize an app in its destination form as an end-user program on a device, the actual architecture of an app will continuously be traced to its dev and the servers that enable a connection to this environment. Even though an app appears to be installed and tethered to a specific device, it still relies on database calls to ensure the app is being used within the terms of the license agreement (there are legally dubious ways of side-stepping this, such as jail-breaking destination devices, which is discussed later). By default, the dev environment will be signed to a developer account and this must always be current; the lifespan of an app signed through these means will always be reliant on a yearly licensed cycle.

Of course, not all apps are being made in the same way and deployed and available for end-users following a single or straightforward procedure. This is in part due to how artists conceive their works and consequently how these works are being delivered to collecting institutions. For apps that are not available to the general public, they are typically uploaded directly to the phone, referred to as ad-hoc or “sideloading.” This still requires a developer license since the developer account must be verified by the external database that supports the deployment of the code. In most cases apps are downloaded from the App Store whereby the developer registers the app to the store, which monitors the available destination platforms and performs software upgrades in order to align with newer destination versions. This further implies that Apple is positioning themselves as primary owners and authors of the code, controlling what is available and in what form.

D) Embedded storage partitions 

All mobile devices have embedded storage systems that cannot be removed. This is a very important detail that differentiates mobile devices and their constituent applications from computers. A computer is built with a removable hard drive where all system information is stored. In the realm of computer-based artwork preservation, safely removing the hard drive and employing forensic tools for the acquisition and analysis of data is an agreed-upon practice among library, archive, and collecting institutions for the preservation of these works.

The impossibility of removing hard drives from mobile devices poses questions and challenges in creating backup data of the device and more specifically of the app, independently from the Apple creation environment. An iOS mobile device is built with two partitions: a system partition and a data partition. A system partition—also called system partition—is generally overwritten every time an iTunes upgrade is performed. This partition contains system files and basic user applications. The data partition is where all user data are located and stored. This partition is where all iTunes applications are stored. 

THE ARTWORK: COMPOSITION FOR MARIMBA BY MUNGO THOMSON

Composition for Marimba by Mungo Thomson in an example of an ad hoc application. The work is largely inspired by the generative, chance-operated musical works by John Cage, in which randomness is an essential part of the work. Building off of iterations of this work that involved other mediated forms such as a player piano, the artist finally arrived at an iPhone, given the ability to display life-size images such as that of playing cards, which correspond to each note. The piece is essentially a musical work that plays a sequence of 52 notes (each of the 52 notes is used in each sequence, but in random order) and displays the cards simultaneously. The app contains the images of the playing cards and the marimba tones, and the software maps the tones to the images and controls the randomizer. The sounds are sent to wireless speakers through the AirPlay app. The work is also of a sculptural nature since it plays on an iPhone mounted on a tripod that acts as a set piece and audio-visual display device.

In 2016, LACMA received Composition for Marimba as a gift from John Baldessari. When this piece arrived, the Media Collections Manager role had just been defined and the artwork went immediately on exhibition.  Since we lacked the lead time and the resources, the appropriate condition checking was not possible. Fortunately, the artist provided a movie file that documented the work in action and the Xcode files originally needed to create the app, but we did not have the ability to fully test it, nor did we have a backup phone.

At the time, the complexities of iOS app works were not completely understood and it was thought that, provided the iPhone was kept intact, and we kept the source code, we had enough to preserve the work. The phone was put on airplane mode to avoid any software updates and put into physical storage after exhibition, and the source code was placed in digital storage. It wasn’t until later on when the museum’s newly reformed Time Based Media Committee started focusing on software-based works in 2018 that this work was reexamined.

Upon booting up the phone we were immediately prompted to perform a software update which we rejected. However, this made us concerned that there were updates that may have taken place in the background without even prompting us, later reified by the fact that the automatic updates feature had not been turned off. We also tried to launch the app, but it would initialize and immediately crash. We were not certain whether an update had taken place or if the app had somehow become corrupted. We decided to perform a full back-up of the phone since one had not been performed before, but also hoping this might allow us to acquire some systems log data about what changes may have occurred to the phone since it was acquired. In order to perform more analysis of the functions of the iPhone and attempt to rehabilitate it, we purchased a replica phone so as not to damage the original. In commencing our assessment of the work, we were immediately confronted by the limitations of Apple systems for performing digital preservation work.

While we hypothesized that the iOS update was the reason why Composition for Marimba was crashing, we learned from the artist that all five editions of the work crashed at the same time due to their Apple Developer License expiring. 

OPERATING SYSTEM TRAIL

We first wanted to exhaustively document the phone itself, since not even the iOS version had been recorded anywhere. Since the app would initiate and start to launch only to crash, we hypothesized that iOS had been updated without our knowledge. As mentioned, the automatic updates had not been turned off, so there was no telling what had taken place in the moments the phone had been turned off since it had been acquired.

Also, the systems audits are limited in scope and proprietary in format (e.g. MobileSync, iPhone Analyzer). Without the aid of Apple-authored forensic tools, there is no way to get a complete audit of installed dependencies and version histories of those dependencies. Through the Time Machine back-up, the user is able to restore to previous versions² and access some information about the phone’s usage, but it is not complete. To this extent, we were not able to immediately answer what may have gone wrong with the iPhone and whether we could isolate the issue as having to do with incompatible platforms. We simultaneously decided to examine whether it was possible to reauthor the source code into a functional app, even if the original environment was somewhat updated or compromised. 

BRINGING THE ARTWORK UP TO DATE

Once the replica phone was acquired, we found that the iOS on the new equipment was current.  Since it is very difficult to upload an older version of iOS to an iPhone, we decided our testing would be twofold: 1) can we get the code to work and 2) can we also update it to match the current iOS?  Using a copy of the artist-provided code files and Xcode version 8, we had to do a fair amount of manipulation to get the program to work:

• Relink media files to the local dev environment, as well as moving the info.plist file which references and compiles these media files (different locations in the directory between Swift 2 and Swift 3).

• Move audio files into “Supporting Files” folder in the project.

• Set the destination setting to iPhone 6 Plus to match the equipment we were using. Updated Swift to 3, using autoconverter. We ultimately needed to go to Swift version 4, but you cannot update from 2 to 4 in Xcode 9. Xcode 8 was needed to bridge this update.

• Once we had it running in the simulator, we needed to update to Xcode 9.4.1.

• Updated to Swift 4. 

• Set iOS deployment target to match phone (11.4).

• While trying to upload ad-hoc, we encountered signing errors and needed to sign up for a developer account.

• Added account to Xcode settings, downloaded manual profiles. Updated the developer settings and the provisioning profile in Xcode.

• Uploaded to device/phone, worked and started up automatically. 

To complicate matters, we first used a workstation that already had Xcode 9 installed on it, but were confronted with immediate errors. We were prompted to update the versions of Swift (the underlying programming language) from version 2 to version 3, but could not do that with the Xcode version 9 on the computer and needed to revert to an older Xcode version in order to perform the Swift migration. However, once we installed a second version of Xcode 8, a whole new host of issues arose, specifically in compiling all the media files and configuring all the various directory path settings in the Xcode project. This led us to perform a test on a computer environment with no previous versions of Xcode installed (only Xcode 8), which further crystallized our understanding of how essential the underlying dependencies are in compiling Xcode: even though we had installed a second version that was more compatible for the Swift migration, this version was not able to point to the underlying Swift dependency that, unbeknownst to us, was deeply nested somewhere in the Xcode configuration. While the second environment proved much more promising for the Swift environment, there were still errors in configuring all the necessary source code files.

COLLECTING DATA BEFORE INTERVIEWING THE ARTIST

Next we had to dive into the source code to see if we could interpret the exact behaviors of the original program. We then compiled our list of questions including:

• Is there a deliberate timing/sequencing involved in the work or is it based off of a randomized algorithm? What is the algorithm and where is it invoked in the script?
• Are the image and sounds correlated? Where does this mapping exist?
• Are the sequences ever reset or repeated, or is it the nature of the algorithm to generate images/tones at random regardless of what came before?
• Airplay vs. any Bluetooth speakers
• Who else owns this work?
• Can this be rebuilt using different equipment if necessary?
• Since the work is not dependent on audience interaction, can the shell of an iPhone be used in conjunction with new technology to create a similar, but not Apple-based, work?
• Can we have the contact information of any fabricators you worked with?

We found it extremely helpful for our artist interview to be scheduled after we had done our experiments.  Had we done the interview earlier, we wouldn’t have known what questions to ask.

Based on the artist interview, a number of important preservation requirements were defined. First, the artist was not particularly adamant about the use of Apple technologies in the future, but was merely intrigued by the use of mobile technologies as an everyday display device and specifically chose this model of iPhone because of the dimensions of the screen (which were approximately the same size as a standard deck of playing cards). He was also fond of the ability to wirelessly transmit sound to speakers (to reduce clutter during display) and found that generic Bluetooth technologies lower the sound quality of the audio whereas AirPlay³ could present the audio in its full quality.

We also delved deeper into the nature of the randomizer. It is designed to mimic the actual process of shuffling a deck of cards whereby the first sequence is always the two of diamonds up to the ace of spades. The first seven subsequent rounds will divide this sequence in half and increasingly scramble the order with each passing sequence. Following seven sequences, the order is fully shuffled and will be completely random henceforth, never to repeat the same exact sequence again. Should the software ever need to be recreated through other means (e.g. in the event of the complete obsolescence of the iPhone or necessary iOS platform), this would give us the proper behavioral structure for how the sounds and images are to be presented. The artist finds this to be an acceptable pathway towards preserving the work if necessary. The speed of the work is another significant property, since the speed is hardcoded as a variable option—by dragging two fingers across the screen, the user has the ability to speed up or slow down the playback speed of the piece. Ideally this haptic functionality will port over to successive versions of iOS and iPhone, but should the work need to be redesigned, there may need to be a more concerted effort around ensuring the work plays back at the proper speed or allows for some degree of control and variability.

Following our own assessment of the functionality of the work and the conversation with the artist, we arrived upon the following conclusions that would further inform future acquisitions of similar proprietary software-based artwork. For ongoing care of the work, we found that it was critical to:

1. Have a budget for duplicate equipment and specialized software—works of this nature require highly customized hardware and software that do not show promise of continuing creation or distribution into the future. Stockpile!

2. Assess the work in regular cycles. Given the dependence on Apple licenses, issues with battery life, and the nature of app-signing, a work will need to be checked on a regular basis to ensure its functionality. A year is probably appropriate given what we know about Apple licenses.

3. A complete snapshot of the dev environment. Not only is it important to save the Xcode project and document the versions of Xcode and Swift that are compatible, but it may even be necessary to encapsulate the entire computational environment for compiling and signing the app (given the bundled dependency for Swift within the user profile of the computer). This may require packaging all the software dependencies or even imaging the entire environment if storage space is not an issue.

4. Have a plan to rebuild. This is an extremely important step with works of this nature that are highly proprietary and for which the materials (app-signing software, licenses, etc.) remain within the control of the companies that created them. One should expect that at some point, the work cannot be mediated with the original hardware and software components. Get an understanding of what is important to the artist and what kind of tech support is available, including this language within the purchase agreement.

ONGOING RESEARCH

A popular technique for removing the proprietary restrictions enforced by Apple on their iOS technologies—possibly going against some conservation practice in that you are modifying the original—is known as jailbreaking. Jailbreaking uses installed software, generally released by the open-source community, that modifies Apple’s operating systems in order to remove restrictions and give greater user control over the device (iDB 2019). While jailbreak software is technically legal, the use of jailbreaks (and more specifically how the jailbroken device is used) could possibly be considered illegal or could be in violation of copyright or intellectual property laws. As of the writing of this paper (September 2019), the jailbreak for 12.4.1 was just released. While there are many tools on the market for performing jailbreaks, we experimented with unc0ver, which also requires installation of ftOS (for removing embedded software update files from the iPhone’s file system, which will otherwise block jailbreaks). Given that these tools are developed and released by the open source community, they are often buggy and do not consistently work across devices and specific patches of OS versions. While we were able to jailbreak an iPhone 7 with iOS 12.4.1, we would need to perform another update to the work’s original Xcode project and inherent dependencies (e.g. Swift. Based on the current Xcode, it required Swift 5, which has introduced many changes to the inherent structure of project files). So far the jailbreaks for older iOS versions (prior to 11.4) have proven to be very buggy (Undecimus 2019). We are still performing research on how to perform jailbreaks on older models as well as to see if we can update the work’s source code/project files to the most current iOS version. If this were to be successful, it is thought that the developer account could be removed from the Xcode project, allowing apps to be signed to devices without the license restrictions that otherwise trigger the yearly “self-destruct” feature (and thus would obviate our need to rely exclusively on an archived dev environment in order to re-perform the work in its current state into the future). This would allow us to load an app to a phone and, barring any issues with the battery or the hardware components, the work could ostensibly be run on the iPhone long into the future.

It is also worth mentioning that LACMA has a business account with Apple and we have pursued the possibility of receiving customized support for iOS technologies as artworks. However, it has become clear to us that not only is this notion of archivable or legacy media unfamiliar to them, but that increasingly Apple technologies are resistant to achieving reverted states of technology (e.g. when restoring from a back-up, one used to be able to restore from the original iOS and sidestep any needs to update to the current version. This is no longer the case as the user will always be forced to update to the current iOS version). A recent development within the app development community that shows great promise in terms of a movement towards sustainable/open-source development and deployment is the increase in Progress Web Applications (PWA) on the market (Google Developers 2019). These apps are web/browser-based and are built on JSON as the manifest file format. They are apparently making great strides to ensure that all of the behaviors found in iOS apps can be replicated within this language, however code migration would be necessary in order for the work to be realized as a PWA. Increasingly, it feels that this may be our only hope to ensure that this work is sustainably preserved long into the future. We hope to have more updates on this research in the future and plan on sharing out along with our colleagues’ updates from MoMA and Martine Syms’s WYD RN.

OVERALL CONSIDERATIONS AND CONCLUSIONS

Based on our experiences working with the piece, we have concluded the following:

• Apple’s proprietary back-up formats, iOS filesystems, and analysis tools (e.g. time machine/mobileSync/iPhoneAnalyzer) make it very difficult to generate a complete audit of all activities and software updates that have occurred on the phone. Museums should try to work with Apple to develop better systems for acquiring preservation data from such devices. “Jail-breaking” phones may be a requirement to have full access to phone data but are also reliant on the most current versions of iOS technologies and dependencies, and extra steps need to be taken to ensure that phones do not self-update.

• A true back-up or archival master of an iOS work requires much more than just the source code; it also relies heavily on specific versions of Xcode/Swift, as well as the OS of the host computer that runs these versions of Xcode/Swift. LACMA is considering best practices for stabilizing and storing this work, such as a container file that has the source code, related Xcode download with necessary Swift dependency, and possibly also a download for the OS. Also, one needs to have all the assets used for the creation of the app. It is important to know that the file structures provided by the artist often come with unused and test projects and assets.  We have decided to keep everything as is rather than risk deleting something important in order to clean up the folder structure.

• A further risk associated with app-based artworks is the means for distribution, namely whether it is attached to a specific developer account or if it is managed within an App Store. In the case of the Mungo Thomson work, the artist was able to move the app signing over to an iCloud account that LACMA can manage itself, rather than having to maintain a licensed developer account. However, this still requires yearly upkeep in order for the app to continue to function and also predicates the life of the work on the existence of an iCloud account.

•  A further point for consideration is whether museums can work with Apple or other mobile app distribution systems to develop strategies or workarounds for preserving these works…or consider whether this is even a good idea, in the event that it creates even deeper layers of reliance on the good will of such companies.

• The reality of these artworks is that they likely require a much more frequent cycle of refreshing in order to ensure their longevity.

• An interview with the artist is CRITICAL to the long-term preservation of the work. Having conversations around the use of alternate technologies (playback/execution) may be necessary to continue to present the work.

• The hardware is just as important as the code.  Is the work reliant on a particular brand and version of a phone or computer?  Can this be upgraded 50 years from now?  If not, does the institution have the ability to stockpile equipment?  Internal batteries need to be addressed, as well, in addition to a maintenance plan of checking the equipment annually. 

NOTES

REFERENCES

Apple. 2019. Welcome to Xcode. https://help.apple.com/Xcode/mac/current/#/devc8c2a6be1 (accessed 12/09/19).

Google Developers. 2019. Introduction to Progressive Web App Architectures. https://developers.google.com/web/ilt/pwa/introduction-to-progressive-web-app-architectures (accessed 06/15/20).

Hsu, H. 2015. “The Appsmiths: Community, Identity, Affect and Ideology Among Cocoa Developers from NeXT to iPhone.” PhD diss. Cornell University. https://ecommons.cornell.edu/bitstream/handle/1813/40636/hh334.pdf?sequence=1&isAllowed=y (accessed 06/15/20).

iDB, 2019. How to Jailbreak. https://www.idownloadblog.com/jailbreak/ (accessed 06/15/20).

Mallikarjun, M.K., 2017. Different Type of Mobile Application—Native, Hybrid, and Web Apps. https://blog.trigent.com/different-types-of-mobile-applications-native-hybrid-and-web-apps (accessed 06/15/20).

Undecimus. 2019. RootFS already mounted, delete OTA file from Settings—Storage if present and reboot. https://github.com/pwn20wndstuff/Undecimus/issues/1137 (accessed 06/15/20).

Wodehouse, C. 2015. Swift vs. Objective-C: A Look at iOS Programming Languages. https://www.upwork.com/hiring/mobile/swift-vs-objective-c-a-look-at-ios-programming-languages/ (accessed 06/15/20).

AUTHORS

Joey Heinen
Digital Preservation Manager
Los Angeles County Museum of Art

Flaminia Fortunato
Media Conservator
Brooklyn Museum

Morgan Kessler
Media Specialist