I hate using such a search engine friendly title to a blog post, we normally bask in the willfully obscure, but as this may actually contain something of interest as opposed to the usual random words I figured it was worth at least trying to vaguely flag it up.
Let's start with a big caveat. I developed Zap using the beta version(s) of Flash CS5, and due to it's very nature it's not the final finished product. That means a couple of things, firstly that the launch version is going to be better than the one I used, the Flash team are really breaking their necks with the iPhone exporter and just doing great work. Secondly as it was beta software things are pretty fluid. I really honestly doubt that there are going to be any major changes so soon to release, but some of these tips may not be valid on release.
One last thing, being on the beta program means being under a NDA. In terms of this post it means I won't be going into technical things, performance or new API's etc. Think of this more as a primer which can hopefully give you a little head start than a sneak peek at what's under the hood.
Ok, the main thing is eeking out as much performance as you can.
* Vectors / Drawing API / Gradients. No, no and no. We're bitmaps all the way baby.
* BlendModes. Think more about burning the effect you want onto the bitmap itself.
* MovieClips. Save them for intros and title screens, avoid them in-game, as you just can't cache them efficiently so you're hitting the slower vector plotter.
* Text. It's slow enough when running in a swf. Time to code yourself a text plotter using bitmaps ( Like Movieclips, for in-game anyway. Top and Tails performance is never really a big issue )
* CacheAsBitmap. He's going to be your new best friend, love him and cherish him, as he'll give you much better performance ( There is a new cache command too, but NDA and all that ).
Some things to keep in mind, setting sprite.visible=false wipes the cache, so when you use sprite.visible=true again you're forcing a re-cache. Altering the alpha property also forces a re-cache ( As does scale etc. All the things I'm sure you're aware of any way ). One thing I didn't know before starting on Zap was that if you holder.removeChild(sprite) the cache is lost too, and that the cache only kicks in when the displayObject is first added to the stage.
In terms of how that hit my workflow, I had to change up and create all my sprites / bitmaps in each classes constructor and add them to the stage hidden off to the side.
When you first launch an app on the iPhone the "boot" picture appears straight away. Make sure that the very first thing you do is have a copy of that same image sitting topmost on your stage. Then you can call all your constructors and create all your display assets hidden under that cover, and when everything is in place you just transition that screen out. It hides any nasty stutters whilst the game makes everything it needs ( Using Zap as an example, the boot pic is our logo with "loading" text displayed on it, with the same image minus the loading text in the game itself, so the change from bootpic to game is pretty seamless ).
* Every pixel counts. Only plot what you need to, abuse the swf background colour as much as you can to save plotting.
* Pooling. Hopefully this is something you're used to doing anyway, but it's really vital when exporting to iPhone. During the constructor stage of my game I created all the pools too. Just using a simple Vector list, or linked lists. Pooling is such a simple thing to do and avoids any more object creation / deletion and stops the garbage collector being a big fat processor hog.
* Music. That loop that doesn't sound too bad on your PC at 32kps sounds really nasty on your iPod, funny what with it being a music player first and foremost. It's not a web game, push that bitrate up.
* scrollRect. I usually use that for animating bobs ( Blitter objects, ie sprites you plot with copyPixels or by adding the Bitmap directly to your stage ), using it to view a window on a sprite sheet to make it look like a sprite is animating, all nice simple stuff. I only had the briefest of tests with it on the iPhone, and I think it could be a texture memory hog, so the best way may be to just copyPixel each frame as you need it ( I've really not tested this to death so this could be complete arse, I was using a really big sprite sheet, so for now take this point with a pinch of salt ).
* Think blitter. Our good friend Rich showed me a blitter engine running on the iPod and it was really impressive. Blitting really is the way to go, just one canvas and plot all your pixels to it. I've just finished our own blitter engine for the up coming "Destroy More Cars" game which will be handy for future iPhone games. I'll post more details about that another time ( I'm tempted to open source it, but I really can't be doing with "This feature doesn't work" feedback. It doesn't ? Write your fucking own then ).
* Petty things. Mark your classes as final where you can, don't divide by two when you can multiply by 0.5, stop events from propagating. All tiny tiny things, but every little helps.
* Remember startDrag ? Sure you do, we all used it back in Flash 5. You're designing for the sexy iPhone now, it's not a mouse interface, let the player drag things around in a sexy way, they'll love you that little bit more for it. Apple have lots and lots of style guide docs, give them a read, it still applies to us even if we're Flash kids.
In terms of workflow, if you use Flex or FlashDevelop then you're not wanting to go back to the IDE in a hurry, it's too much of a shock to the system. I stuck with Flex ( By that I mean coding as3 in it, not mxml, there's still so much confusion about it even now ) and with including the AIR swc got auto-complete goodness on all the new commands. Lovely. Because Zap doesn't use anything really iPhone specific that needs to be on the device to test, I just added a simple test. If it's running via Flex check the keyboard and use that, if it's on the device don't run the keyboard code and revert to just mouse events.
I can't emphasis how much time this saved. You surely know the difference in compile time from Flex / FD compared to the IDE anyway, who wants to go running back to that ? It's not always going to be possible, but where you can make a version that can be tested off the device.
( In saying that, still test often on your device just to ensure that you're getting the performance you expect ).
How I set it up was having an empty fla with the iPhone publish settings in it, which just pulled in my classes. With CS4/5 supporting <embed> you don't have to change a line of your code, just use a different fla for laying out your assets for import. Using an empty fla just feels cleaner to me ( In actual fact I used two, one for testing and one for distribution, as you have to use different certs / profiles for each, more on that below ).
Moving on to Apple related things, brace yourself, this isn't the same as uploading a game to newgrounds. We've all read that getting a game published on the App Store is so easy and pain free, but that's mainly coming from people who are more used to the hell of developing for consoles, not Flash.
You're going to have to pay your $99 or whatever it is to register as a developer with Apple. My advice here is just register as a person rather than a company, it's a lot less hoops to jump through, plus when it comes to the App Store you can use a company name anyway which is searchable.
Next up is getting a cert and provisioning profile so you can test the game on your device. On the Mac that's fairly straight forward, on Windows it's a couple more things to do, our mate Iain touched on it in his blog post about his iPhone game. Come launch time I'm sure the web will be sinking under the weight of tutorials on how to do it.
One thing with the provisioning profile is that you can add devices to it. We couldn't really get access to any non-3GS / 3rd gen devices which restricted our testing, but you really want to be bugging everyone you know with an Apple machine for their device IDs so you can send out builds of your game for testing.
Come the glorious day that your app is ready to submit remember you'll need a distribution profile and cert. Also remember to re-read all the Apple guidelines, you don't want your game knocked back because of a silly mistake. You'll need to supple a link to a support site for the app, so prepare to remember your html skills that you've forgotten ( We just used the zap preview page, added a link to the contact form and job done. We've got a pimping and support page all in one ).
One last submission tip, when setting the release date, set it off in the ( Near ) future. If you leave it as todays date then when the game is passed at least 2/3 days after todays date it will be hidden in the latest releases ( Say you submit your app today, the 26th, and leave that as the release date. The game is accepted on the 28th. Your game will be classed as being launched on the 26th even though no one can actually buy it 'til the 28th, and even then it's got to filter around all the worldwide App Stores. This means all the games released after the 26th will be shown above yours in any latest games list ).
Once the app is approved, dive into itune connect and alter the launch date to tomorrow.
I think that's it. Hopefully I've not said anything I shouldn't have and got myself into trouble. If I have then I'll just lie and say my Mum is ill and start crying, no one will give me a bollocking then. When you do finally get your hands on the brand new Flash CS5 have a good google around for Apple developer forums. Every possible problem you'll ever have with submitting game has already been covered off by other people, the iPhone development community is huge and excellent, imagine our community without all the "I need teh codez lol!" and that's pretty much it.