> Puffin releases were rejected citing app review guideline 2.5.6: "Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript."
Setting aside whether that is a good rule or not, it has nothing whatsoever to do with the previous claim.
I think your first example is somewhat disingenuous.
The vast majority of people will never change their default settings on the vast majority of things. The ability to change something does not contradict the view that a company is engaging in that behavior, and persisting it, for money. E.g. Mozilla/Firefox recently swapping to Google as their default browser would be the same thing, even if they know it's likely somewhat antithetical to many of their users - they will profit from those who are too lazy, or too ill informed, to change it.
I get what you're saying, but your point is also self-defeating for your argument. I would posit that someone who goes out of their way to install Puffin for its benefits would also be aware enough of the ability to change search providers. I have difficulty envisioning the user interested enough to research alternative browsers that are not Safari/Chrome/Firefox who also is not aware of changing default search settings.
It's not just those that would be aware of changing default search settings, but those that actually would. So we have a Venn Diagram of users that would be willing to try out something marketed as "a wicked fast mobile browser" and those that would go out of their way to change Google as the default search engine. What's the exact intersection there? I think we're both left to just wildly speculate, but I do think we can agree it wouldn't be even remotely close to 100%.
Quite sincerely, they should just look into running WebKit server-side.
That said, in my experience if Apple has secretly decided they don't like you, they tend to move the goalposts on you in subsequent reviews, so migrating their systems to WebKit may not be time well spent.
Server-side??? Apple requires apps use the Apple WebKit framework only for web content, which runs only on the client-side. The point of Puffin is to run Flash and other desktop crapware websites that don’t work on Mobile Safari (Apple WebKit) properly.
Puffin isn’t a native or local web browser; it’s an optimized, virtual, remote browser viewer. If they sell it as a “Citrix for the web,” they might have a shot.
Full text from their Facebook post, so you don't have to go to FB
"Many of you have asked why we haven’t updated our iOS app and we’re finally ready to share our story – Puffin is a victim of Apple's abuse.
In 2010 we brought our cloud-based Puffin browser to iOS, allowing iPhone users to enjoy the wicked fast speed, frugal data usage, and extreme virus protection available through server-side rendering.
But, Apple has now decided to reject our app, claiming it violates its guidelines. For seven years, Puffin has been approved with no mention of this violation. But now that Puffin has grown to almost 100 million active loyal users, such as yourself, Apple wants to sabotage Puffin in order to protect the billions of dollars of search revenue from it receives Google.
It’s time to call out the #BadApple and if you agree, feel free to share your comments via the hashtag. For our full story, please visit us on Medium: http://bit.ly/2BsLqI2"
Apple's App Review guidelines used to say something along the lines of "If you have a problem, trashing us in the press never helps." I'm not trying to place judgment on Puffin, but this seems to be the wrong strategy. False negative App Store rejections are typically due to a misunderstanding than a nebulous "corporate greed" angle... or sometimes they were even (at least sort of) justified in the first place [0].
See also: when Rollout got rejected, their open letter [1] didn't help them either.
Puffin releases were rejected citing app review guideline 2.5.6: “Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.” Our server-side web browser is based on Chromium instead of Apple’s WebKit, therefore, Puffin is rejected.
We disputed and escalated but Apple insisted it has jurisdiction over our server-side technology.
Seems like a pretty clear violation of the rules. Trying to find a loophole doesn't work, the rules aren't an Ethereum smart contract, they're actually subject to human judgement.
I thought the stated reasoning for the rules was that Apple for safety reasons didn't want apps downloading and running code (javascript in this case). Clearly that justification doesn't apply if the code runs on a server and not the device.
Apple has always, since time immemorial, blocked apps that duplicated functionality of the core OS. Yes they make exceptions, but building a "better" web browser for iOS was a bad business choice, regardless of how long or well you skirted the rules.
In a duopoly condition, telling companies who want to sell products that can only be sold in the markets of two companies, putting "don't take disputes with us to the press" is rather insidious. It might not help. But Apple already has so much leverage against app developers. Yes, individual app rejections are likely not due to Apple being evil. But Apple doesn't have to be evil, just capricious and unresponsive, to turn their dominant market position into bullying smaller developer shops.
Isn't that obvious? With iPhone being major mobile device they put enough pressure on web developers to support WebKit which benefits Safari not just on iOS, but on macOS as well. This also not just wins better support for Safari, but give Apple some foot in making of web standards.
If they allow alternative engines on iOS they'll just slowly lose browser market share they still have which likely end up in death spiral for Safari support.
It's extremely hard to compete with Google since even Firefox on Android is still extremely rare no matter how much effort Mozilla put into it.
They weren't telling the truth about "superior virus protection" or Apple trying to protect Google ad revenue (Apple has supported third party content blockers in Safari for years), why should we believe they are telling the truth here?
Besides, Opera Mini does the same thing - Server side rendering - and has been on the Apple Store for years.
- Ensures a minimum level of battery performance for users browsing the web. Chrome and Firefox for macOS are notoriously hard on your battery and iOS versions would likely have the same issue.
- Reduces the number of vulnerabilities present on the platform.
- In the event that a bad vuln does crop up, Apple can and will scramble out a WebKit patch to fix it, quickly protecting all users, even those using browsers by small/independent developers. This would be impossible if said indie devs were using Blink or Gecko or something instead.
These problems could be worked around if alternate engines were bundled with the OS as part of a partnership with Google and Mozilla, but such a scenario seems unlikely at best.
1) Users have the choice in other types of apps such as PDF renderers and game engines in matters of performance and battery life. Why not browsers?
2) Game engines are very low level and Apple doesn't have a problem with UE or Unity. Maybe the problem is the iOS sandbox would not work with JS engines?
3) I don't buy the security argument. Google and Mozilla are very diligent with updates, even more so than the Webkit team. It could be argued that the Android approach of unbundling components from the OS is actually better in terms of security.
I thought it had to do with sandboxing and remote code execution. I think they still restrict what interpreters/scripting languages can be used for in apps.
Don't give Apple ideas. The cat's already out of the bag, but if Apple could force people to obtain MacOS apps only from the Mac App Store, which does not have other rendering engines, they would. See also: Windows 10 S.
Is it not possible there's just a security violation they need to sort out?
Am unfamiliar with Puffin, but the post leaping straight to "it's a conspiracy!" without indicating what the stated rationale for rejection was appears a bit off.
(I'd I'm normally first in line to attribute things to corporate greed)
Thats not the issue, the issue is that cnn or whatever.com might render differently or not at all if viewed in one browser, instead of the other. I dont know the internals of puffin, but security and js attack vector, might be different as well.
Hard to take the article seriously with this breathless and inaccurate lead:
“Take the “BatteryGate” for example. Apple secretly and deliberately reduces the performance of old phones in order to boost new phone sales in the name of extending the battery life. The company only revealed this after being caught red-handed.”
And it couldn't be they reduce performance to keep the phone from shutting down prematurely when you have a bad battery- a known issue that people were having?
If they wanted to encourage people to buy new phones wouldn't it just be easier to not support older phones with new iOS updates? Why base the slow down on battery life instead of just slowing the phone down after two years?
There are much easier ways to encourage people to buy new phones if they wanted to be underhanded than the Rube Goldberg conspiracy that you are suggesting.
>Puffin is a victim of Apple’s abuse. Puffin is a server-based web browser where web browser sessions are executed on the cloud servers
You and me know to not use something like this for any kind of sensitive site. But the common iOS user doesn’t know this. Apple is protecting their users and their platform.
It’s 2018. making a web browser where all traffic goes through the browser makers server, being unencrypted and then reencrypted is not acceptable any more (I would argue it never was, but then, back in the days of 9600 bits/s it was more excusable)
Especially when you read their privacy policy, realize they're a Chinese company, and see this: "However, be aware of the possibility of surveillance by intelligence agencies in your home country and our home country."
I wish this was higher up in the discussion. This is a very interesting point, not only when considering the Puffin browser, but considering this entire company. Their whole business model is to improve traditionally-local software by having data processed in the cloud. I have seen people affiliated with the company reply to other comments on this post but yours demands some sort of clarification. This company's real business is selling reports generated from the logs of its users' activity.
They are based in Taiwan based on their job postings [0]. Whether or not Taiwan is technically part of China is up for debate, but the two are defintiely linked.
>Not seeing any documentation on https and puffin. If I log in using puffin, can your servers see my password?
Their answer:
>Yes. Puffin server will see your password even for HTTPS. The browser is physically running on the server. The closest analogy to Puffin is RDP (remote desktop).
Am I reading this right? Who in their right mind would use this shit?
This by itself is a good enough reason for Apple to reject the app on grounds of protecting customer privacy.
Liking it or not, of the major tech companies Apple has had a track record of caring about its users' privacy. I remember Tim Cook mentioning that as a basic value for him personally.
The bigger problem with iOS is that its a complete lock-in. Even if users want the app, Puffin is unable to distribute its app to users since Apple doesn't approve it.
This doesn't happen on Android, if you don't like Play Store, you can still distribute apk and ask the user to download & install.
People may spin it any way they want but this is corporate greed !
> Apple, concerned about the rising competition, decided to sabotage Puffin in order to protect the billions of dollars of search revenue from Google.
Settings → Safari → Search Engine → Yahoo/Bing/DuckDuckGo. There, look, no Google.
The next sentence:
> Puffin releases were rejected citing app review guideline 2.5.6: "Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript."
Setting aside whether that is a good rule or not, it has nothing whatsoever to do with the previous claim.