Overview

If there’s one thing I’ve learned from delving into iOS, Android, and Blackberry app development, it’s that there’s a lot more to creating a mobile app than just coding it. One of the things that can catch you off guard, especially if you are devoid of design ability like me, is the amount of icons and images necessary to deploy your apps. This becomes even more daunting when you intend to deploy to multiple platforms.

The other concern is that it isn’t always evident from the development tools how many different graphics you need to account for all scenarios. A new iOS developer will likely be unaware that you need a 58×58 pixel icon for iPhone 4 Spotlight and Settings. To attempt to alleviate some of this confusion, I put together these charts to detail what I know so far about the graphics required for submitting mobile apps to the various Android, iOS, and Blackberry markets.

Icons

	Android	iOS	Blackberry Playbook	Notes
29×29				iPhone Settings and Spotlight, iPad Settings
36×36				low pixel density icon
48×48				medium pixel density icon
50×50				iPad Spotlight. iOS will trim 1 pixel off each side and add a drop shadow, making it 48×48
57×57				standard iPhone icon
58×58				iPhone 4 Settings and Spotlight
64×64				optional small custom document icon
72×72				Android high pixel density icon, iPad icon
86×86				standard Playbook icon. It will trim 5 pixels off each side, making it 76×76
96×96				Potential icon size if iPad gets a high ppi screen
114×114				standard iPhone 4 icon
144×144				Potential icon size if iPad gets a high ppi screen
320×320				optional large custom document icon

Distribution Images

	Android Market	Apple App Store	Blackberry App World	Amazon App Store	Notes
screenshot sizes	320×480, 480×800, 480×854, 1280×800	iPhone: 320×480, 480×320, 320×460, 480×300 iPhone 4: 640×960, 960×640 iPad: 768×1024, 1024×768, 748×1024, 1004×768	640×640 or smaller	480×854, 854×480	required # of screenshots: Android: at least 2 Apple: at least 1 Blackberry: 1-50 Amazon: 3-10
114×114					device icon
180×120					Promotional graphic (no alpha)
480×480					Product icon that should match your 86×86 icon
512×512					Large/High resolution product icon
1024×500					Feature graphic for market

Additional Notes

For Android, your 36×36, 48×48, and 72×72 pixel icons should be placed in the drawable-ldpi, drawable-mdpi, and drawable-hdpi folders of your Android project respectively. Be sure to specify the name of the file you will be using in the android:icon attribute of the element in your AndroidManifest.xml file. Android also allows you to include a promotional video.

For iOS you simply need to add your appropriately sized and named icons to your Resources directory in your XCode project. Here’s a mapping of the icon sizes to the required name of the icon file. NOTE: There is purposely no extension on the 512×512 iTunesArtwork file.

• 29×29 – Icon-Small.png
• 50×50 – Icon-Small-50.png
• 57×57 – Icon.png
• 58×58 –
• 72×72 – Icon-72.png
• 114×114 –
• 512×512 – iTunesArtwork

For Blackberry Playbook, you need to specify the name of your 86×86 application icon in your application’s blackberry-tablet.xml file. Below is a sample of how you would set that up.

>
    >
        >86x86.png>
    >
    >My Company>
    >core.games>
    >my_splashscreen.jpg>
>

For the Amazon App Store you can also submit promotional images of various sizes and up to 5 promotional videos.

Summary

So as you can see, you’ve got a lot to consider when it comes to presenting your mobile application to the masses. As a developer, I’m looking for the simple solution here. For me, the easiest thing to do was use this 512×512 iOS icon template, create my icon, and scale it down to all the required sizes. If you happen to be reading this post and know a better/easier workflow, please let me know.

Here’s a few references to check out to get some additional information on mobile app icons and market images:

• iOS Human Interface Guidelines – Custom Icon and Image Creation Guidelines
• App Icons on iPad and iPhone
• Android Icon Design Guidelines
• Blackberry Playbook – Designing Application Icons

