Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Clearly different words being used, but the issue seems to be that the ACM is either deliberately being obtuse, or is simply incapable of understanding what a new, separate app actually entails.

Re-compiling an existing app into a new binary is not difficult, and it would in fact be a new, separate app from the previous one if there were changes to the code base. The suggestions that developers could include a flag to include separate IAP options and maintain a single app, compiled with and without the flag set, would suffice to create a new, separate app.
They completely understand it.
Apple just failed to argue why developers should need to make a new app instead of the one all their customers already use.

It could even be as simple as a geography or based on Dutch banks providing a “free” IAP that provides with 3d party payment options. Developers already can offer uneque IAP based on location etc.

Of all the solutions apple opted for the most complicated one for no good reason outside of incentivizing developers to stay with apples IAP solution.
 
  • Like
Reactions: dk001
Why doesn't Apple just ban all dating apps in the Netherlands and let customers complain to the government that they messed up with their arcane ruling?

It's not like the Dutch market amounts to anything, it's a tiny place with ~17 million people.
 
  • Haha
Reactions: dk001 and boss.king
Things like this should be handled on EU level, it's just stupid that Duchland wants to regulate a big part of Apple's international trade on its own.
They are working with the EU commission and their current investigation. That is why the ACM was allowed to continue on this one area in parallel and drop the rest
 
Why doesn't Apple just ban all dating apps in the Netherlands and let customers complain to the government that they messed up with their arcane ruling?

It's not like the Dutch market amounts to anything, it's a tiny place with ~17 million people.
It's going to blow your mind when you find out that the EU is a thing. Think of it like the US, but more functional.
 
One easy explanation: the ACM doesn't require this for any other type of app, so having two SKUs immediately shows the customers that there is something different going on.
And that’s not ACMs problem if they target only one section right now. EU commission is already investigating the rest in parallel.

And apple already allow this with Uber etc as pointed out by the court ( apple’s personal opinion of the distinction isn’t relevant)
 
Considering this isn’t a problem for 100% of the rest of the market and 99.9999% don’t blame the manufacturer when they act dumb. Why would we expect apple to be the exception?

Scams= already illegal
Porn= is legal, and get over it you prudes.
Apple shouldn’t be the moral arbiter.

Steam allows porn games and nobody lost their minds.
It’s still apples platform.
 
Well the requirement only applies to the Dutch market. Why should Apple extend it to the whole EU?
Two reasons
1: EU law mandates a single market. Just as USA is a single market or state is a single market
2: forcing developers to submit different apps and to make existing consumers to switch or use both instead of offering this in one app for no technical reason outside of “ we want to” isn’t legitimate defense.

IAP can already provide uneque local options. So apple wasn’t able to defend its decision.
 
If i didn't know better, I would say Tim Cook is Putins buddy, both acting equally idiotic lately in their phantasialand.

But Apple did comply with the requirements, laying out a process for developers to offer external payment methods. But that wasn't good enough for them... so who's acting unreasonably?
 
  • Like
Reactions: MacNeb
They completely understand it.
Apple just failed to argue why developers should need to make a new app instead of the one all their customers already use.
Was the original ruling that Apple must allow developers to provide a universal app to the entire world with alternative IAP options? It certainly makes sense that two SKUs provides that ability to cordon off where the ruling is in effect.

Also, they wouldn't need to make a new app. They would just compile the same app with the new features; the same app can be compiled with or without those features, resulting in two separate binaries (one with the feature, one without). You don't need to maintain two codebases -- you just set a region-specific compile flag that includes the alternative IAP option.

It could even be as simple as a geography or based on Dutch banks providing a “free” IAP that provides with 3d party payment options. Developers already can offer uneque IAP based on location etc.
Honest question: which APIs allow developers to offer unique IAP based on location?

Of all the solutions apple opted for the most complicated one for no good reason outside of incentivizing developers to stay with apples IAP solution.
I can think of a lot more complicated solutions than the very simple one proposed by Apple.
 
Last edited:
  • Like
Reactions: CarlJ
But Apple did comply with the requirements, laying out a process for developers to offer external payment methods. But that wasn't good enough for them... so who's acting unreasonably?
Still Apple. They did not comply sufficiently. They chose an overly complicated and burdensome solution and were told to do better, and have yet to revise their plan adequately.
 
