Apple agrees to settle potential class action suit by U.S. developers
axios.com
axios.com
I really hope they implemented this as an enum, so someone has to wade through:
enum PricePoint {
UNKNOWN = 0;
NINTEY_NINE_CENTS = 1;
ONE_DOLLAR = 2;
TWENTY_DOLLARS = 3;
NINETEY_EIGHT_CENTS = 4;
DEPRECATED_NINETY_SEVEN_CENTS = 5;
TEN_DOLLARS_PER_MONTH = 6;
PORTUGAL_NATIONAL_BALLOON_DAY_2019_SPECIAL_NINTEY_NINE_CENTS = 7;
// 500 lines follow.
}“Tests pass, ship it”
Unicode sidestepped the issue by naming the characters RIGHT/LEFT-POINTING DOUBLE ANGLE QUOTATION MARK.
“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”
“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.
(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.)
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].
Technically there are several namespaces since you can, for example, name a struct the name as its type.
“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).
I thought it was supposed to be REEFERER.
It doesn't catch everything however.
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.....
Did you just use incorrect as a verb?
Beaten by ten years: https://www.gocomics.com/calvinandhobbes/1993/01/25 :)
> it's troubles
> it's projects
> So now I'm often finding myself misspelling common words
> And all of this is intentional too!
:-D
CRIRCLE = 2
CIRCLE = CRIRCLE
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.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".
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.
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!")
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;
}
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.
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).
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'm sure Steve sent a lot of emails. Which one are you referring to?
This one:
https://www.theverge.com/2021/5/4/22418828/apple-app-store-c...
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.
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.
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 have a post here[1] with a list of federal antitrust departments and how to send them info.
> 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. 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?
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?
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.
Correct me if I'm wrong.
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.
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...
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.
Subject: save 30% over in-app prices!
Body:
"don't pay through the app, use this link to our website"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?
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.
They have to show only the $12 in the app?
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.
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.
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.
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.
They did. They released a generic press release and said nothing else.
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.
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.
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.
> 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.
Of course if something goes wrong and the customer gets litigious they'll be your customer then.
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.
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.
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.
> 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.
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 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 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.
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.
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.
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.
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.
>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?
This is in regards to letting users know about such options outside the iPhone's scope (email for instance)
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 :/
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.
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...
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 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.
https://sixcolors.com/post/2021/04/apples-record-second-quar...
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.
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.
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.
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.
- 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.
Except for having to buy a Mac to do development in the first place. And the developer registration yearly fee.
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
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.
Developers could still object to the settlement[0]. That way, Apple will still be bound by its concessions, while the suit goes forward.
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.
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 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.
In any case, as a game dev, this deal seems bad.
This is status quo.
I vote no.
I suppose this is not unusual, but is it ever considered to not have a judge hear more than one case by a party?
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.
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...
Is this a one time check to all developers who gross less than $ 1 million?
"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."
This seems like a non-concession from Apple.
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.
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.
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
This is just another brick on the "benevolent monopoly" road.
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.
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 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.
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.
> 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.
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.
In reality, for both sides there is a benefit in reducing the risk of an uncertain outcome and avoiding protracted litigation.
This situation is not symmetrical.
* 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?
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.