[ratfacemcgee]

its not Crystals fault, but its disappointing that this kind of ad blocking is unavailable for 32bit devices, like iPhone 5/5c (and below).

[Doctor_Fegg]

Indeed. I find it curious that it's not available for "performance reasons" - surely rendering an ad takes more CPU than blocking one?

[tdkl]

You can compile and sideload an open source content blocker on a 32bit device. But performance on some sites is slower then without blocking because of the regex performance difference, it's almost 50% slower. I'd quote the statement from a dev on reddit, but can't remember where it was.

[msephton]

what regex? content blocking compiles the source regex to byte code which is executed natively.

the 32-bit hang up is because of performance of compiling the rules, not executing them.

[giovannibajo1]

It should be true, but the reality is that most ad blockers have such a complex ruleset to match that they can actually go slower and use more RAM than not running them.

The graphs that uBlock shows are very compelling: https://github.com/chrisaljoudi/uBlock

I'm not saying that Apple tried hard enough; the content blockers on iOS are JIT-compiled to native ARM 64-bit code, so maybe they didn't have the codepath ready for 32-bit and/or they didn't bother. But it's surely not just a technical excuse.

[LoSboccacc]

Maybe it refers to the RAM constraints more. They just call out the devices, but the actual constraint might or might not be the CPU

on old devices new safari already struggle to keep in memory more than a couple tabs, so gut instinct points to memory being the issue.