Apple agrees to settle potential class action suit by U.S. developers(axios.com)
axios.com
Apple agrees to settle potential class action suit by U.S. developers
https://www.axios.com/apple-settles-developer-class-action-c13bb308-daf3-4231-a399-ffd48b6b2c52.html
260 comments
Lol, few things trigger my OCD more than misspelled words in identifiers. I legit missed important use case while amending legacy system just because someone decided to have “priveleges” in the variable name. I hope all those ways to spell number 90 are part of the joke.
Oh yeah it's especially wonderful if it's too late to fix the spelling mistake lol.
I feel like being proactive about these things is one of the most important parts of my job.
I'll just leave this here for you:
https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.2
https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.2
That's a good one. Since legacy code is less likely to change than the English language, I just call it a "referer" in writing unrelated to HTTP. That way, I'm never confused. (Everyone else? Good luck.)
I once saw this implemented as a regex. Unfortunately the regex was refer*er.
“Tests pass, ship it”
“Tests pass, ship it”
The tests clearly did not include spinning up an HTTP server and actually using the correctly-spelled header (as per correct English), then.
I don't know enough about overflows, but that could theoretically be exploited, right? referrrrrrrrrrrrrrrrrrrrrrrrrrrer
inb4 refeer (should've used referr?er)
I also feel like this is a buffer overflow waiting to happen. If somehow someone makes the header length way longer than expected (eg. referrrrrrrrrrrrrrer).
? is 0 or 1 instances of the preceding character, so referrrrrrrrrrrrrrer wouldn’t match /referr?er/, only referer or referrer.
Proof: https://regex101.com/r/s56ebD/1
Proof: https://regex101.com/r/s56ebD/1
I'm replying to the grandparent comment. I said "Also" meaning I was adding onto your comment.
I used to do technical writing and for some software that I wrote the manual and help system for, one of the menu items was misspelled. I spelled the word correctly in the text describing its functionality, but whenever I referred (so to speak) to it directly as the menu item to be selected, I kept the misspelling (this was the early 90s, the days of people saying non-ironically that they couldn't find the "any" key on their computer).
Pretty sure people still can't find the any key, we just stopped asking them to!
Yep, I get some prompts now that say "Press the $X key" (often space), but will actually proceed if you hit any key. It always give me a touch of chuckles when I think about why they named a specific key then.
[deleted]
Lets not forget the misspelling of guillemet as guillemot that is now firmly embedded into PostScript and Adobe software with no chance of ever being fixed.
Unicode sidestepped the issue by naming the characters RIGHT/LEFT-POINTING DOUBLE ANGLE QUOTATION MARK.
Unicode sidestepped the issue by naming the characters RIGHT/LEFT-POINTING DOUBLE ANGLE QUOTATION MARK.
Unicode also documents its mistakes in technote 27 “Known Anomalies in Unicode Character Names” (https://unicode.org/notes/tn27/), with remarks such as
“U+034F COMBINING GRAPHEME JOINER
The name does not describe the function of this character. Despite its name, it does not join graphemes”
“The use of the spelling lamda derives from ISO 10646. This does not mean that it is more correct than lambda, merely that the spelling without the 'b' is the one used in the formal character names”
“A spelling error: "brakcet" should be "bracket". A formal alias correcting this error has been defined”
“U+034F COMBINING GRAPHEME JOINER
The name does not describe the function of this character. Despite its name, it does not join graphemes”
“The use of the spelling lamda derives from ISO 10646. This does not mean that it is more correct than lambda, merely that the spelling without the 'b' is the one used in the formal character names”
“A spelling error: "brakcet" should be "bracket". A formal alias correcting this error has been defined”
I’ve heard Greeks insist that lamda is indeed correct (as a non-misleading approximation of something like [lamða], not necessarily as an English spelling), so that part might have been a deliberate result of the ISO process.
(There’s also the name caron for the haček, apparently not used by anyone before the 80s; per the official FAQ:
Q: Why is the haček accent called “caron” in Unicode?
A: Nobody knows.)
(There’s also the name caron for the haček, apparently not used by anyone before the 80s; per the official FAQ:
Q: Why is the haček accent called “caron” in Unicode?
A: Nobody knows.)
Not for lack of trying: https://www.babelstone.co.uk/Blog/2009/08/antedating-caron.h...
Why can't unicode change the names of the glyphs?
From that page:
“Because Unicode Standard is a character encoding standard and not the Universal Encyclopedia of Writing Systems and Character Identity, the stability and uniqueness of published character names is far more important than the correctness of the name. The published character names are normative for the purposes of the Unicode standard and the large number of other IT standards that reference it. These standards require stable identifiers and character names must therefore be immutable — any change of character names is almost as disruptive of the standards as changing code points for characters would be. Accordingly, the Unicode Consortium has adopted the Name Stability Policy, preventing changes in character names. As a result, errors in character names cannot be corrected. Instead, important character name anomalies anomalies (SIC) are documented with annotations in the Unicode Character Code Charts.”
Also because somebody, somewhere, might have used those names to look up Unicode code points.
Part of each Unicode release is a file named “UnicodeData.txt” (https://unicode.org/Public/13.0.0/ucd/UnicodeData.txt), so those strings are public information.
“Because Unicode Standard is a character encoding standard and not the Universal Encyclopedia of Writing Systems and Character Identity, the stability and uniqueness of published character names is far more important than the correctness of the name. The published character names are normative for the purposes of the Unicode standard and the large number of other IT standards that reference it. These standards require stable identifiers and character names must therefore be immutable — any change of character names is almost as disruptive of the standards as changing code points for characters would be. Accordingly, the Unicode Consortium has adopted the Name Stability Policy, preventing changes in character names. As a result, errors in character names cannot be corrected. Instead, important character name anomalies anomalies (SIC) are documented with annotations in the Unicode Character Code Charts.”
Also because somebody, somewhere, might have used those names to look up Unicode code points.
Part of each Unicode release is a file named “UnicodeData.txt” (https://unicode.org/Public/13.0.0/ucd/UnicodeData.txt), so those strings are public information.
Just a note in passing: Unicode doesn't name glyphs; it names characters.
The key is to write out the enums to long-term storage as the names instead of the numbers, that way nobody can ever fix your spelling mistakes.
There are lots of ways for spelling errors to get reified. They can also end up in a data interchange XML schema (I bumped into that one at a previous job where it seemed like an obvious and trivial fix to correct the spelling of a class name and discovered that it had ended up in a company-wide data interchange schema which could not be practically fixed).
The most important example of that class of error is REFERER. It should have been spelled REFERRER. But nobody caught it, and you really can't change something that is part of the HTTP standard...
> The most important example of that class of error is REFERER. It should have been spelled REFERRER.
I thought it was supposed to be REEFERER.
I thought it was supposed to be REEFERER.
Early header compression.
Took a leaf out of the UNIX creat/umount handbook, clearly.
umount() is actually legit - early C limited extern identifiers to 6 chars (or rather it would allow more than that, but the rest would be silently ignored for linking purposes), hence why we also have strlen() etc.
creat() is weird because create() would fit that constraint just fine, so there's no obvious reason as to why it had to be shortened. The 1978 K&R C book actually notes it with [sic].
creat() is weird because create() would fit that constraint just fine, so there's no obvious reason as to why it had to be shortened. The 1978 K&R C book actually notes it with [sic].
When you're dumping loads of short, generic, common words into the global namespace (well ... the only namespace in C), it's nice to have them misspelled so user code is still free to use the real word.
At this point I think it may be question whether the problem lies with English itself. Such an error prone language.
You don't know the half of it. Many contemporary and common words are the results of misspellings.
“a nickname” was originally “an ekename” (eke being an old English word meaning also)
conversely, “an apron” was originally “a napron.”
English is a weird agglomeration of different languages, with things like the application of French-style plurals (-s) to Anglo-Saxon words (but not always, cf. ox -> oxen) and a generally Germanic syntax with a large fraction of Romance root words.
As part of my Dewey Decimal Project¹ https://www.dahosek.com/category/dewey-decimal-project/ I ended up reading some interesting books on English linguistics (scroll down to the 500s for those).
———
1. I’m not quite done. I have two read books to blog about before I read the last book in the series which will be the book my local library has at its highest Dewey Decimal call number. Alas, it's not a 999 Extraterrestial Worlds book, but I think it's either Antarctica or Australia (I looked when I first started on this seven years ago, but I've since forgotten).
“a nickname” was originally “an ekename” (eke being an old English word meaning also)
conversely, “an apron” was originally “a napron.”
English is a weird agglomeration of different languages, with things like the application of French-style plurals (-s) to Anglo-Saxon words (but not always, cf. ox -> oxen) and a generally Germanic syntax with a large fraction of Romance root words.
As part of my Dewey Decimal Project¹ https://www.dahosek.com/category/dewey-decimal-project/ I ended up reading some interesting books on English linguistics (scroll down to the 500s for those).
———
1. I’m not quite done. I have two read books to blog about before I read the last book in the series which will be the book my local library has at its highest Dewey Decimal call number. Alas, it's not a 999 Extraterrestial Worlds book, but I think it's either Antarctica or Australia (I looked when I first started on this seven years ago, but I've since forgotten).
Tangent: this reminds me of the _aptly_ named "mod_speling" module.
Or get your typo into a spec like "referer"
[deleted]
I was just trying to debug something today and noticed how the referer HTTP header is spelled wrong and that is the spec while there are several other headers that spell it referrer. Crazy!
Have fun naming the variable you use for referer.
do you actually have OCD or are you just using this as a figure of speech?
As a dev with dyslexia, I apologize. I've for sure committed some sins there in places that are nasty to fix.
Well, pasting the enum example into IntelliJ highlighted the spelling mistakes and suggested replacing NINTEY and NINETEY with NINETY. I think this is how my dyslexic colleague works too - copy pasting instead of writing and looking for various wiggly lines in code editor.
Yeah, spell check in editor is killer, and I work in strongly typed languages so it's a compiler error if I misspell a variable name is another big one.
It doesn't catch everything however.
It doesn't catch everything however.
In a triple A game I worked on, the PlayStation button enums were CROSS, SQUARE, TRIANGLE, and...... CRIRCLE.
Would drive me absolutely livid. But of course no one was allowed to fix is since it was already in a few different games, countless script files, network-controlled configs etc.....
Would drive me absolutely livid. But of course no one was allowed to fix is since it was already in a few different games, countless script files, network-controlled configs etc.....
I feel your pain. A company I work for has a weird name that doesn't follow the rules of English spelling correctly (I can't say more without giving away the company name). This was an intentional decision and poses enough of a problem for guests visiting the company. But the absurd thing is this company decides to double down on it's troubles by naming all of it's projects using the same broken rule as the company title. Often these projects will be common English words re-spelt in the style of the company name. So now I'm often finding myself misspelling common words because of this stupid company name. And all of this is intentional too! Drives me nuts.
I see what you did here...
> it's troubles
> it's projects
> So now I'm often finding myself misspelling common words
> And all of this is intentional too!
:-D
> it's troubles
> it's projects
> So now I'm often finding myself misspelling common words
> And all of this is intentional too!
:-D
You mean like Optimizely? I thought most startups these days had absurd adjectiverbnoun names.
Googol?
At this point most students learning about that number assume it's misspelled when first introduced and incorrect the teacher.
>>incorrect the teacher.
Did you just use incorrect as a verb?
Did you just use incorrect as a verb?
A favorite pastime of HN is users incorrecting each other on topics they know nothing about. ;)
Reminds me of this comic.
https://www.gocomics.com/getfuzzy/2003/04/27
https://www.gocomics.com/getfuzzy/2003/04/27
Verbing weirds language.
Beaten by ten years: https://www.gocomics.com/calvinandhobbes/1993/01/25 :)
Beaten by ten years: https://www.gocomics.com/calvinandhobbes/1993/01/25 :)
That's so discorrect.
Reminds me of the occasional encounter with "deinstall" versus "uninstall."
That distinction is a little unrelevant, don't you think? Irregardlessly, you make a good point.
A very long time ago we outsourced our Wordpress development and customization to a developer we found on a website who was from Moldova. He did pretty decent work and we got a great deal, but the HTML/CSS was a bane to work with. Almost half the DIV id's and such were spelled slightly wrong. Didn't affect the operation of the site but was very annoying to work with.
CROSS = 1
CRIRCLE = 2
CIRCLE = CRIRCLE
CRIRCLE = 2
CIRCLE = CRIRCLE
I remember Allegro used to have double functions for Palette and Pallet.
You may notice that a lot of the code in Allegro spells 'palette' as 'pallete'. This is because the headers from my old Mark Williams compiler on the Atari spelt it with two l's, so that is what I'm used to.That's what code reviews are for :)
[deleted]
This reminds me when I was learning to code I was working through the Project Euler problems in python, one of them has you write code to do something with the English words for numbers.
I wrote my code and was fairly confident it was correct, submit the answer and it is rejected, spend the next few hours trying to find the logic error. Of course it's because English is ridiculous and it's "forty" instead of "fourty".
I wrote my code and was fairly confident it was correct, submit the answer and it is rejected, spend the next few hours trying to find the logic error. Of course it's because English is ridiculous and it's "forty" instead of "fourty".
In an old code base I worked in, someone misspelled “params” as “parms.” Always made me want a sandwich.
Sounds like a lisper.
https://duckduckgo.com/?q=site%3Apaulgraham.com+parms
https://duckduckgo.com/?q=site%3Apaulgraham.com+parms
I worked with a (home-rolled at the company, but long before my time with no compilation documentation) comms library that had functions named "receive" and functions named "recieve".
Even better, the library was called into as a COM object by a Visual Basic Script script, and the misspelled corner case only got hit rarely. Figuring out that the problem was the correctly spelled function call was a joy.
Even better, the library was called into as a COM object by a Visual Basic Script script, and the misspelled corner case only got hit rarely. Figuring out that the problem was the correctly spelled function call was a joy.
I rarely work with Excel. A couple of days ago I had the joy to need to apply a function with multiple parameters. The formula parser complained with an error message which meant nothing to me. I finally figured out that I needed to use semicolons as separator for the function arguments (I am from Germany). Who in his right mind does THIS? I tried to change the separator in Windows setting, to no avail.
Magento 1.9X used to have a typo in the database that lasted for years because so much stuff already relied on it and it wasn't user facing. I do not miss those days.
You're going to love this: U+FE18 ︘ PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET: bracket is spelled incorrectly.
https://en.wikipedia.org/wiki/Unicode#Anomalies
https://en.wikipedia.org/wiki/Unicode#Anomalies
I once fat-fingered a `rails new APPNAME` command and didn't catch it for several months. Not impossible to change, but also not really critical either.
Even worse than misspelled is when it’s inverted polarity! Like uninitialized=true means that it IS initialized. I’ve seen something similar to that in multiple jobs.
You kid but they are a list of “tiers” that get localized.
I kind of assumed. You can't just take the price in dollars and convert it with the exchange rate, because customers don't want to buy a "89.398723 yen" app. It has to be $0.99, £0.89, ¥99, etc.
It is interesting that things are not priced in "buying power", but in numbers that aim to most deceive. ("It's not even a dollar!")
It is interesting that things are not priced in "buying power", but in numbers that aim to most deceive. ("It's not even a dollar!")
Steam is very often priced in buying power. Depending on the country you live in, prices can be half as high as in other countries.
Why don’t more digital platforms take this approach? Are they worried people from higher relative income countries will log in with a VPN and buy it cheaper?
There’s also the often forgotten fact that in many countries the listed prices include VAT while in others they don’t.
Complete with spelling errors, semicolons in place of commas, shouting snake case, and unnecessary explicit numbering. Definitely enterprise-grade.
Not complete until it has a poorly documented API with some name like PriceKit, maybe hidden behind an entitlement as well.
The explicit numbering is so that you can reorder them to be more "readable" later. I didn't have the heart to do that here, but in the real world, anything goes!
When somebody comes along and inserts a new case next to an existing case because they're closely related, you'll be glad the numbers are explicit.
Negative - if these are going to be treated like keys where the integer value needs to retain the same meaning between builds, then an enum is the wrong abstraction to use.
The real enterprise case is when additions are made for things that aren’t even pricing
BLUE_BANANA_CONCESSION = 9001
There's also less enterprisy and more "1990s engineering" variant of this:
enum PricePoint {
//all the 500+ price points defined above...
REGULAR_PRICE = 1023;
PROMO1_PRICE = 1047552;
PROMO2_PRICE = 1072693248;
AUTOHINT_ROUND_99 = 1073741824;
AUTOHINT_BUYING_POWER = 2147483648;
}
There is some evidence of this - if you can log in to app store connect (need a developer account) there is this page:
https://appstoreconnect.apple.com/apps/pricingmatrix/1539646...
It shows the tiers from 0 (free) to 87 (USD 999).
Then come the party tiers: 510, 530, 550, 560, 570, 580, 590 which are just repeats of the other tiers, probably for some good historical reason which I'm not aware of.
https://appstoreconnect.apple.com/apps/pricingmatrix/1539646...
It shows the tiers from 0 (free) to 87 (USD 999).
Then come the party tiers: 510, 530, 550, 560, 570, 580, 590 which are just repeats of the other tiers, probably for some good historical reason which I'm not aware of.
> which are just repeats of the other tiers
Those are the price adjusted tiers. They look like repeats in USD, but if you look at other currencies you’ll see they’re different. They’re designed to allow you to offer price points that are scaled according to the market (i.e, 99c in the US, but considerably cheaper than that in India or China).
Those are the price adjusted tiers. They look like repeats in USD, but if you look at other currencies you’ll see they’re different. They’re designed to allow you to offer price points that are scaled according to the market (i.e, 99c in the US, but considerably cheaper than that in India or China).
Makes sense, thanks.
Huh, so $999 is the max -- and here I was all this time thinking the I Am Rich [0] dev had generously chosen an affordable price point.
[0] https://en.wikipedia.org/wiki/I_Am_Rich
[0] https://en.wikipedia.org/wiki/I_Am_Rich
Just note, that link only works for you; if you have a developer account, you'll have to substitute the ten-digit number for one from your apps.
Today I found out we have a national balloon day!
> Developers can communicate directly with customers about alternative payment options. Customers have to consent and be given the right to opt-out.
This is a huge step forward (though it falls well short of the ideal case) for iOS development. Having the ability to tell customers about other, often cheaper, payment methods removes a substantial barrier for some apps that have high-priced subscriptions.
Positive as this change is, there is still a lot of ground to be won here. I'm fearful concessions like this will work as legal currency in the Epic case, instead of momentum pushing ongoing shifts in app store policy. Can someone with more legal understanding weigh in on that?
This is a huge step forward (though it falls well short of the ideal case) for iOS development. Having the ability to tell customers about other, often cheaper, payment methods removes a substantial barrier for some apps that have high-priced subscriptions.
Positive as this change is, there is still a lot of ground to be won here. I'm fearful concessions like this will work as legal currency in the Epic case, instead of momentum pushing ongoing shifts in app store policy. Can someone with more legal understanding weigh in on that?
What do you think the step forward is here?
The developers are still not allowed to communicate about alternate purchase options in the app, they would need to have some other form of communication with the user. Such advertising via side-channels was never forbidden, it's just that it's impractical for most developers to establish that side-channel.
I really have to congratulate whoever wrote that press release. They gave away nothing, and even stated that the policy did not change, but still appear to have convinced a ton of people that there was some kind of a concession here.
The developers are still not allowed to communicate about alternate purchase options in the app, they would need to have some other form of communication with the user. Such advertising via side-channels was never forbidden, it's just that it's impractical for most developers to establish that side-channel.
I really have to congratulate whoever wrote that press release. They gave away nothing, and even stated that the policy did not change, but still appear to have convinced a ton of people that there was some kind of a concession here.
Someone should set up a payment service for apps that's cheaper for the consumer and developer, then advertise it heavily. "Check if your favorite app is on FOO to save money". Every app using such a system could benefit from the direct advertising done once by the payment provider. They could even offer a service that checks your bill from Apple and helps you switch the payment for eligible apps, thereby saving money.
Revenuecat is perfectly positioned to do that, but probably won’t dare anger Apple in this way.
Why? Apple is not paying them, the developers are.
Apple controls the (app store) APIs they are using.
Apple could ban the SDK.
That would be a beautiful piece of anti-competitive behaviour for the Epic case.
I would like to see Apple try. Free PR for revenuecat.
Developers are also not allowed to link to account management on a webpage if they signed up via a website, which contributes to lots of user confusion when it comes to cancellation of a subscription for instance.
I think this is exactly what is being changed here? Now you can link away to a web portal with your account and alternative payment options.
Correct me if I'm wrong.
Correct me if I'm wrong.
> Developers can communicate directly with customers about alternative payment options. Customers have to consent and be given the right to opt-out.
This is the only statement that might be construed as such from the article, but it doesn't say anything about management, and I'm really not sure what consent means - is it a popup that says "do you want to be informed about non-apple payment methods?". Maybe it is what is being changed, but I can't really tell.
I can say that customer confusion is often built into app store policies, and the amount of backend and customer service work to clean up users who sign up with multiple payment methods accidently is not a trivial cost.
This is the only statement that might be construed as such from the article, but it doesn't say anything about management, and I'm really not sure what consent means - is it a popup that says "do you want to be informed about non-apple payment methods?". Maybe it is what is being changed, but I can't really tell.
I can say that customer confusion is often built into app store policies, and the amount of backend and customer service work to clean up users who sign up with multiple payment methods accidently is not a trivial cost.
Moreover, communication about alternate payment options is not the same as ALLOWING alternate payment options.
you can't link directly from the app. however you can ask for email and send the link via email. the settlement hasn't been approved yet (filed yesterday) so the exact terms haven't been updated.
This Apple press release and term changes are super confusing. Probably designed to be confusing. Let's look into them.
First, let's take the old terms. App Store guidlines point 3.1.3 from 2020-11-28: [1]
Apps in this section cannot, either within the app or through communications sent to points of contact obtained from account registration within the app (like email or text), encourage users to use a purchasing method other than in-app purchase.
The old rules seem pretty straightforward. You're not allowed to contact users about other payment options if you acquired the contact info through the app.
Now, the press release from 2021-08-26 says: [2]
Apple is also clarifying that developers can use communications, such as email, to share information about payment methods outside of their iOS app. [..] Users must consent to the communication and have the right to opt out.
This seems like it's purposely vague. The press release doesn't talk about the source of the contact information at all.
So let's take a look at the updated terms. App Store guidelines point 3.1.3 from 2021-08-25: [3]
Apps in this section cannot, within the app, encourage users to use a purchasing method other than in-app purchase. Developers cannot use information obtained within the app to target individual users outside of the app to use purchasing methods other than in-app purchase (such as sending an individual user an email about other purchasing methods after that individual signs up for an account within the app). Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.
What a bizarre paragraph. First it explicitly makes it clear that it's forbidden to send the payment information using contact information obtained via the app. However the last sentence is a generic statement that seems to contradict that. Does Apple mean that you can only use contact information obtained elsewhere? That would then match the previous terms. So it's probably that. However it is worded in such a horrible way that I can't be sure.
--
After looking more into it, I think some actual changes might still be coming. Here's the key paragraph from the actual court document: [4]
Apple has agreed to revise its App Store Guidelines to permit developers of all app categories to communicate with consenting customers outside their app, including via email and other communication services, about purchasing methods other than in-app purchase. See Berman Decl., Ex. A at § 5.1.3. Under the App’s Store existing Guidelines, developers may not use contact information (emails, phone numbers, etc.) obtained within an app to contact their user base outside the app. As a practical matter, this prevents developers from alerting their customers to alternative payment options. The proposed Settlement lifts this restriction, and it does so for all app categories.
--
[1] https://web.archive.org/web/20201128030647/https://developer...
[2] https://www.apple.com/newsroom/2021/08/apple-us-developers-a...
[3] https://web.archive.org/web/20210825162013/https://developer...
[4] https://s3.documentcloud.org/documents/21049923/apple_propos...
First, let's take the old terms. App Store guidlines point 3.1.3 from 2020-11-28: [1]
Apps in this section cannot, either within the app or through communications sent to points of contact obtained from account registration within the app (like email or text), encourage users to use a purchasing method other than in-app purchase.
The old rules seem pretty straightforward. You're not allowed to contact users about other payment options if you acquired the contact info through the app.
Now, the press release from 2021-08-26 says: [2]
Apple is also clarifying that developers can use communications, such as email, to share information about payment methods outside of their iOS app. [..] Users must consent to the communication and have the right to opt out.
This seems like it's purposely vague. The press release doesn't talk about the source of the contact information at all.
So let's take a look at the updated terms. App Store guidelines point 3.1.3 from 2021-08-25: [3]
Apps in this section cannot, within the app, encourage users to use a purchasing method other than in-app purchase. Developers cannot use information obtained within the app to target individual users outside of the app to use purchasing methods other than in-app purchase (such as sending an individual user an email about other purchasing methods after that individual signs up for an account within the app). Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.
What a bizarre paragraph. First it explicitly makes it clear that it's forbidden to send the payment information using contact information obtained via the app. However the last sentence is a generic statement that seems to contradict that. Does Apple mean that you can only use contact information obtained elsewhere? That would then match the previous terms. So it's probably that. However it is worded in such a horrible way that I can't be sure.
--
After looking more into it, I think some actual changes might still be coming. Here's the key paragraph from the actual court document: [4]
Apple has agreed to revise its App Store Guidelines to permit developers of all app categories to communicate with consenting customers outside their app, including via email and other communication services, about purchasing methods other than in-app purchase. See Berman Decl., Ex. A at § 5.1.3. Under the App’s Store existing Guidelines, developers may not use contact information (emails, phone numbers, etc.) obtained within an app to contact their user base outside the app. As a practical matter, this prevents developers from alerting their customers to alternative payment options. The proposed Settlement lifts this restriction, and it does so for all app categories.
--
[1] https://web.archive.org/web/20201128030647/https://developer...
[2] https://www.apple.com/newsroom/2021/08/apple-us-developers-a...
[3] https://web.archive.org/web/20210825162013/https://developer...
[4] https://s3.documentcloud.org/documents/21049923/apple_propos...
> What a bizarre paragraph. First it explicitly makes it clear that it's forbidden to send the payment information using contact information obtained via the app. However the last sentence is a generic statement that seems to contradict that. Does Apple mean that you can only use contact information obtained elsewhere? That would then match the previous terms. So it's probably that. However it is worded in such a horrible way that I can't be sure.
That sounds like you can’t use contact info you received as part of a paid signup to contact to switch to an out of band payment method.
In contrast to contacting a free tier user who’s email you’ve received as part of their signup flow. That situation would be allowed.
Indeed it’s bizarre as depending on when the contact data was gathered decides what you can do with it.
That sounds like you can’t use contact info you received as part of a paid signup to contact to switch to an out of band payment method.
In contrast to contacting a free tier user who’s email you’ve received as part of their signup flow. That situation would be allowed.
Indeed it’s bizarre as depending on when the contact data was gathered decides what you can do with it.
It seems to me that paragraph hasn't been updated to reflect the settlement terms yet, since the settlement was filed today?
That seems to be the case yes. The settlement hasn't been approved yet either.
The way I interpret it is that you can email all your free users at the same time, with the below email, but you can't target individuals users and email them one at a time. My guess is what they are trying to avoid is a flow of: user signs up for free account with email => you inbox them saying:
Subject: save 30% over in-app prices!
Body:
"don't pay through the app, use this link to our website"> the actual court document
That's a nice find!
I still find the language in the filing to be odd, specifically "all app categories". What good does allowing the communication changes for all app categories do, when most of them are not permitted to use non-IAP methods for payments in the first place? On the other hand, if they were changing the rules around when non-IAP payments are allowed, it seems like something that would be called out explicitly.
Maybe it could affect 3.1.3(f) and 3.1.4?
That's a nice find!
I still find the language in the filing to be odd, specifically "all app categories". What good does allowing the communication changes for all app categories do, when most of them are not permitted to use non-IAP methods for payments in the first place? On the other hand, if they were changing the rules around when non-IAP payments are allowed, it seems like something that would be called out explicitly.
Maybe it could affect 3.1.3(f) and 3.1.4?
Agreed. This is just about the very least Apple could do.
> The developers are still not allowed to communicate about alternate purchase options in the app, they would need to have some other form of communication with the user.
I'm pretty sure this "anti-steering" restriction in-app will go away with the Epic vs. Apple ruling. It's classic "tying" in anti-trust. Nothing else in that case might go Epic's way, but this likely will.
I'm also pretty sure every major player generating in-app revenue already has already developed their cheaper payment alternative to rollout the minute the ruling drops, so Apple will have to hustle to get a stay order.
I'm pretty sure this "anti-steering" restriction in-app will go away with the Epic vs. Apple ruling. It's classic "tying" in anti-trust. Nothing else in that case might go Epic's way, but this likely will.
I'm also pretty sure every major player generating in-app revenue already has already developed their cheaper payment alternative to rollout the minute the ruling drops, so Apple will have to hustle to get a stay order.
Shouldn't be too hard. Collect email when they register, give them a free trial, email them instructions to purchase through your website.
Does the settlement allow for alternative payment methods to be cheaper?
They are already allowed to be cheaper. This is just saying you can email people about it outside of the app.
So Spotify still can’t say front and center in the app ”Buy subscription in app: $12/mo or click here to purchase on Spotify dot com for $10”?
They have to show only the $12 in the app?
They have to show only the $12 in the app?
That’s my understanding, yes.
What they can now do is, if you sign-up for a free Spotify account using their app they can send you an email advertising the $10 subscription. In the past they could’ve only sent an email advertising the $12 one.
What they can now do is, if you sign-up for a free Spotify account using their app they can send you an email advertising the $10 subscription. In the past they could’ve only sent an email advertising the $12 one.
[deleted]
It seems like nothing in this prevents a new rule, however, that says you can't sell it cheaper on your own website. Amazon has been doing this with Kindle indy authors for a long time.
Do you know that there can be different pricing with alternative payment options ? This is suspiciously absent from the article.
I have the same concern as well. Apple won't change a damn thing unless a US Court backs anyone but them. If you have legal precedence of a loss on Apples part, they won't be able to pull this BS in the future.
This is the same judge that is doing the Apple vs Epic ruling. I would expect the final ruling on Apple vs Epic to, ultimately, have very similar results to this settlement (or would have).
If you've been following Hoeg Law's hours long legal commentary on Apple vs Epic, they believed the most likely resolution would be Apple being forced to remove the "anti-steering rule" which gags developers from talking about alternative payment options. This settlement has that already. It looks like, unless there is a major upset, the Apple vs Epic ruling will be virtually moot (in terms of legal consequences that benefit developers) unless it gets appealed.
If you've been following Hoeg Law's hours long legal commentary on Apple vs Epic, they believed the most likely resolution would be Apple being forced to remove the "anti-steering rule" which gags developers from talking about alternative payment options. This settlement has that already. It looks like, unless there is a major upset, the Apple vs Epic ruling will be virtually moot (in terms of legal consequences that benefit developers) unless it gets appealed.
Link?
> This settlement has that already.
It sounds like an extremely limited version of that. Email? How magnanimous of them. I'm surprised it was registered mail or carrier pigeon.
It sounds like an extremely limited version of that. Email? How magnanimous of them. I'm surprised it was registered mail or carrier pigeon.
> This settlement has that already.
This settlement is not good enough for many developers, since developers are still subject to Apple's anti-steering rule in their iOS apps. Having to establish another communication channel with the customer is an unnecessary hurdle to let the customer know that they could avoid the (up to) 42.8% price hike on their subscription and future app-related purchases if they pay outside the app.
This settlement is not good enough for many developers, since developers are still subject to Apple's anti-steering rule in their iOS apps. Having to establish another communication channel with the customer is an unnecessary hurdle to let the customer know that they could avoid the (up to) 42.8% price hike on their subscription and future app-related purchases if they pay outside the app.
I love how in their press release they say:
"The terms of the agreement will help make the App Store an even better business opportunity for developers, while maintaining the safe and trusted marketplace users love."
This is going to make the App Store even better! You're going to love it! (not because we did this on our own, but because we saw the writing on the wall and were forced to).
I can't stand how they are burning so much good faith with developers to keep the rent of the app store.
This is going to make the App Store even better! You're going to love it! (not because we did this on our own, but because we saw the writing on the wall and were forced to).
I can't stand how they are burning so much good faith with developers to keep the rent of the app store.
Well, what else are they going to do, not release a statement? If you release a statement about a legal ruling you lost, it's obviously going to be spun from whoever published it.
Not releasing a statement sounds like a good option to me. Even better would be simply not "spinning" it. I don't see what's obvious about it. Companies don't have to behave dishonestly.
It was a known court case that had the potential to have a major impact on Apple’s bottom line. Not releasing a statement about the settlement was not an option. Neither party is 100% happy with the agreement, but realistically — both parties got what they wanted (and they wanted what they got).
This is something of a nitpick but:
Apple did not lose a legal ruling. Some companies initiated a lawsuit against them, and Apple and those parties mutually agreed to resolve their dispute, presumably with concessions from both sides. The agreement needs to be approved by a judge, but the parties in the case are saying that they are no longer in dispute under the proposed terms.
Companies that get sued agree to settlements all the time, even if they believe they are fully in the right, because going to trial has a large potential risk; and the legal expected fees for litigating a trial and possible appeals might exceed the cost of the proposed settlement.
If the party suing you is willing to settle for known terms, then it might be preferable to accept the (undesirable to you but fixed and known ahead of time) costs/downsides by settling, than roll the dice by allowing the case to proceed to a judge or jury trial where you might indeed lose the case and suffer a much worse outcome. Companies might settle if they think there is some chance that they plaintiff might prevail, even if that chance is low, when there could be a large (potentially unbounded) downside to losing the case — as could be the case for a class action.
This is the same risk management reasoning that allows patent trolls to get away with their bullshit. If you don’t think their patent is valid and would survive scrutiny in court, and even know of prior art, or you don’t think you are infringing it, the legal costs to litigate an fight that battle in court might be higher (and take years of time and energy from senior staff members of the company – a distraction) than settling with the patent troll for what they’re asking for to “license” their patent.
It was a travesty that trolls got away with it for so long, but computers and software historically were new whereas most judges & juries consisted of older individuals, and know little to nothing about the internals of computers & software. Meanwhile both sides could bring in so-called expert witnesses to claim whatever they want.
This asymmetry resulted in some tech companies agreeing to pool their patents, and formally or informally agree not to sue each other over patents, and form mutual defense coalitions. The Supreme Court also tightened up what inventions are patentable in the software space considerably, as I recall, to eliminate the “pure abstract idea implemented in software and running on a computer“ category of patents.
Judges are also starting to become more tech savvy and specialized court circuits are developing to focus on the area. Take a look at how Google versus Oracle was handled: the judge assigned to the case learned introductory programming (!) so as to assess whether Oracle’s claim about their code snippet being copyrightable was true, vs. being obvious and something any practitioner of the art would necessarily write when building compatibility with the Java API (which he did end up concluding as I recall; definitely correct decision IMO, if you recall what that function was – something like checking whether a given index was within the bounds of an array or something similar; any function to do that will look about the same). The case was appealed and I haven’t kept up-to-date on it since then.
As the holder of several patents myself, I personally think only substantial research breakthroughs should be patentable (where it comes to software patents that are essentially pure algorithms). The MP3 algorithm was a complete game changer for music & audio distribution, for example, drastically reducing its data size and making it feasible to economically transmit over the Internet. Breakthroughs of this magnitude ought to be the minimum bar in my mind, that I would want the patent office to hold for software patents personally. A novel way to organize your CRM database should not be patentable.
A secondary problem is that the patent office has no incentives to be strict (after all, they can just issue the patents and let people litigate in court if they think it’s wrong), and I doubt their competence in their ability to evaluate whether a claimed invention is worthy. they also make income from the patent submission process so their incentives are to allow companies to submit a lot of patents; and if they made those patents too difficult to get, companies would not bother, relying on keeping inventions as trade secrets instead, which companies by and large are doing anyway.
A final travesty is how many patents don’t disclose any useful information for someone to replicate the invention when the patent expires. As compared to patents for mechanical devices that must include diagrams of functional machines, software patents have hand wavy abstract architectures that would help you little if at all in your efforts to duplicate the “invention“ after the patent expires.
All right, it looks like I’ve gone off on a rant. Suffice it to say that the legal system has lots of complicated incentives and motivations influencing parties involved in it. There may be numerous reasons for a company to take any particular course of action in a legal dispute.
Apple did not lose a legal ruling. Some companies initiated a lawsuit against them, and Apple and those parties mutually agreed to resolve their dispute, presumably with concessions from both sides. The agreement needs to be approved by a judge, but the parties in the case are saying that they are no longer in dispute under the proposed terms.
Companies that get sued agree to settlements all the time, even if they believe they are fully in the right, because going to trial has a large potential risk; and the legal expected fees for litigating a trial and possible appeals might exceed the cost of the proposed settlement.
If the party suing you is willing to settle for known terms, then it might be preferable to accept the (undesirable to you but fixed and known ahead of time) costs/downsides by settling, than roll the dice by allowing the case to proceed to a judge or jury trial where you might indeed lose the case and suffer a much worse outcome. Companies might settle if they think there is some chance that they plaintiff might prevail, even if that chance is low, when there could be a large (potentially unbounded) downside to losing the case — as could be the case for a class action.
This is the same risk management reasoning that allows patent trolls to get away with their bullshit. If you don’t think their patent is valid and would survive scrutiny in court, and even know of prior art, or you don’t think you are infringing it, the legal costs to litigate an fight that battle in court might be higher (and take years of time and energy from senior staff members of the company – a distraction) than settling with the patent troll for what they’re asking for to “license” their patent.
It was a travesty that trolls got away with it for so long, but computers and software historically were new whereas most judges & juries consisted of older individuals, and know little to nothing about the internals of computers & software. Meanwhile both sides could bring in so-called expert witnesses to claim whatever they want.
This asymmetry resulted in some tech companies agreeing to pool their patents, and formally or informally agree not to sue each other over patents, and form mutual defense coalitions. The Supreme Court also tightened up what inventions are patentable in the software space considerably, as I recall, to eliminate the “pure abstract idea implemented in software and running on a computer“ category of patents.
Judges are also starting to become more tech savvy and specialized court circuits are developing to focus on the area. Take a look at how Google versus Oracle was handled: the judge assigned to the case learned introductory programming (!) so as to assess whether Oracle’s claim about their code snippet being copyrightable was true, vs. being obvious and something any practitioner of the art would necessarily write when building compatibility with the Java API (which he did end up concluding as I recall; definitely correct decision IMO, if you recall what that function was – something like checking whether a given index was within the bounds of an array or something similar; any function to do that will look about the same). The case was appealed and I haven’t kept up-to-date on it since then.
As the holder of several patents myself, I personally think only substantial research breakthroughs should be patentable (where it comes to software patents that are essentially pure algorithms). The MP3 algorithm was a complete game changer for music & audio distribution, for example, drastically reducing its data size and making it feasible to economically transmit over the Internet. Breakthroughs of this magnitude ought to be the minimum bar in my mind, that I would want the patent office to hold for software patents personally. A novel way to organize your CRM database should not be patentable.
A secondary problem is that the patent office has no incentives to be strict (after all, they can just issue the patents and let people litigate in court if they think it’s wrong), and I doubt their competence in their ability to evaluate whether a claimed invention is worthy. they also make income from the patent submission process so their incentives are to allow companies to submit a lot of patents; and if they made those patents too difficult to get, companies would not bother, relying on keeping inventions as trade secrets instead, which companies by and large are doing anyway.
A final travesty is how many patents don’t disclose any useful information for someone to replicate the invention when the patent expires. As compared to patents for mechanical devices that must include diagrams of functional machines, software patents have hand wavy abstract architectures that would help you little if at all in your efforts to duplicate the “invention“ after the patent expires.
All right, it looks like I’ve gone off on a rant. Suffice it to say that the legal system has lots of complicated incentives and motivations influencing parties involved in it. There may be numerous reasons for a company to take any particular course of action in a legal dispute.
> Apple and those parties mutually agreed to resolve their dispute
Indeed, but only after those parties took legal action. It's not that Apple at the first sign of disagreement said: "oh well, you were right all along".
Like somebody else said: Apple should just sh*t up about this. Don't spin it.
Indeed, but only after those parties took legal action. It's not that Apple at the first sign of disagreement said: "oh well, you were right all along".
Like somebody else said: Apple should just sh*t up about this. Don't spin it.
> Apple should just sh*t up about this.
They did. They released a generic press release and said nothing else.
They did. They released a generic press release and said nothing else.
As a developer - I don't understand how any developer still holds Apple in good faith.
Literally every step they have taken over the last 8 years has been miserable for independent developers trying to release products on Apple devices.
- Random API shutoff and access changes
- Documentation used to be okayish, is now mostly trash
- Absolutely hostile to virtualization for device testing and deployment pipelines
- Forced payments, tied hands for external payments
- Forced integration of Apple specific features (sign-ups as an example)
- A clear habit of copying successful apps, recreating a mediocre in-house version, then bumping you WAY down below the "Apple" version of your app in the store
And I'm not even talking about the store fees, which in my opinion amount to extortion since they prohibit any other installation method.
I can vaguely understand why some users like Apple, since they market very well.
But as a dev - Apple is literally the fucking devil. They will screw you over at every turn, often with nothing but automated responses, and have a complete disregard for you, your users, and your products.
I wish them a FUCKING HARD fall from grace here. Apple is not a nice company. Apple is a fucking mob extortionist with a great PR story.
Literally every step they have taken over the last 8 years has been miserable for independent developers trying to release products on Apple devices.
- Random API shutoff and access changes
- Documentation used to be okayish, is now mostly trash
- Absolutely hostile to virtualization for device testing and deployment pipelines
- Forced payments, tied hands for external payments
- Forced integration of Apple specific features (sign-ups as an example)
- A clear habit of copying successful apps, recreating a mediocre in-house version, then bumping you WAY down below the "Apple" version of your app in the store
And I'm not even talking about the store fees, which in my opinion amount to extortion since they prohibit any other installation method.
I can vaguely understand why some users like Apple, since they market very well.
But as a dev - Apple is literally the fucking devil. They will screw you over at every turn, often with nothing but automated responses, and have a complete disregard for you, your users, and your products.
I wish them a FUCKING HARD fall from grace here. Apple is not a nice company. Apple is a fucking mob extortionist with a great PR story.
Official announcement thread: https://news.ycombinator.com/item?id=28322638
So you can now tell users that you can pay/subscribe on your website but you can’t offer alternative payment in-app (or can you if it’s a webview?)
But can you do that instead of offering in app payment? Or will you be required to have both.
Personably I really don’t want to see alternative payment methods in app unless they follow the same policies and APIs as the existing ones. I hate that Adobe will stop giving my access as soon as I cancel my subscription. I love that I can cancel my Lightroom subscription from Apple’s subscription list with no fuss and have it expire when it’s due.
But can you do that instead of offering in app payment? Or will you be required to have both.
Personably I really don’t want to see alternative payment methods in app unless they follow the same policies and APIs as the existing ones. I hate that Adobe will stop giving my access as soon as I cancel my subscription. I love that I can cancel my Lightroom subscription from Apple’s subscription list with no fuss and have it expire when it’s due.
The wording makes it so you can send email blasts to free-tier users about signing up via an avenue that's not the App. Within the app itself, for digital items, you still cannot use other payment processors or even Apple Pay, and cannot allude to that fact.
I don't understand... did anything even really change? Like, "more price points"... but that seems like a non-sequitur :/. A big change would be letting developers make it clear to users how to use alternative payment options, but Apple's press release only says via e-mail... which I guess they insist wasn't allowed before?
I don't think the list of price points was the problem as much as it would be nice to have versioned upgrades. (I.e. FileMaker 2, FileMaker 3, FileMaker 4, and so on under the same listing and with access to old versions). Or, you know, a lower developer cut. Or competitive app stores.
I'm just in the same boat... how did you make that your issue worth agreeing over? That's something Apple might have fixed on a Friday afternoon.
I'm just in the same boat... how did you make that your issue worth agreeing over? That's something Apple might have fixed on a Friday afternoon.
I believe one of the arguments used in the suit was along the lines of "Apple, by making the minimum price (other than 'free') for apps and IAPs 99c, prevents us from charging, say, 37c and this harms consumers and is anticompetitive". I believe it was just to provide a clear, verifiable argument that customers were being charged more than they would be in a free market (whereas other things Apple does are infinitely more serious, but also harder to prove and quantify). I'd guess the agreement addresses that to be consistent, even though I don't think anybody truly cares about the granularity of the price tiers.
> A big change would be letting developers make it clear to users how to use alternative payment options, but Apple's press release only says via e-mail
It really says something that "allowing" businesses to communicate certain information with their own customers via an independent channel was considered a concession in this settlement. I'm still wrapping my head around it.
It really says something that "allowing" businesses to communicate certain information with their own customers via an independent channel was considered a concession in this settlement. I'm still wrapping my head around it.
I think it's important to wait for the final language from the settlement. After all, the original PR Post from Apple doesn't actually mention the $100 million fund that Axios does.
It's mentioned:
> Apple will also establish a fund to assist small US developers, particularly as the world continues to suffer from the effects of COVID-19. Eligible developers must have earned $1 million or less through the US storefront for all of their apps in every calendar year in which the developers had an account between June 4, 2015, and April 26, 2021 — encompassing 99 percent of developers in the US. Details will be available at a later date.
> Apple will also establish a fund to assist small US developers, particularly as the world continues to suffer from the effects of COVID-19. Eligible developers must have earned $1 million or less through the US storefront for all of their apps in every calendar year in which the developers had an account between June 4, 2015, and April 26, 2021 — encompassing 99 percent of developers in the US. Details will be available at a later date.
They're not your customers, they're Apple's customers and they're granting you a limited audience with them as long as you follow the house rules.
Of course if something goes wrong and the customer gets litigious they'll be your customer then.
Of course if something goes wrong and the customer gets litigious they'll be your customer then.
I can feel your frustration, but it also strikes me as tone-deaf to those very same customers. The most common kind of email I send these days—by orders of magnitude—is “unsubscribe”. I don’t want your emails unless I actively asked for them. (And, no, passively being opted in or being forced to opt in by a user agreement or whatever doesn’t count.) I would happily pay middle men a lot extra to get fewer unwanted emails, phone calls, or just generally more privacy.
There was an article earlier today on HN about how user-hostile software has become, and I think that explains my problem. Until developers as a whole become not just less hostile, but actively prioritize my needs over their own, I don’t think I’ll change my mind.
My real problem is that I don’t have any leverage as an individual customer against hostile developers. So I’m stuck paying mega corps like Apple or Google to be the middle man for me because they _can_ leverage my interests against developers. So I just don’t feel any sympathy when developers complain that they are having a hard time abusing me.
There was an article earlier today on HN about how user-hostile software has become, and I think that explains my problem. Until developers as a whole become not just less hostile, but actively prioritize my needs over their own, I don’t think I’ll change my mind.
My real problem is that I don’t have any leverage as an individual customer against hostile developers. So I’m stuck paying mega corps like Apple or Google to be the middle man for me because they _can_ leverage my interests against developers. So I just don’t feel any sympathy when developers complain that they are having a hard time abusing me.
> I would happily pay middle men a lot extra to get fewer unwanted emails, phone calls, or just generally more privacy.
My life has changed significantly for the better ever since I signed up for this: http://33mail.com/AQwZJR3
The real trick is using a custom domain so
A) They’re very unlikely to add it to their disposable email list (and thus block it)
B) If this service ever goes under you can still get the emails you want because you own the domain they’re being sent to.
Yes you could theoretically implement this yourself in gWorkspace or O365 but that sounds like a ton of work and $12/yr is 1000x worth it.
(Disclaimer: that’s my referral link, if enough ppl sign up with it I get a free year of service)
I’ve been using it since March of this year and it’s been wonderful, there was like 30 min of downtime once where the dashboard didn’t work but emails were still getting delivered, and I they answered any questions I had when I reached out to them. So I highly recommend it and tell everyone about it.
My life has changed significantly for the better ever since I signed up for this: http://33mail.com/AQwZJR3
The real trick is using a custom domain so
A) They’re very unlikely to add it to their disposable email list (and thus block it)
B) If this service ever goes under you can still get the emails you want because you own the domain they’re being sent to.
Yes you could theoretically implement this yourself in gWorkspace or O365 but that sounds like a ton of work and $12/yr is 1000x worth it.
(Disclaimer: that’s my referral link, if enough ppl sign up with it I get a free year of service)
I’ve been using it since March of this year and it’s been wonderful, there was like 30 min of downtime once where the dashboard didn’t work but emails were still getting delivered, and I they answered any questions I had when I reached out to them. So I highly recommend it and tell everyone about it.
On the flip side for Apple users we get up 100 Hide My Emails in iOS 15 with the same functionality.
I like the UI of 33mail more. It’s easier to click a link at the top of an email in w/e client you’re using vs digging through apple’s portal and ever changing menus to toggle the right thing off.
Unless it’s gotten easier in iOS15… right now on my iPhone it’s not possible to turn off forwarding.
I need to go to appleid.apple.com,
login, 2FA,
find the menu,
wait for it to load (bec it always seems to take like 5 seconds, even if I just opened it),
figure out which service is the one attached to the email I chose (names of company that makes the app and is thus associated with that ID may not always align with the name I know it as),
turn it off.
Also I don’t get to choose the email address, instead apple makes it a random mix of letters and numbers: which means I must save it to a password manager and hope I never need to manually type it in for some reason (say on a public PC).
With 33mail, the link to disable forwarding is in the header, like any unsubscribe link. You can still manage everything from their portal. You choose the domain and then they set it up as a catch all, to receive everything, except that which you say to deny. So you can have creative names for each service.
Unless it’s gotten easier in iOS15… right now on my iPhone it’s not possible to turn off forwarding.
I need to go to appleid.apple.com,
login, 2FA,
find the menu,
wait for it to load (bec it always seems to take like 5 seconds, even if I just opened it),
figure out which service is the one attached to the email I chose (names of company that makes the app and is thus associated with that ID may not always align with the name I know it as),
turn it off.
Also I don’t get to choose the email address, instead apple makes it a random mix of letters and numbers: which means I must save it to a password manager and hope I never need to manually type it in for some reason (say on a public PC).
With 33mail, the link to disable forwarding is in the header, like any unsubscribe link. You can still manage everything from their portal. You choose the domain and then they set it up as a catch all, to receive everything, except that which you say to deny. So you can have creative names for each service.
How does Apple’s service handle the main functionality described above?
> B) If this service ever goes under you can still get the emails you want because you own the domain they’re being sent to.
> B) If this service ever goes under you can still get the emails you want because you own the domain they’re being sent to.
They actually also allow you to set up your own domain, after reading his reply and writing my own I thought I’d research it some more. They apparently released the doc for it yesterday, I just followed it and while it’s impressive that apple is allowing this level of technical expertise to be handed over to their users (modifying DNS records), their doc itself could use a little work. I have it working now for another domain I own.
I still don’t like the UX though compared to 33mail, I still need to go into the UI, add the email I want to use and then it’ll deliver.
I’m guessing the same is true for removal, only way to turn off the address is through the portal.
If you use gWorkspace or O365, you already have this, it’s called aliases, and at least O365 gives you seemingly unlimited aliases. My big pet peeve with that was needing to go into the O365 portal and manage the aliases.
I still don’t like the UX though compared to 33mail, I still need to go into the UI, add the email I want to use and then it’ll deliver.
I’m guessing the same is true for removal, only way to turn off the address is through the portal.
If you use gWorkspace or O365, you already have this, it’s called aliases, and at least O365 gives you seemingly unlimited aliases. My big pet peeve with that was needing to go into the O365 portal and manage the aliases.
By all means use vxNsr’s service (though I wish they mentioned their financial incentive before hand, props for mentioning it in the first place).
I second their approach. By using a unique email per service you maintain a bit more control by being able to filter via “to” address or deregister the email via the service provider. It’s not perfect but it’s at least some bit of control where trust is not required.
Personally I am using simplelogin.com. And full disclosure I wish it had smoother UX in many cases but overall the price vs feature set cannot, as far as I am aware, be beat.
In general: I agree. Demanding attention, whether that be in person such as via mail, txt, or phone call or digital such as via email, should be opt in and NOT opt out. Incentive wise it simply does not make any sense for it to be opt out when the cost of contact is close to 0.
I second their approach. By using a unique email per service you maintain a bit more control by being able to filter via “to” address or deregister the email via the service provider. It’s not perfect but it’s at least some bit of control where trust is not required.
Personally I am using simplelogin.com. And full disclosure I wish it had smoother UX in many cases but overall the price vs feature set cannot, as far as I am aware, be beat.
In general: I agree. Demanding attention, whether that be in person such as via mail, txt, or phone call or digital such as via email, should be opt in and NOT opt out. Incentive wise it simply does not make any sense for it to be opt out when the cost of contact is close to 0.
Once I’d already signed up for 33mail I found simplelogin.io it looks great too, especially feature-wise for the price. It’s 2.5x more expensive vs 33mail (at the base plans) but you get a slicker looking UI and a lot more features.
I was excited about 33mail bec the founder hangs out here sometimes.
You’re right I should have kept the disclaimer closer to the link, I’m on mobile and kept adding stuff and lost track of how it looked, it’s too late to edit now.
I was excited about 33mail bec the founder hangs out here sometimes.
You’re right I should have kept the disclaimer closer to the link, I’m on mobile and kept adding stuff and lost track of how it looked, it’s too late to edit now.
Even though not enforceable in practice, you could've been booted off App Store for sending notifications/other means of communication about a cheaper way to pay.
> did anything even really change?
Nope, that's the point of coming out in front like this and donating 100 million dollars towards keeping the status quo in place. To me, it reads as an insult to anyone who thinks their processes are democratic.
Nope, that's the point of coming out in front like this and donating 100 million dollars towards keeping the status quo in place. To me, it reads as an insult to anyone who thinks their processes are democratic.
Apple is willing to spend $100 million because their executives are in an echo chamber.
There are investigations (and some proposed laws) in the US, EU, Australia, UK, South Korea, and others. If Apple were a regular business, it should be obvious at this point that losing the App Store is inevitable by now. A question of when, not if.
And yet Apple thinks that maybe, just maybe, they can buy their way out and have a chance to keep the status quo still. I think it's way too late for that now. We just need to sit back and wait for the lawmakers to finish the job.
There are investigations (and some proposed laws) in the US, EU, Australia, UK, South Korea, and others. If Apple were a regular business, it should be obvious at this point that losing the App Store is inevitable by now. A question of when, not if.
And yet Apple thinks that maybe, just maybe, they can buy their way out and have a chance to keep the status quo still. I think it's way too late for that now. We just need to sit back and wait for the lawmakers to finish the job.
> it should be obvious at this point that losing the App Store is inevitable by now
This is a radical reading of current facts. It is plausible. But we're very far from inevitability. If you aren't seeing the broad opposition to and limited, focussed support for opening up iOS to competing App Stores, you may be in an echo chamber.
This is a radical reading of current facts. It is plausible. But we're very far from inevitability. If you aren't seeing the broad opposition to and limited, focussed support for opening up iOS to competing App Stores, you may be in an echo chamber.
> which I guess they insist wasn't allowed before?
I think they'd actually claim that it was allowed before. The press release is after all saying that all that's happening is that they're clarifying the policy, not that they are changing it.
I think they'd actually claim that it was allowed before. The press release is after all saying that all that's happening is that they're clarifying the policy, not that they are changing it.
I wonder if that means app developers can now send emails to freshly subscribed users (who are still in the trial period) to cancel their App Store subscription and instead subscribe via an alternative payment provider. Eg. customer could pay 10% less, developer gets up to 24% more, win-win. Maybe the developer could throw in some goodies, like auto-cancellation after the first year.
Let's be clear about this: this settlement means that Apple is offering developers less than what they believe they would be forced to provide by law. There is never any other business logic behind these settlements.
This is just another brick on the "benevolent monopoly" road.
This is just another brick on the "benevolent monopoly" road.
Not necessarily, it could be they believe a lawsuit would inflict PR damage and depress their stock price, or that they feel the risk of an extremely negative outcome is too high, even if still unlikely.
The App Store is under investigation by at least a half dozen countries right now.
To me, Apple losing the App Store appears completely inevitable; and Apple is willing to throw $100 million at a last-ditch effort to keep the status quo.
And if we're lucky and devs are smart, we'll have developers publicly mock those checks from Apple's fund because that was money that Apple took from them with the revenue split and is giving back a fraction of, how generous.
It's like when people get excited about tax refunds from the IRS. Super exciting, until you realize it was excess money taken from you to begin with.
To me, Apple losing the App Store appears completely inevitable; and Apple is willing to throw $100 million at a last-ditch effort to keep the status quo.
And if we're lucky and devs are smart, we'll have developers publicly mock those checks from Apple's fund because that was money that Apple took from them with the revenue split and is giving back a fraction of, how generous.
It's like when people get excited about tax refunds from the IRS. Super exciting, until you realize it was excess money taken from you to begin with.
It's not that apple is going to lose the app store, it's that some of apple's more egregious policies (such as banning pointing users to other payment methods to monopolize payments completely unrelated to apple provided services) are being challenged and apple doesn't want to set any precedents or get any judgements against them on this civil suit.
> It's like when people get excited about tax refunds from the IRS. Super exciting, until you realize it was excess money taken from you to begin with.
Not the best analogy. You can't necessarily know ahead of time exactly what your tax burden is and you define the withholdings to give to the IRS.
You could specify no withholdings and have a big tax bill each year or be too aggressive and get a refund, or somewhere in between. Most people over estimate their obligation because it's easier to overpay than to come up with a large sum every year, especially when living paycheck to paycheck.
Not the best analogy. You can't necessarily know ahead of time exactly what your tax burden is and you define the withholdings to give to the IRS.
You could specify no withholdings and have a big tax bill each year or be too aggressive and get a refund, or somewhere in between. Most people over estimate their obligation because it's easier to overpay than to come up with a large sum every year, especially when living paycheck to paycheck.
> Let's be clear about this: this settlement means that Apple is offering developers less than what they believe they would be forced to provide by law.
Not necessarily. You haven't taken account of costs, or the possibility that the parties both felt this was the best outcome regardless of what (unpredictable) quantum a court may have awarded.
Litigation is a poor use of time for both parties and is best avoided for the good of both parties.
Whether the settlement is "fair", "reasonable", "agreeable", or "forced" is another matter. The point is, you can't assess or deduce it without more information.
Not necessarily. You haven't taken account of costs, or the possibility that the parties both felt this was the best outcome regardless of what (unpredictable) quantum a court may have awarded.
Litigation is a poor use of time for both parties and is best avoided for the good of both parties.
Whether the settlement is "fair", "reasonable", "agreeable", or "forced" is another matter. The point is, you can't assess or deduce it without more information.
Completely agree, especially due to the incredible expenses involved with going to court.
[deleted]
> There is never any other business logic behind these settlements.
Never? That assumes hostility or bad faith by at least one of the parties.
On the contrary, when both parties negotiate in good faith, there is often other business logic to be discovered.
By talking through points of difference, the parties have the opportunity to learn about each others strengths and weaknesses, which are the necessary ingredients for better design.
You never know with this. Apple might learn something from smaller devs that their executives didn't know before. The art is in translating that knowledge into a business advantage for both parties that doesn't cost Apple something in its business relationship with bigger shops, such as Epic.
How? The devil is in the details.
Apple executives naturally have more exposure to big shops than small devs. This exercise at least gets small devs on their radar, and vice versa.
Never? That assumes hostility or bad faith by at least one of the parties.
On the contrary, when both parties negotiate in good faith, there is often other business logic to be discovered.
By talking through points of difference, the parties have the opportunity to learn about each others strengths and weaknesses, which are the necessary ingredients for better design.
You never know with this. Apple might learn something from smaller devs that their executives didn't know before. The art is in translating that knowledge into a business advantage for both parties that doesn't cost Apple something in its business relationship with bigger shops, such as Epic.
How? The devil is in the details.
Apple executives naturally have more exposure to big shops than small devs. This exercise at least gets small devs on their radar, and vice versa.
If you can assume one side thought a settlement is better than an outcome via trial, can you also assume the other side thought so too?
> Let's be clear about this: this settlement means that the developers got more than they believe Apple would be forced to provide by law. There is never any other business logic behind these settlements.
Im inclined to agree without other commenters that this line of thinking doesn’t help.
> Let's be clear about this: this settlement means that the developers got more than they believe Apple would be forced to provide by law. There is never any other business logic behind these settlements.
Im inclined to agree without other commenters that this line of thinking doesn’t help.
> If you can assume one side thought a settlement is better than an outcome via trial, can you also assume the other side thought so too?
No. The cost factor has higher weight on one side of that equation. Apple is one of the largest companies on earth, with an expert and carefully curated legal team. The other side is a loose association of individual interests.
Unless you believe that the legal process is absolutely fair, and that its outcomes are in no way related to the opposing parties' "legal burn rate". In that case, your reasoning is correct.
But that is not the case.
No. The cost factor has higher weight on one side of that equation. Apple is one of the largest companies on earth, with an expert and carefully curated legal team. The other side is a loose association of individual interests.
Unless you believe that the legal process is absolutely fair, and that its outcomes are in no way related to the opposing parties' "legal burn rate". In that case, your reasoning is correct.
But that is not the case.
Applying the same logic to the plaintiffs, you would conclude that Apple is offering developers MORE than what the developers could hope to obtain through the legal process.
In reality, for both sides there is a benefit in reducing the risk of an uncertain outcome and avoiding protracted litigation.
In reality, for both sides there is a benefit in reducing the risk of an uncertain outcome and avoiding protracted litigation.
[deleted]
Your reasoning is only sensible if both parties were on equal footing. They are not. The settlers will offer as little as they can get away with, and the settled will take whatever they can get.
This situation is not symmetrical.
This situation is not symmetrical.
Greatest risk is alternative app stores which provides apple with no revenue.
I don't understand why the App Store, this small "side business" in the grand scheme of things, is something Apple is worth fighting and dying over.
It's literally, a small fraction of their revenue, and yet it grabs 80% of the bad PR and is now under investigation and proposed legislation in the US, UK, EU, Korea, and I think Australia.
If I'm Apple, shouldn't it be obvious at this point that losing the App Store monopoly is inevitable, a when instead of an if? And yet...
It's literally, a small fraction of their revenue, and yet it grabs 80% of the bad PR and is now under investigation and proposed legislation in the US, UK, EU, Korea, and I think Australia.
If I'm Apple, shouldn't it be obvious at this point that losing the App Store monopoly is inevitable, a when instead of an if? And yet...
Side business? $64 billion in revenue in 2020. That's like a quarter of their overall revenue?
Revenue, but that's before devs get their cut.
https://www.marketwatch.com/story/how-profitable-is-apples-a...
In total... more like $22 billion of profit? Not trivial, but compared to Apple's other profitable businesses...
https://www.marketwatch.com/story/how-profitable-is-apples-a...
In total... more like $22 billion of profit? Not trivial, but compared to Apple's other profitable businesses...
Apple's entire profit in 2020 was $57 billion. $22 billion is highly non-trivial even when compared to all of their other businesses combined.
Some quick googling told me a lot of things
Apple hides how much it makes in the app store by combining it into their iPhone product segment.
"Apple doesn’t disclose how much revenue its App Store makes per year. Instead, since 2013, it has released data points in January that include the total that Apple has paid to developers since the beginning of the App Store in 2008."
The low estimates for the app store are $64 billion last year and 70%+ margins. It is entirely possible Apple makes most of its money from the app store.
Apple hides how much it makes in the app store by combining it into their iPhone product segment.
"Apple doesn’t disclose how much revenue its App Store makes per year. Instead, since 2013, it has released data points in January that include the total that Apple has paid to developers since the beginning of the App Store in 2008."
The low estimates for the app store are $64 billion last year and 70%+ margins. It is entirely possible Apple makes most of its money from the app store.
I’m pretty sure the App Store is accounted under “Services” not “iPhone.” $64B sounds about right, but even if services had a 70% margin and hardware had only a 30% margin, hardware would still be the more profitable side of the business at the moment.
https://sixcolors.com/post/2021/04/apples-record-second-quar...
https://sixcolors.com/post/2021/04/apples-record-second-quar...
Maybe so, however if they drop their take to 15% from 30% it will drop their annual profit by 30Billion , which will influence the stock price massively.
Senior management who have a large chunk of their salary in stock arent going to do it easily.
Apple can survive without this money yes, but no one at apple is likely to let it go without fighting for it.
Senior management who have a large chunk of their salary in stock arent going to do it easily.
Apple can survive without this money yes, but no one at apple is likely to let it go without fighting for it.
It's a corollary to Apple's mantra "The best way to make software to make your own hardware". Apple believes in total end-to-end control over the experience.
Yes to a certain extent they are motivated by money, but they are far more motivated by maintaining control. Allowing users to install third party software via another route means that Apple is no longer in control. Apple wants to be the singular provider of everything on their platform.
You can see this in action on macOS. Apple makes almost no money from macOS, yet their grip over it is ever tightening.
Yes to a certain extent they are motivated by money, but they are far more motivated by maintaining control. Allowing users to install third party software via another route means that Apple is no longer in control. Apple wants to be the singular provider of everything on their platform.
You can see this in action on macOS. Apple makes almost no money from macOS, yet their grip over it is ever tightening.
> If I'm Apple, shouldn't it be obvious at this point that losing the App Store monopoly is inevitable?
I think Apple believes their own PR story here. They really do believe that the App Store is great for everyone, not just them. They really do believe that they're entitled to a generous cut of all transactions that happen on their devices.
Objectively, you're right -- although I think I'd go farther and suggest that it actually wasn't inevitable from the start. If Apple had dropped their cut from 30% to 20% five years ago, had looser restrictions on third-party in-app purchases (say, allowing them for "cross-platform digital media" like ebooks), and treated streaming game apps the way they treat other streaming media, those alone might have been enough. Sure, they'd have lost some money that way, but objectively, probably not enough to be worth the risk of going through what they're facing now.
I think Apple believes their own PR story here. They really do believe that the App Store is great for everyone, not just them. They really do believe that they're entitled to a generous cut of all transactions that happen on their devices.
Objectively, you're right -- although I think I'd go farther and suggest that it actually wasn't inevitable from the start. If Apple had dropped their cut from 30% to 20% five years ago, had looser restrictions on third-party in-app purchases (say, allowing them for "cross-platform digital media" like ebooks), and treated streaming game apps the way they treat other streaming media, those alone might have been enough. Sure, they'd have lost some money that way, but objectively, probably not enough to be worth the risk of going through what they're facing now.
> probably not enough to be worth the risk of going through what they're facing now.
Easing restrictions over the years wouldn't prevent the inevitable. Doing it this way lets them face the inevitable lawsuits from a position of power, rather than a weaker position after years of slowly easing restrictions.
It's like ripping off a bandaid.
Easing restrictions over the years wouldn't prevent the inevitable. Doing it this way lets them face the inevitable lawsuits from a position of power, rather than a weaker position after years of slowly easing restrictions.
It's like ripping off a bandaid.
It's not fair to be called a side project at this point, it's used to mediate all software on a computing device used by over a billion people
At this point, I don't think it's an economic calculation anymore, if it ever was. I think it's moreso that Apple genuinely believes that third parties shouldn't have access to their platforms without prior review. Everything else has an explanation from that:
- We need to monopolize control over who can publish software for our platforms, so we can enforce our security guidelines.
(This includes banning third-party app stores, emulators, virtualization, alternative browser engines, and all the other fun things Android users chuckle at iPhone users about.)
- Hiring reviewers to check all the apps we ship for problems costs money, so we need to get paid for that review.
- However, we can't just charge developers money for review, as it would be prohibitively expensive and encourage developers to not fix broken software.
(At this point we need to review what Apple's competition was in this space at the time of the App Store launch. That is, game consoles, which have been universally locked down and monopolized since 1985. The companies that owned those platforms generally charged per software build submitted for review. The cost per submission was somewhere in the 5 figure range and could take up to a month to approve. Nintendo was extra spiteful, and would actually refuse to pay you after you updated your game, until you sold another 1000 units. Steam didn't really bother reviewing software submissions, not because it was a free-for-all, but because partnering with them used to be a legitimate challenge involving bugging several different Valve employees.)
- Therefore, we need to bundle how we get paid for reviewing software into the cost structure of apps. That way, we get paid when developers get paid.
- Thus, we can't have third-party billing, because that would let developers evade payment for our software review.
- We need to monopolize control over who can publish software for our platforms, so we can enforce our security guidelines.
(This includes banning third-party app stores, emulators, virtualization, alternative browser engines, and all the other fun things Android users chuckle at iPhone users about.)
- Hiring reviewers to check all the apps we ship for problems costs money, so we need to get paid for that review.
- However, we can't just charge developers money for review, as it would be prohibitively expensive and encourage developers to not fix broken software.
(At this point we need to review what Apple's competition was in this space at the time of the App Store launch. That is, game consoles, which have been universally locked down and monopolized since 1985. The companies that owned those platforms generally charged per software build submitted for review. The cost per submission was somewhere in the 5 figure range and could take up to a month to approve. Nintendo was extra spiteful, and would actually refuse to pay you after you updated your game, until you sold another 1000 units. Steam didn't really bother reviewing software submissions, not because it was a free-for-all, but because partnering with them used to be a legitimate challenge involving bugging several different Valve employees.)
- Therefore, we need to bundle how we get paid for reviewing software into the cost structure of apps. That way, we get paid when developers get paid.
- Thus, we can't have third-party billing, because that would let developers evade payment for our software review.
>- Thus, we can't have third-party billing, because that would let developers evade payment for our software review.
Except for having to buy a Mac to do development in the first place. And the developer registration yearly fee.
Except for having to buy a Mac to do development in the first place. And the developer registration yearly fee.
And also, the value developers add to Apple's ecosystem
I didn't want to get into that part of it, but Apple definitely needs developers just as much as developers need them. They tried "just make webapps" (which is way better if your main focus is security over all else) for a year and realized very quickly on that they needed native software for their phones.
I know, it's not popular to be on the developers' side. But being an Apple developer many times feels like being an unpaid employee. Apple users get value from your work, for free. Actually, it's not even free since you have to pay a subscription and buy Apple hardware
Monetization is so broken.. the whole model is designed to discourage legitimate app sales. If I didn't enjoy my work I'd think I'm crazy
Monetization is so broken.. the whole model is designed to discourage legitimate app sales. If I didn't enjoy my work I'd think I'm crazy
[deleted]
I guess you can look forward to a check for $2.12 in the mail. Feels like Apple's highfalutin way of mocking devs.
yep. Class action lawsuits are almost always a scam. I remember when I was a kid my parents bought a Kodak instant film camera. Polaroid sued them. As part of the settlement Kodak gave customers... coupons for a discount on Kodak branded batteries and a specific model of camera my parents could never find in stock.
[deleted]
I don't understand the fund. Who would receive the funds, and how?
Is this a one time check to all developers who gross less than $ 1 million?
Is this a one time check to all developers who gross less than $ 1 million?
I was wondering about this too...
From the actual press release:
"Apple will also establish a fund to assist small US developers, particularly as the world continues to suffer from the effects of COVID-19. Eligible developers must have earned $1 million or less through the US storefront for all of their apps in every calendar year in which the developers had an account between June 4, 2015, and April 26, 2021 — encompassing 99 percent of developers in the US. Details will be available at a later date."
"Apple will also establish a fund to assist small US developers, particularly as the world continues to suffer from the effects of COVID-19. Eligible developers must have earned $1 million or less through the US storefront for all of their apps in every calendar year in which the developers had an account between June 4, 2015, and April 26, 2021 — encompassing 99 percent of developers in the US. Details will be available at a later date."
The same federal judge is hearing the Apple-Epic case and a ruling could come at any time.
I suppose this is not unusual, but is it ever considered to not have a judge hear more than one case by a party?
I suppose this is not unusual, but is it ever considered to not have a judge hear more than one case by a party?
Well, there's only a limited number of federal district judges in a given jurisdiction, so the odds are that a bunch of tech companies going at each other in California will get in front of the same federal judge.
However, I'd argue it's also beneficial: Having two different judges rule radically differently on very similar cases (this one and Epic) would only create more confusion, as to what the ruling is, or should be. If either party doesn't think the judge is going to make the right ruling, there's jury trials, and of course, they can always appeal.
However, I'd argue it's also beneficial: Having two different judges rule radically differently on very similar cases (this one and Epic) would only create more confusion, as to what the ruling is, or should be. If either party doesn't think the judge is going to make the right ruling, there's jury trials, and of course, they can always appeal.
> If either party doesn't think the judge is going to make the right ruling, there's jury trials,
Apple and Epic both opted out of a jury trial, probably would have needlessly extended the process and neither of them think a jury would be able to take in all of the nuances of the case to make an informed decision.
Unless, can either party still demand a jury trial a month before/a week before the ruling?
https://www.gamesindustry.biz/articles/2020-09-30-epic-and-a...
Apple and Epic both opted out of a jury trial, probably would have needlessly extended the process and neither of them think a jury would be able to take in all of the nuances of the case to make an informed decision.
Unless, can either party still demand a jury trial a month before/a week before the ruling?
https://www.gamesindustry.biz/articles/2020-09-30-epic-and-a...
I don’t understand, what is a potential class action lawsuit?
In any case, as a game dev, this deal seems bad.
This is status quo.
I vote no.
In any case, as a game dev, this deal seems bad.
This is status quo.
I vote no.
[deleted]
LOL. Apple's revenue is about 140 million per hour. $100M won't deter a damn thing.
Apple was terrified of what might happen in trial.
Edit: downvote away. I'm a former federal law clerk and cofounder of Upsolve. This is how and why settlements happen -- they resolve the uncertainty of trial.
This is how power works in the legal system.
Edit: downvote away. I'm a former federal law clerk and cofounder of Upsolve. This is how and why settlements happen -- they resolve the uncertainty of trial.
This is how power works in the legal system.
Some more information I got from reading the Preliminary Approval Order
Every iOS app developer is automatically included in the class unless she objects to being included, i.e., requests to be excluded.^1 The entire class is represented by two representative members.^2 They in turn are represented by legal counsel selected by a judge.
The settlement approval is still preliminary. It will remain preliminary for several months and still needs to be finally approved by the court. Any app developer can object to the agreement in the meantime.^3
Unless an app developer requests to be excluded from the class, then if no developers object to the settlement agreement and it is approved, she will be bound by the terms of the agreement.
Unless I am mistaken, it is possible the agreement could, e.g., limit her right to take part in lawsuits against Apple in the future, among other things. Question for the reader: Should an iOS developer/Apple read that agreement. A copy will be published online within the next 45 days.^4
App developers have the next 105 days to request to be excluded from the class and/or object to the agreement as well to the fees to be paid to the lawyers representing the class.
1. "Any person who desires to request exclusion from the Settlement Class must do so by 105 days from the entry of this Preliminary Approval Order, and such request for exclusion shall be in the form of a letter mailed or otherwise delivered to the Settlement Administrator stating that the person wants to be excluded from the Cameron et al. v. Apple Inc., Case No. 4:19-cv-03074-YGR (N.D. Cal.) settlement, and the letter must include the persons name and address,and identify all of the persons Apple Developer Accounts. All persons who submit valid and timely requests for exclusion shall have no rights under the Settlement Agreement, shall not share in the distribution of the settlement funds, and shall not be bound by the final judgments relating to Defendant Apple Inc. entered in the litigation"
"All written objections and supporting papers must (a) clearly identify the case name and number (Donald R. Cameron, et al. v. Apple Inc., Case No. 4:19-cv-03074-YGR), (b) be submitted to the Court either by mailing them to the Class Action Clerk, United States District Court for the Northern District of California, 1301 Clay St, Oakland, CA 94612, or by filing it in person at any location of the United States District Court for the Northern District of California; and (c) be filed or postmarked on or before 105 days from the entry of this Preliminary Approval Order"
2. The two app developers who are acting as class representatives for all iOS app developers are: David R Cameron and Pure Sweat Basketball, Inc.
3. See #1
4. It will be published at this address: https://smallappdeveloperassistance.com
Every iOS app developer is automatically included in the class unless she objects to being included, i.e., requests to be excluded.^1 The entire class is represented by two representative members.^2 They in turn are represented by legal counsel selected by a judge.
The settlement approval is still preliminary. It will remain preliminary for several months and still needs to be finally approved by the court. Any app developer can object to the agreement in the meantime.^3
Unless an app developer requests to be excluded from the class, then if no developers object to the settlement agreement and it is approved, she will be bound by the terms of the agreement.
Unless I am mistaken, it is possible the agreement could, e.g., limit her right to take part in lawsuits against Apple in the future, among other things. Question for the reader: Should an iOS developer/Apple read that agreement. A copy will be published online within the next 45 days.^4
App developers have the next 105 days to request to be excluded from the class and/or object to the agreement as well to the fees to be paid to the lawyers representing the class.
1. "Any person who desires to request exclusion from the Settlement Class must do so by 105 days from the entry of this Preliminary Approval Order, and such request for exclusion shall be in the form of a letter mailed or otherwise delivered to the Settlement Administrator stating that the person wants to be excluded from the Cameron et al. v. Apple Inc., Case No. 4:19-cv-03074-YGR (N.D. Cal.) settlement, and the letter must include the persons name and address,and identify all of the persons Apple Developer Accounts. All persons who submit valid and timely requests for exclusion shall have no rights under the Settlement Agreement, shall not share in the distribution of the settlement funds, and shall not be bound by the final judgments relating to Defendant Apple Inc. entered in the litigation"
"All written objections and supporting papers must (a) clearly identify the case name and number (Donald R. Cameron, et al. v. Apple Inc., Case No. 4:19-cv-03074-YGR), (b) be submitted to the Court either by mailing them to the Class Action Clerk, United States District Court for the Northern District of California, 1301 Clay St, Oakland, CA 94612, or by filing it in person at any location of the United States District Court for the Northern District of California; and (c) be filed or postmarked on or before 105 days from the entry of this Preliminary Approval Order"
2. The two app developers who are acting as class representatives for all iOS app developers are: David R Cameron and Pure Sweat Basketball, Inc.
3. See #1
4. It will be published at this address: https://smallappdeveloperassistance.com
>Apple agrees to make sure the search results in the App Store are based on objective criteria.
I cant help but laughed when I was reading it. What were they doing before that?
I thought the most important part was the next bit,
>The settlement, which must be approved by Judge Yvonne Gonzalez Rogers, comes as Apple is awaiting a ruling in a separate lawsuit, brought by Fortnite developer Epic Games, which seeks to force Apple to allow rival in-app payment and store options.
>The same federal judge is hearing the Apple-Epic case and a ruling could come at any time.
My guess is that the way things are going in these cases are not in Apple's flavour. And for all the court case I followed over years Apple tends to be the favourite in court. Rightfully or not. ( Some of the Judge are very clearly biased ) But Judge Yvonne Gonzalez Rogers was clearly trying to get to the bottom of things. And asking some very hard questions.
Is this enough? I am not sure if Judge Yvonne Gonzalez Rogers is easy to please either. And let's not forget this is US only. EU are grinding their teeth. Then there are South Korea and Japan. And China is surpassingly quiet in all of these.
Phil Schiller was right, if Apple were to ever change its fee structure, that it should do so “from a position of strength rather than weakness”. It was unfortunate Steve passed away soon after that email.
I cant help but laughed when I was reading it. What were they doing before that?
I thought the most important part was the next bit,
>The settlement, which must be approved by Judge Yvonne Gonzalez Rogers, comes as Apple is awaiting a ruling in a separate lawsuit, brought by Fortnite developer Epic Games, which seeks to force Apple to allow rival in-app payment and store options.
>The same federal judge is hearing the Apple-Epic case and a ruling could come at any time.
My guess is that the way things are going in these cases are not in Apple's flavour. And for all the court case I followed over years Apple tends to be the favourite in court. Rightfully or not. ( Some of the Judge are very clearly biased ) But Judge Yvonne Gonzalez Rogers was clearly trying to get to the bottom of things. And asking some very hard questions.
Is this enough? I am not sure if Judge Yvonne Gonzalez Rogers is easy to please either. And let's not forget this is US only. EU are grinding their teeth. Then there are South Korea and Japan. And China is surpassingly quiet in all of these.
Phil Schiller was right, if Apple were to ever change its fee structure, that it should do so “from a position of strength rather than weakness”. It was unfortunate Steve passed away soon after that email.
Here's another possible entry for a class action suit, I had a arachnoid type game on Appstore under 'Arcade' category for couple of years and one night I received an email telling Apple is moving my game from 'Arcade' category to some X category because it's naming it's new game subscription as 'Apple Arcade'.
I'm sure every other game in the Arcade category was bolted out unless it could be part of their subscription service. I'm in that part of the world where I can do nothing about it, But was hoping those in U.S. or EU sued the Apple for this.
I'm sure every other game in the Arcade category was bolted out unless it could be part of their subscription service. I'm in that part of the world where I can do nothing about it, But was hoping those in U.S. or EU sued the Apple for this.
You can still report this to the various agencies and offices in the US that hear cases like yours and have the power to investigate and prosecute Apple for antitrust violations.
I have a post here[1] with a list of federal antitrust departments and how to send them info.
[1] https://news.ycombinator.com/item?id=28176193
I have a post here[1] with a list of federal antitrust departments and how to send them info.
[1] https://news.ycombinator.com/item?id=28176193
That's very useful information, Thanks for your comment. I will explore the content further and see what information I provide regarding this incident.
No problem. The US also has antitrust legislation that applies to US companies operating in foreign countries, as well as a myriad of antitrust treaties and agreements with other nations. It might be worth it to also report it to the government of the country you reside in, as well.
> It was unfortunate Steve passed away soon after that email.
I'm sure Steve sent a lot of emails. Which one are you referring to?
I'm sure Steve sent a lot of emails. Which one are you referring to?
> Which one are you referring to?
This one:
https://www.theverge.com/2021/5/4/22418828/apple-app-store-c...
This one:
https://www.theverge.com/2021/5/4/22418828/apple-app-store-c...
The value that objectively pays Apple the most per click.
Separately... I remain astounded at the risks of quasi-arbitrary government action (lawsuit here, Senators here, regulators in EU) that Apple is running to protect their app store vig. Just amazing.
Separately... I remain astounded at the risks of quasi-arbitrary government action (lawsuit here, Senators here, regulators in EU) that Apple is running to protect their app store vig. Just amazing.
> And let's not forget this is US only. EU are grinding their teeth.
Either I am misreading this part of your comment, or you may have overlooked this paragraph:
> With the exception of the fund for small developers, the rest of the changes are being made globally.
Either I am misreading this part of your comment, or you may have overlooked this paragraph:
> With the exception of the fund for small developers, the rest of the changes are being made globally.
But the main complaint is "Apple has a monopoly on app distribution for iPhone users", not "Apple won't let me set the price to $1.05"
I can't but hope that this means that Search Ads will be going away. But that seems quite unlikely if they say they were doing it before…
>> Apple agrees to make sure the search results in the App Store are based on objective criteria.
> I cant help but laughed when I was reading it. What were they doing before that?
I assume that's referring to the fact that previously, they occasionally hard-coded certain search terms to show Apple app results before third-party apps, even if the search term was an exact match. [1]
And that "objective" search results means no more hard-coding of exceptions like this to give "partiality" to a particular company or app.
[1] https://news.ycombinator.com/item?id=27476206
> I cant help but laughed when I was reading it. What were they doing before that?
I assume that's referring to the fact that previously, they occasionally hard-coded certain search terms to show Apple app results before third-party apps, even if the search term was an exact match. [1]
And that "objective" search results means no more hard-coding of exceptions like this to give "partiality" to a particular company or app.
[1] https://news.ycombinator.com/item?id=27476206
"My guess is that the way things are going in these cases are not in Apple's flavour. "
1. I feel this went in Apple's favor.
2. I'm not sure if I got my facts right, but Appe is required to pay developers out of a 100 million fund? 100 million is what they spend on office parties?
3. Offer companies whom are under 1 million in sales, a 15% fee. Biggercompanies are still at 30%.
4. Companies can pay directly. (Yea--I care enough about Epic Games enough to pay them directly? Epic--treat your low level employees better, and I might care? )
Apple seems to have won?
1. I feel this went in Apple's favor.
2. I'm not sure if I got my facts right, but Appe is required to pay developers out of a 100 million fund? 100 million is what they spend on office parties?
3. Offer companies whom are under 1 million in sales, a 15% fee. Biggercompanies are still at 30%.
4. Companies can pay directly. (Yea--I care enough about Epic Games enough to pay them directly? Epic--treat your low level employees better, and I might care? )
Apple seems to have won?
What is Apple's rationale for saying that apps can not charge within themselves? The intention is to make more money, but what is the stated reason? Couldn't Apple make plenty by charging up-front to install things, for the "utility" of it's marketplace and userbase? I struggle understanding why Apple should get every right to money exchanged within apps they didn't program or administer.
[deleted]
Not bad
A more suitable headline for the original article would have been: "US developers' lawyers agree to settle potential class action suit". I wish they didn't. There are important and rather easy wins to be attained (e.g. I don't see how the Apple Payment requirement could survive a trial).
Developers could still object to the settlement[0]. That way, Apple will still be bound by its concessions, while the suit goes forward.
[0] https://news.ycombinator.com/item?id=28323992
Developers could still object to the settlement[0]. That way, Apple will still be bound by its concessions, while the suit goes forward.
[0] https://news.ycombinator.com/item?id=28323992
I also wish companies would put justice above profits, but this is so far removed from our current reality it's hard to imagine.
gonna go ahead and collect my 2.77 from a future class action, who else is in? lol
Suggestion: push for another lawsuit and demand being able to push the information about any price and payment method right in the app.
This seems like a non-concession from Apple.
This seems like a non-concession from Apple.
Good to know.
Suddenly Apple rejected my last app release because of link to app Patreon page(it was there in all previous releases).
Hope now I will be able to back this link to the app.
Suddenly Apple rejected my last app release because of link to app Patreon page(it was there in all previous releases).
Hope now I will be able to back this link to the app.
It’s funny, apple’s share price dropped today, presumable based on this. But I think this is net positive for apple. They are being helped out here by the legal system - forced to make the developer experience and customer experience much better. In the long run this will be good for them.
Meanwhile, as long as you understand that you are allowed to sell your wares to Apples customers - and not yours - you may proceed. This is the key element, that Apple continues to own the customer relationship, rather than that your customers make use of their eco-system and hardware.
Yes, because iOS users will ask Apple for refunds if your app screws them over.
>Developers can communicate directly with customers about alternative payment options. Customers have to consent and be given the right to opt-out.
>Apple ceded some ground on issues of interest to developers but gets to keep (at least for now) key structures of its App Store, including the overall commission structure of the store as well as its prohibition against using rival app stores or in-app payment mechanisms
So are alternative payment methods going to work? Or is it that this is only allowed after you direct a user to an external URL? Would embedded browsers be ok to process the IAPs?
>Apple ceded some ground on issues of interest to developers but gets to keep (at least for now) key structures of its App Store, including the overall commission structure of the store as well as its prohibition against using rival app stores or in-app payment mechanisms
So are alternative payment methods going to work? Or is it that this is only allowed after you direct a user to an external URL? Would embedded browsers be ok to process the IAPs?
It'll be as it has always been. Apps can't show or hint at alternative payment options.
This is in regards to letting users know about such options outside the iPhone's scope (email for instance)
This is in regards to letting users know about such options outside the iPhone's scope (email for instance)
I was hoping Apple was ceding some ground in this, it’s what puts the dirtiest taste in my mouth. If you go to even Walmart (a company very strict on their suppliers) and pick up some object, on the back of the packaging will be www.exampleproduct dot com. And on that website you could theoretically sell your product directly.
What does Apple do? “Oh on that privacy policy we mandated you could click here and then here and then pay online - REJECT”
So now people only know that Netflix can be paid online, but few think to sign up for DuoLingo or the like online :/
What does Apple do? “Oh on that privacy policy we mandated you could click here and then here and then pay online - REJECT”
So now people only know that Netflix can be paid online, but few think to sign up for DuoLingo or the like online :/
Seems like a massive PR trick then. The only difference is that they will set up $100M for US devs. Probably the ones that brought the court case?
But Walmart wouldn’t let a vendor set up a kiosk in the middle of the store and accept payments with a Square reader on a phone, would they?
Walmart has already purchased the items they're selling in their stores - in most situations.
That's how distributers work - They purchase an order of items up front and then sell them at a price point of their choosing.
Not to mention - In the walmart case, the user is free to go shop at safeway/publix/kroger/target/etc if they want. Where as with Apple you can only shop at the company store.
That's how distributers work - They purchase an order of items up front and then sell them at a price point of their choosing.
Not to mention - In the walmart case, the user is free to go shop at safeway/publix/kroger/target/etc if they want. Where as with Apple you can only shop at the company store.
how come Apple/Google is not consider a monopoly on smart phone?
Probably because they are more than one company
Is this enough to open a competing store?
* Put your app for free on the appstore, but with a paywall
* In order to activate the app, you must buy it on an external site
* A web-based store allows users to browse and purchase apps, and "download" links send them to the appstore
* Customers can link their Apple IDs (or another account) so that purchases can be confirmed without having to sign in to every app individually
Or is there still something in the developer contract that prevents this?
* Put your app for free on the appstore, but with a paywall
* In order to activate the app, you must buy it on an external site
* A web-based store allows users to browse and purchase apps, and "download" links send them to the appstore
* Customers can link their Apple IDs (or another account) so that purchases can be confirmed without having to sign in to every app individually
Or is there still something in the developer contract that prevents this?
One of my first thoughts. The purchase of a license would need to occur on the web-based store, where presumably you'd create an account, download the free (with in app purchases, because you don't want to restrict sales even if they're at a lower margin) app from the App store, and sign in with your account to activate.
Seems like entities wishing to operate a secondary app marketplace would continually be balancing tradeoffs in UI/UX (v. native Apple experience) and cost of acquisition for a relatively small reduction in fees.
Seems like entities wishing to operate a secondary app marketplace would continually be balancing tradeoffs in UI/UX (v. native Apple experience) and cost of acquisition for a relatively small reduction in fees.
I would rather risk the class action tbh. This is Apple, the company that changes major things on a whim and doesn't care if it's bad. 10-20 years down the road we'll be in the same spot.
I really hope they implemented this as an enum, so someone has to wade through: