Mobile Tim Apple v Tim Epic - update: Apple has terminated Epic’s developer account lololol

[Kal-El814]

 

 

[TwinIon]

While not directly related to the trial, you can add one more upset app creator to the pile. Fanhouse, which is described as something between Only Fans and Patreon, is mad that Apple want's its full 30% for every dollar that goes through the app.

 

This does seem like a place where Apple's distinction between physical and digital goods is particularly difficult. It also seems odd that Patreon can use third party payment solutions, but Fanhouse, which is pretty much the same model, can't.

 

Fanhouse even suggested that Apple could take a 30% cut of Fanhouse's revenue, which is 10% of a subscription, though it's not hard to imagine why Apple wouldn't want to create that kind of precedent.

 

They also seem to have an Android app that doesn't look like it has in-app-purchases, but it only has 5K downloads to it's not clear if Google decided to give them a pass or if they're just small enough to be under the radar for now.

 

The Fanhouse folks make a lot of "you're taking food out of our mouths" arguments, which I'm not really inclined to agree with, but I do think more examples of Apple being inconsistent with their rules and potentially harmful to innovation is bad for their future prospects in the Epic case and other inevitable anti-trust action.

[Commissar SFLUFAN]

Court issues permanent injunction in Epic v. Apple case

WWW.THEVERGE.COM

---

The app store model on trial

 

Quote

 

Judge Yvonne Gonzalez-Rogers issued a permanent injunction in the Epic v. Apple case on Friday morning, handing a major setback to Apple’s App Store model.

 

Under the new order, Apple is:

 

"permanently restrained and enjoined from prohibiting developers from including in their apps and their metadata buttons, external links, or other calls to action that direct customers to purchasing mechanisms, in addition to In-App Purchasing and (ii) communicating with customers through points of contact obtained voluntarily from customers through account registration within the app."

 

 

[chakoo]

 

Good.  

[Brian]

 

[ort]

This is the common sense answer people have been looking for for a long time.

 

Apple should have made this change on their terms years ago rather than wait for a judge to force it on them on someone elses terms.

[Commissar SFLUFAN]

Overall, this is the "conservative" ruling that pretty much everyone expected with no significant industry-wide ramifications.  There is little-to-no chance that this will be overturned on appeal.

[ort]

It could have industry wide ramifications. Google is sure to have to abide by this as well... and after that, why wouldn't the consoles too?

[Commissar SFLUFAN]

Just now, ort said:

It could have industry wide ramifications. Google is sure to have to abide by this as well... and after that, why wouldn't the consoles too?

 

Do the consoles stores not permit steering to external links for payment?  I genuinely don't know.

[chakoo]

In the app world this will bring huge changes. Apple has straight up blocked apps because someone found buried 5 pages deep in an FAQ that payment management is handled through the website that an app linked to. This means apple is going to have to become more competitive in dropping their rates or you'll start seeing more and more apps sending you to their sites for billing. 

 

2 hours ago, Commissar SFLUFAN said:

Do the consoles stores not permit steering to external links for payment?  I genuinely don't know.

 

It depends but is less strict than apple. I worked on a VOD app for PS4/PS3 that was allowed to have a banner to tell you where to go to signup (could not launch the site using the systems browser) and all status for signups that came from that URL had to be shared with Sony and a fee paid out based on the number of signups it got.

[Commissar SFLUFAN]

 

[TwinIon]

As was always going to be the case, Apple as a monopolist depends on how you define the market, and the judge didn't buy either definition. Instead she defined it as "digital mobile gaming transactions," which is why I don't think this will affect console stores but will likely apply to Google.

 

Reading the injunction, I'm not entirely clear on where the line is. Can you implement full on Google or Amazon Pay buttons in your app like you see on many websites? Will they actually allow product level links like that old Kindle app, or is Apple going to try and force a single link out like they recently announced? Perhaps most importantly, can you implement an alternative payment button without offering Apple's IAP? The order does say "in addition to IAP" so perhaps not? If you are required to provide IAP, can you price things differently? Can you simply charge 30% more through IAP than you do if you pay directly?

 

There's a lot of nuance here that will determine how big of a deal this ends up being.

 

 

From Sweeney's reaction, it seems like he doesn't think a link out to alternative payment counts as real competition to In-App payment options. I suppose they'd hold out if you're required to implement Apple IAP while also offering other options.

 

