Archive for May 29, 2024

Wednesday, May 29, 2024

App Store Apps Can Be Translocated

Howard Oakley:

This article demonstrates that the last of those isn’t necessarily true, and what happens when an App Store app ends up being translocated.

The combination of an App Store app with a quarantine xattr is a particular problem for users, as those apps are installed direct to their intended final destination, and their permissions discourage the user from trying to move them from there. That combination therefore defaults to satisfying all three requirements for app translocation to occur, which it will every time that app is run.

Without using Terminal’s command tools or third-party utilities like xattred and Mints, there’s no way for the user to discover whether an App Store app has a quarantine xattr, nor to check whether the app is being translocated. As (almost?) all other App Store apps don’t have a quarantine xattr and aren’t translocated, the user is unlikely to suspect those might be occurring, and could account for problems with that App Store app. In this case, purchasing and using the App Store version of UTM puts the app and its user at significant disadvantage compared to obtaining the app direct.

It’s not clear to me how the App Store download got the quarantine attribute. My guess was that this could happen if you do a direct download, don’t move it to /Applications, and then the App Store updates it to a newer version. In other words, the quarantined app becomes the App Store version. But that doesn’t seem to be what happened here.

Howard Oakley:

When you run an iOS/iPadOS app on an M1 Mac, if it has been downloaded from the App Store (currently the only supported method, as sideloading is forbidden), it doesn’t have a quarantine flag. Not only that, but app translocation has only occurred with apps undergoing their first run: once that flag has been unset, further translocations don’t occur. Thus, under the original rules for app translocation, there’s no way that it should occur in this case.

I’m going to look in more detail at how macOS launches and runs iOS/iPadOS apps in future articles, but here I’ll show some relevant log entries which demonstrate what happens, including the translocation.

John Smith:

iOS apps are translocated on macOS because of the possibility of spaces in app names (and in “Group Containers”). Some iOS apps expect GUID-based names and may not properly escape spaces, hence the translocation, whose name has no spaces.


[Another]/related factor is that the user could rename the apps, which is something that isn’t allowed or accounted for when run on iOS.


CloudKit Throttles and Debugging


The CloudKit infrastructure is shared by all apps and services. The resources are finite, and so high utilization from one app can negatively affect others. To avoid this kind of impact and optimize the overall experience, CloudKit implements a number of limits and controls on incoming traffic, which are known as throttles.

CloudKit can enforce throttles when it deems necessary on any app or service that uses the CloudKit framework, CloudKit Web Services, CloudKit JS, NSPersistentCloudKitContainer, and NSUbiquitousKeyValueStore. This technote discusses how to identify CloudKit throttles with representative error messages and how to handle them.

It does not actually say what the limits are.

Howard Oakley:

I came to suspect that iCloud imposed quotas on its use nearly six years ago, when I was exploring the only command tool that provides any useful information about iCloud, brctl. When examining one of its dumps, I came across an entry for syncUpBudget referring to BRCSyncBudgetThrottle, and another item global sync up budget giving the budget available. As with almost everything in brctl and iCloud generally, there appeared to be no documentation of these.


Devices can also apply their own local system throttles in some circumstances; for example, when the device’s battery runs low, its system may well throttle CloudKit requests until the device has been recharged to a specific battery level. Those shouldn’t affect the syncing of other devices, though.


Perhaps the worst approach the user could then try is one of the solutions most commonly recommended: turning iCloud off and back on again, as it has no effect on the retry interval, and could trigger further throttling.

Howard Oakley:

Apple has recently confirmed that CloudKit databases can be throttled, which effectively blocks all access to them for requests for a set period of time. This isn’t a limitation in transfer rate in the way that iCloud Drive might experience, but an intentional denial of service until the retry interval has elapsed.


Apple currently imposes limits on the number of items that can be stored in shared databases and elsewhere in iCloud. These are given here for Contacts, Calendars, Reminders, Bookmarks and Maps, here for mailboxes and message size, and here for Shared Albums.

Throttling, as described by Apple, doesn’t make any sense in the context of iCloud Drive, as CloudKit doesn’t manage that, and no app is making requests of CloudKit in the process.

But iCloud Drive is built on CloudKit, which as Apple says is shared infrastructure. It’s not clear to me whether CloudKit will throttle one app due to high utilization from another app or system service (iCloud Drive, iCloud Photos).

