App (Store) Policy Histories

Team Members

Lead: Anne Helmond, Fernando van der Vlist, Esther Weltevrede (alphabetical)

Participants: Kath Bassett, Tom Coggins, Nayana Dhavan, Ben Hunter, Daniel Joseph, Mace Ojala, Camilla Pilotto, Jacopo Poletto, Linan Tang, Yixiu Wu, Chris Young (alphabetical)

Contents

Research Questions

1. How have app (store) politices and governance models evolved?
2. How are app (store) policies networked, interdependent, and layered?
3. What is being governed by these policies and how?
4. How can app (store) policies be used to tell (his)storeies about the evolution of the app ecosystem?

Data Sets / 'Included Policies'

The policies we included in our sample and which our various project streams analyzed, included: Apple's and Google's developer policies (review guidelines + programme licenese agreements), as well as at Huawei's and Tecent's app catalogue and developer policies.

In what follows we will present four main policy stories which utilize these policy documents to shed light on our intial research questions.

Policy Story #1: Networked Policy Structure

Policy Story #2: Policy Revision and Readability Dynamics

To investigate the policies as specimens of a genre of texts we reproduced Kevin Litman-Navarro's 2019 scrollytelling piece We Read 150 Privacy Policies. They Were an Incomprehensible Disaster in New York Times which was also presented at the project pitch on Monday. Litman-Navarro's piece is more comprehensive and focuses on privacy policies and concerns with the users. Instead, for this project we wanted to work on policy documents which govern the development and distribution of apps on Google and Apple platforms. We selected Google's policies from Developer Policy Center and Apple's App Store Review Guidelines. Both two are a collection of guidelines for app development. While the documents are different, both effectively aim to govern the artefacts, services and relations being crafted in the app development platforms, and the people and organizations developing and offering these artefacts and services.

After copypasting both documents into text files by split sections, we brought them into Jupyter Notebooks running Python for computation and visualization with Altair library, rendering them to Vega-Lite declarations for sharing, publishing, and handing off for further visual design. We calculated standard Flesch Reading Ease metric based on counts of sentences, words and syllables for each section, and tokenized the text and calculated each sections lengths in words, and plotted them on connected scatterplots, orienting section length along the horizontal axis with shorter sections toward the left, and the reading ease score along the vertical with easier sections toward the top.

The organization of Apple's and Google's documents is not comparable, but from the visualization of consequent series of sections, we see that the Apple App Store Review Policy starts and ends with easier, shorter sections of introducing and finalizing the process of publishing an app. In the policy, business and legal matters are discussed at length and burden the reader more. Sections on design and performance are similar in length, but somewhat easier to read, according to this metric. Apple's chapter on safety is short, but hard to comprehend. The Google Developer Program policies, organized and presented as a collection on Policy Center rather than a serial document like Apple's, offers a more less progressing reading experience, with edges crisscrossing. Google's text is in overall easier to read, with shorter and more consistent sections.

Next, to investigate the development of the two policies over time, we performed a longitudinal comparison of four versions each, ranging across approximately 3 years. This time we map time on the horizontal axis, length and reading ease on the vertical on a faceted lineplot, and overlay the two platforms, each mapped to color. From the visualizationswWe see that the length of both platform's governance documents have been on the steady, near linear increase, while both have also been moving towards ease of grasping.

We explored dispersion plot tools to see where selected words appear in documents, and concordance analysis to see in what text contexts given words, e.g. 'user' appear, but did not pursue those lines of inquiry.

We looked at bigrams "user x" in the Google Developer Policies pre-GDPR and post-GDPR, to see which words appear together with the term user, and observe that the already frequent use of "user data" increased considerably since implementation date of GDPR in late May 2018, while other terms such as "user experience" and "user actions" decreased. Possible explanation is that design concerns have been moved to other documents such as Material Design guide.

Finally, and to align with the policy story #3 which studies the definitions in Apple Developer Program License Agreement. We implemented a small, computationally augmented workflow to lift definitions from the Apple Developer Program License Agreement, as well as from the Google Play Distribution Agreement and see how their definitions overlap.

The single overlapping definition of 103 Apple's definitions and 15 Google's is You.

In Apple's document it is given as

[You] means and refers to the person(s) or legal entity (whether the company, organization, educational institution, or governmental agency, instrumentality, or department) that has accepted this Agreement under its own developer account and that is using the Apple Software or otherwise exercising rights under this Agreement.