[Guest]

Appreciate all your coverage @TwinIon

[Commissar SFLUFAN]

 

Does this mean that Apple would even be entitled to a cut of revenue from an external payment provider?

[TwinIon]

19 minutes ago, Commissar SFLUFAN said:

 

Does this mean that Apple would even be entitled to a cut of revenue from an external payment provider?

 

That part of the judgement is describing existing IAP models used in other products and noting that if Apple did change to one of those that they'd still get their cut. The "all models" refereed to there are "current e-commerce models" that experts testified to (presumably Google's, Amazon's, Microsoft's, etc.). All it's really saying is that under any existing in app purchase model, the platform maker gets their cut, it's not describing the remedy enacted by the judge.

 

At least, that's how I read that section, I'm not a lawyer.

[TwinIon]

This interesting interpretation from The Verge pitches the idea that the key wording is the difference between "button" and "external link." That is, it's reasonable to conclude that the difference isn't visual, but functional. An external link sending you to a web page is one thing, and a button that opens an alternative in-app payment mechanism is another.

 

The real key from that piece though is that the court has said it will strictly enforce this judgement and so there's going to be some real back and forth between Apple and developers, and the court will decide what the line is.

 

The more I think about it, the more I think that will also determine the requirement to use Apple's IAP. Those words "in addition to" are doing a lot of work. I'm sure that Apple will read that as "you can't include these links or even the call to action to pay elsewhere unless you also implement IAP." I think that's a very frustrating outcome, since it would mean big companies like Netflix or Amazon would continue to avoid in app purchases because they don't want to send any money to Apple, but scamy little games will throw tons of external links at people and try every dark pattern in the book to push their victims toward their payment systems.

 

The other thing that will be interesting to watch is how Apple denies the apps that push this too far. There are a million stories out there of devs who were rejected by the app store and never given a good reason, or given reasons that didn't make sense, or reasons that were obviously not the case. In pretty much all these stories, they're not getting much info from Apple as to what they actually did wrong. If Apple just sends vague rejections, it might take some real effort to get the courts involved, because it's unlikely to be obvious that any given rejection was because of IAP issues.

[chakoo]

49 minutes ago, TwinIon said:

The more I think about it, the more I think that will also determine the requirement to use Apple's IAP. Those words "in addition to" are doing a lot of work. I'm sure that Apple will read that as "you can't include these links or even the call to action to pay elsewhere unless you also implement IAP." I think that's a very frustrating outcome, since it would mean big companies like Netflix or Amazon would continue to avoid in app purchases because they don't want to send any money to Apple, but scamy little games will throw tons of external links at people and try every dark pattern in the book to push their victims toward their payment systems.

 

No it most likely means, and what apple will push, is akin to sign-in with apple. You're not allowed to offer a link to another payment processing service in app unless you also include apple's IAP system. When apple does that I hope devs push back.

 

The whole sign-in with apple ecosystem is ***ked from top to bottom. If you had SSO with google/facebook that your app is reliant on, you are now no longer allowed to offer those if you don't also offer apple's SSO. Yet the inclusion of apples SSO requires all SSO usage to adhere to their guidelines. So if someone made a new account using an SSO you are not permitted to ask the user for their name to apply to the account (I know devs who had their app rejected over this).

 

The scumminess of some random game should not be apart of the discussion (That shit exist even under the existing IAP system).

[Guest]

16 minutes ago, chakoo said:

The whole sign-in with apple ecosystem is ***ked from top to bottom. If you had SSO with google/facebook that your app is reliant on, you are now no longer allowed to offer those if you don't also offer apple's SSO. Yet the inclusion of apples SSO requires all SSO usage to adhere to their guidelines. So if someone made a new account using an SSO you are not permitted to ask the user for their name to apply to the account (I know devs who had their app rejected over this).

 

Can you elaborate on this. What does SSO stand for, and how do it relate to the sign-in with Apple stuff?

[Commissar SFLUFAN]

5 minutes ago, sblfilms said:

 

Can you elaborate on this. What does SSO stand for, and how do it relate to the sign-in with Apple stuff?

 

I believe SSO stands for "Single Sign On".

[chakoo]

6 minutes ago, sblfilms said:

 

Can you elaborate on this. What does SSO stand for, and how do it relate to the sign-in with Apple stuff?

Single sign-on - Wikipedia

