3 ms·

No, it isn't. You are demanding of App Store reviewers, and thus implicitly of app developers who have to satisfy review to publish, an equal level of concern

No, it isn't. You are demanding of App Store reviewers, and thus implicitly of app developers who have to satisfy review to publish, an equal level of concern with, and effort to support, the experience of the half a percent or so of users still on 4.7"-class devices, as with that of the 99.5% or so on everything else. This would require significant extra work in just about every app, 2x as much in some, probably averaging around 1.5x as much in most. That is not a reasonable expectation. I've been in that half a percent myself, and I realize those with an attachment to remaining in that cohort will not find such an argument convincing. But I'm also, in retrospect, not really sorry that the last of the five 1st gen SEs I'd been carefully maintaining - four of which I'd bought used, three of which I'd replaced screens and batteries on - landed on its corner when I dropped it a year and a half ago, wrecking the sleep/wake button integral to the mainboard and well beyond any soldering skill I can acquire, and thus effectively requiring a complete replacement that I decided was finally no longer worth it. The 12 mini turned out not to be meaningfully larger or less wieldy than the 1st gen SE had been, and it's a lot more pleasant to use. There's value in not being actively, constantly frustrated by the experience of using my phone - especially since I do that every day for work now, too. We aren't going to agree on this, I think, and that's fine with me. But I am going to say that I no longer have the sympathy for your perspective that I would have a couple of years ago. It's a perspective I shared for a long time, and one I put more effort into than most. I'm glad I did, not least because learning to fix phones has been useful. But I'm also glad for what I've learned since then, even though it's why I don't share that perspective any more.

Dylan16807 4y ago
> This would require significant extra work in just about every app, 2x as much in some, probably averaging around 1.5x as much in most. That is not a reasonable expectation. This is not a reasonable estimate of the work needed. Also I was thinking more of "don't waste tons of memory, making it unable to run on devices with less", which could just be a mandatory rule for everyone's benefit.
- throwanem 4y ago
  > This is not a reasonable estimate of the work needed. One of the things that did the most to change my mind on this subject was actually estimating that work - specifically, estimating what it'd take in a live and fairly complex app, which is where most teams would have to start. (You haven't lived till you've tried to prototype a complicated custom time series chart control with several interactions, that can transparently render itself across a wide range of sizes and be legible and usable in all of them. You really haven't lived till you've tried to test it!) Another was seeing for myself in Amplitude both the absolute fraction and the trend for how few users would even be in a position to notice the result. > Also I was thinking more of "don't waste tons of memory, making it unable to run on devices with less", which could just be a mandatory rule for everyone's benefit. I agree this is worth more than it's valued. Would such a singleminded focus be to everyone's benefit, though? Most apps might not spend much effort on clean UI restore after suspend, but actual data loss is very rare in my experience, and teams have only the capacity that they do. That makes it a tradeoff between features and other bugfixes, and this; the next request I see in Canny for showing the launch screen less often on app switch will be the first, an absence which likewise leads me to suspect that the wants of users in general aren't accurately captured in the perspective of those who are heavily invested on this point.
- theshrike79 4y ago
  But where does the line between "wasting memory and resources" and "wanting to make a game that utilises the full power of a modern phone" go? It's REALLY hard to make a game that works equally well on the latest and greatest and also that one weird Android phone someone in the Philippines bought in an outdoor market.
  - Dylan16807 4y ago
    If you're truly using that power, and can't just turn down the graphics, that's fine. The complaint is when boring apps like the train ticket handler start running out of memory at random. A huge majority of non-game apps could fit into a small amount of resources if the devs tried.
robocat 4y ago
On Android, slow old devices are used by poor people, so it is particularly harsh to not support them if your app is critical for them. I class it as an accessibility issue. Because our App was maintained over many many years, we just needed to be careful to continue to support phones we historically supported, and avoid using new features that would break obsolete devices. That said, we did make decisions at times to drop the few users on older phones, for a variety of different reasons. We knew how many obsolete phones were used. We knew how many in each of our client companies, so sometimes we held back server updates for specific companies that used old browsers (although we were SaaS, companies were upgraded to new versions independently). To cover our arses, we informed users for a few years that their device was obsolete, and that the App would stop working at some point in the future.

Dylan16807 4y ago

> This would require significant extra work in just about every app, 2x as much in some, probably averaging around 1.5x as much in most. That is not a reasonable expectation. This is not a reasonable estimate of the work needed. Also I was thinking more of "don't waste tons of memory, making it unable to run on devices with less", which could just be a mandatory rule for everyone's benefit.

throwanem 4y ago
> This is not a reasonable estimate of the work needed. One of the things that did the most to change my mind on this subject was actually estimating that work - specifically, estimating what it'd take in a live and fairly complex app, which is where most teams would have to start. (You haven't lived till you've tried to prototype a complicated custom time series chart control with several interactions, that can transparently render itself across a wide range of sizes and be legible and usable in all of them. You really haven't lived till you've tried to test it!) Another was seeing for myself in Amplitude both the absolute fraction and the trend for how few users would even be in a position to notice the result. > Also I was thinking more of "don't waste tons of memory, making it unable to run on devices with less", which could just be a mandatory rule for everyone's benefit. I agree this is worth more than it's valued. Would such a singleminded focus be to everyone's benefit, though? Most apps might not spend much effort on clean UI restore after suspend, but actual data loss is very rare in my experience, and teams have only the capacity that they do. That makes it a tradeoff between features and other bugfixes, and this; the next request I see in Canny for showing the launch screen less often on app switch will be the first, an absence which likewise leads me to suspect that the wants of users in general aren't accurately captured in the perspective of those who are heavily invested on this point.
theshrike79 4y ago
But where does the line between "wasting memory and resources" and "wanting to make a game that utilises the full power of a modern phone" go? It's REALLY hard to make a game that works equally well on the latest and greatest and also that one weird Android phone someone in the Philippines bought in an outdoor market.
- Dylan16807 4y ago
  If you're truly using that power, and can't just turn down the graphics, that's fine. The complaint is when boring apps like the train ticket handler start running out of memory at random. A huge majority of non-game apps could fit into a small amount of resources if the devs tried.

robocat 4y ago

On Android, slow old devices are used by poor people, so it is particularly harsh to not support them if your app is critical for them. I class it as an accessibility issue. Because our App was maintained over many many years, we just needed to be careful to continue to support phones we historically supported, and avoid using new features that would break obsolete devices. That said, we did make decisions at times to drop the few users on older phones, for a variety of different reasons. We knew how many obsolete phones were used. We knew how many in each of our client companies, so sometimes we held back server updates for specific companies that used old browsers (although we were SaaS, companies were upgraded to new versions independently). To cover our arses, we informed users for a few years that their device was obsolete, and that the App would stop working at some point in the future.