Would it be wise to switch over to deferred rendering in the future to perform lighting? Right now, I'm doing my lighting in shaders, and it's messy since I have to recompile different versions of my model rendering shader pair to take into account all of the different lighting combinations, etc... I can only have 1 of each type of light due to varying constraints, and that really seems to push iOS hardware doing that.

I've heard that deferred lighting is pretty expensive on mobile devices for now since the filtrate for mobile GPUs are far more limited compared to their desktop counterparts. Then there's this OES 3.0 spec that's just been ratified giving us a new take on functionality...

I've been weighing those disadvantages also, but it would mean I could have many lights on-scene, and it would get away from messy shader code. Maybe I'll develop a system for the desktop since MRTs actually exist on that medium, and a year from now when OpenGL ES 3.0 starts to make its way on newer devices, I'll make it OES-compatible. I could imaging that the way I would get past transparency issue is to loop through my rendering scene twice: once just to draw all meshes not completely opaque, and the second time for all opaque objects (or maybe it's the other way around?).

If I want to apply post-processing effects, I've already got the scene rendered to a texture.