Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple and Google must allow other in-app payment systems, Korean law declares

theverge.com

Post reply on HN
Print view View original

561–570 of 627 posts

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#561

Post by zrm »

ece wrote: post #343
zrm wrote: post #319

Earlier quoted context omitted.

Not only that, "we charge 10% to the big monster and 30% to the little guy" is terrible PR against the amount of money they would generate from just the little guy. It's so bad that by that point they might as well just charge the lower rate to everybody. Especially when they're trying to stave off legislation.

Steam is doing this 30%-20%, and it seems to be working fine of them.. so far. I generally think volume discounts come a bit too close to price fixing, if proven in court. Granted, it's tough to prove, as we've seen in Intel vs. AMD which settled out of court AFAICR.

The unusual thing about Steam is that their high fees discourage developers from using it. If they charged 3% then everyone would use it, there would be a million games there and being in the store wouldn't cause you to stand out at all.

If they charge 30%, most small developers don't use it and then if you choose to pay, you get to be featured on a list without that many of your competitors. You're paying for exclusivity. Then you reach an equilibrium where small developers pay to be listed next to Valve's first party AAA titles, until there are enough of them that the exclusivity is sufficiently diluted to stop attracting more developers.

That doesn't apply to Apple because anyone who wants to reach iOS customers doesn't have any reasonable alternative way to do it, so there are millions rather than thousands of apps in the store and the exclusivity of being listed is already diluted to nothing. But they still charge the same rate.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#562

Post by greggman3 »

dwaite wrote: post #473
kmonsen wrote: post #368

Earlier quoted context omitted.

Isn't this mostly due to burdensome requirements which means most apps would have to remove features and the fact that they don't support upgrades? At least those are the arguments I have seen to not put the apps in the mac store.

For many apps the issue isn't feature removal but sandboxing. https://panic.com/blog/coda-2-5-and-the-mac-app-store/ MAS requires sandboxing, distribution outside the store does not. That said, Apple turns the 'default sandboxing' screw another half turn with every release. In addition to subscription revenue, upgrades are possible by releasing a new product version (e.g. "OmniGraffle 7" in MAS) with a free tier ("re…

I see those 2 things are orthogonal. if it was up to me all apps, even apps not from the app store would be sandboxed by default (and if you wanted to you could give the permissions to un-sandbox them). ideally though they'd run in the sandbox.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#563

Post by zrm »

cletus wrote: post #432
zrm wrote: post #319

Earlier quoted context omitted.

Not only that, "we charge 10% to the big monster and 30% to the little guy" is terrible PR against the amount of money they would generate from just the little guy. It's so bad that by that point they might as well just charge the lower rate to everybody. Especially when they're trying to stave off legislation.

Paying lower unit price for higher volume customers is literally how the entire economy works. People deal with this every day. It's why jumbo packs in the supermarket are cheaper. It's how Costco exists. It's the one capitalist principle almost nobody has a huge problem with.

Volume discounts come about because the true cost of a product has both fixed and variable components. If it costs a given amount to have a checkout clerk ring up your order, that amount doesn't change based on whether you buy a case of ramen or a single cup, so if you buy the case they can spread it over a larger volume.

But in this context, the fixed and variable costs are already split out. iOS developers pay the $99 fixed charge that should cover any of Apple's fixed costs and pay 30%. If you're already paying the fixed costs explicitly then the unit price only needs to cover the variable costs and higher volume yields no change.

And they're starting off from a PR hole because the rate so obviously has no relationship to their actual costs. It costs them the same to distribute a 100MB app whether the developer charges $1 or $100, but they charge $0.30 in one case and $30 in the other. A developer with a 10MB app sold for $10 pays ten times more than a developer with a 100MB app sold for $1 even though their distribution cost to Apple is ten times less.

Ordinary competitive markets don't work like that because otherwise a competitor would come in charging prices more proportional to their costs and everyone being overcharged would switch to the alternative.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#564

Post by nodamage »

mikehearn wrote: post #404

I have a question about monopolies and market abuses. Apple released their phone in 2007, the App Store in 2008, and in-app payments in 2009. During that time their marketshare was fairly small, and it didn't start to really grow until they expanded availability to the Verizon network in 2011. Right at launch of the App Store, Apple announced its sales commission would be 30%. Then they extended that same fee to in-a…

In the United States the courts have consistently said this determination is based on how much market power the competitor wields:

