Introduction
This guide contains the general information on the procedures and requirements for the successful submission of an iOS app to the App Store.
Test on Devices
Test your app thoroughly on iPad, iPhone, and iPod touch before uploading it to iTunes Connect. The iPhone Simulator is ideal for prototyping your ideas, debugging memory leaks, simulating memory warnings, and getting a good feel for how your app is going to work. However, since the iPhone Simulator simulates iOS, not hardware, it is not a replacement for testing on an actual device.
App Review Process
The Apple App Review Team checks every app submission in order to protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of iPad, iPhone, and iPod touch. All aspects of your app must comply with the criteria outlined in the App Store Review Guidelines and should conform to the iOS Human Interface Guidelines.
After your app has been reviewed and approved, it will be set to the Ready for Sale state and published to the store within the day.
If an issue is discovered during the review of your app, the university will be notified via email. You will then be contacted on the details regarding your app rejection which explains how you can resolve it before resubmitting.
Information and Assets
In addition to your binary, you will need to submit or assign several attributes for your application, including:
ATTRIBUTE NAME | DESCRIPTION |
---|---|
App Name | The localized name of your app as it appears on the store. The app name must be at least two characters and no more than 75 characters. |
Description | A localized description of the app, detailing features and functionality. Descriptions are limited to 4000 single-byte characters. The description should be in plain text, with line breaks as needed. HTML formatting isn’t recognized. Make sure to check your text for spelling or grammar errors. |
Version | The version number of the app you are adding. Numbering should follow typical software versioning conventions (for example, 1.0 or 1.0.1 or 1.1). |
What's New in this Version | Localized release notes detailing the changes in this version of your app. For example, you might want to list new features, UI improvements, or bug fixes. This text can be as long as 4000 single-byte characters. This field isn’t available for the first version of an app. |
Keywords | One or more localized keywords that describe your app. Separate search terms with commas. At least one keyword of greater than two characters is required. You can provide up to 100 bytes of content. Your app is searchable by app name and company name, so you do not need to duplicate these values in the keyword list. Names of other apps or companies are not allowed. Keywords cannot be edited once your binary is in review.
For example: SMU, business, higher education, postgraduate, undergraduate doctoral, continuing education, research |
Support URL | The support website you plan to provide for users who have questions regarding the app. The support URL must lead to actual contact information so that your users can contact you regarding app issues, general feedback, and feature enhancement requests. The URL can specify a localized site. Include the entire URL, including the protocol.
For example: http://support.example.com |
Marketing URL |
The website where users get more information about the app. The URL can specify a localized site. Include the entire URL, including the protocol. |
Privacy Policy URL | A URL that links to your company’s privacy policy. Privacy policy URLs are required for all apps that offer auto-renewable or free subscriptions and for apps that are set to Made for Kids. Customers see this URL on their invoice and on the subscription confirmation email they receive. The URL can specify a localized site.
Specify the entire URL, including the protocol. |
Primary Category | The category that best describes the app you are adding. Choose one from the list:
|
Secondary Category | Choose another category from the list above. |
Pricing | All apps by default will be released to the App Store as free. If you are adopting a paid model for your app, kindly contact IITS for further information. |
Available Date | The date your app will become available on the App Store. If no date is specified, the app will be released immediately once the Apple Review Team has approved it. |
Territories | Indicate the App Store territories in which you want to make your app available. Unless specified, your app will be available in all App Store territories worldwide. Placing the app worldwide is recommended as some international students are using their own country's iTunes account instead of the one from Singapore. |
Large App Icon | A large version of your app icon that will be used on the App Store. It must be at least 72 DPI, in the RGB color space, and 1024 x 1024 pixels (it cannot be scaled up). The file type must be .jpeg, .jpg, .tif, .tiff, or .png. It must be flat artwork without rounded corners. |
Important: Make sure to submit app icons for high-resolution Retina displays. All new app submissions must include a large app icon with a minimum of 1024 x 1024 pixels.
Screenshots
Engaging screen shots can make a significant influence on a user’s perception of your app. This is your opportunity to demonstrate the capabilities, graphics, and usability of your app. When creating screen shots to be posted to the App Store, follow these general guidelines:
- Make sure the content is legible and appropriate.
- Consider cultural sensibilities and restrictions.
- Take screen shots on the target device (not the Simulator). To do this, hold down the Power button and press the Home button. The screen shot is saved to Camera Roll.
- Always remove the status bar from screen shots.
- Donʼt forget to localise the screen shots. Set the language for iPhone before taking screen shots by going to Settings » General » International » Language.
Signing Identities and Certificates
Code signing your app lets users trust that your app has been created by a source known to Apple and that it hasn’t been tampered with. All iOS apps and most Mac apps must be code signed and provisioned to launch on a device, to be distributed for testing, or to be submitted to the store. Code signing uses cryptographic technology to digitally sign your app and installer package. The university maintains the set of production identities and certificates required for the signing of your binary to be submitted to the Apple App Store. Developers are required to submit the entire Xcode project, including all external libraries and SDKs, and a set of specific instructions to compile and run, where applicable. The codes will subjected to vulnerability assessment before being signed and submitted to the App Store.
App ID
An App ID is a two-part string used to identify one or more apps from a single development team. The string consists of a Team ID and a bundle ID search string, with a period (.) separating the two parts. The Team ID is supplied by Apple and is unique to a specific development team, while the bundle ID search string is supplied by you to match either the bundle ID of a single app or a set of bundle IDs for a group of your apps. There are two types of App IDs: an explicit App ID, used for a single app, and wildcard App IDs, used for a set of apps. Explicit App IDs cater for app features such as Push Notifications, In-App Purchases etc. The university uses explicit App ID for all submissions and will assign your app with an appropriate App ID.
Comments