I see your app is GPLv3 but I don't see any exception in there for Apple, nor do I see any mention of a release for other developers to sign before accepting pull requests.
Apple removed the VLC app because of a copyright infringement claim from the VLC copyright holder. The don't proactively remove GPL'd apps just because of the license.
There's something weird with this app, it asks to "sign in with icloud" to update the blocking rules... I'm already signed into icloud and I honestly don't understand how this is related to an app's block list update feature??!
Hi! I'm the developer of AdMop. The reason why you're being ask to login is because app needs access not only to iCloud but also iCloud Drive. This is for downloading new rules, which I publish as files over iCloud Drive. I'm planning to change that mechanism in the next version of AdMop; the current approach was the fastest "quick and dirty" solution to have a working implementation. That said I do want to keep using CloudKit as a backend - which requires iCloud access - so I can use it as a place for users to store their own white lists; something quite a few have asked me for. Anyway thanks all for trying AdMop - thanks to your feedback I'll include a note in the store description in future for why the app needs iCloud access.
Good ad blockers should not have paid "acceptable" ad lists, but those that don't allow users to create their own whitelists/blacklists are not good either. Reddit for example uses ad networks sometimes, but also do their own ads.
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).
Correct, Adblock Fast’s blocking is meant to be “good enough” (and not catch every single, last ad) but in exchange for much better browser perf than other ad blockers or no ad blocker.
The vanilla GPLv3 is incompatible with Apple's App Store and they have pulled GPL apps in the past as a result. See: http://www.zdnet.com/article/no-gpl-apps-for-apples-app-stor...
Here's an example of a work-around that would allow you to retain a copyleft license and continue to distribute your app on the app store: https://github.com/WhisperSystems/Signal-iOS/blob/master/CON...