• HTML5 or iOS

Academic Honesty

All work that you do toward fulfillment of this course’s expectations must be your own. Collaboration on projects is not permitted.

Viewing or copying another individual’s work (even if left by a printer, stored in an executable directory, or posted online) or lifting material from a book, website, or other source—even in part—and presenting it as your own constitutes academic dishonesty, as does showing or giving your work, even in part, to another student or soliciting the work of another individual. Similarly is dual submission academic dishonesty: you may not submit the same or similar work to this course that you have submitted or will submit to another. Nor may you provide or make available solutions to problem sets to individuals who take or may take this course in the future. Moreover, submission of any work that you intend to use outside of the course (e.g., for a job) must be approved by the course’s instructor.

You are welcome to discuss the course’s material with others in order to better understand it. You may even discuss projects with classmates, but you may not share code. In other words, you may communicate with classmates in English, but you may not communicate in, say, Objective-C. If in doubt as to the appropriateness of some discussion, contact the course’s instructor.

You may turn to the Web for instruction beyond the course’s lectures and sections, for references, and for solutions to technical difficulties, but not for outright solutions to problems on problem sets or your own final project. However, failure to cite (as with comments) the origin of any code or technique that you do discover outside of the course’s lectures and sections (even while respecting these constraints) and then integrate into your own work may be considered academic dishonesty.

All forms of academic dishonesty are dealt with harshly. If the course refers some matter to the Administrative Board and the outcome for some student is disciplinary action, the course reserves the right to impose local sanctions on top of that outcome for that student that may include, but not be limited to, a failing grade for work submitted or for the course itself.


Your work on this project will be evaluated along four primary axes.

  • Correctness. To what extent is your code consistent with our specifications and free of bugs?

  • Design. To what extent is your code written well (i.e., clearly, efficiently, elegantly, and/or logically)?

  • Scope. To what extent does your code implement the features required by our specification?

  • Style. To what extent is your code readable (i.e., commented and indented with variables aptly named)?


Before proceeding to write any code:

  1. Decide whether you’d like to implement an HTML5 app or an iOS app.

  2. Submit a formal proposal at

Within 72 hours, your teaching fellow, via email, will either approve your proposal or request modifications thereto. Be sure not to submit an app that wasn’t approved. Unapproved apps may not be accepted.

Implementation Details

Once your proposal has been approved by your teaching fellow, it’s time to implement your app! In addition to the features you have required of yourself, we do have some additional requirements.

HTML5 Apps

If you implement an HTML5 app:

  • Your app’s UI should be designed for an iPhone or iPod touch whose width is defined by device-width.

  • The entry point to your app should be a file called index.html. Code that you write may live within that file or external JavaScript and/or CSS files.

  • Your app may depend on third-party services but may not rely on any server-side scripts of your own. Any code that you yourself write must be client-side JavaScript.

  • Your app may utilize third-party JavaScript (and CSS) libraries so long as they do not implement most of your app’s functionality.

  • Your HTML must be valid HTML5 per, but your CSS does not need to be valid per

  • Your CSS and JavaScript must not be minified.

  • Under no circumstances should we be able to trigger runtime errors in your JavaScript code. Be sure that you handle unwanted inputs and HTTP failures elegantly, as by reporting such errors or silently handling. Under no circumstances should your code trigger errors in Webkit’s own console.

Native Apps

If you implement a native app:

  • Your app’s UI should be sized for an iPhone or iPod touch.

  • Under no circumstances should we be able to cause your program to crash at runtime.

  • Your project’s Product Name may be anything. Your project’s Company Identifier should be edu.harvard.

  • Your app must use Automatic Reference Counting (ARC).

  • Your app must tolerate low-memory warnings (as by reloading views when needed).

  • Your app must work within the iOS 6.1 Simulator; you need not test it on actual hardware. However, if you own an iPad, iPhone, or iPod touch, and you’d like to install your app on it, see for instructions.


In addition to code, you must also write some documentation so we know how your project works and what it should do. Once your project is complete, write a document called README.pdf or README.txt that describes your app’s usage, its purpose, and any setup that’s required to get it working properly. In essence, reading through this documentation should provide us with enough information so that we understand your app and the entirety of its usage without needing to ask you any questions.