Of course where the seller has no control or dominance over the tying product so that it does not represent an effectual weapon to pressure buyers into taking the tied item any restraint of trade attributable to such tying arrangements would obviously be insignificant at most. As a simple example, if one of a dozen food stores in a community were to refuse to sell flour unless the buyer also took sugar it would hardly tend to restrain competition in sugar if its competitors were ready and able to sell flour by itself. (https://casetext.com/case/northern-pac-r-co-v-united-states)

Whether Apple has enough dominance over the smartphone market to cause an unreasonable restraint of trade in the app distribution market is up to a court to decide at this point.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#565

Post by frutiger »

novok wrote: post #410
haswell wrote: post #376

Earlier quoted context omitted.

I work on a platform that provides its subscribers with a store for 1st and 3rd party apps/solutions built on that platform. Every app delivered on this store must go through the same review process whether it's internally built or not. This has led to healthy innovation on the app store and deep empathy for the 3rd party developer. To be fair, it is possible to ship components that are part of the core platform outs…

So what is the platform?

Somewhat obvious if you check their submission history.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#566

Post by dannyw »

vlovich123 wrote: post #555
haswell wrote: post #376

Earlier quoted context omitted.

I work on a platform that provides its subscribers with a store for 1st and 3rd party apps/solutions built on that platform. Every app delivered on this store must go through the same review process whether it's internally built or not. This has led to healthy innovation on the app store and deep empathy for the 3rd party developer. To be fair, it is possible to ship components that are part of the core platform outs…

Do you run 1p and 3p code in the same environment? That’s frequently the challenge mobile operators run into - the OS needs privileged access to location services (eg 911) that it can’t grant untrusted code.

OP isn't saying the OS goes through the same review processes, but (some) 1p apps do.

For example, Apple Music should not have privileged access to location services - it should be using the exact same location APIs and permissions as 3p apps.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#567

Post by zaarn »

minhazm wrote: post #244
zaarn wrote: post #208

Earlier quoted context omitted.

They can't but the korean developer has a relationship with Google or Apple that the government can reach. If Google forbade a korean dev from making an international app with external payment provider, then SK could very much punish Google SK for it. Doesn't matter if the target users are in Europe. Read the GDPR, same principle.

> Doesn't matter if the target users are in Europe. Read the GDPR, same principle. Actually this is not true. It only applies to companies that are providing services to people physically in the EU. If you're an EU citizen but you're in America, it does not apply. > When the regulation does not apply. Your company is service provider based outside the EU. It provides services to customers outside the EU. Its clients…

That's not what I meant though? The GDPR, as you clearly laid out, applies to you if you do business on EU territory, regardless of where you are. The Korean Regulation can similarly apply if you're physically operating in Korea or not as long as you offer service to Korean developers.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#568

Post by fabianhjr »

jtbayly wrote: post #517
fabianhjr wrote: post #265

Earlier quoted context omitted.

They do that to pay proportionally less (not zero) and the countries they are paying proportionally less to are interested in being the fiscal hosts of those multinationals.

So taxation is a free market competition for global corporations.

Not really, other countries have better capital controls to avoid fiscal shenanigans.

Re: Apple and Google must allow other in-app payment systems, Korean law declares

#569

Post by AnthonyMouse »

vlovich123 wrote: post #555
haswell wrote: post #376

Earlier quoted context omitted.

I work on a platform that provides its subscribers with a store for 1st and 3rd party apps/solutions built on that platform. Every app delivered on this store must go through the same review process whether it's internally built or not. This has led to healthy innovation on the app store and deep empathy for the 3rd party developer. To be fair, it is possible to ship components that are part of the core platform outs…

Do you run 1p and 3p code in the same environment? That’s frequently the challenge mobile operators run into - the OS needs privileged access to location services (eg 911) that it can’t grant untrusted code.

> That’s frequently the challenge mobile operators run into - the OS needs privileged access to location services (eg 911) that it can’t grant untrusted code.

It doesn't actually need this. The phone app can just ask for permission to access your location, which you would then give it when you call 911 because you want the emergency responders to know where you are.

Anyone who really wants to can already deny the phone their location by using a Faraday cage with a WiFi access point in it so the phone has internet but no GPS or cellular triangulation. You can't prevent it by not allowing the user to deny the permission.

There is no excuse for special permissions.

Post reply on HN