DISCLAIMER: This article is about Adobe Air as an alternative to native API mobile development. Other mobile frameworks like Appcelerator Titanium and PhoneGap are not discussed.

The overview

So you want to make an iPhone app? Wait, you want to run it on Android too? And any tablet? And any desktop? And you want to be able to reuse the code base for all of them? OK, sounds good, now let me just get the magic elves and unicorns to take care of that for you. It will cost you one soul. Doesn’t have to be yours.

Or… you could use the Adobe Air SDK. Yeah, Adobe Air can do all that. Check out this video from Christian Cantrell’s blog where he shows how a single AS3 code base can be used to create an app for the iPad, iPhone, iPod Touch, Droid, multiple desktops, and the web. Pretty incredible stuff for indie developers:

For those wondering how you get past the Steve Jobs stranglehold on the Apple app store with an Adobe Air app, check out the Adobe Labs project “Packager for iPhone,” which also works for the iPad and iPod Touch. He also got it running on the Blackberry Playbook emulator. Its also worthy to note that Adobe Air and Flash are in the pipeline for Windows Phone 7, Blackberry phones, and many more mobile devices.

Now if I can do this with one language and one framework rather than 1/2 a dozen, why even bother learning the Java & Android SDK, Objective-C & iOS, or any other combination that may arise? At some point you have to have a better answer than “to learn it.” As with any consideration like this, there’s lots of pros and cons for each side of the argument. Here’s a few things to consider.

on the native side…

People want a uniform user experience

And by “people” I mean “non-technical users.” And by “uniform” I mean “native.” People want all their interface components to have the same look and feel. Its gives apps a more intuitive nature. While Adobe’s Flex Hero interface components are uniform to Adobe Air apps, they don’t represent the components found on each individual mobile device.

You can, however, use AS3 libraries like or android-components to preserve that native experience. As you might be able to guess by their names, they are collections of UI components for the iPhone and Android respectively that mimic those of the native system. While this solves the uniformity problem, it adds additional complexity to your multiscreen projects thereby undoing some of the efficiency added by the Adobe Air & AS3 workflow.

Or you could just forgo the whole uniformity thing and have a designer make all your components.

Native code will perform better

This is kind of a no-brainer. In my experience, and in talking with mobile users, responsiveness and performance is consistently better in native mobile applications. And not just that it is consistently better, but also that it is consistent across devices. I’ve heard many complaints about packaged Flash apps running crazy slow on Apple devices but fine elsewhere. This is especially true of resource intensive apps like games. Granted this isn’t shocking news, but it is a concern for those trying to preserve the user experience.

But this doesn’t necessarily apply to everyone. If you are building a simple data and UI component driven app, Adobe Air should be more than enough to handle that with smooth performance. And those resource intensive apps that may not run as well as native apps now are going to be catching up soon. Adobe is constantly increasing performance on mobile devices. Recently they have had a strong focus on GPU processing for graphics and will even be releasing a full, low level 3D API called “Molehill” mid 2011. As long as they keep this pace with performance enhancements, there’s no reason to believe that Flash and Air games won’t be as prevalent on mobile devices as they are on the web.

Steve Jobs can shut you down

Until just a few months ago, deploying AS3 written apps to Apple devices was impossible. This was because Apple had a restriction that no 3rd party development tools could be used to create Apple apps. You used the Apple sanctioned workflow or you were SOL.

Luckily Steve came to his senses and lifted the ban and Adobe re-released the iPhone packager. But it shines light on a dangerous precedent. There’s nothing to stop him from doing it again at some point in the future. Hell, MacBook Airs are not even preinstalled with Flash anymore. If Apple drops the hammer, BOOM, there goes a significant portion of your mobile audience.

Native functionality

Without native coding, you are at the mercy of what Adobe has currently implemented and abstracted. Things like Android Intents hit the cutting room floor for the sake of creating a single framework. While Adobe does a good job of either capturing all available functionality (like Geolocation, microphones, and cameras) or creating similar functionality, it will be by nature, a step behind the advances in mobile development. This could be offset if Adobe maintains a close relationship with the major mobile players.