Two reasons
1: EU law mandates a single market. Just as USA is a single market or state is a single market
2: forcing developers to submit different apps and to make existing consumers to switch or use both instead of offering this in one app for no technical reason outside of “ we want to” isn’t legitimate defense.

IAP can already provide uneque local options. So apple wasn’t able to defend its decision.
Neither of those things is true. Nothing in the EU law prevents you from distributing different versions of your app in different countries.
 
1:You obviously haven’t read the ruling.
2: this is standard procedure in EU. Regulators aren’t your mom who does the job for you. They provide with the criteria and the rules you need to fulfill with the solution you come up with.

If I tell you to build a colorful treehouse with hand tools.

But you end up building a big grey storage box on the ground above a tree sapling and friends using electric tools for you. You still failed to comply, you just tried to be clever.
Does the rule indicate a specific percentage amount that Apple should charge? If no, then they realize that’s not their authority and, as such, did not include any such criteria.

Are you indicating that in the EU, they wouldn’t even expect a definition of what “treehouse” is with any degree of specificity? The EU just assumes that everyone knows what a “treehouse” is? Just considering the different languages across the EU, it doesn’t seem like that’s right.
 
  • Like
Reactions: MacNeb
If I am interpreting the article correctly, Apple is requiring one Developer Binary for Dutch customers (so hosted in the Dutch App Store) and another Developer Binary for non-Dutch customers (so hosted in every other App Store).

So if you are purchasing from the Dutch App Store, you would get the binary that offers third-party IAP payment processing options.

And if you are purchasing from any other App Store, you would get the binary that only offers Apple's IAP service.




Again, if I am interpreting the article correctly, Dutch customers do have a choice as to whether using Apple's or a third-party's IAP purchase processing using the Dutch App Store binary.

I do agree with you that Apple is making it deliberately difficult for developers by making them maintain two binaries. And that is the point, to be honest (see below).



Apple appear to have made it clear that they do not want to offer third-party in-app purchase processing (TPIAPP) in countries they do not have to. If they allow developer's to implement TPIAPP code in their native binary, but just not enable it outside of countries where they do not have legal sanction to do so, they are making it easier for other countries to mandate that Apple "turn it on" and they want to prevent that by forcing developers to maintain a binary with TPIAPP and one without TPIAPP.
Almost. Apple dictate that developers in Netherlands can do three things.
1: offer app with Apple IAP functions but no third party payment. In every region

2: offer 3d party payment but no apple IAP and only in Netherlands.
3: both but separate apps

And honestly if Netherlands can mandate it, then any EU nation can
 
  • Like
Reactions: CWallace
I can, because it's not just submitting an app and walking away. It's now maintaining two apps instead of one. There's no reason it couldn't all be in a single app.

Keeping it as a single app would even make things easier on Apple's own (apparently strained) App Store review team.
Wow
Really?
I wish I could respond with the first thought that came across my mind.

So, a DEVELOPER needs the burden of submitting two nearly identical apps.
[…]
For an artificial constraint.

The whole point is Apple is trying to make it so difficult that no developer does it, and if they do, no customer uses it.
Huh? Whether to offer and support variations of products (beyond price-focused tiers) has been a required decision for companies providing products/services in multiple countries/markets/regions forever. For example:


The App Store is similar. You can publish an app in just one store (typically the country your company is based in/where you reside), to all of the regional App Stores, or only a select. The decision would be based on variables such as development/maintenance difficulty/cost, local laws prohibiting functionality, etc.

The CUSTOMER needs the burden of selecting and installing one of two apps that matches how they want to pay.
There should be no need for such s decision from the customer perspective. Provide just the app version allowing payment via Apple Pay as well as other methods or just third-party methods in the NL App Store and a version with Apple Pay only in other countries/regions stores (assuming the app is being made available elsewhere).

From what I have seen, most developers do not create country/region-specific versions when offering their app in multiple regions. Either the compatibility/support (e.g. languages, currencies) is baked into the sole package and thus reasonably offered or that country/region is simply ignored — which seems to be the logical approach.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.