MEMORANDUM To: Date: Re: Professor Alison Jaenicke January 26, 2012 Analysis of App Store Review Guidelines

as a Technical Document

From: Brian Golden

The purpose of this memo is to provide my analysis of Apples App Store Review Guidelines as a technical document. The version I will be referencing is the first version of the guidelines, released September 2010. Its purpose is to provide an extensive list of unacceptable practices that developers need to be aware of when developing and eventually submitting an application to Apples App Store. Addresses Particular Readers It is made clear from the beginning of the guidelines that the document is designed for use by current and potential developers looking to get their applications approved for Apples App Store. We can break this group down into three distinct primary audiences for whom this document is intended; programmers, designers, and conceptualizers (from this point, I will refer to the collective audience as the developer). The programmers of applications are addressed in sections that speak about software concepts, outside of the realm of the content itself; that is to say, it focuses on basic functionality of the application while ignoring its purpose. Throughout the document various functionality aspects are addressed. In fact, the second section is entitled Functionality, and lists issues that will keep an app from being approved, such things include apps that crash, have bugs, or do not function as advertised in the app description. In addition, issues regarding location-based services, push notifications and information collection are listed so that developers know how they should implement certain functionality. A second and equally important group of people addressed in the guidelines are designers of applications. Often times in the development process, there are artists who design the layout of the program in terms of how the graphics and user interface features are presented. As such, the section on the user interface discusses situations that would force Apple to reject an app related to control flow. The final audience is the initial conceptualizers of applications. Apple lays out the sections on violence, pornography, personal attacks and other objectionable content so that these people will know what not to include in an app to begin with. These sections detail content that should be avoided when determining the main purpose of an application. All of the issues mentioned throughout the document are very short and leave little to interpretation. They are quite blunt so that each subject avoids being bogged down by verbose descriptions, and as such a developer or designer knows the exact purpose of each one. In addition, the entire document addresses these groups in a very direct tone and makes no effort to lighten up on the reader. In Apples mind, developers should have a positive view of development and should not be deterred by some straightforward language. Helps Readers Solve Problems The authors of this document mention at the start that the guidelines were released to help you steer clear of issues as you develop your app, so that it speeds through the approval process

The document is meant to aid developers in avoiding poor programming and design practices the first time around so that they can keep their application from being rejected. The guidelines set forth by Apple would likely be used as a sort of checklist for developers to make sure that they are not including anything in their application that would cause problems with approval. The document would also be utilized in three separate phases; planning, during development and after development is initially finished. The document may be used a fourth time if an application is rejected by Apple; in this last case, the guidelines could be used for the developer to evaluate and find what clause was violated. Reflects Apples Goals and Culture Apple is a company that prides itself on the simple design that gives all of their products direction. As such, the document itself is a very simple one. Each bullet point is a simple declaration of something that Apple will reject an application for; often times they do not extend past one or two lines of text. The introduction also makes mention of how much pride Apple takes in its products and how much they love what they do. By the same token, they are also dedicated to providing the best possible experience for their users. These principles are apparent in that the document is designed in such a way that it is as easy for developers to make great applications as it is to use the product (iPhone, iPad, or Mac) by itself. Evidence of Collaboration All together, the guidelines entail twenty-two separate sections for developers to be aware of in the development process. Some of them are focused on the coding parts of development (see Functionality, Push Notifications, Media Content, etc.); some are focused on legal and sensitivity issues (see Legal requirements, Violence, Religion, culture and ethnicity, etc.). These entities require that experts are used to determine what issues developers should be thinking about during development. For example, computer scientists were probably tapped for the kinds of software matters to be aware of, while lawyers would be able to bring up legal issues that could cause problems for both the developer and Apple. It seems unlikely that any one group of people at Apple would have complete knowledge of application issues, making collaboration in producing the guidelines a necessity. Uses Design to Increase Readability Just as simplicity is evident in Apples culture, it was certainly also a consideration in the presentation of the App Store guidelines. The document contains no graphics to distract from the content itself, which is most important. A table of contents is provided which plainly outlines the focus of each section for easy navigation. Also, each header is bolded and larger than the body text. As mentioned before, each clause usually does not extend past one or two lines of text, which makes each section easy to look over so that a reader does not miss any important items while reading through the document. It is also important to note that sans serif font is used, which gives the document a smooth look and feel. As a whole, the document is laid out using a strong hierarchical numbering system, so that readers can recognize where they are in the document and refer to specific content. Effective Use of Words By making effective word choices and making use of repetition, Apple is able to convey purpose quite easily to the reader. One thing that really caught my attention was the way each clause was written. I would estimate that 90% of clauses in the document are structured as applications that do this will be rejected. The vast majority end with that will be rejected phrase and by using that repetition throughout, Apple is able to drive home the point that the purpose of the document

is to inform developers of what they should not write into their applications under any circumstances. Another interesting thing about the guidelines is how Apple chose to end it; they do so with a section entitled Living document. Here, they remind readers that the document will evolve as [Apple is] presented with new apps and situations, and [Apple will] update it periodically to reflect these changes. Here and throughout the document, Apple assumes a very conversational manner of speaking, such that the reader can feel some sort of connection to the authors. Although very direct in their writing, Apple is sure to write everything in a very matterof-fact way, rather than choose to be overly formal. The authors wrap things up by thanking the developers reading for their own hard work and by inviting them in trying to surprise and delight users and to go the extra mile. This makes the reader feel a part of Apples community because of their friendly and encouraging tone. Summary I found Apples App Store Review Guidelines to be a prime example of a technical document that although very long and intimidating at first is easy to navigate, read and understand. It was heavy on content but the authors did an effective job of making it useful to its audience by encouraging current and potential developers to work on Apples iOS framework.