Designing and developing
Stanford mobile apps
The following information is intended to help guide the use of Stanford’s visual identity for mobile applications.
Questions regarding these guidelines and standards may be submitted using this form.
Any and all new mobile apps assets that do not follow these guidelines and standards should be designed in consultation with the Endpoint Engineering and Development (EED) team in University IT. While some legacy apps may not follow these guidelines and standards, all newly designed and developed apps are expected to adhere.
Submit a ServiceNow request for app development questions
Pre-approved mobile app templates for iOS and Android
The app icon should display Stanford’s block “S” with tree emblem centered above the app’s name. The content below the emblem should reflect the content and character of the app. The block “S” with tree emblem must remain visible and its permutations beyond those outlined here are not permitted. Additional options, including more branded color options, are actively being designed and will be included here as they become finalized.
The launch screen displays Stanford’s wordmark in white font on a Cardinal Red background, centered both vertically and horizontally.
Official Stanford University app stores
Learn more about building and submitting mobile apps to Stanford’s Apple Developer Connection (ADC) or Google Play Console.
Stanford University Developer Console Policies and Guidelines
Requirements for receiving Stanford approval of an Apple App Store or Google Play Store application submission
Important note: following the below policies and guidelines does not alone guarantee approval for application distribution in the Stanford University developer accounts, as some applications might be more appropriately suited for distribution under another Stanford-related developer account or an individual developer account. Any and all exception requests will be routed through the Stanford CIO.
An active and valid SUNet ID is required for all Stanford University Apple App Store and Google Play Store account creations. Non-Stanford accounts are not eligible for developer console access.
If you are working with a vendor, or an individual(s) without a SUNet ID, you will need to provide account sponsorship.
Code repository access
Read-only access to the application’s code repository must be provided to University IT.
While hosting your application’s code in Stanford’s GitLab instance is an option, it is not a requirement.
Stanford University provides standards intended to reflect the minimum level of care necessary for sensitive data. Applications must adopt these standards, prioritizing by risk level.
Brand and identity guidelines
The Stanford University name and logo are well-established and carry world-class brand equity. All applications must use these elements in a consistent manner to maintain a clear, unified brand identity.
Stanford provides well documented guidelines, best practices, examples, and resources.
Stanford University’s goal is to provide applications that conform to modern accessibility guidelines and standards. The Stanford Online Accessibility Program (SOAP) provides resources for designers, developers, and content creators to help in the production of applications that are accessible to the broadest audience possible.
All applications must meet, at least, the minimum requirements for platform accessibility which you can find at the site below.
Apple and Google code of conduct
Prior to an application’s release, a review by Apple and/or Google is required.
Apple and Google provide guidelines related to safety, performance, business, design, and more. All applications should follow the guidelines below to ensure the most streamlined release process.
Community code of conduct
As a developer who has been provided access to Stanford University’s Apple and/or Google consoles, you agree to support and assist with the following:
- Ensuring only vetted developers are provided access
- Keeping open communication about the most current state of applications and associated developers
- Avoiding any actions that could have negative ramifications on others (e.g., deleting a common certificate)
- Corresponding and documenting as much as possible through ServiceNow rather than by direct communication