Matt Burgess (MacRumors, ArsTechnica):

On Thursday, San Francisco city attorney David Chiu sent legal notices to Apple and Google demanding that they remove from their app stores 13 face-swapping apps, which allow users to create AI-generated nonconsensual nude images. The letters say the Silicon Valley giants should stop “aiding and abetting” the sale of explicit deepfake images and “sever” business relationships with the app developers.

[…]

Researchers have repeatedly found and reported apps in Apple’s App Store and Google’s Play Store that allow people to generate sexual images using AI—including some apps being rated as suitable for use by children. While new laws and bans aim to tackle the scourge of explicit deepfakes online, technology and social media companies consistently direct millions of people toward the harmful tech.

Both Apple and Google have developer policies that prohibit pornography, abuse, and harassment on their platforms.

Burgess gives the impression, which is my base assumption, that these 13 apps were clear about what they do, so App Review has no excuse for missing them. But I’m sure it’s keeping us all safe in other regards.

Meanwhile, in a preprint research paper published in May, researchers from Cornell University and Georgetown University identified 420 apps offering general face-swapping capabilities on Google’s and Apple’s app stores. They tested 155 to see if they could be used to create face swaps with nude images; in 70 percent of cases, it was possible, with the apps not including safety measures to prevent this.

Previously:

• Sirius Pomodoro
• Apps for YouTube℠™®•!
• Sanctioned Entities Slip Through App Store Controls

Update (2026-07-21): Danny Bradbury:

Chiu isn’t arguing that hosting an app automatically makes a platform liable for what it does. Platform operators already won that battle with Section 230 of the Communications Decency Act. That 30-year-old law says websites generally aren’t responsible for content posted by users, allowing platforms to host user-generated content without getting sued every time someone defames someone in a comment thread.

Courts have often extended those protections to cover app stores too. Apple and Google are treated as distributors of whatever a third-party developer uploads, rather than publishers.

Chiu is attempting to sidestep that argument by focusing on the companies’ payment systems, noting that Apple and Google collect a cut of every in-app purchase. According to the Tech Transparency Project (TTP), that means they profit from apps that generate revenue by creating non-consensual intimate imagery.

SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

• I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

• The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

• Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

• Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

• I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

• I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

• There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

• The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

• Xcode 27 Announced
• SpamSieve 3.3
• Swift Proposal: Precise Control Flags Over Compiler Warnings
• Swift at 10

Ed Hardy:

Finding useful software in the App Store is about to get easier. Apple is apparently preparing to remove what it describes as “opportunistic” apps that provide little value to iPhone and iPad users.

It already had a policy of not approving applications that are “indistinguishable from what’s already widely available.” This week, it quietly warned developers that it will start removing low-value software that doesn’t attract attention from users.

App Review Guidelines (News):

4.3 (b) Don’t submit apps that are indistinguishable from what’s already widely available. Opportunistically creating variants of existing app categories or popular apps degrades App Store discovery, reduces overall app quality, and harms both users and developers. Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience. We may remove these apps from the App Store going forward if they are not updated, improved, or do not attract customers. Other kinds of apps, such as drinking games, Kama Sutra, fart, and burp apps, are mediocre, low-quality, or low-effort and do not add value to the App Store. Repeated submissions of this kind may lead to removal from the Apple Developer Program.

Previously:

• Updates to Vibe Coding Apps Rejected From the App Store
• Apple’s Explanation for Removing Old Apps
• App Store Removing Old Apps That Still Work
• Wordle Clones
• App Store Competition
• How to Game the App Store
• Removing Abandoned Apps and Shorter App Names
• Removing Unmaintained Apps from the App Store

Update (2026-07-14): Aleksandar Vacić:

Waiting for Review enters day 3. I don’t recall when was the last time this happened for any of the apps I am working for.

[…]

I sent messages to App Review Board and received nothing in response (so far).

It seems that if Apple ever removed your app from App Store for reason of “not sending regular updates” that app is…gone. It’s not deleted but it seems to dwell in some sort of limbo.

Previously:

• Mac App Store Review Times Increasing