Written by : Gaurav D. Sharma 2011INDEX
1. Code Should follow this terms, conditions and code standards. Unless Apps will be rejected.
2. Apps Store Review Guidelines
⁃ Make your code distributed (Binary for upload to apple store (itunesconnect.apple.com)) Before apply this please read both try first then apply this step.
3. Distribution
⁃ Try one
⁃ Try two
4. App Store Approve Process
5. There are 16 types of status of your apps in itunesconnect.apple.com
6. Distributing your applications Ad Hoc (Optional)
Download it as PDF click here
=========================================================================
Apps Store Review Guidelines
Code should follow this terms and conditions.
_____________________________________________________________________________________________________
Introduction
We're pleased that you want to invest your talents and time to develop applications for iOS. It has been a rewarding experience - both professionally and financially - for tens of thousands of developers and we want to help you join this successful group. We have published our App Store Review Guidelines in the hope that they will help you steer clear of issues as you develop your app and speed you through the approval process when you submit it.
We view Apps different than books or songs, which we do not curate. If you want to criticize a religion, write a book. If you want to describe sex, write a book or a song, or create a medical app. It can get complicated, but we have decided to not allow certain kinds of content in the App Store. It may help to keep some of our broader themes in mind:
• We have lots of kids downloading lots of apps, and parental controls don't work unless the parents set them up (many don't). So know that we're keeping an eye out for the kids.
• We have over 350,000 apps in the App Store. We don't need any more Fart apps. If your app doesn't do something useful or provide some form of lasting entertainment, it may not be accepted.
• If your App looks like it was cobbled together in a few days, or you're trying to get your first practice App into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don't want their quality
Apps to be surrounded by amateur hour.
• We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.
• If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps.
• If you attempt to cheat the system (for example, by trying to trick the review process, steal data from users, copy another developer's work, or manipulate the ratings) your apps will be removed from the store and you will be expelled from the
developer program.
• This is a living document, and new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this.
Lastly, we love this stuff too, and honor what you do. We're really trying our best to create the best platform in the world for you to express your talents and make a living too. If it sounds like we're control freaks, well, maybe it's because we're so committed to our users and making sure they have a quality experience with our products. Just like almost all of you are too.
Table of Contents
1. Terms and conditions
2. Functionality
3. Metadata, ratings and rankings
4. Location
5. Push notifications
6. Game Center
7. iAds
8. Trademarks and trade dress
9. Media content
10. User interface
11. Purchasing and currencies
12. Scraping and aggregation
13. Damage to device
14. Personal attacks
15. Violence
16. Objectionable content
17. Privacy
18. Pornography
19. Religion, culture, and ethnicity
20. Contests, sweepstakes, lotteries, and raffles
21. Charities and contributions
22. Legal requirements
1. Terms and conditions
• 1.1
As a developer of applications for the App Store you are bound by the terms of the Program License Agreement (PLA), Human Interface Guidelines (HIG), and any other licenses or contracts between you and Apple. The following rules and examples are intended to assist you in gaining acceptance for your app in the App Store, not to amend or remove provisions from any other agreement.
2. Functionality
• 2.1
Apps that crash will be rejected
• 2.2
Apps that exhibit bugs will be rejected
• 2.3
Apps that do not perform as advertised by the developer will be rejected
• 2.4
Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected
• 2.5
Apps that use non-public APIs will be rejected
• 2.6
Apps that read or write data outside its designated container area will be rejected
• 2.7
Apps that download code in any way or form will be rejected
• 2.8
Apps that install or launch other executable code will be rejected
• 2.9
Apps that are "beta", "demo", "trial", or "test" versions will be rejected
• 2.10
iPhone apps must also run on iPad without modification, at iPhone resolution, and at 2X iPhone 3GS resolution
• 2.11
Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them, such as fart, burp, flashlight, and Kama Sutra apps.
• 2.12
Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected
• 2.13
Apps that are primarily marketing materials or advertisements will be rejected
• 2.14
Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected
• 2.15
Apps larger than 20MB in size will not download over cellular networks (this is automatically prohibited by the App Store)
• 2.16
Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.
• 2.17
Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
• 2.18
Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected
• 2.19
Apps that provide incorrect diagnostic or other inaccurate device data will be rejected
• 2.20
Developers "spamming" the App Store with many versions of similar apps will be removed from the iOS Developer Program
• 2.21
Apps that are simply a song or movie should be submitted to the iTunes store. Apps that are simply a book should be submitted to the iBookstore.
• 2.22
Apps that arbitrarily restrict which users may use the app, such as by location or carrier, may be rejected
3. Metadata (name, descriptions, ratings, rankings, etc)
• 3.1
Apps or metadata that mentions the name of any other mobile platform will be rejected
• 3.2
Apps with placeholder text will be rejected
• 3.3
Apps with descriptions not relevant to the application content and functionality will be rejected
• 3.4
App names in iTunes Connect and as displayed on a device should be similar, so as not to cause confusion
• 3.5
Small and large app icons should be similar, so as to not to cause confusion
• 3.6
Apps with app icons and screenshots that do not adhere to the 4+ age rating will be rejected
• 3.7
Apps with Category and Genre selections that are not appropriate for the app content will be rejected
• 3.8
Developers are responsible for assigning appropriate ratings to their apps. Inappropriate ratings may be changed/deleted by Apple
• 3.9
Developers are responsible for assigning appropriate keywords for their apps. Inappropriate keywords may be changed/deleted by Apple
• 3.10
Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the iOS Developer Program
• 3.11
Apps which recommend that users restart their iOS device prior to installation or launch may be rejected
• 3.12
Apps should have all included URLs fully functional when you submit it for review, such as support and privacy policy URLs
4. Location • 4.1
Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
• 4.2
Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
• 4.3
Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
• 4.4
Location data can only be used when directly relevant to the features and services provided by the app to the user or to support approved advertising uses
5. Push notifications • 5.1
Apps that provide Push Notifications without using the Apple Push Notification (APN) API will be rejected
• 5.2
Apps that use the APN service without obtaining a Push Application ID from Apple will be rejected
• 5.3
Apps that send Push Notifications without first obtaining user consent will be rejected
• 5.4
Apps that send sensitive personal or confidential information using Push Notifications will be rejected
• 5.5
Apps that use Push Notifications to send unsolicited messages, or for the purpose of phishing or spamming will be rejected
• 5.6
Apps cannot use Push Notifications to send advertising, promotions, or direct marketing of any kind
• 5.7
Apps cannot charge users for use of Push Notifications
• 5.8
Apps that excessively use the network capacity or bandwidth of the APN service or unduly burden a device with Push Notifications will be rejected
• 5.9
Apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the APN service will be rejected
6. Game Center • 6.1
Apps that display any Player ID to end users or any third party will be rejected
• 6.2
Apps that use Player IDs for any use other than as approved by the Game Center terms will be rejected
• 6.3
Developers that attempt to reverse lookup, trace, relate, associate, mine, harvest, or otherwise exploit Player IDs, alias, or other information obtained through the Game Center will be removed from the iOS Developer Program
• 6.4
Game Center information, such as Leaderboard scores, may only be used in apps approved for use with the Game Center
• 6.5
Apps that use Game Center service to send unsolicited messages, or for the purpose of phishing or spamming will be rejected
• 6.6
Apps that excessively use the network capacity or bandwidth of the Game Center will be rejected
• 6.7
Apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the Game Center service will be rejected
7. iAds • 7.1
Apps that artificially increase the number of impressions or click-throughs of ads will be rejected
• 7.2
Apps that contain empty iAd banners will be rejected
• 7.3
Apps that are designed predominantly for the display of ads will be rejected
8. Trademarks and trade dress • 8.1
Apps must comply with all terms and conditions explained in the Guidelines for Using Apple Trademarks and Copyrights and the Apple Trademark List • 8.2
Apps that suggest or infer that Apple is a source or supplier of the app, or that Apple endorses any particular representation regarding quality or functionality will be rejected
• 8.3
Apps which appear confusingly similar to an existing Apple product or advertising theme will be rejected
• 8.4
Apps that misspell Apple product names in their app name (i.e., GPS for Iphone, iTunz) will be rejected
• 8.5
Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
• 8.6
Google Maps and Google Earth images obtained via the Google Maps API can be used within an application if all brand features of the original content remain unaltered and fully visible. Apps that cover up or modify the Google logo or copyright holders identification will be rejected
9. Media content • 9.1
Apps that do not use the MediaPlayer framework to access media in the Music Library will be rejected
• 9.2
App user interfaces that mimic any iPod interface will be rejected
• 9.3
Audio streaming content over a cellular network may not use more than 5MB over 5 minutes
• 9.4
Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64 kbps audio-only HTTP Live stream
10. User interface • 10.1
Apps must comply with all terms and conditions explained in the Apple iOS Human Interface Guidelines • 10.2
Apps that look similar to apps bundled on the iPhone, including the App Store, iTunes Store, and iBookstore, will be rejected
• 10.3
Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iOS Human Interface Guidelines may be rejected • 10.4
Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected
• 10.5
Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected
• 10.6
Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected
11. Purchasing and currencies • 11.1
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
• 11.2
Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
• 11.3
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
• 11.4
Apps that use IAP to purchase credits or other currencies must consume those credits within the application
• 11.5
Apps that use IAP to purchase credits or other currencies that expire will be rejected
• 11.6
Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
• 11.7
Apps that use IAP to purchase items must assign the correct Purchasability type
• 11.8
Apps that use IAP to purchase access to built-in capabilities provided by iOS, such as the camera or the gyroscope, will be rejected
• 11.9
Apps containing "rental" content or services that expire after a limited time will be rejected
• 11.10
Insurance applications must be free, in legal-compliance in the regions distributed, and cannot use IAP
• 11.11
In general, the more expensive your app, the more thoroughly we will review it
• 11.12
Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Developer Program License Agreement. • 11.13
Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected
• 11.14
Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app, as long as there is no button or external link in the app to purchase the approved content. Apple will not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app
12. Scraping and aggregation • 12.1
Applications that scrape any information from Apple sites (for example from apple.com, iTunes Store, App Store, iTunes Connect, Apple Developer Programs, etc) or create rankings using content from Apple sites and services will be rejected • 12.2
Applications may use approved Apple RSS feeds such as the iTunes Store RSS feed
• 12.3
Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
13. Damage to device • 13.1
Apps that encourage users to use an Apple Device in a way that may cause damage to the device will be rejected
• 13.2
Apps that rapidly drain the device's battery or generate excessive heat will be rejected
14. Personal attacks • 14.1
Any app that is defamatory, offensive, mean-spirited, or likely to place the targeted individual or group in harms way will be rejected
• 14.2
Professional political satirists and humorists are exempt from the ban on offensive or mean-spirited commentary
15. Violence • 15.1
Apps portraying realistic images of people or animals being killed or maimed, shot, stabbed, tortured or injured will be rejected
• 15.2
Apps that depict violence or abuse of children will be rejected
• 15.3
"Enemies" within the context of a game cannot solely target a specific race, culture, a real government or corporation, or any other real entity
• 15.4
Apps involving realistic depictions of weapons in such a way as to encourage illegal or reckless use of such weapons will be rejected
• 15.5
Apps that include games of Russian roulette will be rejected
16. Objectionable content • 16.1
Apps that present excessively objectionable or crude content will be rejected
• 16.2
Apps that are primarily designed to upset or disgust users will be rejected
17. Privacy • 17.1
Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used
• 17.2
Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
• 17.3
Apps that target minors for data collection will be rejected
18. Pornography • 18.1
Apps containing pornographic material, defined by Webster's Dictionary as "explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings", will be rejected
• 18.2
Apps that contain user generated content that is frequently pornographic (ex "Chat Roulette" apps) will be rejected
19. Religion, culture, and ethnicity • 19.1
Apps containing references or commentary about a religious, cultural or ethnic group that are defamatory, offensive, mean-spirited or likely to expose the targeted group to harm or violence will be rejected
• 19.2
Apps may contain or quote religious text provided the quotes or translations are accurate and not misleading. Commentary should be educational or informative rather than inflammatory
20. Contests, sweepstakes, lotteries, and raffles • 20.1
Sweepstakes and contests must be sponsored by the developer/company of the app
• 20.2
Official rules for sweepstakes and contests, must be presented in the app and make it clear that Apple is not a sponsor or involved in the activity in any manner
• 20.3
It must be permissible by law for the developer to run a lottery app, and a lottery app must have all of the following characteristics: consideration, chance, and a prize
• 20.4
Apps that allow a user to directly purchase a lottery or raffle ticket in the app will be rejected
21. Charities and contributions • 21.1
Apps that include the ability to make donations to recognized charitable organizations must be free
• 21.2
The collection of donations must be done via a web site in Safari or an SMS
22. Legal requirements • 22.1
Apps must comply with all legal requirements in any location where they are made available to users. It is the developer's obligation to understand and conform to all local laws
• 22.2
Apps that contain false, fraudulent or misleading representations will be rejected
• 22.3
Apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected
• 22.4
Apps that enable illegal file sharing will be rejected
• 22.5
Apps that are designed for use as illegal gambling aids, including card counters, will be rejected
• 22.6
Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected
• 22.7
Developers who create apps that surreptitiously attempt to discover user passwords or other private user data will be removed from the iOS Developer Program
• 22.8
Apps which contain DUI checkpoints that are not published by law enforcement agencies, or encourage and enable drunk driving, will be rejected
Living document
This document represents our best efforts to share how we review apps submitted to the App Store, and we hope it is a helpful guide as you develop and submit your apps. It is a living document that will evolve as we are presented with new apps and situations, and we'll update it periodically to reflect these changes.
Thank you for developing for iOS. Even though this document is a formidable list of what not to do, please also keep in mind the much shorter list of what you must do. Above all else, join us in trying to surprise and delight users. Show them their world in innovative ways, and let them interact with it like never before. In our experience, users really respond to polish, both in functionality and user interface. Go the extra mile. Give them more than they expect. And take them places where they have never been before. We are ready to help.
© Apple, 2011
=========================================================================
Distribution
Try One :(Best )
https://developer.apple.com/ios/manage/distribution/index.action
_____________________________________________________________________________________________________
The distribution area of the iOS Provisioning Portal is where you will prepare and learn how to submit your iPhone and/or iPod touch application for delivery via in-house or Ad Hoc distribution. Only Team Agents are authorized to prepare and submit applications for distribution.
For information about distributing your application on the App Store, please see the App Store tab.
Obtaining your iOS Distribution Certificate(Need this step only Once)
In order to distribute your iOS application, the Team Agent is required by Apple to create an iOS Distribution Certificate. Only the Team Agent for your team will be able to create this certificate and only this certificate will enable application submission.
Generating a Certificate Signing Request
To request an iOS Distribution Certificate, you first need to generate a Certificate Signing Request (CSR) utilizing the Keychain Access application in Mac OS X Leopard. The creation of a CSR will prompt Keychain Access to simultaneously generate your public and private key pair establishing your iOS Distribution identity. Your private key is stored in the login Keychain by default and can be viewed in the Keychain Access application under the ‘Keys’ category. To generate a CSR:
1. In your Applications folder, open the Utilities folder and launch Keychain Access.
2. In the Preferences menu, set Online Certificate Status Protocol (OSCP) and Certificate Revocation List (CRL) to “Off”.
3. Choose Keychain Access -> Certificate Assistant -> Request a Certificate from a Certificate Authority. Note: If you have a private key highlighted in the Keychain during this process, the resulting Certificate Request will not be accepted by the Provisioning Portal. Confirm that you are selecting “Request a Certificate From a Certificate Authority...” and not selecting “Request a Certificate From a Certificate Authority with <Private Key>…”
4. In the User Email Address field, enter your email address. Please ensure that the email address entered matches the information that was submitted when you registered as an iOS Developer.
5. In the Common Name field enter your Company/Organization/Department name. Please ensure that the name entered matches the information that was submitted when you registered as an iOS Developer.
6. No CA Email Address is required.
7. Select the ‘Saved to Disk’ radio button and if present, select ‘Let me specify key pair information’ and click ‘Continue’.
8. If ‘Let me specify key pair’ was selected, specify a file name and click ‘Save’. In the following screen select ‘2048 bits’ for the Key Size and ‘RSA’ for the Algorithm. Click ‘Continue’.
9. The Certificate Assistant will create a CSR file on your desktop.
Submitting a Certificate Signing Request for Approval
1. After creating a CSR, log in to the iOS Provisioning Portal and navigate to ‘Certificates’ -> ‘Distribution’ and click the ‘Add Certificate’ button.
2. Click the Upload file button, select your CSR and click ‘Submit’. If the Key Size was not set to 2048 bits during the CSR creation process, the Portal will reject the CSR.
3. Approve your iOS Distribution Certificate.
Downloading and Installing iOS Distribution Certificates
1. In the ‘Certificates’-->’Distribution’ section of the Portal, Control-Click the WWDR Intermediate Certificate link and select “Saved Linked File to Downloads” to initiate download of the certificate. After downloading, double-click the certificate to launch Keychain Access and install.
2. In the same area of the Provisioning Portal, click on the name of the iOS Distribution Certificate to download.
3. On your local machine, double-click the downloaded .cer file to launch Keychain Access and install your certificate.
Saving your Private Key and Transferring to Other Systems
It is critical that you save your private key somewhere safe in the event that you need to build your application on multiple Macs or decide to reinstall your system OS. Without your private key, you cannot sign binaries in Xcode and there you will be unable to upload your application to the App Store or install your application on any Apple device. When a CSR is generated, the Keychain Access application creates a private key on your login keychain. This private key is tied to your user account and cannot be reproduced if lost due to an OS reinstall. If you plan to do development and testing on multiple systems, you will need to import your private key onto all of the systems you’ll be doing work on.
1. To export your private key and certificate for safe-keeping, open up the Keychain Access Application and select the “Keys” category.
2. Highlight the private key associated with your iOS Distribution Certificate and select “Export Items” from the ‘File’ menu. Save your key in the Personal Information Exchange (.p12) file format.
3. You will be prompted to create a password which will be used when you attempt to import this key on another computer.
4. You can now transfer this .p12 file between systems. Double-click on the .p12 to install on a system. You will be prompted for the password you first entered above.
Create and download your iOS Distribution Provisioning Profile for App Store Distribution (Need this step only Once)
To successfully build your application with Xcode for distribution via the App Store, you first need to create and download an App Store Distribution Provisioning Profile. These are different than the Development Provisioning Profiles that were used earlier in that Apple will only accept applications if they are built with an App Store Distribution Provisioning Profile.
Note: App Store provisioning profiles do not allow for a distribution built application to be installed on an Apple device. To install your distribution ready application on a device, you must create an Ad Hoc provisioning profile.
1. Team Agents should navigate to the Provisioning section of the Provisioning Portal and select the Distribution tab.
2. Select the App Store radio button.
3. Enter the name for your Distribution Provisioning Profile.
4. Confirm your iOS Distribution Certificate has been created and is displayed.
5. Select your wild-card App ID to build all of your applications with your single Distribution Provisioning Profile.
6. Click ‘Submit’.
7. Click on the name of the Distribution Provisioning Profile to download the .mobileprovision file.
8. Drag the .mobileprovision onto the Xcode or iTunes icon in the dock to install.
Creating and Downloading a Distribution Provisioning Profile for Ad Hoc Distribution
To successfully build your application in Xcode for Ad Hoc distribution, you will need to create and download an Ad Hoc Distribution Provisioning Profile.
1. Team Agents should navigate to the ‘Provisioning’ section of the Provisioning Portal.
2. Select the ‘Ad Hoc’ radio button.
3. Enter the name for your Ad Hoc Distribution Provisioning Profile.
4. Confirm your iOS Distribution Certificate has been created and is displayed.
5. Select the App ID for the application (or suite of applications) you wish to distribute.
6. Select up to 100 UDIDs which you wish to run your application on.
7. Click ‘Submit’.
8. Click on the name of the Distribution Provisioning Profile to download the .mobileprovision file.
9. Drag the .mobileprovision onto the Xcode or iTunes icon in the dock to install.
Building your Application with Xcode for Distribution
1. Launch Xcode and open your project.
2. If you have not already done so, drag the Distribution Provisioning Profile downloaded from the Provisioning Portal onto the Xcode or iTunes icon in the dock (or, drag into ‘~/Library/MobileDevice/Provisioning Profiles’ directory.)
3. Open the Xcode project and Duplicate the “Release” configuration in the Configurations pane of the project's Info panel. Rename this new configuration “Distribution”.
4. In the Target Info window, select the ‘Build’ tab and set the ‘Configuration’ to ‘Distribution’
5. In the Target Info window, navigate to the ‘Build’ pane. Click the ‘Any iOS Device’ pop-up menu below the ‘Code Signing Identity’ field and select the iOS Distribution Certificate/Provisioning Profile pair you wish to sign and install your code with. Your iOS Distribution certificate will be in bold with the Provisioning Profile associated with it in grey above. In the example below, ‘iOS Distribution : Example Corp, Inc.’ is the Distribution Certificate and ‘My App Store Distribution Provisioning Profile’ is the .mobileprovision file paired with it. Note: If the private key for your iOS Distribution certificate is missing, you will be unable to select the iOS Distribution Certificate/Provisioning Profile pair and you will see the following. Importing the private key for your iOS Distribution certificate will correct this.
6. In the Properties Pane of the Target Info window, enter the Bundle Identifier portion of your App ID. If you have used an explicit App ID you must enter the Bundle Identifier portion of the App ID in the Identifier field. For example enter com.domainname.applicationname if your App ID is A1B2C3D4E5.com.domainname.applicationname. If you have used a wildcard asterisk character in your App ID, replace the asterisk with whatever string you choose. Here are example App IDs and what should be input into the Identifier field in Xcode.
◦ Example App ID: A1B2C3D4E5.com.domainname.applicationname Identifier to enter in Xcode: com.domainname.applicationname
◦ Example App ID: A1B2C3D4E5.com.domainname.* Identifier to enter in Xcode: com.domainname.<name_of_application_or_suite>
◦ Example App ID: A1B2C3D4E5.* Identifier to enter in Xcode: <full_reverse_dns_company_and_application_or_suite_name>
7. In the project window, select the Distribution Active Configuration from the overview popup and set the Active SDK to the desired Device. For App Store Distribution, skip to Step 12. For Ad Hoc Distribution, complete the following:
8. In the File Menu, select New File -> iPhone OS -> Code Signing -> Entitlements.
9. Name the file “Entitlements.plist" and click ‘Finish’. This creates a copy of the default entitlements file within the project.
10. Select the new Entitlments.plist file and uncheck the “get-task-allow” property. Save the Entitlements.plist file.
11. Select the Target and open the Build settings inspector. In the ‘Code Signing Entitlements’ build setting, type in the filename of the new Entitlements.plist file including the extension. There is no need to specify a path unless you have put the Entitlements.plist file somewhere other than the top level of the project.
12. Click ‘Build’. (Note: Your binary must contain a flattened, square-image icon that is 57x57 pixels. This icon is displayed on the iPhone or iPod touch home screen.)
13. Highlight the app located within the "Products" sub-folder and select ‘Reveal in Finder’ from the Action popup.
14. Use the compress option in Finder to create a .zip file containing your application. Be sure to compress only the .app file only and not the entire build folder.
Verifying a Successful Distribution Build
To confirm your build was successful, check for the following:
1. Open the Build Log detail view and confirm the presence of the "embedded.mobileprovision” file. This will take you to the line in the build log that shows the provisioning profile was successfully called. Ensure that the embedded.mobileprovision is located in the proper “Distribution” build directory and is not located in a “Debug” or “Release” build directory. Also, confirm that the destination path (at the very end of the build message) is the app you are building.
2. Search for the term “CodeSign” in the Build Log detail view - this will take you to the line in the build log that confirms your application was signed by your iOS Certificate.
If your project is lacking any of the above files or pointing to the wrong directory, do the following:
1. Select the Target and open the Build Settings Inspector. Confirm you are in the Distribution Configuration.
2. Delete the Code Signing Identity: iOS Distribution : COMPANYNAME
3. In the Xcode Build Menu, select Clean all Targets.
4. Delete any existing build directories in your Xcode project using Finder.
5. Re-launch Xcode and open your Project.
6. Re-enter the code-signing identity iOS Distribution : COMPANYNAME in the Target Build Settings Inspector.
7. Rebuild your Project.
Updating your Application
The App Store uses three pieces of information in your application to identify a submission as an update to an existing application. *When you are submitting an update of your application to iTunes Connect for App Store distribution, make sure to:
Use the same Distribution Provisioning Profile to build each new version of your application
Increment the CFBundleVersion and CFBundleShortVersionString values in your project Info.plist file. Note: Version numbers must be period-delimited sequences of positive integers (1.0 to 1.1, or 2.2.1 to 2.2.2).
_________________________________________________________________________________________________________________________________________________________________________________________
List/Guideline for submitting iPhone Application to Apple Store
Try two: (good)
http://adeem.me/blog/2009/04/04/list-guideline-for-submitting-iphone-application-to-apple-store/
_____________________________________________________________________________________________________
If you have issues doing this, send me an email at info@adeem.me to do this for you but then you have to donate me something
It took me 3 days to submit my first application on Appstore, its not very complicated but you have to follow many steps to do it right. So today one of my friend Naeem requested me to write down the steps for him.
I assume that you have iPhone Developer License. Please follow the following steps, one by one:
• Step 1:(Need this step only Once) Certificate is very important part for submitting or testing your application on iPhone. It has the code-sign(Signatures) which will be checked when you submit your application on apple store or to test it on your iPhone. (You can bypass those to install application on your jail-break iPhone or to submit it to Cydia but you will not be able to submit it to appstore. Check my previous post to bypass code signature).There are two steps to create a certificate from developer portal. I simply copied those two from “iPhone developer portal”
1. Generating a Certificate Signing Request
2. Submitting a Certificate Signing Request for Approval
• Generating a Certificate Signing Request
1. In your Applications folder, open the Utilities folder and launch Keychain Access.
2. In the Preferences menu, set Online Certificate Status Protocol (OSCP) and Certificate Revocation List (CRL) to “Off”.
3. Choose Keychain Access -> Certificate Assistant -> Request a Certificate from a Certificate Authority.
4. In the User Email Address field, enter your email address. Please ensure that the email address entered matches the information that was submitted when you registered as an iPhone Developer.
5. In the Common Name field enter your name. Please ensure that the name entered matches the information that was submitted when you registered as an iPhone Developer.
6. No CA (Certificate Authority) Email Address is required. The ‘Required’ message will be removed after completing the following step.
7. Select the ‘Saved to Disk’ radio button and if prompted, select ‘Let me specify key pair information’ and click ‘Continue’.
8. If ‘Let me specify key pair’ was selected, specify a file name and click ‘Save’. In the following screen select ‘2048 bits’ for the Key Size and ‘RSA’ for the Algorithm. Click ‘Continue’.
9. The Certificate Assistant will create a CSR file on your desktop.
• Submitting a Certificate Signing Request for Approval
1. After creating a CSR, log in to the iPhone Developer Program Portal and navigate to ‘Certificates’ > ‘Development’ and click ‘Add Certificate’.
2. Click the ‘Choose file’ button, select your CSR and click ‘Submit’. If the Key Size was not set to 2048 bits during the CSR creation process, the Portal will reject the CSR.
3. Upon submission, Team Admins will be notified via email of the certificate request.
4. Once your CSR is approved or rejected by a Team Admin, you will be notified via email of the change in your certificate status.
• Download/Installing Certificate on your machine
1. Upon CSR approval, Team Members and Team Admins can download their certificates via the ‘Certificates’ section of the Program Portal. Click ‘Download’ next to the certificate name to download your iPhone Development Certificate to your local machine.WWDR Intermediate Certificate download this certificate and install it.
2. On your local machine, double-click the downloaded .cer file to launch Keychain Access and install your certificate.
• Certificate is installed on your MAC now the next step is create a App ID. (Note:You have to follow this step only once and later you don’t have to make certificates for your other applications.)
• Step 2: Creating an App Id is very easy, you have to follow few simple steps:
1. Log in to the iPhone Developer Program Portal and navigate to ‘App IDs’ and click ‘Add Id’.
2. In “App Id Name” enter the name of your application (i.e iphoneapp) and in “App Id” enter something like com.yourdomain.applicationame (i.e com.adeem.iphoneapp) and clicked on Submit
3. Please write done the “App Id” because you will used this in Info.plist, Bundle identifier tag
• Step 3: Now the next step is to create a Provisioning File for your Xcode and this will be your last step for creating binary which you submit it to appstore.
1. In to the iPhone Developer Program Portal and navigate to ‘Provisioning’ > ‘Distribution’ and click ‘Add Profile’.
2. Now select “App Store” in “Distribution Method”
3. In “Profile Name” type your application name (i.e iphoneapp) which will be your provisioning profile name as well.
4. In “App ID” select the app name (i.e iphoneapp) which you created in Step 2
5. Download the Provisioning profile and copy it to your /YourUserName/Library/MobileDevice/Provisioning Profile
• Step 4: Now everything is step up, open your project in Xcode
1. Select your project from “Group & File” in left side bar and click on “i” ( info ) button.
2. Move to “Configuration” tab and select “Release”. Press the “Duplicate” button from bottom, name is “iphoneDistribution”.
3. Click on “Build” tab and select “iphoneDistribution” and type in “Search in Build Settings” filed ‘Base SDK’ and select the current selected Device and change it to what device your application is targetting ( I prefer “Device – iPhone OS 2.0)
4. Now in “Search in build setting” field type “code signing identity” and select the provisioning profile you created in Step 3. Also do the same thing for the child property “Any iPhone OS Device”.
5. Now in “Search in build setting” field type "Tergeted device family" and select which application you are making iPhone / iPod or iPhone or iPad.
6. Now Close the Info screen and select the “Target” > “YourApp” from “Group & File” in left side bar and clicked on “Info” button again from Xcode.
7. Repeat the step 3,4 and 5 again for safe side.
8. Now Info screen is still open clicked on “Properties” tab and in Identifier field type the “App Id” (i.e com.adeem.iphoneapp)
9. Everything is set up, click on “Build”(cmd+B) from Xcode>Build
10. Now right click on “Product”>”YourApp” and select “Reveal in Finder”. This is your binary file so please zip this file.
• Step 5: Now you are done from Xcode and iPhone Developer Protal. Now you will submit this binary to itunesconnect.apple.com
1. In your browser type https://itunesconnect.apple.com/ (this website is very slow over https) and login using your iphone developer account.
2. Click on “Manage Your Account” > “Add Application”
3. Now answer simple question from apple and submit your application to appstore. Few thing you should have before you submit your application there in System/Mind:
▪ Application Name ( must be uniqe)
▪ Application description
▪ Application Category
▪ URL for your application feedback
▪ Icon of your application in 512×512 size
▪ Main picture of your application in 320×480 or 320×460 size. (Optionaly you can submit up to 4 more pictures of your application as well)
4. Now time to upload to binary on itunesStore. Open FINDER in your mac and open Macintosh HD->Developer->Application->Utilities->Application Loader .
▪ Through application loader you may upload to binary to iTuneStore.
5. Now check on itunesconnect.apple.com and check that upload received (yellow) and wait for review from apple.
That’s all you need to do (Please post anything in comments that I missed and I will update the post) Not very long but it might take 2-3 hours!
=========================================================================
App Store Approve Process 16 Status
https://developer.apple.com/appstore/resources/approval/
_____________________________________________________________________________________________________
1. Waiting for Upload (Yellow)
Appears when you've completed entering your metadata, however, you have not finished uploading your binary or have chosen to upload your binary at a later time. Your app must be in the Waiting For Upload state before you can deliver your binary through Application Loader.
2. Prepare for Upload (Yellow)
Appears when you have created a new version, but you have not yet clicked the Ready to Submit Binary button. This state also indicates that you can now deliver your binary through Application Loader.
3. Upload Received (Yellow)
Appears when your binary has been received through Application Loader, but is still being processed by the iTunes Connect system.
4. Pending Developer Release (Yellow)
Appears when the version of your app has been approved by Apple and you have turned on the Version Release Control, but have not yet clicked Send Version Live. You should also see a pending action symbol on the version. Your version will remain in this state, and thus will not be live on the App Store until you click Send Version Live.
5. Processing for App Store (Yellow)
Appears when the version is being processed to go live on the App Store. Once the processing is complete, the version state will change to "Ready for Sale." This is a temporary state (approx. 1 - 2 hours).
6. Waiting for Review (Yellow)
Appears after you submit a new application or update and prior to the application being reviewed by Apple. This status means that your app has been added to the app review queue, but has not yet started the review process.
7. Waiting For Export Compliance (Yellow)
Appears when your CCATS is in review with Export Compliance.
8. In Review (Yellow)
Appears when we are reviewing your app prior to the application being approved or rejected. It takes time to review binaries so we appreciate your patience and ask that you allow sufficient time for the processing of your application.
When the status of your application is in review, you have the option to reject the binary you have submitted by clicking Reject Binary. This will remove your binary from the review queue and will allow for another update to be submitted. If you reject your binary, the status of your app will change to Developer Rejected and when your binary is re-submitted, the review process will start over from the beginning.
9. Pending Contract (Yellow)
Appears when your application has been reviewed and is Ready for Sale but your contracts are not yet in effect. You may check the progress of your contracts in iTunes Connect by clicking on the Contracts, Tax & Banking information module.
10. Ready for Sale (Green)
Appears once your application been approved and posted to the App Store. When your application is in this status, you have the option to remove it from the store by going to the Rights and Pricing page and removing all App Store territories.
11. Missing Screenshot (Red)
Appears when your app is missing a required screenshot for iPhone and iPod touch or iPad for your default language app or for your added localizations. At least one screenshot is required for both iPhone and iPod touch and for iPad if you are submitting a universal app.
12. Invalid Binary (Red)
Appears when a binary is received through Application Loader, has been processed, but your binary is invalid. Examples of an invalid binary are: your binary icon does not meet our requirements, you have placed the payload directory at the wrong level in the .app wrapper, you attempted to use a non-increasing CFBundleVersion, etc.
13. Rejected (Red)
Appears when the binary has been rejected.
14. Removed from Sale (Red)
Appears when the binary has been removed from the App Store.
15. Developer Rejected (Red)
Appears when youʼve rejected the binary from the review process. Existing versions of your application on the App Store will not be affected by self-rejecting binaries in review.Important: When you self-reject your binary, you lose your place in the review queue. Your binary will be placed at the end of the queue when you resubmit.
16. Developer Removed from Sale (Red)
Appears when you’ve removed your application from the App Store.
=========================================================================
Distributing your applications Ad Hoc (Optional)
Ad Hoc certificate require if you want to run your application manual on the different system.
_____________________________________________________________________________________________________
Ad Hoc distribution allows you to share your application with up to 100 iPhone, iPad or iPod touch users, and to distribute your application through email or by posting it to a web site or server. To prepare your application, the following steps will need to be completed.
1. Create and Download an iOS Distribution Certificate
2. Create and Download an Ad Hoc Distribution Provisioning Profile
3. Build your application with Xcode
4. Share your application file and the Ad Hoc Distribution Provisioning Profile with the owner of each device
5. Recipients of the application will need to drag the application file and Ad Hoc Distribution Provisioning Profile into iTunes, then sync their iPhone, iPad or iPod touch to iTunes to install
=========================================================================
Reference
1. Key chain access
⁃ Finder -> Application(places {left menu bar}) -> Utilities -> key chain access
2. Application loader
⁃ Finder -> Macintosh HD (Device {left menu bar}) -> Developer -> Application -> Utilities -> Application Loader
3. Provisioning Profile
⁃ XCode ->Window -> Organizer (control + cmd + O {^+window+o}) ->Provisioning Profile
4. Useful links
⁃ https://developer.apple.com Developer Reference area
⁃ https://itunesconnect.apple.com Application Submit area
⁃ http://developer.apple.com/library/ios/navigation/index.html iOS library language and API reference
⁃ http://developer.apple.com/ios/manage/overview/index.action Provisioning Profile Menu
⁃ http://developer.apple.com/appstore/resources/approval/ Approval status detail
⁃ http://developer.apple.com/appstore/resources/approval/appreview.html App Standard and Review Resource
⁃ http://adeem.me/blog/2009/04/04/list-guideline-for-submitting-iphone-application-to-apple-store/ Submission Process
⁃ http://developer.apple.com/ios/manage/distribution/index.action Submission Process
5. Useful Books
⁃ Apress Publication Learn Objective C for Java Developers Best For java developer
⁃ O'really Publication Cocoa and Objective C
⁃ O'really Publication iPhone sdk (XCode to apps store)
⁃ Wrox Publication iPhone development with objective C
=========================================================================
awesome and very useful artical for app submission process
ReplyDelete