Some of the most important information that needs to be passed on to Apple comes in the form of technical specifications.  Pay close attention to the criteria below to be sure your app contains all necessary data and formats to successfully be submitted to Apple.


(plus) Take a look at Apple's Best Practices page and discover some really great tips and insider information about submitting your app to the store. 


Apple and Android Guidelines

Before beginning any app development, it is important to regularly review and adhere to the development guidelines provided by the operating system provider (Apple for iOS, Google for Android), as well as the PBS-specific requirements presented in this documentation. Not only is adherence to the operating system provider's guidelines required by PBS policy, failure to do so may result in your app being rejected at submission. The operating system guidelines are updated frequently (at least once per quarter), are available as part of your Developer Agreement with the operating system provider, and can be accessed through the appropriate developer portal.

Apple Guidelines:          Android Guidelines:









Please read and follow all mobile development and distribution guidelines carefully, including relevant platforms; failure to do this can cause significant delays to app release. The developer is absolved from adhering to any and all PBS specifications that violate platform policies, in the event that the PBS specifications are contradictory or out of date. However, please do notify PBS if this is the case so that (1) PBS may update these specifications and (2) because from time to time Apple may grant special exceptions, so do not automatically assume that these specifications are invalid.






Applications (“Apps”) must be compatible with the iPhone SDK 4.3 and above and Android 2.3 and above. The app must be tested and qualified on the newest release of each OS at the time of final delivery.



Apps must be native apps, i.e., not using a third party self-publishing tool, unless otherwise agreed in advance.



PBS library modules must be incorporated, as may be provided by PBS. These include standard mechanisms for sharing/community features, localization, TV schedules and cross-promotion, among other planned modules.



The developer should state if the app will require Internet access and, if so, which functionality will be rendered inoperable without connectivity and how disconnected state will be handled.



There is a 50MB file size cap for downloads of apps over the 3G/4G network. Exceeding this cap means that the user must use wifi to download or purchase the app. If the app is projected to be above that size when compressed, please note this in the specification or alpha phase of development.



Apps should be usable on pocket and tablet devices unless otherwise agreed.  Apple requires delivery of a universal binary.






APPLE REQUIRES DELIVERY OF A DEVELOPMENT AND DISTRIBUTION CERTIFICATE. PBS will provide you with development certificates and provisioning profiles. If early stages of development occur under the developer’s internal certificates, PBS will require a minimum of five device IDs for review purposes. Android does not require this.  

Content Restrictions



Use of video clips of length greater than two minutes from programs airing on PBS will require discussion at the concept phase.



HTTP Live Streaming video must be transcoded by PBS and served using PBS’s “COVE” backend infrastructure for optimized performance.



Usability Guidelines for All Ages



In general, for both Apple and Android, refer to and follow the iPhone Human Interface Guidelines.



Due the small screen size, visual design should be as simple and streamlined as possible. All elements on screen should have a function.



For standard elements (turning sound on/off) we recommend making use of the device Settings panel.



Text should always be presented in a manner consistent with the changing contrast needs of a mobile device; dark sans-serif text on a light background is preferred.



Hot Zones - Each interactive element should have a 40x40 pixel hot zone to fit a fingertip.



Navigation - Always have a clear, consistent way to return to the previous screen or main menu. Back arrows and home icons are generally recommended.






Cross-promotion - A button and/or banner space must be included on the main menu of the app that links to other PBS apps, as appropriate, in the App Store.



Splash - The splash screen should be short and, if possible considering application load time, allow the user to skip to the app content by tapping the screen. The splash screen must feature the PBS logo, the PBS URL and the app title. A second screen for producer/developer is permitted but must be shared.



App information - Both of these elements should be available, preferably from the primary menu screen of the app.

  • Info should provide the legal lines, copyright and privacy information and should use the Apple circle ‘i' icon (a.k.a. “i-dot”) unless otherwise agreed upon.
  • About should include a short description of key features.



  • Google Analytics must be implemented in each app using a tracking ID provided by PBS.
  • Developer and PBS should work together to identify elements to be tagged, which should be implemented at the Alpha stage.
  • Please provide documentation of the tagged elements and the analytics software used.



