Processing plain text doesn't take very much ram. On the other hand, mobile apps often deal with ram-consuming image data. For example, you'd want your web browser to be able to fit rendered pages in ram so you can switch tabs quickly, and you'd expect a maps application to keep satellite imagery in ram, to provide a smooth interface, free of hiccups due to swapping out to disk.

Of course - bearing in mind the server in question has GD performing tasks for about 70% of the page requests, and has a very heavily tracked mysql instance. I'm not claiming a general use-case. Additionally, given the speed of the flash disk on mobile devices, swapping to disk becomes less of an issue than on traditional, platter-based drive driven systems.

Besides, even if a single app never takes advantage of all available ram, extra ram will always help with caching disk and other apps. I'd bet that this would also improve battery life, since apps can be resumed from ram, as opposed to being re-read off of disk and doing any initialization over again.

On a system where power consumption is measured in such infinitesimally small amounts, the refresh power consumed by the additional RAM vs. the amount of power drawn by both the CPU and the solid-state disk for occasional disk swaps is a lot closer than the draw of a platter-based disk. I would hazard a guess that a company that openly prides itself on attention to detail (regardless of personal opinion on the product) has measured this and has opted for the best possible scenario based on several years of real-life statistics to draw on. Supposition is great, and I welcome vigorous debate, but I can only imagine that Apple have made a decision based on knowledge and not based on a cost analysis, as their products are rather pricey as it is.

I don't think "Preemptive multitasking" means what you think it means, and it's a completely orthogonal concept to any discussion of ram usage. Regardless, both BSD and Linux allow for preemptive multitasking (assuming you're talking about scheduling algorithms), and it's the same for any interactive OS. I am curious, however, as to what specifically differs between the BSD and Linux kernels that you believe would reduce ram usage.

Sorry - perhaps I was being ambiguous. Both operating systems allow for preemptive multitasking, but I made it quite clear that I was referring to heritage. Android's implementation of background processing when it comes to apps is distinctly different to Apple's approach. Where Android has a rather nice implementation of memory allocation for background apps, it is still essentially allowing a background app to manage itself, and thus it is forced to manage each process (including apps) at the same priority level (essential services aside, of course). On the other hand, Apple forces apps that wish to do background processing to use various SDK hooks to perform a limited set of possible background tasks, thus enabling an easier control of background tasks.

Specifically, I'm guessing that Android is based on a reasonably current Linux kernel, which would mean that its multitasking (and Linux's in general) is based on the Completely Fair Scheduler. On the other hand, the Mach kernel still implements a Multilevel Feedback Queue, albeit with some tweaks (such as a dedicated idle queue). I'm given to understand (and I claim no particular specialist understanding of scheduling) that in the limited frame of reference when discussing Android and iOS, that an MFQ manner of scheduling lends itself quite nicely to the iOS background apps implementation, and due to the tighter control less RAM is required, as the specific SDK hook an application is using will dictate when that app's active memory stack+heap needs to be rotated back into RAM.

If I may posit an example: let's say I write an application that is an alarm, and will sound a warning at 6am tomorrow. On iOS I hook into an SDK that tells the OS that I need to do something at 6am tomorrow. Until then, I am quite literally cycled out of memory, freeing the RAM up for other tasks. At 6am, I am rotated back into memory and I resume processing. On Android, on the other hand, I would run in the background, polling the time every few seconds or whenever to see if it was time yet for me to take the necessary action. The stub I maintain in memory may be small, but overall it adds up to a greater memory requirement for similar tasks. This is quite possibly an overly simplistic example, and no doubt I've made errors in what I've written, but I do stand by what I originally said; the way the OS handles things like task scheduling will most assuredly affect RAM utilisation and tasks queues in memory.

And just to clarify - this isn't an "iOS good, Android bad" debate - my example of choosing BSD over Linux is likely down to personal preference at this stage. That having been said: I do think that if iOS can run blazingly fast on a high resolution display with a gig of RAM, and Jelly Bean can't, then surely the fault has to lie in the underlying OS?