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.
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.