and in Google's

Any person or company who provides Products for distribution through Google Play in accordance with the terms of this Agreement

Comparing which definitions have been added, removed or deleted is not hard to to formulate as a set-theoretical problem and automate as such, and from the policy story #3 a visualization over times was made (figure 3. below)

Finally, this time investigating the given definitions, we returned back to dispersion plots for both Google's and Apple documents, and constructed visualizations how the defined terms are used thorough the documents.

Policy Story #3: Evolving Policy Definitions & Governed Actors

Group: Kath Bassett, Tom Coggins, Ben Hunter, Daniel Joseph and Chris Young

Introduction

Our goal with this stream of the project was to understand how App developers are governed by Apple via the Developer Program, and how these logics of governance have shifted over time. To shed light on these issues, we collected, compared, and analyzed Apple's Developer Program License Agreements over the years. In doing so, we developed two protocols for the future study of these documents including a 'longitudinal' and an 'event-based' protocol. We developed and applied the longitudinal protocol to ten license agreements between the years of 2008 and 2019 (when the App Store first launched to the present moment). And finally developed and applied the event-based protocol to two license agreements released in 2010 representing the shift from the iPhone OS to the iOS operating systems (as well as the release of the iPad). Both analyses we conducted revealed how Apple governs developers infrastructurally by expanding their software and service offerings that they require developers to engage with and utilize in order to develop, test, and distribute their Apps via the App Store.

Research Questions

What is being goverened by the Apple Developer Program License Agreement? How has this governence changed over time? How can we best study these shifts in governance?

Methodology

We chose to analyze Apple's developer program license agreement (ADPLA) because we conceptualize Apple as a major market shaper. While Apple didn't technically develop the first smart phone, they did popularize them with the release of the iPhone in 2007. While the iPhone was a revelation in and of its self, Apple's introduction of the App Store nine months later (2008) and their encouragement of third party software developers to make, test, and distribute their products via the App Store spured major shifts in the tech industry landscape. Due to this, we chose to focus our attention on Apple's developer program in order to gain a better sense of how the 'rules of the game' have evolved overtime and as competition has increased. Even though we only focus on Apple, we hope to provide insights and tools which may be applied to other types of developer and end-user policy documents.

Our Process

To gain our bearings, we started out looking only at the most recent 2019 ADPLA document. We first collectivly indexed it's sections so that we could get a sense of what all was there. Next we subdivided and assigned outselves sections and started reading and summarzing what we were finding so that we could start answering our research questions. In the process of doing this, we were able to additionally hone these questions a bit more so that they could properly account for the specific policies we were focusing on.

Once we felt we had a good grasp on the structure and content of this particular policy document, we came back together and tried to figure out what types of events we might be able to study through these documents. This lead us to discussions about what constiuted a signifigant event. For example, does this include hardware and software launches? Cultural and political events such as the post-Snowden revelations and Cambridge Analytica? What about policy events such as the implentation of the GDPR? We disscussed how the latter types of events might be a bit harder to study right off the bat since we were unsure of how quickly these events become accounted for within tech company's software and policies. We thus decided to focus on Apple's software and hardware launches (the former), but with an eye for how the shifts in governance we observed might be related to these latter types of events.

After deciding what types of events we were going to focus on, we did a bit of research on Apple's software and hardware updates and created a timeline in order to visualize this trajectory. Next we collected as many policy documents as we could to see how these mapped onto our timeline -- or rather, to figure out what events were possible to study via the documents at our disposal. Important to note, the ADPLA policy documents, unlike the review guidelines, are not readily available and can typically only be accessed by logging into the developer web portal. However, due to lawsuits which have been filled against Apple, we were able to track down many of these policy documents through the years via Google Search, Duck Duck Go, and in some cases the Wayback Machine (Internet Archive Project). We were able to find and include 9 out of 12 years of documents in our longitudinal sample. The only years we are missing include 2012, 2014 and 2017. Thus, based off of the documents we were able to track down, we decided to focus our indepth analysis on the shift from the iPhone OS to the iOS operating systems (as well as the release of the iPad) in 2010.

