12 May 2011
ページ ツール |
Familiarity with ActionScript 3 and its object-oriented features as well as familiarity with Flash application development.
中級
Getting your application accepted into the Apple App Store can be a confusing and difficult process to navigate. Developers often run in to common pitfalls that add time to their submission cycle. Use this guide to understand the steps you can take to make your submission as pain-free as possible.
Using Adobe AIR for iOS support in Flash Professional CS5.5 to get your content to the Apple App Store involves three main steps:
Before you start to package your AIR app for submission, make sure you take care of some key considerations to ensure your users have the best experience possible. These fall generally into two categories: performance and usability. To make sure you have built a high-performing app, test your application on a variety of devices.
Typically, the iPod touch is faster than an iPhone in the same class of hardware. For example, the iPod touch 32GB and iPod touch 64GB are faster than the iPhone 3GS, even though they're in the same class of hardware. The original iPhone is quite a bit slower and more limited, both in terms of CPU performance and available memory. Getting high performance out of the original iPhone requires tuning and optimization. The iPhone 4 and the iPad both share a common processor, which are the fastest among all the iOS devices. (For more information, see Scott Petersen's article, Optimizing content for Apple iOS devices.)
The second key consideration to ensure you have a great app is usability. There are many similarities as well as differences between building an AIR app in Flash Professional CS5.5 for an iOS device and building an AIR app for the desktop, or even a SWF for the web. Even more so than on the web, users spend only a few minutes in your app and are quick to leave it for something else. Your app should expect to be shut down by the iOS at any time and for any reason. This is exacerbated on iOS devices because of incoming calls or SMSs and can happen for a variety of reasons, including low memory conditions. So be sure to save your state often. If you're building a puzzle game, make sure you save the user's state so the user doesn't have to replay the puzzle halfway through. If you're building a RPG, save the last trading state of the app. For examples of iOS apps that do this, check out Chroma Circuit or Trading Stuff.
Another thing to consider when building your AIR apps for iOS—that is different from web apps—is how to use the finger as a pointing device. The finger is quite a bit different than a mouse. No matter how hard you try, your finger is an inaccurate device compared to a mouse. Even when it seems like it's tapping in the same place, the finger often moves around slightly. Try to ensure that your app takes that fact in to account, and make your hit targets much larger than you would in a web app.
Once you've built a well-performing app that provides your user with a great experience, you're ready to submit it to the Apple App Store.
Thus far, you have been testing and deploying to devices using a development certificate and a development provisioning profile. These two are used for your development environment. For deploying apps to the App Store, you need a distribution certificate and a distribution provisioning profile.
To acquire the distribution certificate:
Note: Often the iOS Dev Center will display an "in process" message (or something like that). If that's the case, wait a minute and refresh the page.
Once you have the distribution certificate, you will need to create a distribution provisioning profile:
Once you have your new distribution certificate and your distribution provisioning profile, you will need to rebuild your application:
Skipping any of these steps when you build an app for deployment often causes an app to get rejected automatically from iTunes Connect, so make sure all the right certificates and provisioning files are properly included.
Apple requires the icon for your app to come in at least two sizes, preferably three. The two main sizes are 57 × 57 pixels and 512 × 512 pixels. The former is used as the icon on the iPhone home screen and must be a PNG file. The latter is used during your submission to the store and must be a JPEG file. The 512 × 512 icon is used as the artwork for your application in iTunes. The imagery of these two icons must be exactly the same. In some rare instances, the 512 × 512 icon can contain more detail than the 57 × 57 icon, but only if it makes the 57 × 57 icon seem like a cropped version of the larger icon. Generally, this is not recommended, and it should be kept identical. One additional size of icon, 29 × 29 pixels, is used for Spotlight search results on the device, and is optional.
As you design your icons, you should make them appear as flat square icons without the iOS half-circle gleam (or glossy, round beveling) effect, as this is automatically added by the iOS. If you desire to have a flat icon without the gleam, you can add a flag to a custom application.xml file that informs the iOS to not draw the gleam. For more information, consult the Application Icons and Application Launch Images sections of the iOS Application Programming Guide in the iOS Reference Library.
Lastly, be sure to name the image that gets launched with your application as Default.png. The most effective way to take advantage of this iOS feature is to use it as a way to make a perceived performance boost to your app. Use the launch image to make your app appear to load faster. In most cases, it should be the same as the first screen of your application or a splash screen. Simply taking a screenshot of your app at startup often will be sufficient as your launch image. Another way is to export the background of your app from Flash Professional and save that as Default.png.
Once you've prepared your iPhone Application (.ipa) file, you'll need to fill out the required forms on the iTunes Connect site to submit the application to Apple. Two pages that cause the most problems are the Overview and Upload pages. In the Overview, be as transparent as possible to Apple, including any demo accounts that might be needed. The Apple reviewers need to be able to verify your application, so giving the information they need ahead of time will help your application get through the review process. Also note that on the overview page, Apple's policy stipulates that your app's keywords cannot contain your app's name.
The Upload page is where you upload your actual application. Rename your .IPA file to .ZIP and upload it to the Application section; upload the 512 × 512 image to the large icon section.
The last two sections are screenshots of your application. These screenshots are used in the App Store, both from within iTunes and on the device. The quickest way to generate the screenshots is within the device by pressing the Home button and the lock button at the same time, then pulling the image off of the device.
I hope that the tips and summary provided here help you build an application that goes through the approval process without a hitch. The best practices included here guide you through how to use Flash Professional CS5.5 and AIR for iOS to build an app that can be submitted to the App Store with a painless approval process.
Check out this series of articles to help you learn more about developing for iOS using Flash Professional:

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License