EN.WIKIPEDIA.ORG

 

It is the sign in with your google / facebook / twitter you see all over the web.

[Guest]

1 minute ago, chakoo said:

Single sign-on - Wikipedia

EN.WIKIPEDIA.ORG

 

It is the sign in with your google / facebook / twitter you see all over the web.

 

Gotcha. So, does Apple have worse requirements, or are you just in favor of everybody being able to set their own standards for their SSO implementation? 

[chakoo]

If you want something to read on why devs were not happy with sign-in with apple.

 

https://blog.anylist.com/2020/06/sign-in-with-apple/

 

The system also had a security flaw on day one, now patched. This isn't the first time apple systems have had security flaws.

 

Sign in with Apple flaw allowed unauthorized access to linked services, now fixed - 9to5Mac

9TO5MAC.COM

---

A now-patched vulnerability in Sign in with Apple let attackers access user accounts at linked third-party services. The flaw was discovered by researcher Bhavuk Jain, who reported the problem to Apple through the company’s bug bounty program. As detailed by The Hacker News, the vulnerability relied on how Apple validated users “on the client side […]

 

[chakoo]

4 minutes ago, sblfilms said:

 

Gotcha. So, does Apple have worse requirements, or are you just in favor of everybody being able to set their own standards for their SSO implementation? 

The problem isn't other SSO. It's you're not allowed to offer SSO without also offering apples SSO, and by extension if you use apple SS all your SSO usage now have to conform to apples rules for their SSO.

 

[Guest]

1 minute ago, chakoo said:

The problem isn't other SSO. It's you're not allowed to offer SSO without using apples, and by extension if you use app all your SSO usage now have to conform to their rules.

 

I understand, hence my question. You are saying the issue is the need to conform to Apple's rules, so, does Apple have worse rules OR do you just want everybody to be able to operate under their own set of standards regardless of whether those standards are better or worse than Apple's?

[chakoo]

1 minute ago, sblfilms said:

I understand, hence my question. You are saying the issue is the need to conform to Apple's rules, so, does Apple have worse rules OR do you just want everybody to be able to operate under their own set of standards regardless of whether those standards are better or worse than Apple's?

 

Read the links I posted above. The rules they enforce has/can break the core functionality of an app. 

[Guest]

3 minutes ago, chakoo said:

 

Read the links I posted above. The rules they enforce has/can break the core functionality of an app. 

I'm asking YOU what YOU think  I'm a little confused as to why my question is not clear to you!

[TwinIon]

35 minutes ago, chakoo said:

No it most likely means, and what apple will push, is akin to sign-in with apple. You're not allowed to offer a link to another payment processing service in app unless you also include apple's IAP system. When apple does that I hope devs push back.

 

The whole sign-in with apple ecosystem is ***ked from top to bottom. If you had SSO with google/facebook that your app is reliant on, you are now no longer allowed to offer those if you don't also offer apple's SSO. Yet the inclusion of apples SSO requires all SSO usage to adhere to their guidelines. So if someone made a new account using an SSO you are not permitted to ask the user for their name to apply to the account (I know devs who had their app rejected over this).

 

The scumminess of some random game should not be apart of the discussion (That shit exist even under the existing IAP system).

I agree the SSO stuff is a mess, and it's a good point of reference for what IAP could become with this decision. You'll have Apples' own way to do a thing (that is required), and then you'll have third party systems that will only be allowed under specific circumstances while following Apples' rules (that happen to be designed specifically to disadvantage the third party systems).

 

As for scummy apps, I just bring that up as a disappointing outcome of this, not something that should govern any decisions. If the judge had been a tiny bit more broad, we might see a bunch of apps move from not allowing IAP of any kind, to implementing their own payment systems. Kindle is the easiest example, but there are plenty of others like Hey that would probably allow you to sign up. Instead, the continued requirement of Apple's IAP will likely mean those apps will continue to avoid IAP of all kinds.

 

Meanwhile, we'll probably get to at least get a glimpse of what apps without an IAP requirement might look like thanks to South Korea.

[chakoo]

2 hours ago, sblfilms said:

I'm asking YOU what YOU think  I'm a little confused as to why my question is not clear to you!

 

Your question is clear, I just don't have time atm to really distill it down into something that would make more sense. Would you accept that to process credit cards at your drive in you have to adhere to strict rules from visa that says because their services are down from 8pm-10pm you're not allowed to process credit cards from other sources during that time and to just not accept visa your not allowed to accept credit cards from any other company?

 