When we identified which 2010 documents would help us study this shift (the license agreements from 1/22/10 and 9/9/10), we installed DiffChecker (Figure 1) onto our laptops and uploaded these two documents in order to compare them. However, before we could compare these documents, we had to optimize the documents for comparison. Through trial and error we discovered that the best way to optimize was by selecting the "trim white spaces" option, as well as the track "chatacters" (instead of "word" differences) option. These steps made it so that the document lined up better for comparison. After this, we started scrolling up and down the document to better understand what the tool was tracking and measuring. We quickly discovered that the numbers of 'additions' and 'subtractions' that it was tracking was not very telling, and that our use of what it was capturing would have to be much more interpretive. For example, the tool picked up on spelling error between documents, and while this is no doubt amusing to regnognize, we didn't see such errors as analytically useful for telling a story about governance of developers, and thus left this case out of our notes/records.

Figure 1: DiffChecker

After optimizing the documents and getting more comfortable with DiffChecker, we collectivly went through the document and made a preliminary list of 'additions', 'subtractions', and 'changes' in a word document. Within these interactions we started to make some hypotheses about events and happenings that might have shaped the changes we were observing int he shift from iPhoneOS to iOS. For example there was a change in the games section that we think might have been shaped by the Farmville/Facebook data collection debacle of 2010. As we moved through the documents we feel we observed how Apple has refined it's developer program in an effort to sustain it's own power and reputation. The details of which will be discussed in our 'Findings' section.

Our biggest find from conducting this in-depth, preliminary analysis was that the 'Definitions' section (Figure 2) of each policy document gave us a framework to make sense of the various changes we observed in the larger document. For the most part this gave us a sense of the expansion of services on Apple's part and how these additions would impact how developers may make, test, and distribute their product. But additionaly slight changes in definitions tended to give us a sense of the overarching logics of governance at particular points in time. Based on this insight, we decided to conduct a longitudinal analysis of the various 'Definitions' sections of each policy document we had between 2008 and 2019 so that we could provide a key of sorts for future research into event.

Figure 2: Definitions Section as key to understanding shifts in governance

To conduct this longitudinal analysis we first had to isolate the definition sections of each document and transform them into .txt files (documents of their own) for comparison on DiffChecker. Here we gave each defintion it's own line and inserted a space between each line. Once each defintion section was it's own document, we uploaded our two earliest documents onto DiffChecker and began analysis. It was within our first comparison that we solidified our defintiions and codings of 'changes', 'addtions', and 'subtractions' -- where the former represents instances where alterations have been made to defintions between documents, whereas the latter represent instances where whole defintiions have been added or subtracted.

To record data, we had one person scroll through the documents and narrate what they were coming across. Then we had one person recordning quantiative data (the numbers of 'changes', 'additions' and 'subtractions') and another person recordning qualitative data (the details of these 'changes', 'additions' and 'subtractions' which could help us tell a strory about governance). Finally we had two people taking notes a long the way on our method and some of the analysis that was coming through our communications.

After we repeated this protocol for all documents from 2008 until 2019, we decided to go back to the event we had originally selected and reanalyzed the two documents with our more refined coding scheme, developed from the longitudinal analysis, in mind. However, instead of just coding 'changes', 'additions', and 'subtractions', we additionally coded these elements of the document as pertaining to the 'legal', 'technical', 'content', 'buisness' and (goverened) 'actors'. In the next section we will discuss what our analyses yielded, but before this we will more explicitly lay out our proposed protocols for the study of how App developers are governed by Apple via the Developer Program:

Longitudinal Analysis Protocol

