iPad 2 and above have pretty strong GPUs. You can google for the varios triangle throughputs. We have animated models of around 1500 triangles. Not sure number of vertices and we handle 5 skinned meshes, I think around eighteen bones + around 15K geometry fine and could probably do more. The 3G S can just about manage the above as well and here I am talking about achieving 30 fps. We do take advantage of occlusion culling and have our own complex LOD system to ensure that we don’t animate more than 5 skinned meshes at a time, swapping a skinned renderer for a simple idle pose model for all but the nearest 5 models in view.
Mobile GPUs are getting better, but alpha, multiple lights (we use one + lightmapped environments) and complex shaders, will kill GPU performance as the devices becomes fill rate limited for a given set of shaders or resolution.
Using any kind of per pixel lighting on underpowered GPUs, such as those in last generation iPod Touch, iPad 1 and iPhone 4 - those with higher density displays but older processors - can quickly fill limit the device.
We use per pixel lighting but will run at half the resolution (quarter the pixels) on these graphically underpowered processors. Note that we do use per-pixel lighting.
If you can use lightmaps and have no real-time lights or can fake them, then the shaders are much cheaper.
We have quite a high number of bones, the number of bones and the number of bones that can affect a vertex will have a compounded effect on framerate as you push the number of skinned animations - you might get away with a single skinned animation with 10K polys and 5000 vertices, but you won’t be able to have many of those - possibly iPad 4 will manage a few more than an iPad 2.
Texture atlases are a big help as are shared materials. We have typically two for an entire environment at the very base and this is a good thing as with enemies, spell effects and the link we probably have dozens of materials and maybe a dozen textures in play at any one time (but our app is graphically quite intense).
I’ve never used the terrain system on mobile, but I know it works and is viable but cannot help there. Multi-texturing is entirely possible but texture look ups on mobile can be expensive, so it will depend on the number of different textures in play and how detailed the terrain is and the draw distance.
On mobile devices your heap will be small, so you need to avoid instantiate only because this can cause a stutter in the frame rate: instantiate as much as you can when your level loads; use prefab pools so you can recycle objects - typically we do this for spell FX and temporary geometry. Avoid new like the plague - new will allocate objects on the heap, and the more you new during your frame and the more often, the more the garbage collector will kick in. Similarly if you’re instantiating and destroying objects I believe.
With audio you should avoid compressed audio types. We use uncompressed wav with same characteristics (mono, 8 bit, 22050hz), to avoid having to mix samples of different types and mono as the sounds are typically 3D sounds and so the stereo effect will be determined by the audio engine to give the notion of the sound’s position.
You’re already instantiating your enemies which is fine. Yes it will increase the size of the scene but I don’t know by how much. There’s no problem having some lightweight marker for an object and replacing it with an enemy when the scene loads using instantiate as you’re doing this when the scene loads rather than every frame - instantiate is fine onlevelwasloaded.
Sorry but I have not tried Android devices as yet, so I cannot speak for these but there are similarly powerful GPUs in android devices, some more, some less powerful. We’ll get to android devices just as soon as we have released for iOS, or earlier if a quick port to OUYA looks promising