As you’re most probably aware, there’s an ongoing war between iOS and Android, and it will stay that way for years to come. While there are several aspects by which you can compare these two operating systems, RAM requirement is a very interesting one.
An iOS device is equipped with only about half of the RAM of an Android device with similar capabilities.
But what does iOS do differently to Android to only need much less RAM? The following three answers we have picked out from the internet should give you an in-depth understanding about this phenomenon. Beware, things can get a bit technical down there.
Android was built to run Java applications across any processor – X86, ARM, MIPS, due to decisions made on the early days of Android’s development. Android first did this via a virtual-machine (Dalvik), which is like a virtual computer layer between the actual hardware and the software (Java software in Android’s case).
Lots of memory was needed to manage this virtual machine and store both the Java byte-code and the processor machine-code as well as store the system needed for translating the Java byte-code into your device’s processor machine-code. These days Android uses a Runtime called ART for interpreting (and compiling!) apps – which still needs to sit in a chunk of memory, but doesn’t consume nearly as much RAM as the old Dalvik VM did.
Android was also designed to be a multi-tasking platform with background services, so in the early days extra memory was needed for this (but it’s less relevant now with iOS having background-tasks).
Android is also big on the garbage-collected memory model – where apps use all the RAM they want and the OS will later free unused memory at a convenient time (when the user isn’t looking at the screen is the best time to do this!).
iOS was designed to run Objective-C applications on known hardware, which is an ARM processor. Because Apple has full control of the hardware, they could make the decision to have native machine code (No virtual machine) run directly on the processor. Everything in iOS is lighter-weight in general due to this, so the memory requirements are much lower.
iOS originally didn’t have background-tasks as we know them today, so in the early days it could get away with far less RAM than what Android needed. RAM is expensive, so Android devices struggled with not-enough-memory for quite a few years in the early days, with iOS devices happily using 256MB and Android devices struggling with 512MB.
In iOS the memory is managed by the app, rather than a garbage collector. In the old days developers would have to use alloc and dealloc to manage their memory themselves – but now we have automatic reference counting, so there is a mini garbage collection system happening for iOS apps, but it’s on an app basis and it’s very lightweight and only uses memory for as long as it is actually needed (and with Swift this is even more optimised).
Android’s original virtual machine, Dalvik, was built in an era when the industry did not know what CPU architecture would dominate the mobile world (or if one even would). Thus it was designed for X86, ARM and MIPS with room to add future architectures as needed.
The iPhone revolution resulted in the industry moving almost entirely to use the ARM architecture, so Dalvik’s compatibility benefits were somewhat lost. More-so, Dalvik was quite battery intensive – once upon a time Android devices had awful battery life (less than a day) and iOS devices could last a couple of days.
Android now uses a new Runtime called Android RunTime (ART). This new runtime is optimised to take advantage of the target processors as much as possible (X86, ARM, MIPS) – and it is a little harder to add new architectures.
ART does a lot differently to Dalvik; it stores the translated Java byte-code as raw machine-code binary for your device. (This is Dalvik, not ART.) Art compiles the Java byte-code during the app install (how could I forget this? Google made such a huge deal about it too!) but these days it also uses a JIT interpreter similar to Dalvik to save from lengthy install/optimisation times.
In recent times, Android itself has become far more power aware, and because it runs managed code on its Runtime Android can make power-efficiency decisions across all apps that iOS cannot (as easily). This has resulted in the bizarre situation that most developers thought they’d never see where Android devices now tend to have longer battery life (a few days) than iOS devices – which now last less than a day.
The garbage collected memory of Android and its heavy multi-tasking still consumes a fair amount of memory, these days both iOS and Android are very well optimised for their general usage. The OS tend to use as much memory as it can to make the device run as smoothly as possible and as power-efficient as possible.
Remember task managers on Android? They pretty much aren’t needed any more as the OS does a fantastic job on its own. Task killing in general is probably worse for your phone now as it undoes a lot of the spin-up optimisation that is done on specific apps when they are sent to the background. iOS gained task killing for some unknown reason (probably iOS users demanding one be added because Android has one) – but both operating systems can do without this feature now. The feature is kept around because users would complain if these familiar features disappear. I expect in future OS versions the task-killers won’t actually do anything and will become a placebo – or it will only reset the app’s navigation stack, rather than kills the task entirely.
There are several reasons relating to the varying use cases as others have described, but the main reason is this: Android uses a form of automatic memory management that uses garbage collection, while iOS uses a more manual form of memory management. Garbage collection works better if there is always a good chunk of memory free, so the garbage collector doesn’t have to run so often.
The reason to use garbage collection is because it saves the programmer from manually having to managed memory. Memory management is tricky, and if you make a mistake, you might begin to leak memory (memory consumption goes up slowly) or create a security hole. Recent versions of iOS use something called automated reference counting, which means that the compiler (technically the pre-processor) will figure the correct memory management automatically. This means that the workload of managing memory moves from the phone to the computer of the developer that compiles the software.
The reason for this difference is historical. Android uses the Dalvik runtime, which borrows from Java, while iOS uses Objective-C and now Swift, which had a simple manual memory management system (manual reference counting). Apple used Objective-C because that is what they use in their own OS – Google used a Java analogue because it is a modern safe language that was widely by the time they launched Android, and so was easy for developers to learn.