I believe their claim is that it's for performance reasons. Drawing the line at everything without a 64 bit processor seems reasonable (from a "where do we draw the line" not a where dhould we draw the line)
Yeah, I love how they make it sound like old iphones
"weren't powerful enough to handle blocking ads!" when blocking ads actually significantly cuts down on the resource usage. What's frustrating is that on their new phones you can block ads in Safari proper, but apparently not from within an app like Flipboard. I guess they're saving that particular "feature".
Correct me if I'm wrong. I watched the Safari Content Blocker video that is presented in WWDC 2015 and it mentioned that the list of content to be filtered is compiled to bit code instead of reading it as a JSON file, which makes it more efficient and less draining on CPU. Since it is compiled down to bit code, 32-bit will not be compatible to 64-bit and that's why only the newer iPhones and iPads are compatible. It is not that iPhone 5 is not powerful enough but simply the CPU architecture doesn't support.
That's the most artificially overengineered solution I've seen in a while. Since the adblock list is custom, it would have to be "compiled" on the phone anyway, so arch mismatch simply doesn't apply. Even if it did, it could be done at phone startup. It's "compiling" a list of strings, not building an office suite...
There are so many high-performance/low-power ways to solve the extremely complicated problem of "does a given string appear in a given list?"... this is just Apple looking for excuses to force people on 5 to upgrade, as usual.
How would a framework that is explictly part of and designed for Safari possibly work in a third-party app with sandboxing? Seems pretty silly to accuse Apple of nefariously "saving" this.
Similarly, Apple never "made it sound" like old iPhones "weren't powerful enough". You really shouldn't put things in quotation marks and attribute them to others when you just made them up.
They could have it edit the hosts file or some better global interface for blocking/not blocking certain hosts from any app (which would be most users' preference when using ad blockers?)
I think it's ok to use scare quotes to convey sarcasm instead of a direct quote. There's admittedly some ambiguity there.
32bit vs 64bit is a super lame limitation to claim, and to most people "number of bits" would appear performance related. It's nice they finally enabled a way to block ads, but it's hardly a feature they deserve a pat on the back for. It's more like, I was seriously considering switching to Android if they didn't add it.
Right. No one is going to do that, because they make money off of ads.
This is why every other implementation of ad-blocking does not require the website owner to make changes (because they wouldn't, that's why there are resource hogging ads everywhere, because they put them there).
It's not their choice, that's the point. They can deny access to the site or app if they detect ad blockers enabled, I'm fine with that. I just think they'll lose their audience if they do. But what apple has done here is enabled the absolute minimum amount of ad blocking because they are at competitive risk if they can't at least check the box.
Apparently the block list is compiled/JITed to native code when loaded for better performance and battery life.
They probably decided it wasn't worth the engineering effort to add a second code generation backend for 32bit phones (which are now three+ generations old and already facing RAM limitations).
