5 ms·

iOS is much more aggressive about suspending and killing backgrounded apps than Android. Apps are expected to recover from this on their own in order to provide

iOS is much more aggressive about suspending and killing backgrounded apps than Android. Apps are expected to recover from this on their own in order to provide the illusion of seamless runtime, but the difficulty of doing so scales I think superlinearly with the complexity of a given app's state, and between that and most apps these days being more like rich web browsers in that they're obligate clients for a source-of-truth backend, most devs don't seem to bother.

rtpg 4y ago
The irony being that Android is the one whose SDK has a hell of a lot of support for this sort of suspension and recovery.
- makushenko 4y ago
  [flagged]
- fingerlocks 4y ago
  iOS has just as much support for this too. It’s built into the default constructor for all UI elements, but most devs just ignore it.
  - deleted 4y ago
    [deleted]
- olliej 4y ago
  The app switching model for iOS apps has been “expect to be killed at any time” from day 1. The APIs and such are built into almost everything and everywhere it is relevant, because that is the iOS model. Terminating an app that isn’t being used is always better for battery life and system performance. Doing that well has been why iDevices have always had less ram than equivalent generation android devices. The problem is the increasing number of giant custom “cross platform” apps, that require vastly more ram, and have never put any effort into actually being good software. Given all the BS reasons apps get rejected from the App Store the fact that not handling sudden termination isn’t something that gets apps rejected is obnoxious.
TrueGeek 4y ago
> most devs don’t seem to bother And by devs, let’s be clear it’s product owners. As a dev this isn’t hard to do. The problem is making sure it’s made a priority.
- aikinai 4y ago
  As a product manager who cares about experience and craftsmanship, I hear you.
WirelessGigabit 4y ago
Honestly, I don't care how aggressive iOS is with this. But why does Apple allow all these applications in the app store that aren't properly coded for when they get tombstoned (or whatever the term is). Even modern applications like Yelp 'suffer' from this. And I have the latest iPhone with the most RAM.

rtpg 4y ago

The irony being that Android is the one whose SDK has a hell of a lot of support for this sort of suspension and recovery.

makushenko 4y ago
[flagged]
fingerlocks 4y ago
iOS has just as much support for this too. It’s built into the default constructor for all UI elements, but most devs just ignore it.
- deleted 4y ago
  [deleted]
olliej 4y ago
The app switching model for iOS apps has been “expect to be killed at any time” from day 1. The APIs and such are built into almost everything and everywhere it is relevant, because that is the iOS model. Terminating an app that isn’t being used is always better for battery life and system performance. Doing that well has been why iDevices have always had less ram than equivalent generation android devices. The problem is the increasing number of giant custom “cross platform” apps, that require vastly more ram, and have never put any effort into actually being good software. Given all the BS reasons apps get rejected from the App Store the fact that not handling sudden termination isn’t something that gets apps rejected is obnoxious.

TrueGeek 4y ago

> most devs don’t seem to bother And by devs, let’s be clear it’s product owners. As a dev this isn’t hard to do. The problem is making sure it’s made a priority.

aikinai 4y ago
As a product manager who cares about experience and craftsmanship, I hear you.

WirelessGigabit 4y ago

Honestly, I don't care how aggressive iOS is with this. But why does Apple allow all these applications in the app store that aren't properly coded for when they get tombstoned (or whatever the term is). Even modern applications like Yelp 'suffer' from this. And I have the latest iPhone with the most RAM.