1. Isolate the 'Definitions' section of all available policy documents that you wish to include on your timeline / in your comparison, and transform them into their own .txt documents
2. Upload the earliest two .txt documents that you wish to compare onto DiffChecker & optimize the documents so that they align and can be eaisly compared -- 'trim white spaces' + track 'characters' (instead of 'word') differences [repeat this for all documents, moving from earliest to most recent]
3. Use DiffChecker highlights to identify 'changes', 'additions' and subtractions [repeat this for all documents, moving from earliest to most recent]
4. Record these quantiativly and qualitativily so that you can have a broad sense of how the program (and Apple's governace) has evolved overtime.

Event-Based Analysis Protocol

1. Figure out what event you wish to focus on & select the appropriate documents to compare
2. Upload these documents onto DiffChecker & optimize the documents so that they align and can be eaisly compared -- 'trim white spaces' + track 'characters' (instead of 'word') differences
3. Use DiffChecker highlights to identify 'changes', 'additions' and subtractions
4. Record these qualitativly and provide detail when you can about the specifics of these changes -- what 'changed', 'added', or 'subtracted' defintions do these changes in the document relate to?
5. Once you have recorded these, go back and code them as they relate to the 'legal', 'technical', 'content', 'buisness' and (governed) 'actors' so that you can have a sense of how the progam (and Apple's governance) has changed over the span of this event

Findings & Discussion

Ultimatly, what the ADPLA document is governing is the 'Developer Program'. It governs this program via developers' membership. Membership is accomplished via registration, but additionally by utilizing Apple's services and software for making, testing, and distributing apps via the App Store.

In the longitiduinal study we saw that over the past 11 years, the defintions in the the agreements have quadrupled (as shown by the line graph in Figure 3). We analysed these modifications by looking for 'changes', 'additions' and 'subtractions' to/of definitions, which are represented by the yellow, green, and red bars on the graph (also shown in Figure 3). We found that 'additions' largely represented and are introduced to regulate new features and devices that Apple has added to it's portfolio. However in some cases, these additions seemed to be in response to external, and technical changes. Removals (or 'subtractions') were rare but still signifigant, as they often reflect changes in branding or refinements in the functioning of the platform. 'Changes' on the other hand, tend to represent Apple's efforts to tweak it's goverance of existing services. Essentially, our analysis showed that as the platforms' scope expands, restructions increase at a similar rate and developers' roles and responsibilities shift in response.

Figure 3: Longitudinal Analysis of Apple's Developer Program License Agreement

With our event-based study (Figure 4) our goal was to contextualize the spike in definitions in a short period of time. As stated previously, we focused on the shift from iPhoneOS to iOS. The definitional increase in this time can be attributed then to the launch of the iPad, the Game Center, their advertising API, and several other features. We observed the most changes in the larger document which were related to 'actors' (i.e. developer responsibilities if they want to keep using the platform).These changes were also related to the 'technical' (i.e. developers are given access to and must conform to new tech offerings to maintain their membership. In sum, in this shift we see how developers are activly goverened by Apple to turn software into Apps, revealing the trend towards 'platformization'.

Figure 4: Event-Based Analysis of Change from iPhoneOS to iOS (2010)

Conclusion

We conceptualize 'Apple's Developer Program License Agreement' as a living document which is contingent and open to change. In other words, we might imagine that the developer has entered into and is playing a game where the rules are constantly shifting, and where they must adjust their practices to continue playing. Important to note, App developers may not engage with these documents in as much depth as we have. However, these shifts and changes in the document become embedded and encoded within the developer web portal, as well as in the software and services they must engage to continue developing, testing, and distributing their product via the App Store. In this way, applying our 'longitudinal' and 'event-based' protocols to these documents can shed light on how tech entities govern developers infrastructurally at particular points in time AND how these logics of governance shift over time and around events.

Policy Story #4: App-policy Dependencies

We took the top 10 Android apps and looked what kind of software development kits (SDKs) have been embedded to build the app and to include functionality and advertising. With the app as software package (and not the app store) as starting point, we were interested in finding out which policies are evoked by the SDKs that developers embed in the software.

Figure 5: App-policy dependencies

Figure 5 shows that the top 10 apps contain 26 unique SDKs for advertising and social logins and 60 unique SDKs for app development. And this is where things scale up, as each of these SDKs also has 1 or more policies connected to it. We then looked up the developer policies for each of our embedded software development kits.The network challenges the boundaries of the app shows the multi-layeredness and networkedness of app developer governance - as well as the multiplication of the scale of policies that developers need to adhere to.

Conclusion

To conclude, we have used archived app (store) policies to examine which objects and actors have been central to app store and developer governance over time, how this changes, as well as how they are governed. Policies offer a specific perspective to app (hi)stories and show what the platforms care about in terms of app development (e.g. new technological developments such as the introduction of a new device or functionality, or external developments such as GDPR). Importantly, we have found that while app store governance is centralised, governance on the level of the app as software object is highly distributed, networked, and layered.

References

• Litman-Navarro, Kevin. 2019. We Read 150 Privacy Policies. They Were an Incomprehensible Disaster. New York Times. https://www.nytimes.com/interactive/2019/06/12/opinion/facebook-google-privacy-policies.html

Slides

• Project pitch: https://docs.google.com/presentation/d/16Hgac4rDGXBRM6eBak0TayvqCSU6q4aLE0Avlla3ihw/edit?usp=sharing
• Final presentation: https://docs.google.com/presentation/d/1-waimFkc41QqB3miYlYfeqIxu1_S4-kiiscWU0bCc7I/edit?usp=sharing