Apple absolutely will not tell you how much RAM is in an iPhone. They will hide how many milliamp hours the battery is. They won't even reveal the clock speed of their custom chipsets — it's not listed on the spec sheet. You can't even turn your own damn AirPods on or off your own damn self.
But why, though?
Toxic spec syndrome
Spec sheets are… borderline toxic in tech these days. They're quantitative, not qualitative, and often presented without a lick of context or qualification as to what they mean or how they affect the user experience.
And, because some people, in some markets, insist on buying almost entirely based on the specs on the box. Some companies just go to ridiculous levels goosing those specs. It's why we see quad camera systems where, like, three and a half of the cameras are junky 2-megapixel macros. Just so they can have that number on the box.
Apple has always insisted on… spec fighting different. And I'm not here to make excuses for it, to justify it. Just to explain it. You can agree with it or disagree, and on a case by case basis. You can love it or hate it. But If you hate it, I just want you to hate smart.
No RAM for you
So, let's start with the memory, the RAM. iPhones just don't need as much RAM as Android phones. That's the simple truth.
First, Apple makes iOS and iPhones, the whole widget, the whole stake, from silicon to icons, from atoms to pixels. So, they can optimize iOS specifically for the iPhone. Google makes Android, but a wide variety of different companies slap it on a wider variety of even more different Android phones. That means you get just a ton of options to choose from, but it also means you get a lot less optimization for each and every one of those options.
Second, for similar reasons, iOS is a native platform, and iOS Apps are native apps written in native languages, Objective C and Swift. Android is an interpreted platform, and Android apps run through virtual machines. Originally, Dalvik, now the Android Runtime, and are written in interpreted languages, Java or Kotlin. Again, more flexibility, less optimization. And that goes deeper as well, down to how iOS uses automatic reference counting and Android uses Garbage Collection, and there are pros and cons to both approaches, but Apple's is just lighter on RAM.
Third, multitasking and memory management are surfaced differently. Both iOS and Android are full-on multitasking monsters. Steve Jobs demoed seamless native app task switching on the original iPhone. Apple has just never extended full multitasking access to third-party apps. They treat iOS like a console. And Google treats Android pretty much like a full-on traditional computer environment. So, you can run out of RAM on Android, but iOS… iOS will jettison your app with savage fury any time and every time it needs to. The bigger the app, like a game or social networking, and the more important the new task, like launching the camera, the faster and harder they get the memory door slammed on them.
And I know I got some of those technical details wrong, so just yell at me in the comments, like, tabs vs. spaces loud. Nerds.
But, basically, it's like a tractor-trailer typically has and needs more wheels than a sports car. There's no correct amount of wheels for a vehicle, just a sufficient amount for that vehicle to get the job done, hopefully efficiently.
But rather than just explain all that, and more importantly, risk people making bad decisions based on the number on a spec sheet, Apple prefers to just not put the number on the spec sheet to begin with.
Same with battery. All of those factors I just talked about, along with the custom systems-on-a-chip, or SoCs, Apple has been making for the iPhone since 2010, mean that the iPhone puts much less demand on a battery than a typical Android phone.
And, sure, they all do things now like try to split loads between lower and higher power cores, use machine learning to enhance power management, and otherwise do everything they can to get as much life out of whatever amount of battery is available.
But pumping in more battery into a phone isn't like pumping more jelly into a donut. Everything is a trade-off. Everything is a compromise. And batteries are hot, heavy, and not radio transparent.
So, Apple tries to lock into the life they want to deliver and then figure out how small of a battery they can get away with to deliver it.
And that means, instead of talking about battery capacity, or milliamp hours, where they look small, Apple only talks about battery efficiency, or usage hours, where it tends to scale well by device size.
Same with clock speed on those SoCs. Apple routinely fields, core for core, some of the fastest processors on the planet. Fastest in mobile and, straight out the M1 gate, in the running for desktop already as well.
But they never, not ever talk about clock speed. Because, for them, it's just an implementation detail. The highest frequency they can run at given the thermal envelop of the device they're inside. And when that changes from an iPad to a Mac, they let the frequency go up, and when heat has saturated the whole stack, they turn frequency down.
But unlike other companies, Apple won't just pump voltage in to goose frequencies and force performance at the expense of heat and power consumption. If given a choice, if they could increase efficiency and battery life a lot by giving up absolute performance numbers a little, that's a trade-off the silicon team will absolutely make... 12 times out of 10.
And that means other companies can and will post higher core counts, higher frequencies, higher all the things but performance efficiency. So, while Apple is absolutely not above bragging about being so damn fast, they don't want to get into the weeds of… speeds and feeds.
They don't want to get stuck arguing over the nebulous benefits of non-meaningful numbers. They'd rather have inarguable experience benefits.
It all boils down to the same reason AirPods, even the AirPods Pro and brand-new AirPods Max, don't have power switches.
Designing for humans
Apple designs products, so the 80-90% of normal human beings don't have to stress over things like micro-managing battery-life or even remembering to switch headphones on or off.
Which is, of course, absolute anathema to the 10-20% of us tech nerds, who rapidly race to ruin it for ourselves by stressing over the lack of micro-management and on/off switches.
But regular people just shouldn't have to worry about keeping devices charged between 20 and 80%. So Apple just builds better and better charging controllers to do that for them. They shouldn't even have to worry that the battery will run down if they forget to turn a device off. So Apple uses sensors like accelerometers to put devices to sleep when they're not moving. That way, there's no switch, so you can't forget. It's just handled.
Now, that's not to say Apple's philosophy is right or good for everyone, far from it. Or that the way Apple chooses to implement that philosophy is always even right for anyone. Because they have more than their fair share of bugs and butterfly screw-ups all the time as well. That's why it's so important that we have so many different options to choose from.
Apple's singular goal has always been to make technology simpler and more accessible for the mainstream, to abstract away the complexities, and to try to make things… just work.
The only reason it's a problem is that design and performance are often so good, we nerds want it too. But then immediately want to take it about and see how it all… just works. Most especially when it stops working… or is just not.
Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.
All of these specs are easily found. All iPhone 12 models have a 6 core A14, running at 3 GHz. The Mini and 12 have 4GB of RAM. The Pro and Pro Max have 6GB. They all have mediocre cameras. Apple does not talk specs because iPhone specs are pretty lame compared to flagship Android phones. True, Android does indeed NEED more hardware for equivalent performance. But some/many/most (take your pick) people won't believe that, and just buy the better specs. I used to have Android phones, during the Android 6, 7 and 8 timeframe. Android's memory management was (at that time at least) terrible. In fact, it did not exist. You had to run a utility app to manually kill apps that you closed 3 days ago, to free up resources. Every few months, the phone would overheat in my pocket, and the battery would be down to 20%. All due to some app that was running wild in the background. This happened on 2 different phones over 3 OS versions. This was reason #1 why I switched to Apple. Presumably, things have improved in Android land by now. But I have no desire to find out.
Agree on the camera part. The only place Apple wins is with video recording. Their cameras are middle of the pack anymore with Android having surpassed them years ago and Apple seemingly not caring to try and level the playing field in that regard.
So, emphatically *not* yelling at you Rene. My biases are all with the way Apple does things; native code, ARC, etc. It might be a very slightly bit reductive to call Java and Kotlin 'interpreted' languages, although it's kind of true, although kind of not true, in a legalistic, letter-of-the-law kind of way. I believe they're both JIT'ed languages (Just-In-Time compiled), or some variant thereof. Meaning, probably the system compiles the interpreted P-code just before executing it, rather than executing each line of script one line at a time, like a 'true' interpreter. And then the native compiled image gets some sort of least-recently-used cache treatment, so subsequent invocations are much faster. To be honest, some engineer will holler my explanation, no doubt, because I'm quite sure what *exactly* happens is not quite that - Android engineers probably know, and I'm sure it varies from year to year as Google figures out what makes for the best performance tradeoffs. Bottom line, not a fan of garbage-collected languages, prefer reference counting. I'm willing to go with ARC over handling it myself, albeit reluctantly, because I'm convinced ARC does a better job than I would. As an old C/C++ programmer, back in the 90s when we rejected 'smart pointers' with automatic new/delete behaviors, for a variety of good reasons, all this automagic memory management has been a solution for a problem I was never having, not with good rigorous development practices, and good SDET (engineers who write code solely to test my code) helping to ensure no memory leaks, but still.... ....the hard-won lessons of yesteryear get forgotten and lost, with new generations of developers, and the same mistakes get made again. TBH, with modern exception handling architectures in C++, there's no point in resisting smart pointers any more. They pretty much do perform as advertised. Using Exceptions for error handling, rather than just for exceptional cases? That's another question. Sorry, digression (whew). Bottom line, I think you're dead-on correct, in in spirit, if not in the dead-nuts nitty-gritty technical details. Apple's memory management system (ARC, with native code) probably does perform better for most cases than Android's very sophisticated garbage-collected JIT'ed scheme. It probably (not without exception) does require a little more thought on the part of the app developer to do it correctly, although I think it's quite possible to leak memory in Android apps, too (not as savvy about how that happens, but I see diagnostics complaining about it in our Android app at work).
So is it your position to keep buyers in the dark for Apple's benefit? If so, how shilling of you.
Get the best of iMore in in your inbox, every day!
Thank you for signing up to iMore. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.