That's kind of the deal with SSO for apple. If your app allowed for google SSO in the past, you are not allowed to submit or release updates for your app unless you also add in Apple's SSO and in adding apples SSO your app is no longer allowed to ask for a name, email address or contact info in any way, even if it's just as benign as having you setup a name/title on a  profile. So your only option is to pull out features or just not support any company's SSO even if your app previously had it before.

 

-edit-

Just to make it clear, I don't like this because this actually affects my business directly which is building an app that works with Google services. So this isn't me just simply being anti apple (my phone is an iphone and has been for many years), it's something I have to put up with as a business and for the time being we've had to choose not to support SSO and require users to create their own user & passwords.

[chakoo]

2 hours ago, TwinIon said:

I agree the SSO stuff is a mess, and it's a good point of reference for what IAP could become with this decision. You'll have Apples' own way to do a thing (that is required), and then you'll have third party systems that will only be allowed under specific circumstances while following Apples' rules (that happen to be designed specifically to disadvantage the third party systems).

 

As for scummy apps, I just bring that up as a disappointing outcome of this, not something that should govern any decisions. If the judge had been a tiny bit more broad, we might see a bunch of apps move from not allowing IAP of any kind, to implementing their own payment systems. Kindle is the easiest example, but there are plenty of others like Hey that would probably allow you to sign up. Instead, the continued requirement of Apple's IAP will likely mean those apps will continue to avoid IAP of all kinds.

 

Meanwhile, we'll probably get to at least get a glimpse of what apps without an IAP requirement might look like thanks to South Korea.

 

The apps who don't already have IAP in their apps are more monthly service applications, Or services that started out as a website/web app that later created an iOS/Android app who have an established payment processing service (Be it stripe, paypal, etc). It takes a lot of engineering work to support working with multiple payment service providers. The freemium game that lives off IAP isn't going to fully change off their current system because for them to be profitable they need to make the act of buying IAP as seamless as possible.

 

I'm interested in seeing how things go with South Korea. I think it's going to make things easier in the end for consumers there.

[Commissar SFLUFAN]

Judge Yvonne Gonzalez Rogers should replace Justice Stephen Breyer on the Supreme Court.

[SimpleG]

Googles next at bat

Google says Fortnite’s in-app purchase swap was a breach of contract, sues Epic

ARSTECHNICA.COM

---

Epic swapped Google Play IAPs in 2020, but the contract says it couldn't do that.

 

[Keyser_Soze]

Tim Sweeney crying about apple copying another game.

 

 

[Brian]

 

[SuperSpreader]

I hate all these people

[TwinIon]

I wasn't aware of this story, but regulators in the Netherlands decided that Apple was in breach of competition rules specifically for dating apps, and that Apple needed to allow third party payment options. Apple has now put out how they will be complying with the order, and they're not taking it lightly. To summarize, if you have a dating app in the Netherlands and want to use your own payment provider, you:

-Must create a new, separate app that is only available in the Netherlands

-You cannot support both Apple's in app payments and a third party one in the app

-Before linking to the third party payment provider, you have to show a screen warning "This app does not support the App Store’s private and secure payment system" in big bold font, along with a disclaimer telling you about the features you're losing by doing this.

-You need to use a single URL for your sign-up page, with no parameters. So you can't pass existing user info or anything else along.

 

That all seems perfectly brutal, but there's an even bigger catch. Even if you don't use Apple's payment system, Apple still expects their cut! Apple is demanding that anyone using a third party payment method log all transactions from iOS devices, and manually pay Apple a 27% commission, after tax.

 

There's not a ton of reporting on this story yet, and not reading the language I can't exactly go through the court ruling and see if Apple is directly violating it and daring the government to come after them, or if they're just pushing their luck as far as possible. Either way, I think Apple has shown their hand in a way that won't be to their advantage. Regardless of how this plays out with dating apps in the Netherlands, you have to imagine the next time the IAP issue comes up in a courtroom and Apple loses, they'll make sure that Apple can't be this restrictive.

 

The whole idea is that Apple is being anti-competitive and creating "unreasonable conditions" by requiring the use of their own IAP system and charging such a high fee. I would have to imagine a court will look at this and argue that this system alleviates none of the concerns that made them rule against Apple in the first place.