on the adobe air side…

Spend more time creating, less time battling compatibility

This is why we’re here, isn’t it? With a single language, framework, and workflow you can create a code base that can be applied to any device that can support Adobe Air or Flash. That should be mighty intriguing to any indie developer. You can cut your development time down to a fraction of what it would be if you had to learn every mobile device’s framework. You are instantly building to multiple devices and broadening your target audience with almost no additional effort.

Flash, Air, and AS3 resources are abundant

The mobile APIs out there are well documented and have strong, growing communities. Adobe’s communities, though, are even more so. They have been around a much longer time than these relatively new APIs and are chock full of expert developers, designers, examples, and code. The sheer volume of resources available to AS3 and Flash based projects is incredible, just look at this list of available game engines for example. Need inspiration? Check out one of the many open Flash sites out there, like wonderfl.net.

Now lets move on to the tools invovled. Love them or hate them, Adobe knows how to make design and development software. Expensive, yes, but worth every penny. They have the design to development workflow that helps apps stand out down to a science. Let’s say you don’t believe me, or you don’t want to pay the money. That’s fine, because there’s plenty of free tools for creating Flash and Air content out there too. Check out FlashDevelop or FDT for great alternatives to the Adobe suite.

Reuse existing AS3 code

I know what you’re thinking: Can’t I also reuse existing Java in Android or Objective-C on the iPhone? Well yes, but not to the level that you can with AS3. Let’s say you have a game that logs top scores, uses a physics engine, and has some built in menus. Chances are that most of these things, with some serious effort, can be translated into the mobile API of your choice. But even if that is the case, you still need to integrate that all into the mobile API’s framework, which can be a daunting task.

With Flash or Air, though, you can literally compile or package the application AS IT IS to any mobile format that Adobe supports. Wanna make your old flash game a mobile app? Run it through the appropriate compiler or packager and you are good to go, no changes necessary. Now don’t get too excited. Chances are you will need to do some scaling and appearance tweaking in descriptor files to accommodate your target devices, but the transition is much simpler than with mobile APIs and native code.

Flex “Hero” and flash builder “Burrito” makes things a lot easier

Before the MobileApplication framework added to the Flex SDK, mobile development was very possible, but still felt like a flash app instead of a mobile app. With Flex “Hero” Adobe focused on creating a framework for multiscreen development, but also to be able to create apps that behaved like mobile apps.

What do I mean by “behaved like mobile apps?” Well, mobile apps typically operate as a stack of full screen views. Gestures or menu options are used to navigate between the views. Things like “Back”, “Menu”, and “Search” buttons need to be handled in a way the user expects. The app also needs to be able to close itself when no longer in use. These are just a few of the things that give that mobile feel that are not typical of flash apps. These are now present in Hero.

And how do we simply and quickly leverage this new functionality in the Flex SDK? With Flash Builder “Burrito” of course! Burrito is currently a preview release of Flash Builder that supports the creation, development, debugging, and deployment of Air for Android apps (And you can bet other devices are just around the corner). Complete with design view and dimension emulation for the various target Android devices it supports. I highly suggest trying it out since its now available free for a 60 day trial.

The Summary

Condensing the majority of your mobile development down to one framework can cause one indie developer to match the work of a team of native mobile developers. But there are drawbacks. The factors listed above point out the potential shortcomings of an abstracted Adobe Air solution. If you are not willing to deviate from native workflows or only need to develop for one platform, perhaps the Adobe Air path is not for you.

If you are a mobile developer, you owe it to yourself to spend some time with Adobe Air’s workflow for deploying mobile applications. If you are an INDIE mobile developer, especially with an AS3 background, you are shooting yourself in the foot productivity-wise if you are not pursuing this further. Here’s some links to help you on your way to multiscreen development bliss:

→ Flex SDK
→ Air SDK
→ Flex “Hero” SDK
→ Flash Builder “Burrito”
→ Packager for iPhone

If you do go down this path, let me know, I’d love to hear your experience. If not, why not?