Archive for December 18, 2025

Thursday, December 18, 2025

Japan: App Marketplaces, External Payments, New Fee Structure

Apple:

Apple today announced changes impacting iOS apps in Japan to comply with the Mobile Software Competition Act (MSCA). These updates create new options for developers to distribute apps on alternative app marketplaces and to process app payments for digital goods and services outside of Apple In-App Purchase.

[…]

The MSCA’s requirements for alternative app marketplaces and app payments open new avenues for malware, fraud and scams, and privacy and security risks.

They just couldn’t help themselves.

For their iOS apps distributed on the App Store in Japan, developers will be able to include an alternative payment processing method in their app and/or link users to a website to complete a transaction.

These alternative payment options will always be presented alongside Apple In-App Purchase, so that users in Japan are clear on when they are transacting through Apple.

Juli Clover:

Apple has established a new fee structure in Japan, and fees are based on distribution and payment method. Apple says that fees will be the same or lower for 100% of developers in Japan.

Participants in the Small Business Program, Video Partner Program, and Mini Apps Partner Program will pay the reduced rate below. Subscriptions in apps maintained after the first year are also subjected to the lower fee. The Small Business Program includes developers that earn less than 1 million USD annually. Developers that earn more than that have to pay Apple's full commission rates.

  • App Store w/ In-App Purchase - Varies from 15% to 26%. 21% base fee, 5% payment processing fee. Base fee is 10% for program participants, and 5% fee remains the same.
  • App Store w/ Alt Purchase - Varies from 10% to 21%. 21% base fee, no payment processing fee. 10% for program participants.
  • App Store w/ Web Link - Varies from 10% to 15%. 15% Store Services Fee, 10% for program participants.
  • Alternative Marketplace - 5% Core Technology Commission.

Juli Clover:

iPhone and iPad users in Japan can download the alternative app marketplace from the AltStore website, and then use the AltStore to download apps without having to go through Apple’s App Store. Prospective AltStore users need to be physically located in Japan, and have a Japanese App Store account. Devices also need to be running iOS/iPadOS 26.2 or later.

Previously:

Update (2025-12-19): Malte Kirchner (via ednl):

On paper, many things look the same between Japan and the EU. But tone matters. The law passed in Japan in June 2024 relies more on dialogue than confrontation, is heard from Apple Park. The Japanese are concerned with data protection, security, and child protection for users. In Europe, they argue in Cupertino, the interests of a few large competitors are primarily being satisfied. This leads to a worse user experience and compromises in security, Apple is convinced.

What makes Apple conciliatory in Japan is likely the numerous exceptions and the bargaining chips that the company has there. Concerns about cybersecurity or child protection can override certain rules. For example, there are alternative app stores in Japan, but no complete sideloading. The requirements for interoperability also turn the European principle on its head: in Japan, this is available on request, while in Europe they want it "by design" – i.e., when new functions are launched. The European model is based on the fear that requests could be indefinitely postponed. Therefore, they want interoperability immediately. The Americans, on the other hand, see this as an obstacle to innovation and an expropriation of intellectual property, but also as a major security risk.

[…]

At least on the day of introduction, the Japanese conditions seem enviable from a European perspective. No threat of legal action, constructive discussions, and the regulator gets its functions, while new features are to be brought to Japan without delay – European customers undoubtedly wish for this too. However, it remains to be seen whether the situation in Japan will truly remain so harmonious and whether the law will prove to be a tame paper tiger if the regulated parties are too satisfied with it.

Batch Delete in SwiftData

Fatbobman:

SwiftData provides a batch deletion API that is more modern and type-safe than its Core Data counterpart.

[…]

Note: Unlike the standard single-object deletion modelContext.delete(_ model: T), batch deletion is only applied to the database after save() is executed.

Coming from Core Data, this is really strange. With Core Data, NSBatchUpdateRequest and the other batch operations are completely separate from saving the context. This makes sense because they operate directly on the database rather than on the in-memory objects that are owned by the context.

I’m trying to wrap my head around what SwiftData is even doing that batch deletions happen on save. Is it queuing up a bunch of SQL to be executed along with the save? Why would anyone want this?

Going by what the documentation literally says, with it taking place after the save, it sounds like it even reorders operations. If I do a batch delete, then insert some objects, then save, will it delete the new objects (if they match the predicate) even though I intended the insert to happen after clearing out the old objects? Or does executing the batch delete eagerly fetch the IDs of the objects to be deleted and then it deletes them by ID later (when the predicate might no longer match)?

Either way, it seems confusing in the event that there are multiple batch deletes in sequence. The first one might affect which objects match the predicate of the second one.

Although Swift 6 and iOS 26 have brought many improvements, as of now, SwiftData natively supports only batch deletion. It does not yet provide native APIs for Batch Update or Batch Insert.

Previously:

Extended Attributes Flags in Tahoe

Howard Oakley:

When first introduced in Mac OS X, no provision was made for xattrs to have type-specific preservation, and that was added later using flags suffixed to the xattr’s name. For example, the com.apple.lastuseddate xattr found commonly on edited files is shown with a full name of com.apple.lastuseddate#PS to assign the two flags P and S to it, and the most recent xattr com.apple.fileprovider.pinned, used to mark files in iCloud Drive that have been pinned, has the two flags P and X assigned to it for a the full name of com.apple.fileprovider.pinned#PX.

[…]

It’s further complicated by a set of system tables for some standard xattr types that don’t have flags suffixed, but are treated as if they do.

[…]

When using standard commands such as cp, macOS will automatically apply these rules when deciding whether to preserve xattrs. However, using a command for a different intent, such as cp for backing up, won’t normally invoke the behaviour you might want.

Code using standard macOS file operations should follow the behaviour expected for its intent, and shouldn’t require any special handling of xattrs. Lower-level operations are likely to differ, though, and may require implementation of equivalent behaviours.

The xattr_intent_with_flags() function will tell you, given an intent and a set of flags, whether you should preserve the xattr.

Previously:

Copyright © 2000–2025 Michael Tsai.