Howard Oakley:

Stages in transfers with iCloud Drive are subject to throttling, although throttles appear to occur infrequently and only last a few hundred milliseconds.


For transfer and storage in iCloud, files are divided into chunks of just over 15,350 bytes in size, although the maximum chunk size imposed by the system is either 28,455,742 bytes (28 MB), or a fixed maximum of 33,554,432 bytes (33 MB).

Some iCloud servers may impose a connection.max.requests of 100, although others are unlimited.


Under the hood, NSPersistentCloudKitContainer separates the synchronization process into many tasks, and encapsulates all the implementation details. When performing a task, it generates logs, which are persisted as a part of a sysdiagnose. To understand what really happens in the process, which is sometimes necessary when diagnosing a synchronization issue, you need to look into a sysdiagnose.

This technote unveils some details inside the synchronization by analyzing a sysdiagnose, and provides some representative logs that can be used to identify some important tasks and their state.


A synchronization failure can happen because of a code-level issue in your data presentation layer, a configuration issue related to CloudKit, or a limit on the system side. To debug a synchronization issue, look into the system logs in Xcode console or a sysdiagnose, then identify the relevant errors. This technote describes how to identify and resolve common errors seen in the logs when working with NSPersistentCloudKitContainer.

Nikhil Nigade:

Yay! New weird CloudKit situation: The background notifications get delivered to the device, but not to the app unless it’s restarted

John Gordon:

5 hours later and is still stuck on “Syncing with iCloud”. I’ll let it run overnight but it’s not looking good.


Can Anyone But a Tech Giant Build the Next Big Thing?

Jason Snell (Mastodon):

I’m sad about the Ai Pin because it—and a similar AI hardware product, the Rabbit R1—shows just how much potential innovation is strangled by the presence of enormously powerful tech companies, most notably the Android-iPhone duopoly.


The problem is that I’m dismissing the Ai Pin and looking forward to the Apple Watch specifically because of the control Apple has over its platforms. Yes, the company’s entire business model is based on tightly integrating its hardware and software, and it allows devices like the Apple Watch to exist. But that focus on tight integration comes at a cost (to everyone but Apple, anyway): Nobody else can have the access Apple has.


It seems like we’re at the point where even the most groundbreaking hardware device simply can’t succeed in a world where it’s unable to deeply integrate with either the iPhone or Android. (And really, in the U.S. especially, it would need to integrate with both.) This is why the Ai Pin and the Rabbit and similar products are not going to succeed. Instead, Apple and Google will integrate everything that the Ai Pin does into iOS and Android, and those will be the best-in-class implementations, and that’ll be it for Humane and anyone else who wants to create an AI-powered hardware dingus.


I’m not making a legal argument here. (Which is good, because I am not a lawyer.) I’m just observing that the smartphone has become so central to life that if your product can’t offer deep connections to the smartphone, you’re stuck.

This is what I said at the Ai Pin’s unveiling. It should have been an app, but what it wants to do is not allowed for third-party apps. Apple and Google will integrate best-in-class implementations, but they’ll be best in the sense that no one can do better, not that no one could do better.

Jeff Johnson:

Three companies control all of the consumer OS market share on both mobile and desktop. Microsoft was founded in 1975, Apple in 1976, Google in 1998. We’re in a period of terrible tech stagnation.

Also, Apple acquired NeXT and Google acquired Android. Those weren’t home-grown technologies.

Steve Troughton-Smith:

Some simple categories of apps that can’t realistically exist on the iOS/iPadOS/visionOS App Store off the top of my head[…]


Many of Apple’s apps, like Playgrounds, simply could not be built by any third party developer.

John Gruber:

I would argue, strenuously, that the phone is the natural AI device. It already has: always-on networking, cameras, a screen, microphones, and speakers. Everyone owns one and almost everyone takes theirs with them almost everywhere they go.


I’ve been saying for a while that instead of “all phones should use USB-C” and “users should pick a web browser when setting up their phones”, “the Apple-Google duopoly must provide APIs that allow third parties to thrive” is the real thing the EU should’ve focused on.

For example, third-party headphones can’t integrate as well as AirPods, no matter how hard the vendor tries.


I’m still unconvinced it would be a good product. But I think Snell is right: Apple makes it so that Humane cannot make a good product.