Not everything; at least early on, iOS apps were great. But over time, on the one side the developers started adding more and more features, or switched to web tech or some hybrid technology, convinced that it would save them time and money (it didn't and the user experience is the worse for it). I also believe Apple itself added more and more cruft to the system.

One thing my colleague (who was a bit more hardcore than me) was convinced of is that hand-coding interface code was faster than using Interface Builder. I want to believe; I can imagine that the IB interface was just an XML file that had to be read, parsed and its layout built up, whereas handcoded layouts is very dumb code that would compile easily and execute quickly. But at the same time, I want to believe Interface Builder would be converted to obj-c code and compiled as normal.

Anyway Apple had years of head start in terms of performance and user experience (= perceived speed) to Android, their technology decisions was one of the reasons.

And yet, thinking about it, it wasn't even as fast as I could be; because of how objective-C works, function calls are somewhat dynamic so every function call, the runtime has to look up what to call the function on. Later on (with Swift) they managed to add an optimization that could omit this check if they detected the target could not change.

I'm rambling a bit and speaking from memory here btw, take this comment with a grain of salt. I'm no computer scientist, just a developer.

Objective-C message sends are ridiculously fast these days, like less than a handful of nanoseconds on average (1-2 on the fast path). There are ways of making it go even faster, but Apple has chosen to sully the language by taking away some of its dynamism instead :( It’s kind of sad to think about how much the original iPhone could do and how much code goes into the average app these days in comparison. You’d guess it was assets or something but no, if you look at major apps these days they have all sorts of framework dependencies with multi-megabyte binaries. It’s so sad to see…

(And Interface Builder files get compiled to a format that is then read out at runtime and deserializes the right things.)

There are a handful of natively written apps on iOS that have maintained the discipline to avoid bloat. One that I always admire is Overcast for podcasts. It's 5.9 MB and takes < 5 seconds to download and install.

It always makes me slightly resentful or sad about apps that are collections of web views but somehow 100+ MB.

> I have this 4y old Android smartphone which is slow for no good reason. I tried everything, removing/disabling apps, reset etc.

Does it use eMMC storage, or is it new enough to be NVMe? Any pre-2016-ish smartphone is built with basically the guts of an SD card (or MultiMediaCard rather) for internal storage and is a ticking time-bomb with a limited number of write cycles. They'll get slower and slower and then eventually stop working completely. My NoteⅡ and then later my NoteⅣ both succumbed to this. I never owned one but I remember the Nexus 7 being especially notorious for dying this way. You can replace those chips with the right equipment but I've never tried.

Why would eMMC NAND flash memory be less reliable than NVMe NAND flash?

The bus itself doesn't affect reliability obviously, but the storage chips they use on modern phones are much nicer and more expensive better parts :)

> The problem is that apps are just too big.

At least in part, I expect this is because of the AppCompat library that Google recommends using. If you pull in the whole thing, as tutorials show, it adds a huge number of images (icons and such) that don't get trimmed during compilation (which they're supposed to, if unused) - these make up something like 95% of the size of an app I'd recently been working on. I'd only noticed it because this was a rework of one I'd made ~10 years ago, before AppCompat existed.

I can't help but wonder if some of the "optimizations" done by Google when you turn over your keys and let them compile the apk is just removing this extra bloat.

A new out-of-box “Empty Activity” app project in Android Studio compiles to a 1.59 KB APK (if implemented in Java; it goes up to 2.26 MB APK with Kotlin). Rip out the dependencies on AndroidX, and the APK size plummets to 103 KB. (The APK for the de-Appcompat'd Kotlin version is, correspondingly, 709 KB.) 1.5 MB overhead – fifteenfold – for a more convenient layout[0] and the Material theme. Mind-numbingly wasteful. In a big enough app, that overhead will be overshadowed by the size of the meaningful bits, but how many apps really get that big? How many games include Appcompat and then draw their own UI anyway?

[0]: https://developer.android.com/training/constraint-layout

Is the battery easily replaced? I feel like at least some part of slow down I've encountered is deterioration of the battery, since the battery can't deliver the same power for peak moments like before the device feels slower.

As to whether installing an AOSP-derived Android distribution is easy to install or not mostly depends on whether the device is locked in some way or other. If it is you'll need to unlock it which - again depending on the device - can be as easy as flipping a switch or as hard as trying to get some code from a vendor which doesn't really want to give that code or which might not even exist any more. Installing a distribution is no harder than installing Debian, keeping it up to date is easy as it supports OTA updates. Once you're over the first hurdle - unlocking - it should be easy enough.

As an alternative you could root the device and disable (or remove) the bloat in the stock distribution, this often goes a long way towards getting a more usable device. This is what I did on those few devices which I've used on the stock distribution - remove as much bloat as possible, remove all social media cruft, etc. This can lead to surprising results like the battery lasting twice as long and with that giving new life to a tired old device.

How exactly do you install a custom android?

I use LineageOS, which has step-by-step instructions on how to prepare your phone/install the OS. A list of supported devices is at https://wiki.lineageos.org/devices/, with various guides on each device-specific page.

Try buying an iPhone.