Joe Rossignol (iOS/iPadOS release notes, no security, enterprise, no developer):
Apple today released iOS 26.6.2 with a fix for “an issue that prevents downloading a software update over a cellular connection.”
Previously:
Apple's iOS 26.6.2 update fixes downloading issues over cellular connections, ensuring smooth software updates.
(via Cult of Mac - Your source for the latest Apple news, rumors, analysis, reviews, how-tos and deals.)
Zac Hall (July):
Apple just updated TestFlight for iPhone, iPad, Mac, and more. The new version, 4.3, introduces “a search field to quickly find apps.”
But when Apple implemented this change, they also changed the sort order of the list of apps you’re registered to test. Starting with this update, the list is sorted in alphabetical order. For as long as I can remember — perhaps dating back to when TestFlight was a third-party utility — the list was ordered by recency. The most recently updated app was at the top; the oldest at the bottom. Sorting by recency is really the only sort order that makes sense when you’re registered for dozens (or more) of apps. For me, trying to see if there is an update to a new app whose name starts with U now requires scrolling through over 100 items.
[…]
Also, if I consider the broader view, this really speaks to how much we’ve lost in terms of UI vocabulary. For decades, any list of items with names and dates could be sorted by name or date, ascending or descending, through the standard use of clickable headers at the top of every list. This was true for almost any such list in any app, on any platform — Mac, Windows, Unix, Amiga, whatever. This was just basic GUI stuff.
[…]
iOS in 2007 introduced a simplified UI vocabulary that omitted many of these baseline GUI features. That seemed like a reasonable trade-off for a device with a 3.5-inch display and fat fingers as the only input device. But then iOS became popular and Apple stopped bringing the richer UI vocabulary of the Mac to iOS[…]
And it starting bringing iOS limitations to the Mac.
It certainly shouldn’t have taken until July 2026 to be able to search in TestFlight, either. And being able to search, and see the results sorted alphabetically, shouldn’t mean you can no longer view the full list sorted by recency.
Whatever is going on with this sort order, it isn’t affecting everyone. John Siracusa, amongst many others, has the same problem I do — his list is now alphabetical, and it’s driving him nuts too. Ryan Booker, amongst many others, still has his list sorted by recency.
John Gruber (September):
For both of us, yesterday’s v4.3.1 update fixes the bug.
But there should still be more sort options.
Previously:
Update (2026-09-16): John Voorhees:
Returning to reverse chronological order may seem like a small thing, but it’s made a world of difference in keeping up with the apps I test.
Search was near the top of my list of TestFlight wishes for years, and its addition made a meaningful difference to the app’s usability. But I’ve had a lot of TestFlight wishes over the years that are scattered across multiple articles, so I thought I’d share what else I’d like Apple to tackle with TestFlight[…]
Mark Gurman (tweet, John Gruber, Mastodon, 9To5Mac):
The Schiller exit is a bit more notable. Unlike Maestri, he still had a real job: The veteran executive ran the App Store and Apple Events. The App Store portion alone is no joke. It generates an estimated $30 billion a year and can be very challenging to manage. Apple’s app marketplace is loved by many consumers, but often criticized by developers and subjected to increasingly onerous regulations. It was a busy, all-encompassing gig and nowhere near a semiretirement.
[…]
But there’s a bit more to the story, I’m told. Ternus and services chief Eddy Cue want to make even more money from the App Store and figure out ways to raise margins and squeeze additional recurring revenue from the platform. Schiller, on the other hand, seems to believe that such moves will only further irk developers and governments. While there was no internal blowup or anything like that, it’s something he wanted no part of.
“Product guy” dreams about margins, forgets that people buy Apple hardware because of the software.
Apple admitted during its July earnings call that regulatory changes have started to weigh on its Services growth. Apple reported services revenue of $30.7 billion for the June quarter, a record for the period but short of the $31.4 billion that analysts expected.
The hardware guys treating third-party developers like they do their suppliers has stifled Apple’s software platforms
I thought that perhaps with the move to John Ternus as CEO, it could also be an obvious time to revisit such policies. But I hadn’t considered that Apple could actually be in favor of making them more onerous.
See also: Mario Guzmán and Indie Simulator.
Previously:
Apple is facing a £2 billion ($2.7 billion) London lawsuit brought on behalf of app developers over its app tracking rules, with the iPhone maker accused of abusing its power to unfairly impose greater restrictions on third parties.
[…]
Lawyers bringing the new lawsuit against Apple, though, say the feature imposed stricter requirements on third-party app developers than on Apple’s own services, giving its advertising ecosystem a competitive advantage.
Via Ben Lovejoy:
The latest lawsuit has an interesting twist: it’s being brought by Ann Pope, who was previously a senior official with the regulator behind today’s case.
The company told Reuters it was “bound by the exact same requirements as all developers.”
However, regulators across Europe including in France, Italy and Poland have investigated ATT. Germany’s competition regulator, the Federal Cartel Office, last month determined that Apple was favoring its own apps over those from external developers.
The EU is saying “you’re big enough that you have to treat your other business models like third parties” and Apple replies with “but we know we’re solid, so that makes no sense!”
Previously:
Apple has agreed to make changes to its App Tracking Transparency feature in Germany, according to the country’s competition regulator.
[…]
In Germany, Apple has agreed to remove “possibly discouraging symbols and wording” from the App Tracking Transparency prompt, the regulator said. Apps will also be “given more scope to explain to users what significance personalized advertising has for their offering and their business model,” and the “freedom to combine the consent request required by Apple with the consent requests required under data protection law.”
The FCO’s objection appears to be that Apple’s existing prompt is making app tracking sound scarier than it really is. The iPhone maker will make eight changes in order to address this – including removal of the word “track.”
The regulator helpfully offers an illustration of the differences between these prompts on the fourth page of its FAQs (PDF) about the case. There are many things they say could be deterrents in the App Tracking Transparency dialog, and I do not think Apple would deny that they are suggesting that users opt out of tracking. The definition of “tracking” Apple uses is self-serving, which would not matter so much if it did not also have a parallel desire to grow its advertising business.
[…]
A particularly damning finding in that comparison, to my eyes, is the way Apple puts “Ask App Not to Track” as the topmost button in the App Tracking Transparency dialog, but puts the option to “Turn Off Personalised Ads” at the bottom of it its own advertising prompt.
Previously:
Then, when you look at the sample code, it’s all SwiftUI. At least the sample compiles and runs because it uses a completely different syntax than what was shown at WWDC.
[…]
Eventually I stumbled upon TipUIPopoverViewController which inherits from UIViewController. That should work! […] But it didn’t: the close button on the popover didn’t work.
[…]
Until you realize that any changes you make are stored in a SQLite database, debugging is very confusing. It’s also easy for your own state to get out-of-sync with the Tip state: there is not a single source of truth.
[…]
Unfortunately, that sample code doesn’t scale well. If you have a view with multiple tips, you’re going to be littering your code with tip instances, observation tasks, and popover controllers. It’s a mess and a clear sign that the TipKit developers didn’t think much about UIKit.
In the previous article, we introduced the basic usage of TipKit. In this article, we will discuss some advanced topics related to TipKit, such as how to fully customize Tip views (not using TipView and popoverTip), how to use TipKit with UIKit, and how TipKit can share data across different applications, as well as how to reuse Tip declaration code. Additionally, we will attempt to address some common questions and concerns about TipKit.
Previously:
Independent podcast apps are not growing as a category. This is not a particular secret, but perhaps you haven’t seen it stated explicitly. It’s the sort of thing that has to be inferred, but there’s plenty of available data if you look for it. While the podcasting sector has seen growth, this has occurred almost entirely on platforms like YouTube, and the independent podcast app userbase has mostly just stood still.
[…]
I’m sure somewhere out there a 21-year-old just downloaded Castro or Pocket Casts for the first time and thinks RSS feeds are awesome (if you are this person, please email me). But every number I can see indicates the userbase is both static and aging. Every new customer I talk to has used some combination of Apple Podcasts, Overcast, Pocket Casts, or Castro for at least the last 5 years if not the last 10.
[…]
Perhaps there are healthy businesses that get very few new users but instead gracefully age with the ones they have. Ferrari maybe? Buddy, smartphone apps are not one of those businesses.
[…]
I would rather work on flashy features to capture new users, but, reality being what it is, I have to think about things in terms of both the health of the ecosystem and what will actually help retain existing podcast app users.
Anil Dash wrote, in 2014, that the simple phrase wherever you get your podcasts is a “radical statement”:
[…] Because what it represents is the triumph of exactly the kind of technology that’s supposed to be impossible: open, empowering tech that’s not owned by any one company, that can’t be controlled by any one company, and that allows people to have ownership over their work and their relationship with their audience.
Video podcasting changes that. In its simplest form, it is just a YouTube channel, which means it is siloed and controlled by Google. Spotify also supports video but only in its app.
So Marco described a problem. What if someone manually asks to download an episode when they already have three downloaded? You can’t just immediately delete it to keep things tidy. So what do you do? Marco added a special hidden “episode downloaded manually” flag to the database, so those episodes would not count towards the limit.
This is one more example of how even the most seemingly trivial features require thinking through and accounting for different cases that may not be obvious at first glance. Every user interface designer and product designer should collect and absorb examples like this.
[…]
Finally, Marco’s wife Tiff suggests a solution to all the problems: just don’t let users download more episodes, she said, and show them a message, roughly: “Your episode limit is three, but this would be the fourth, denied”.
Marco liked the solution. I didn’t. Sure, it solves Marco’s problems, but not the user’s.
Birman presents this as “Let me click,” but I wanted to offer two alternative/complementary principles that helped me before:
- Let me do things in any order. Here’s Google Home app, where I can change the temperature and the time for holding – but if I change the time first, it frustratingly resets when I subsequently change the temperature. It forces one specific order in an interface that suggests any order is okay[…]
- The current action has the most momentum. The user is right there, active, tapping on things, wanting to get stuff done. If Overcast indeed throws a “your episode limit is three” message, then it forces the user to remember how to get to the settings and change it. The momentum is lost. The decisions of past me should not be as important as the decisions of present me.
FWIW, the entire strict-limit feature is gone in the pending update (awaiting App Store review). EVERYONE hated it.
Now I’m just displaying the added-manually status in the UI and allowing it to be toggled manually in the “…” menu.
I’ve needed to evolve my expectations for what my role in Overcast is.
After building up a large, passionate userbase over a very long time, it’s not really entirely mine anymore. I can’t just do whatever I want with it.
And the growth era of open/RSS/indie/whatever podcast apps is over. The business is now about serving and retaining my existing customers for as long as possible.
So I can add things here and there, very carefully, but I can’t really change anything significant.
Previously:
Unforgetful isn’t a new productivity system to learn.
[…]
This is designed for a small number of short-term tasks. What do you need to do today, tomorrow, this week, or this month?
[…]
If you want tagging, folders, archives, or other ways to organize or file away tasks, this isn’t the app you’re looking for.
Unforgetful is for people who know that if they file away a task, it never gets done.
I’m an OmniFocus person. I love tagging, folders, and archives; I never want to see a notification for a to-do item. I prefer pull to push. So this is absolutely not the right tool for me. But I like the fresh thinking behind this app and how the various design choices interact to make it an opinionated tool for the right type of person.
Calendar alarms changed my life. Events without alarms don’t happen.
[…]
Most of my Reminders interaction has always been via Siri and notifications. And that fits me very well, with three major exceptions:
- If I say “Remind me to buy milk,” but I forget to specify a time (or Siri misses it), Reminders will never notify me, and I’ll never check the app, so it’ll be lost.
- If I inadvertently dismiss a Reminders notification without snoozing it, Reminders will never notify me about it again, so it’ll be lost.
- When I do snooze a Reminders notification, which I do a lot, the snooze options suck.
He has good solutions to these and other problems. I’m tempted to try out Unforgetful just for the purported quick capture of dictated reminders, however there’s no watch app.
Listen to Accidental Tech Podcast to hear about unfortunate limitations of EventKit. Reminders itself is interesting to me in that the (private) data model is now so rich, but I’m put off by the UI, the lack of export, and the limited support for driving it from the keyboard.
Previously:
After years of holding out, Walmart today announced that it will finally begin accepting tap-to-pay options like Apple Pay in some of its Walmart and Sam’s Club stores in the U.S. starting Monday, August 24. The retailer plans to roll out tap-to-pay support to all of its U.S. stores by the end of 2026 and to its gas stations by mid-2027.
Previously:
Apple Mail is the first app open every day and the one I find hardest to defend, and I’ve been defending it for twenty years (longer if you remember the original NeXT mail client).
The broader story is one of abandonment.
[…]
Apple deprecated that API, replaced it with a (much more restrictive) MailKit surface in 2021, and proceeded to lock MailKit down so hard that barely anyone shipped an extension.
[…]
In particular, in this age of desktop AI agents, I come time and again across the fact that AppleScript support in Mail has been left to rot.
[…]
And searching for messages is such a mockery of a user experience that I’m not even sure how to describe it[…]
The last email program I truly loved was Bare Bones’ Mailsmith.
[…]
Now, I’ve tried a lot, like, a lot, of “modern” email clients. The built-in Apple email client is extremely straightforward, but underpowered. Thunderbird is too lumbering and heavyweight for what I want. Hipster ones like Spark are pretty, but focus on things I don’t care about. Mimestream is solid, but it’s Gmail-only. Microsoft Outlook is, unfortunately, Microsoft Outlook. MailMate is nerdy and, in some ways, the most obvious spiritual descendant of Mailsmith, but I find some of its UX inscrutable. Yes, I am aware of the irony of saying this just before describing an Emacs-based client.
And increasingly, commercial email clients are expensive and/or subscription-only.
I almost never use Mail on iOS 26. I just tried to insert an image from my photo library, and I could not figure out how to get back to seeing a keyboard. What a bizarre workflow. Still shocked some of this stuff shipped.
I haven’t been able to use Mail on macOS since macOS 15.4. It hangs on launch if any accounts are enabled. It feels like it’s been so many years since I filed feedback with sample logs and still Apple hasn’t fixed the hang.
I wonder whether I will ever see a time where Mail clients report accurate unread counts (spoiler: clicking on Inbox shows no new mall)
Well, I guess most other mail clients, Thunderbird or Outlook, get this right. But it never worked in any of the Apple mail clients. Like for decades now 🙃
Rishi Ó summarizes the promises for Mail later this year:
Improved Top Results
More reliable search indexing
Improved unread badge accuracy
Improved list formatting
iOS 27 has an overhauled search system that extends to the Mail app. Instead of surfacing results based on keywords and recency, Mail app search ranks results by relevance and intent.
I never found the problem to be relevance ranking but rather that it simply didn’t find certain messages at all.
Long press on any email and you can ask Siri to summarize, find an item in the email, track a package, get a flight number, save a photo, and more.
I guess that’s fine, but as Carmo notes there’s just a whole list of basics that need attention in iOS Mail.
Messages in Mail load faster, search indexing is more reliable, and unread badges between platforms like iOS and macOS sync more reliably.
Mail search is still garbage in iOS 27. 😞 It’s just not better like they claim.
Previously:
Apple (developer, details, Hacker News, TechCrunch, The Verge, 9To5Mac):
These changes resolve Apple’s disagreements with the Commission over business terms and alternative distribution. They also reduce complexity by moving every developer that distributes apps in the EU to a single set of business terms.
[…]
The Core Technology Fee, a per-install fee for developers that achieve extraordinary scale, will be replaced by the Core Technology Commission, a simple 5 percent commission on digital transactions in apps distributed outside the App Store. The new terms also eliminate the initial acquisition fee and store services fee.
[…]
Under the updated terms, developers can now offer Apple In-App Purchase alongside alternative payment options, which had not previously been permitted in the EU.
[…]
Apple is also expanding who is eligible to operate an alternative app marketplace or distribute apps via the web in the EU.
[…]
Apple will continue to require every alternatively distributed app to go through Notarization[…]
Apple will charge a 26% fee for apps distributed through the App Store that use in-app purchase.
[…]
Apps in the App Store that use in-app alternative payment processing will pay 20%.
[…]
Apps that link to a website purchase option will pay 15%.
Apps using Web Distribution or App Marketplaces would pay the 5% CTC (and report transactions). I like that the new terms are simpler and that the fees are slightly lower, but it seems like the EU got tricked or surrendered here.
This is bonkers, I can’t believe the EU Commission agreed to it. The main issue that the DMA was about still remains: Apple retains ultimate control over app developers’ dealings with users.
The status quo that the EU should have pushed for, and which Article 6(7) of the DMA requires, is one where a developer can distribute iOS apps to users without ever entering into any contractual relationship with Apple.
All in all, still extremely anti-consumer. If I can download and run arbitrary code on my Mac--even if I have to jump through scary warnings--why should I not be able to do so on my phone? Why would one computing platform be different from the other?
However, while Apple hopes it will be allowed to charge these lower commissions, it has admitted in a new regulatory filing that it may not be allowed to charge any commission at all on purchases made through third-party app stores and other external platforms.
The commission Apple earns from the App Store is shrinking in markets where it has been forced to relax its grip on in-app purchases, based on new analytics data.
Previously:
Update (2026-08-20): M.G. Siegler:
Notably, this isn’t a proposal, it’s the announcement of actual changes that Apple will implement (starting October 1) after “close collaboration” with the EC. And lest we think Apple is overplaying that last aspect, that group gave a statement to Bloomberg backing up the assertion[…]
[…]
This feels like mainly a way to keep the all-important big gaming fees – which make up most of in-app payments, and as such, most App Store fees – mostly intact.
[…]
It sure looks like Apple knew this EU deal was coming down the pike and that the bloc agreeing to their terms would bolster the case that these are “fair”. The US judge still gets to decide that, and Epic has already pushed back as Apple seeks to negotiate directly. One big reason for pushing? Epic wants to ensure any changes Apple tries to negotiate be put in place for all developers.
The European Commission has since confirmed that it approves of Apple’s changes to its App Store policies, giving a statement to the Irish Independent[…]
Epic Games, a longstanding critic of Apple’s App Store practices, called the scheme “junk fees,” adding that the plan did “nothing to open up the mobile app ecosystem to competition, as required by Digital Markets Act.”
“The law makes it clear that Apple must allow developers to offer link outs to the web for purchases ‘free of charge’ and has to allow ‘effective use’ of competing stores,” the company wrote.
This changes effectively nothing I care about and continues to be completely laughable.
Apple still in complete control over what is allowed in any iOS app.
It’s so weird to me that the regulation that is explicitly against gatekeepers still allows Apple to be the gatekeeper.
I hope this isn’t the end of DMA. Apple taking a cut of out-of-store apps revenue makes as much sense as app developers taking a cut of iPhone revenue.
[…]
And also I still want to live in a world where anyone can write a program and run it on the devices they own and send it to friends, without having to pay $100/year of developer account and do the whole notarization thing (which considering the amount of scam in the app store we know is pretty useless in terms of security). Not everybody is a professional programmer, some people are just doing programming as a hobby, some are also young people that don’t even own a credit card yet.
I have refused to sign any of Apple’s EU DMA agreements thus far, because I think they are illegal, and they have been optional.
I still think their new terms are illegal — they don’t meet the minimum requirements of the DMA, and will not be approved by stakeholders — but they are no longer optional, so the choice now becomes accept the updated developer agreement or stop being a developer.
Update (2026-08-21): John Gruber:
This is a near-total victory for Apple.
[…]
Thanks to the DMA’s sprawling scope, complexity, and overreach, Apple came out of this conceding only 4 percent of the App Store’s 30 percent commission, and no reduction at all to the 15 percent for subscriptions after the first year.
Update (2026-08-24): Jesper:
The CTC is preferable to the CTF in much the same way that a fire burning down your kitchen is preferable to a fire burning down your entire house.
[…]
The Digital Markets Act was introduced to ensure that sideloading would be an available alternative, to essentially force open platforms that have been closed. Debates about the wisdom of this notwithstanding, in the biggest case, and up until recent developments in Android app marketplace governance also only case, it has failed to deliver the promises that were the entire point of the law.
Update (2026-08-25): John Gruber (Mastodon):
I’m sure some of you think I’m all wet in my argument that the point of the DMA was merely to impose ongoing bureaucratic complexity. But my view jibes with the reality of how it’s worked out.
In other words, maybe we who had high hopes were the ones who got tricked, not the EU Commission.
Update (2026-08-28): John Gruber:
I don’t recall seeing POSIWID before, but I love the concept. A friend sent this to me, with the quip that I forgot to include a link to it in my “What Is the Point of the DMA?” piece this week. Indeed, it encapsulates my arguments about the DMA specifically and the European Commission generally. The purpose of the DMA is what it does, not what you imagine it is intended to do.
I admit to being primed by seeing Jeff Johnson’s post, but I’m certain that my mind would anyway have immediately gone to our favorite scam promoting toll booth, the place that “gives people around the world a safe and trusted place to discover apps that meet [Apple’s] high standards for privacy, security, and content.”
Also consider which apps have to pay the toll and which ones show their own ads for free.
Joe Rossignol (iOS/iPadOS release notes, security, no enterprise, no developer):
Apple today released iOS 26.6.1, iPadOS 26.6.1, visionOS 26.6.1, and macOS 26.6.2, with all of the updates containing security fixes.
Apple also released iOS 18.7.10 and iPadOS 18.7.10 with security fixes.
The version numbers are now out of sync with macOS because macOS 26.6.1 fixed an important screen sharing vulnerability a few weeks ago.
There are fixes for an audio vulnerability that could allow an app to leak sensitive user information, an image vulnerability that could allow for arbitrary code execution, a trio of kernel vulnerabilities, and several WebKit bugs that could cause memory corruption or Safari crashes. Of the 29 CVEs outlined in the document, 21 are WebKit-related, and nine are credited to OpenAI Codex Security.
On iOS, Apple also fixed a telephony bug that could allow an attacker in a privileged network position to bypass IPSec authentication and intercept network traffic.
Previously:
Apple has again failed to earn a stay for fee calculations in its ongoing legal fight with Epic Games. Apple's case will be heard by the Supreme Court in the term that begins in October, and Apple asked the U.S. District Court for the Northern District of California to pause proceedings until then, but the court said no [PDF].
U.S. Supreme Court Justice Elena Kagan today granted Apple a one-day stay in its legal fight with Epic Games, giving Apple more time to outline the fees it wants to charge developers for linking out to purchase options on the web.
Apple tried to freeze the entire thing while they appealed to the Supreme Court – and the Supreme Court denied the freeze. But they didn’t deny hearing the case – yet. That’s why they’re pausing the proceedings for now (after Judge Gonzalez Rogers denied the same request), while they weigh Apple’s appeal. But before they do that, they’re basically likely to decide today – again, it was just a 24-hour delay – whether they should grant a longer stay. Presumably if the court thinks they’re unlikely to hear Apple’s appeal, they may not grant that longer stay. Or if they think Apple filing their number won’t harm their business, they’ll let it proceed. But Apple will argue that if the longer stay isn’t granted, it will cause major harm to their business because again, it will effectively end the App Store cut as we know it.
Juli Clover (Engadget, The Verge):
Apple today submitted a court-ordered proposal outlining the commission it believes is reasonable to collect from U.S. apps that link to purchase options outside of the App Store.
Apple is asking for half of its commission on standard apps, so apps that would pay 30 percent for an in-app purchase would pay 15 percent when linking to a web purchase option. Small Business Program participants that would normally pay 15 percent would pay 5 percent.
[…]
The appeals court suggested the commission could be limited to the direct costs of facilitating link-outs, and under that approach, the fee would be zero. Apple says a zero commission would not reflect the value that it provides developers, and its suggested commission gives it fair compensation for the App Store platform.
[…]
The district court will now evaluate Apple’s fee proposal and hear a response from Epic Games , and Apple will need to implement the fee the court sets.
Unlike cost-only based commissions, Apple’s revenue-based commissions incentivize continued investment. Apple charges developers a $99 annual fee for the Apple Developer Program. May 17, 2021 Trial Tr. at 2762:21–2763:13. This modest fee—designed to prevent fraud and expressly not intended to compensate Apple for the use of its IP-protected tools, technologies, and services (id.)—allows developers to build apps using Apple’s offerings and deliver experiences to iOS and iPadOS users worldwide.
The annual developer fee is nominal. Apple relies on percentage-based commissions to recoup and profit from its investments. See id. ¶¶ 87–93. Apple is incentivized to invest in IP- protected tools, technologies, and services that generate revenue for developers (and benefit users).
[…]
Dr. Carlton explains that “reduc[ing] Apple’s incentive to invest and provide the technology and services that benefit users and developers” would harm users and developers, as well as Apple.
I like the part where Apple’s expert argues that its normal commission rates are so high that it would still be profitable for developers to pay the proposed linking commissions on top of what they would pay to Stripe or Paddle. In other words, paying Apple for “IP” almost twice what it admits the other companies charge for “full-service, turnkey payment processing.”
If the point [of the $99] is just to prevent fraud, why do we need to keep paying $99 yearly FOREVER? Is 10 years not enough to prove I’m not a fraud?!?
If the fee doesn’t help pay for Apple IP, then it’s even more blatantly unfair that a minority of apps have to pay for ALL apps to access Apple IP. Free apps, no matter how big or how much $ they make via ads, get access to Apple IP from OUR REVENUE CUT, and not even their $99 counts.
That’s what that enormous hardware margin from customers is already supposed to be paying for — Apple IP! In the early 00’s, I gladly paid the “Apple tax” (PowerBook G4) to get access to the Mac OS X software/ecosystem, including all the Unix and dev tools. I’m not sure why anyone thinks that double-dipping is fine on all the non-Mac platforms, App Store or not.
Jeff Johnson (2):
Schiller’s [previous] testimony about the previous program is extremely misleading, because the new program began in 2008 at the same time as the App Store, so there was no previous iOS developer program, and Mac Developer ID did not begin until 2012, so Apple Developer Program membership was not actually required to distribute Mac apps!
Fourth, it appears that Steve Jobs was wrong: the $99 fee didn’t prevent developers from flooding the App Store with a lot of junk.
I want to quote another remarkable passage from Schiller’s testimony, again with questions from Apple’s own lawyer.
Q. And Mr. Jobs says, “And also just to make it a little clearer, we don’t intend to make money off the App Store. I mean, we don’t make a lot of money off iTunes, and the split with the music companies is about the same, so in the case of the iTunes Music Store, we give all the money to the content owners, and we are basically giving all the money to the developers here. And if that 30 percent of it pays for running the store, well, that will be great, but we just want to create a very efficient channel for these developers to reach every single iPhone user.” Is that a statement that Mr. Jobs made back in March 2008?
A. He did.
[…]
I won’t quote the following passage in which Schiller testifies about his internal email suggesting that Apple limit itself to $1 billion per year in profit from the App Store, hand-waving away the suggestion as merely “spurring conversation.” Of course the email also seems to contradict Schiller’s (absurd) testimony that Apple does not specifically calculate profit from the App Store, only company-wide profit. Apple’s public financial statements also appear to contradict Schiller’s claims.
Previously:
Update (2026-08-20): Marcus Mendes:
On the same day, Apple submitted another motion, asking Judge Gonzalez Rogers to order the parties to attend a settlement conference.
[…]
Epic has now responded to Apple’s motion, stating that although the company “has been, and remains today, willing to entertain any direct approach from Apple with a serious settlement proposal that would introduce competition and benefit all developers,” it “does not believe the prospects of such settlement would be meaningfully advanced through referral to a settlement conference at this juncture.”
Update (2026-09-03): Marcus Mendes:
In addition to the proposal itself, Apple submitted supporting expert reports, alongside a request to seal portions of those filings containing financial data, link-out adoption estimates, developer survey results, and other information Apple considers commercially sensitive.
Epic has now filed an opposition to Apple’s request, arguing “Apple again seeks to conceal information from the public and unnecessarily hamper proceedings.”
Lily Hay Newman (via Ben Lovejoy):
As AI models gain advanced capabilities to find vulnerabilities in software, develop ways to exploit them, and even carry out autonomous hacking sprees, researchers offered a sobering new example on Tuesday, disclosing vulnerabilities in the video conferencing platform Zoom that could have been exploited to take over targets’ devices. Anyone on a call that involved screen sharing, whether participants or the host, would have been vulnerable to a silent attack that could be carried out with no indication and no interaction from the victim.
Researchers from the digital defense firm A Security say the bug was discovered in early June using publicly available AI models, and that it took fewer than 20 prompts to uncover the vulnerabilities and create a working attack. Zoom issued a security advisory on Tuesday, including details about fixes the company has already begun rolling out to address the flaws, which affected devices running all operating systems that Zoom supports—Windows, macOS, Linux, iOS, and Android.
[…]
The vulnerabilities were specifically in the protocol used to facilitate real-time annotation during screen sharing.
I don’t understand how it could take over an iOS device when Zoom’s iOS screen sharing feature only allows observation, not control.
Previously:
Despite my history of uncovering App Store frauds, I rarely go looking for these things intentionally! They’re just so pervasive and obvious, they jump out at me. In this case, I was looking at the list of top paid Safari extensions in the Mac App Store, because two of my own extensions are currently on the list, when I noticed the TabControl Extension.
[…]
The Mac App Store “screenshot” for the app is not actually a screenshot at all. If you look closely, that’s not the real Safari: the toolbar elements are wrong. I suspect that the image was AI-generated.
[…]
Another thing you should note in the fake screenshot is the “4.9 out of 5” stars, giving the impression that this is the App Store user rating of the app.
[…]
These purported reviews, all but one of which is 5 stars, are all in English. Yet none of them is in the US App Store. […] If you’ve ever looked through App Store user reviews, it’s unusual to find this naming format. […] the dates on the reviews, such as “Mar 12,” predate the release of TabControl Extension in the App Store!
God only knows what this obvious AI slop scam is doing with the data from users’ Safari tabs. It’s currently the 12th or 13th most popular Safari extension in the App Store.
Coincidentally, on the same day well-known developer Marco Arment complained on social media that his new, unreleased Mac App Store app had been waiting 12 days for review by Apple.
Arment ended up waiting on hold—listening to an odd choice of music—to talk to App Review, which I didn’t realize was an option. His Unforgetful app is now approved.
Johnson continued browsing Safari extensions in the store:
The apps’s privacy policy is again on Google Drive, but the developer website link goes to
https://aee5e5015.app-ads-txt.com, a suspicious URL. This website is barren and simply redirects back to the App Store[…] Did App Store review ever bother to click the developer website link?[…]
In addition to the 41 apps, each of which required at least one submission to App Store review, I count across those 41 apps at least 327 updates, almost all of which have the same generic description for what’s new in the update: "Bug fixes and performance improvements." So that’s at least 368 submissions to App Store review, most within the past 12 months, from a single developer. In other words, the developer is averaging almost one submission per day. We can count only approved submissions; we have no idea how many submissions by the developer were privately rejected by App Store review.
I get the impression that Apple is asleep at the wheel. Is anyone at Apple counting submissions per developer? How many is too many? How many resources is one developer allowed to consume?
[…]
You may view it as a noble, democratic ideal to treat every app developer the same, but in reality this is the path to the crApp Store, full of scams and slop.
There’s no doubt that there is spam on the App Store, but the way to remove it is to target the spammers, not new developers, students, and hobbyists looking to build their ideas. I know that being an indie developer isn’t an easy way to make a living, but erecting barriers to submitting apps is the surest way to starve Apple platforms of fresh, innovative ideas.
I’d like to see App Store spam cleaned up as much as anyone, but the way to do it isn’t preferring well-known developers and those who can afford to pay more for special treatment.
I don’t agree with paid tiers either. However it feels like there should be a natural brake applied to new developers and new apps. It’s no big deal if your first app takes a week or two to review (often did 10y ago), and as it matures & receives meaningful updates in the store, turnaround increases as trust and “value” (active users?) builds up. Like “tarpitting” new accounts. I think limiting the # of new apps you can add per month to say 1 or 2 would also help…
I was a new App Store developer myself ten years ago. My previous article didn’t propose any new barriers for those groups. To be clear, I did imply that no developer, whether new or not, should have more than 40 apps and average a new App Store submission every day of the year. I’m not aware of any prominent developer who has that many. Apparently, checking just now, Microsoft by my count has 38 App Store apps between iOS and Mac, which is a lot but still less than the 41 apps of the developer I discussed in my previous article who is definitely not one of the largest software developers in the world along with Microsoft. I do think it’s reasonable for Microsoft to pay a significantly higher developer fee to have those 38 apps reviewed than a smaller developer pays to have one app reviewed by Apple.
[…]
My contention is that Apple is actually wasting its own resources treating every developer like a potential spammer or scammer, even the developers who are known to be trustworthy, and this wasting of resources makes it harder on everyone, including new developers, students, and hobbyists. App review is grossly inefficient, and it’s clearly failing to scale to the increase in App Store submissions. What I propose is not raising the gates but rather lowering the gates for developers who have already proven trustworthy, so that Apple can focus its review efforts where they’re most needed.
I’m not sure that paying more would help anything. If scams are profitable, surely it would be worth them paying more, and then we’re back to square one. And I don’t want to create another situation like App Store Search Ads where providing poor service makes the revenue numbers go up. But I like the general idea of considering the account’s history, e.g. the way the Discourse forum gradually increases trust over time. It should count for something if you have a long history of following the rules and submitting updates to a small number of apps on a reasonable schedule vs. frequent spamming of submissions that don’t even have real release notes. It would not be fair for Microsoft to be able to cut in line, but giving spammers equal access to the review queue means they’ll use more than their share of Apple’s resources. That also seems unfair. The current system encourages frequent submissions, which also increases the overall load on the reviewers. I think the incentives need to be changed somehow. Maybe each account should get a certain number of “fast” submissions per month or year, after which you can still submit but it goes into a lower priority queue.
Even among more legitimate-seeming apps, though, Apple is ignoring clear problems. In AppleInsider research, for instance, we found that many price tiers listed for the “Simply Piano” app bore no relation to what the developer actually charges.
[…]
You shouldn’t have to be the one to investigate apps you want to try. That is the future of third-party App Stores, and that is a future to be fought.
But that future is here with the first-party App Store we already have. And this inability to trust an App Store is here, right now, because Apple will not do what it keeps saying it is doing and what it is charging developers to do.
Previously:
Update (2026-08-20): Eric deRuiter:
I wonder if there is already a separate queue, not for Marco or other established indies, but for the huge companies: Facebook, Spotify, Google, etc.
Apparently the App Store developer in question saw my article in the news, because the fake App Store reviews posted on the developer’s website were quickly removed, as reported by AppleInsider and confirmed by me. Until yesterday, the misleading “4.9 out of 5 stars” claim remained in the App Store. However, the developer released an update only hours ago with new screenshots that no longer include the misleading claim, thereby erasing all evidence of the previous fraud. Apple approved the developer’s update and, needless to say, did not remove the app from the App Store.
[…]
There are 59 reviews [of Authenticator ℠], 54 of which are 1 star, and 3 of which are 2 stars. Two of the reviews are 5 stars; of those, one is titled “space jam” and goes on to say, “i believe i can fly and touch the sky.” Anyway, the question is, how did the app manage ratings of 4.1 out of 5 when the reviews average 1.2 out of 5? (That’s a rhetorical question. I think we all know the answer.)
Many of these outages were caused by a single bug, deep in SQLite. It took months of intense forensics to track it down.
[…]
This lack of reliable trigger conditions meant we couldn’t reproduce the bug synthetically. Instead, we had to rely on deploying passive, forensic telemetry in our live environment to catch the corruption red-handed. Gathering live diagnostics for a database issue is the last thing we wanted to do, but we had no choice.
[…]
As an additional complication, the corruption didn’t occur on a regular schedule. Sometimes incidents would be hours apart, other times weeks. This made it difficult to predict progress or plan further work, because we were never sure when we’d get our next diagnostic dump. We had a six-week period between October and December when there were no corruption incidents, before they returned as an unwelcome Christmas present.
[…]
In two incidents, our transaction logs failed to replay cleanly. Upon closer inspection, we discovered that data written and committed by one transaction was inexplicably invisible to later transactions. A write had vanished into thin air without raising an error.
The bug is likely present in all version of SQLite from 3.7.0 (2010-07-21) through 3.51.2 (2026-01-09). It is fixed in version 3.51.3 (2026-03-13) and later. Backports of the fix are available for some earlier releases: 3.44.6 and 3.50.7.
The bug only affects databases in WAL mode when there are two or more database connections open on the same file, in separate threads or processes, and when those two connections attempt to write or checkpoint at the same instant.
This investigation is a useful reminder: running boring technology in a non-standard way is a risk. The common paths and standard configurations are incredibly well-tested and reliable. Most people use SQLite in a standard configuration and never face this sort of issue. Everything we were doing was a public, documented, supported configuration—but by taking manual control of the checkpointing process and running at our own aggressive pace, we stepped off the well-trodden operational path.
I spent the last two years of my time working on SQLite trying to chase this bug down. It was so rare that I never got an internal report; my assessment of the number of customers affected was “about a county’s worth”, some of whom were generous enough to allow their local Genius Bar to send me backups of the affected databases. I spent so many hours in a hex editor staring at the wreckage.
Top three data corruption bug of my career for sure, and the other two weren’t bugs in SQLite.
A former Tailscale employee got in touch and shared that they were checkpointing these databases every 250ms. Multiplied across a fleet of servers that is a fantastic way to surface a super rare bug—they basically built our test rack as a product, but two orders of magnitude more effective (partially due to scale, but mostly because our rack also panics devices at random in order to test the filesystem, NAND controller, etc. and rebooting takes a while)
[…]
13/10 fantastic bug. proof that 100% test coverage is a good start, and that formal methods are needed for critical applications.
I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 – still buggy – set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see the instrumented version here.
Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently – things you’d expect to actually happen in production, all the time. The assertions are also generic to the bug, they’re all standard assertions you’d add to any database, things like “no lost committed writes” and “database is not corrupt” (called integrity check in sqlite).
On my first run, Antithesis caught the bug in 15 mins. Here’s the report.
Of course, it helps that he knew to look in the checkpoint code, but you could imagine using tools like this to quickly investigate hypotheses when you don’t already know the answer.
Talal Haj Bakry and Tommy Mysk (Mastodon, Hacker News, MacRumors, Mac Power Users):
WebKit-based browsers on iOS and macOS can be configured to route all web traffic through proxy servers, which is how Tor browsers on iOS and our own Psylo work. We found three WebKit features — DNS prefetching, WebAuthn Related Origin Requests, and WebTransport — that bypass the configured proxy and send traffic directly from the device, which exposes the user’s real network. The same leaks also affect Apple’s iCloud Private Relay.
[…]
It must be noted that VPNs are not affected, since they tunnel the device’s entire network traffic at the system level.
[…]
We’ve addressed all three leaks in Psylo 1.3.1[…] Passkeys and WebTransport have legitimate uses, so both can be re-enabled at any time through per-silo toggles. This keeps Psylo leak-free out of the box, while users who need one of these features on a given site can opt in explicitly, with a clear understanding of the trade-off.
In an ideal world, we’d report the issues to Apple, they acknowledge the issue, and ship a fix in a timely manner. Unfortunately, our past experience with Apple tells us that reporting this issue would involve months of delays, inconsistent communication, and in some cases, denying the issue’s impact entirely.
We weren’t willing to wait months, or upwards of a year, sitting on bugs that undermine the core privacy guarantees of Psylo and iOS Tor browsers while saying or doing nothing.
[…]
Should we knowingly leave our users exposed while waiting for a system-level fix? We didn’t think that was acceptable or fair to our users. Or should we quietly ship our own mitigations without telling anyone? We didn’t think that was acceptable either. Security fixes deserve transparency, especially when they involve tradeoffs.
Soon after we published the blog, we sent a link to the blog and demo website to Apple in a security report to make them aware of it. Now the report is already in the status “We’re planning to address the issue you reported.” and a fix is planned for Fall 2026 🤯🤯🤯
Mysk:
It used to take months and months to reach this status. We got there in less than 24h
Running to the press always helps…
Previously:
Update (2026-08-11): Ben Lovejoy (MacRumors):
A class action lawsuit accusing Apple of false advertising, misrepresentation, and fraud has now been filed by Clarkson Law Firm – the same lawyers who previously obtained a $250M settlement over the delayed launch of Siri AI.
Login