I think that means this proposal adds a very specific form of finalisers to go.

How is that implemented efficiently? I can think of doing something akin to NSAutoReleasePool (https://developer.apple.com/documentation/foundation/nsautor...), with all allocations inside a `secret.Do` block going into a separate section of the heap (like a new generation), and, on exit of the block, the runtime doing a GC cycle, collecting and clearing every now inaccessible object in that section of the heap.

It can’t do that, though, because the article also says:

“Heap allocations are only erased if the program drops all references to them, and then the garbage collector notices that those references are gone. The program controls the first part, but the second part depends on when the runtime decides to act”

and I think what I am thinking of will guarantee that the garbage collector will eagerly erase any heap allocations that can be freed.

Also, the requirement “ the program drops all references to them” means this is not a 100% free lunch. You can’t simply wrap your code in a `secret.Do` and expect your code to be free of leaking secrets.

Is there any standard that says anything about the performance of fseek?

If not, how can one claim that this is O(1)? :D

I would think making sure outside payment links aren’t scams will be more expensive than that because checking that once isn’t sufficient. Scammers will update the target of such links, so you can’t just check this at app submission time. You also will have to check from around the world, from different IP address ranges, outside California business hours, etc, because scammer are smart enough to use such info to decide whether to show their scammy page.

Also, even if it becomes ‘only’ hundreds of dollars, I guess only large companies will be able to afford providing an option for outside payments.

If you have a hint of a payment button 15 clicked after leaving your support page through the site logo link your app would get immediately flagged for removal unless you deal with it within week or two give to you.

He seems to be ignoring the part of the ruling finding that Apple is entitled to "some compensation" for the use of its intellectual property.

> The appeals court recommends that the district court calculate a commission that is based on the costs that are necessary for its coordination of external links for linked-out purchases, along with "some compensation" for the use of its intellectual property. Costs should not include commission for security and privacy.

https://www.macrumors.com/2025/12/11/apple-app-store-fees-ex...

Apple wanted 27% and Epic thinks it should be 0%. The lower court will have to pick a number in between the two.

> Apple should be able to charge a commission on linked-out purchases based on the costs that are genuinely and reasonably necessary for its coordination of external links for linked-out purchases, but no more.

> In making a determination of Apple’s necessary costs, Apple is entitled to some compensation for the use of its intellectual property that is directly used in permitting Epic and others to consummate linked-out purchases.

> In deciding how much that should be, the district court should consider the fact that most of the intellectual property at issue is already used to facilitate IAP, and costs attributed to linked-out purchases should be reduced equitably and proportionately;

> Apple should receive no commission for the security and privacy features it offers to external links, and its calculation of its necessary costs for external links should not include the cost associated with the security and privacy features it offers with its IAP;

https://fingfx.thomsonreuters.com/gfx/legaldocs/lgvdqxweopo/...

Like, if all major marketplaces only charge 12% from the get-go, we probably would have had much less fuss and lawsuits over this.

This issue was always the disproportionate size of the fee, not the fact that they charge a fee.

Doing it this way makes no economic sense for either the seller or the buyer but it's coincidentally the absolute best way for a middleman to maximize the tax they can extract from a two-sided marketplace they control. In competitive markets, blanket taxing on total gross revenue generally only occurs when there's a single fundamental cost structure tied to that revenue, or the amounts being collected are so small it's de minimis. App stores are highly profitable, multi-billion dollar businesses.

Perhaps the most perverse thing about this is that electronic transactions for purely digital goods which occur entirely on real-time connected digital platforms make it trivial to price each service for maximum efficiency. It's easy for the price a 2GB game with frequent updates pays for electronic delivery to reflect the cost they impose on the infrastructure while a 100k one-time purchase app can pay a vastly smaller amount. And that's exactly the way the competitive marketplaces evolve - from moving shipping containers around the planet to residential propane delivery.

Pick 3 imaginary games for sale priced at $1, $10 and $100. Any one of those games could be a million download a month success, and any one of them could be a complete dud.

What flat rate would you suggest to:

* Pay the developer for their work (ongoing per sale)

* Review each game and ensure it meets store guidelines (once per update)

* Host said game regardless of how popular it is (ongoing)

* Process transactions for the game (ongoing)

The alternative would be pricing based on revenue tiers (similar to what Unreal Engine does now), which aren't known in advance and don't take global variance into account (USD$200 in Eastern Europe might be a month's salary).

Percentage is just simpler. It also means that they'd be taking a loss on every free app or in the case of Free-to-Download In-App purchase apps - until users start transacting.

Do you object to other sorts of royalty-based compensation, like for Unity engine or Unreal engine?

There should be caps overall and under the caps there should be the option to choose between lump sum and royalties.

Nobody should be collecting unlimited revenue for a brilliant idea at the start and benefit from cheap or free scaling.

This entire model is ripping apart the fabric of modern society.

And yes, I known this is blasphemy on this website.

You should look at it the other way, where ANY income or income equivalent, of any kind, should be taxed like income.

So when Bezos spends $5bn per year, that means he made $5bn per year (at least), so his tax statement should show him paying $2bn or whatever the top tax rate would imply.

The scaling also helps so that some (probably most) games aren't losing money to be hosted kn a store. That would be catastrophic as at some point games would need to remove themselves to name financial sense.

If something gets super popular, it presumable costs Epic more. But does 100 sales cost 100x more than 1 sale? That seems unlikely.

Does Microsoft earn their 30% cut on Xbox since they do provide the OS, hardware development and gaming APIs?

Aren't Epic's 12% fee less than half of what is usually charged?

Since courts work on what is reasonable, what makes you think that they will reduce it?

The only other category you can really compare this to is game consoles, but the hardware is sold at a much smaller margin and they still (for now) support physical media.

12% is if you sell directly through Epic's platform - nobody is claiming Apple shouldn't get a cut of that for their own platform.

"0% Store Fee For First $1,000,000 in Revenue Per App Per Year Starting in June 2025, for any Epic Games Store payments we process, developers will pay a 0% revenue share on their first $1,000,000 in revenue per app per year, and then our regular 88%/12% revenue share when they earn more than that. "

But I also recognize that few out there are pressing strong opposition to the idea of paying 3% for someone else to manage their financial transactions, or to host their own business. If I make a million dollars, paying 50k to Patreon or Kickstarter for hosting the service seems to make sense in my mind

So, to you answer your question, the fee that Epic should take is exactly the same as Apple's. It is exactly Zero dollars for all apps that do not go through their app store. Thats already how it works though.

It, of course, would be absurd if Epic was able to force you to pay them money for apps that don't involve Epic in any way and dont go through their app store!

Not that they'd ever do the review to begin with, so the hashing won't be done either, but it's something that could be done on iOS/ipados.

And if you consider that infeasible, you might want to check out current CSP best practices, you might be surprised

Tens to hundreds every time an app goes through review is "super supor minor"... This is how you know Epic has the backs of all the indie devs who fret about $100/year dev membership.

https://store.epicgames.com/en-US/news/introducing-epic-web-...

Is Apple actually checking outside payments for scams outside of review times? Do they check non-payment links for scams outside of review times? How often?

The point is that they should only be able to charge a fee for work they are truly doing, and it shouldn't be retaliatory.

Or we end up with this modern disease where the OS wants to update itself, the browser needs to update itself, Acrobat wants to update itself, etc, etc, all the time.

According to the ruling on page 42, "(c) Apple should receive no commission for the security and privacy features it offers to external links, and its calculation of its necessary costs for external links should not include the cost associated with the security and privacy features it offers with its IAP"

I'm not versed in legalese, so maybe I misunderstand. Isn't it reasonable that Apple receives money for a service they provide, that costs money to run?

Think about it this way: totally free apps with no IAP get reviewed by Apple too, and there's no charge to the developer except the $99 Apple Developer Program membership fee, which Epic already pays too.

On average, Apple spends less than a minute on app reviews for new versions.

You really think that the aggregate cost of fraud mitigation in the app store is 30% of revenue? That seems laughable, the credit card industry as a whole does far, far better than that with far less ability to audit and control transaction use.

Still well before the talk.

I suspect there are others who rarely click “bad” or “good”.

Because of that, I think you first need to train a model on scaling each user’s judgments to a common unit. That likely won’t work well for users that you have little data on.

So, it’s quite possible that a ML model trained on a 3-way choice “very bad or bad/OK-ish/good or very good” won’t do much worse than on given the full 5-way choice.

I think it also is likely that users will be less likely to click on a question the more choices you give them (that certainly is the case if the number of choices gets very high as in having to separately rate a movie’s acting, scenery, plot, etc)

Combined, that may mean given users less choice leads to better recommendations.

I’m sure Netflix has looked at their data well and knows more about that, though.

Also, IMO, Apple’s pictograms look a lot better and are clearer. In Rectangle, the “left half” icon almost is a dark gray rectangle alongside a bright gray one, with the _dark_ indicating where tryout window will go. In Apple’s version, there is only one rectangle and the screen border is much easier to spot.

On the other hand, if a shock doesn’t release all energy it may come to rest in a relatively weak spot that will soon give away again (https://en.wikipedia.org/wiki/Earthquake_swarm: “The Matsushiro swarm lasted from 1965 to 1967 and generated about 1 million earthquakes. This swarm had the peculiarity of being sited just under a seismological observatory installed in 1947 in a decommissioned military tunnel. It began in August 1965 with three earthquakes too weak to be felt, but three months later, a hundred earthquakes could be felt daily. On 17 April 1966, the observatory counted 6,780 earthquakes, with 585 of them having a magnitude great enough to be felt, which means that an earthquake could be felt, on average, every two and a half minutes.”)

Because of that, I think an earthquake will increase the probability of one occurring again soon, but decrease its strength.

Compilers used to use its 80-bit floating point registers for 64-bit float computations, but also might spill them to memory as 64-bit float numbers.

https://hal.science/hal-00128124v3/file/floating-point.pdf section 3 has some examples, including one where the assert can fail in:

  int main (void) {
    double x = 0x1p-1022, y = 0x1p100, z;
    do_nothing(&y);
    z = x / y;
    if (z != 0) {
      do_nothing(&z);
      assert(z != 0);
    }
  }

  void do nothing (double *x) { }