Legal Lines



Must include copyright line for IP owner (varies by contract) and copyrights/trademarks for Series/characters to be provided by PBS.



Privacy Notice -

"The <App Name> app collects anonymous, aggregated analytics data for the purpose of improving the app experience. No personally identifiable data is collected."

OR, for any app that collects pictures, recordings, etc. use this instead:

"The <App Name> app collects anonymous, aggregated analytics data for the purpose of improving the app experience. No personally identifiable data is collected, except as follows: <Media type - photos, recordings, etc.> may be collected by this app and stored locally on your device as part of the explicit functionality of the app. The app does not send this information over a network unless you explicitly choose to use the sharing functionality that may be included with the app."



Development Deliverables

Below are explanations of key deliverables. Other deliverables may be requested by PBS, depending on the type of app you produce.  View critical development stages

  • Concept/design documentation: consists of screenshots and a written description of app flow and functionality. A development schedule and line-item budget should be attached, with time allotted for PBS feedback at each stage.
  • Alpha version: a completely interactive version of the app. May be missing some elements but should represent intended behavior.
  • Beta: the complete app with final art and functionality, but with known bugs and issues documented in release notes. Note that there may be multiple iterations of alpha/beta.
  • Source code for PBS review and archiving.

Provisioning Profile

If you are using your own mobile provisioning profile during the build process, please include the appropriate device UDIDs in the profile for each build.  PBS will provide the most-current UDIDs at the outset of each project.

 What is a UDID and how do I find it?

What is a UDID?

A UDID, or “Unique Device Identifier,” is a unique 40-digit alphanumeric serial number that serves as a way to document the existence of and track your iDevice.  Many ad companies use the UDID to profile cellphone users for marketing purposes

How do I find the UDID?

To find your iPhone’s UDID:

  • Plug your iPhone into iTunes.
  • Click on your iPhone in the list of devices and look at its summary. Name, Capacity, Software Version, Identifier, and Phone Number displays (Figure 1).

Figure 1

Final Deliverables

Final Builds

PBS will need all source files for the project, as well as up to three final binary files. These files should be delivered to PBS as separate ZIP files. Both the ZIP file and the binary should have the same name as the official name of the app that will be in the App Store. All final builds should be compiled with the most-current Apple SDK and with the distribution certificate supplied by PBS. All apps should be tested on the iPod Touch as well as on the iPhone, using the newest OS available.

  1. A Distribution Build that PBS will upload for Apple technical review and posting in the iTunes Store. This should be compiled with the most recent version of the iPhone SDK at the time of delivery, using the PBS Distribution Certificate and posted to your project site as a ZIP file, with the suffix _dist.
  2. A Release Build that PBS can share with Apple for their editorial review when Apple considers promoting the app. This should be compiled with the most recent version of the iPhone SDK at the time of delivery, using the PBS Distribution Certificate as an Ad Hoc build with the suffix _rel.
  3. A Demo Build (only if requested by PBS) that could be incorporated into either Apple’s standard demo device image for a period of time (generally one calendar quarter). This must have limited content, so please consult with PBS to find the best way to limit the content for the demo build. This build must be compiled with the most recent version of the iPhone SDK at the time of delivery, using PBS Distribution certificate as specified above. Both the ZIP file and the binary should have the same name as the official name of the app that will be in the App Store; primary screens must be modified to indicate that it is a demo version.  Carefully read and follow the “Instructions for Submitting your iPhone/iPod touch Demo Application” found in the Apple Developers Center.

iOS Art Asset Specifications and Guidelines

Several pieces of artwork are involved when submitting an app. It is important to review the artwork requirements section and discover what you need to accomplish with your artwork and the things to avoid in order to achieve a successful submission.  Click here to review Artwork Requirements

Apple and Android have their own set of requirements that should be reviewed as well:  Click here to view Apple documentation and guidelines  /   Click here for Android guidelines

(warning) Be aware that because of all of the different devices out there, it is critical that you design your artwork to fit all variations.