>I'm sure with a bit of engineering effort, the memory footprint of iOS could be drastically reduced.
Drastically ?
The core of iOS is fundamentally the same as OSX and there are shared components. If Apple could figure out how to dramatically reduce memory usage they would have done it by now.
OSX heavily uses swap, even when a lot of memory is available (the dynamic pager). On iOS, the dynamic pager is disabled. This is particularly an issue with a language whose default memory allocation behaviour is as bad as Objective-C's - if an app gets backgrounded and frees all of the objects in a 4K page, save one (no matter how small), it will consume 4K until that changes or it gets killed. As it's not a managed language, the heap can't get compacted.
A second thing that's horrendously inefficient about iOS (as far as I can tell - they don't expose this stuff much) is that all of UIKit/Core Animation uses 32-bit/pixel textures. Things like text labels could easily use 8-bit textures with vertex colours for tinting. 8-bit PNGs or GIFs loaded as UIImages are decoded into 32-bit textures, too - okay, the hardware doesn't natively support palettes, so this would take a little bit of extra work to support. Finally, the hardware does support powerful compressed textures (PVRTC) which would suffice for many (most?) images used in apps.
Drastically ?
The core of iOS is fundamentally the same as OSX and there are shared components. If Apple could figure out how to dramatically reduce memory usage they would have done it by now.