Live Text and Visual Look Up are recent features in macOS, first appearing in Monterey nearly four years ago. As that immediately followed Apple’s short debacle over its now-abandoned intention to scan images for CSAM, most concerns have been over whether these features send details of images to Apple.

Although recent Intel Macs also support both these features, they don’t have the special hardware to accelerate them, so are far slower. For this walkthrough, I’ll only present information from Apple silicon Macs, in particular for the M4 Pro chip in a Mac mini.

Initiation

When an image is opened from disk, the VisionKit system starts up early, often within 0.1 second of it starting to open. Its initial goal is to segment the image according to its content, and identify whether there’s any part of it that could provide text. If there is, then Live Text is run first so you can select and use that as quickly as possible.

In the log, first mention of this comes from com.apple.VisionKit announcing
Setting DDTypes: All, [private]
Cancelling all requests: [private]
Signpost Begin: "VKImageAnalyzerProcessRequestEvent"

It then adds a request to Mad Interface, that’s the mediaanalysisd service, with a total method return time, and that’s processed with another signpost (a regular log entry rather than a Signpost):
Signpost Begin: "VisionKit MAD Parse Request"

com.apple.mediaanalysis receives that request
[MADServicePublic] Received on-demand image processing request (CVPixelBuffer) with MADRequestID
then runs that
Running task VCPMADServiceImageProcessingTask

This is run at a high Quality of Service of 25, termed userInitiated, for tasks the user needs to complete to be able to use an app, and is scheduled to run in the foreground. Next Espresso creates a plan for a neural network to perform segmentation analysis, and the Apple Neural Engine, ANE, is prepared to load and run that model. There’s then a long series of log entries posted for the ANE detailing its preparations. As this proceeds, segmentation may be adjusted and the model run repeatedly. This can involve CoreML, TextRecognition, Espresso and the ANE, which can appear in long series of log entries.

Text recognition

With segmentation analysis looking promising for the successful recognition of text in the image, LanguageModeling prepares its model by loading linguistic data, marked by com.apple.LanguageModeling reporting
Creating CompositeLanguageModel ([private]) for locale(s) ([private]): [private]
NgramModel: Loaded language model: [private]
and the appearance of com.apple.Lexicon. An n-gram is an ordered sequence of symbols, that could range from letters to whole words, and the lexicon depends on the language locales. In my case, two locales are used, en (generic English) and en_US (US English).

At this point, mediaanalysisd declares the VCPMADVIDocumentRecognitionTask is complete, and runs a VCPMADVIVisualSearchGatingTask, involving com.apple.triald, TRIClient, PegasusKit and Espresso again. Another neural network is loaded into the ANE, and is run until the VCPMADVIVisualSearchGatingTask is complete and text returned.

The next task is for the translationd service to perform any translations required. If that’s not needed, VisionKit reports
Translation Check completed with result: NO, [private]
These may be repeated with other image segments until all probable text has been discovered and recognised. At that stage, recognised text is fully accessible to the user.

Object recognition

Further image analysis is then undertaken on segments of interest, to support Visual Look Up. Successful completion of that phase is signalled in Preview by the addition of two small stars at the upper left of its ⓘ Info tool. That indicates objects of interest can be identified by clicking on that tool, and isn’t offered when only Live Text has been successful. VisionKit terms those small buttons Visual Search Hints, and remains paused until the user clicks on one.

Visual Search Hints

Clicking on a Visual Search Hint then engages the LookupViewService, and changes the state from Configured to Searching. VisionKit records another
Signpost Begin: "VisionKit MAD VisualSearch Request"
and submits a request to MAD for image processing to be performed. If necessary, the kernel then brings all P cores online in preparation, and the ANE is put to work with a new model.

PegasusKit then makes the first off-device connection for assistance in visual search:
Querying https: // api-glb-aeus2a.smoot.apple.com/apple.parsec.visualsearch.v2.VisualSearch/VisualSearch with request (requestId: [UUID]) : (headers: ["grpc-message-type": "apple.parsec.visualsearch.v2.VisualSearchRequest", "Content-Type": "application/grpc+proto", "grpc-encoding": "gzip", "grpc-accept-encoding": "gzip", "X-Apple-RequestId": "[UUID]", "grpc-timeout": "10S", "User-Agent": "PegasusKit/1 (Mac16,11; macOS 15.6 24G84) visualintelligence/1"]) [private]

When the visual search task completes, information is displayed about the object of interest in a floating window. Visual Look Up is then complete, and in the absence of any further demands, the ANE may be shut down to conserve energy, and any inactive CPU cluster likewise:
ANE0: power_off_hardware: Powering off... done
PE_cpu_power_disable>turning off power to cluster 2

Key points

• Image analysis starts shortly after the image is loaded.
• Central components are VisionKit and mediaanalysisd, MAD.
• In Apple silicon Macs, extensive use is made of the Apple Neural Engine throughout, for neural network modelling.
• Most if not all is run at high QoS of 25 and in the foreground, for performance.
• Segmentation analysis identifies areas that might contain recoverable text.
• Segments are then analysed, using language modelling for appropriate locales and languages, and lexicons, to return words rather than fragmented characters.
• When Live Text is ready, segments are then analysed for recognisable objects. When that’s complete, each is marked by a Visual Search Hint.
• Clicking on a Visual Search Hint initiates a network connection to provide information about that object, displayed in a floating window.

With the next scheduled update to macOS Sequoia likely to be released in September or October, macOS 15.6 officially marks the end of its year-long cycle of full support. This article looks at its updates and how it has changed.

Updates

It took Sequoia a total of 11 updates to reach version 15.6 at the end of July, including five unscheduled patch updates, which is close to average. Prominent through those updates has been the number of security vulnerabilities addressed, peaking at 81 in 15.6.

In terms of cumulative size of updates, Sequoia was close to average at a total of 27.5 GB for Apple silicon Macs and 19.3 GB for Intel models. Although not as bad as Big Sur which took over 50 GB for Apple silicon Macs, it wasn’t as good as Sonoma at just over 21 GB. Update size was relatively small up to 15.3, but added over 9 GB in the three updates it took to reach 15.4. Apple doesn’t appear to have made progress in reducing the size of updates for Apple silicon Macs, and that may not be achieved until macOS 27 next year, when Intel support is finally dropped.

Bundled apps

The total number of bundled apps has increased slightly, from 60 in Sonoma to 62 in 15.0, and 64 in 15.6. That’s set to rise again in Tahoe, with the addition of Journal and Phone.

/System/Library

The total number of bundles in /System/Library has risen further to reach 9,304, almost double the number in 10.14.5 six years ago, and up from 8,392 a year ago in 14.6. Unusually, this has risen by nearly 300 through Sequoia’s cycle. Previously it has been more common for only small rises to occur during a cycle, and in macOS 13 the total fell slightly.

Over that period, the main growth has been in the number of Private Frameworks, which have risen from about 1,760 in 10.14 to over 4,400 in 15.6. Public Frameworks have risen less, from less than 520 to 806. Despite Apple’s campaign for third-parties to move away from kernel extensions, those in macOS also continue to grow, rising from a minimum of 515 in 10.15.0 to 939 in 15.6. Sequoia has added 39 of those in going from 15.0 to 15.6.

This is a more detailed breakdown by category of bundles in /System/Library, comparing 10.15.6 with 15.6:

• Accessibility, a small increase from 125 to 161
• Automator, a small reduction from 266 to 252
• Templates, a marked reduction from 383 to 252
• CoreServices, a small reduction from 390 to 363
• AssetsV2, a substantial growth from 188 to 806
• Public Frameworks, a modest increase from 600 to 806
• Kernel extensions, a substantial increase from 534 to 939
• Private Frameworks, a huge increase from 2,055 to 4,407.

Five years ago in 10.15.6, public Frameworks were almost a quarter of all Frameworks. In 15.6, they are less than 18%. macOS continues to become an increasingly private operating system supporting Apple’s apps, not those of third party developers.

We’re now into August, Apple has released the last substantial updates to macOS before the arrival of Tahoe, so where does macOS stand now?

macOS Sequoia has just had its last scheduled update to 15.6 before it’s expected to enter the first of its two years of security-only updates. The main benefits of this update are an important fix to restoring Macs in DFU mode using either the Finder or Apple Configurator, and its long list of security updates, 81 vulnerabilities in total. If you’re already running Sequoia, it’s an important update.

Sequoia is fully supported on the following Macs:

• iMac 2019, all T2 iMacs including iMac Pro from 2017
• MacBook Air 2020 and later, but not 2018 or 2019
• MacBook Pro 2018 and later (all T2 models)
• Mac mini 2018 and later
• Mac Pro 2019 and later
• all Apple silicon Macs.

macOS Sonoma is now entering its second and final year of security-only updates, and in the latest to 14.7.7 has around 50 vulnerabilities fixed. Although that’s a lot less than in 15.6, those are still important if you’re staying with Sonoma for the time being.

Sonoma is fully supported on the following Macs:

• iMac 2019
• all Intel Macs with T2 chips
• all Apple silicon Macs.

macOS Ventura has probably had the last of its security updates, although in the past Apple has sometimes released one more update in the autumn/fall. Its latest update to 13.7.7 has around 41 vulnerabilities fixed, making it essential if your Mac can’t be upgraded to Sonoma or later. If your Mac is supported by Sonoma, now is the time to plan upgrading it so that it can continue receiving security updates from September.

Tahoe

macOS Tahoe has now entered the public phase of its beta-testing, with the fourth version provided to developers. While much of the debate surrounds its Liquid Glass and new look, it does bring new features such as a Phone app to Macs. So far it appears internally stable and doesn’t look likely to be delayed for major bugs to be wrangled.

Tahoe is fully supported on the following Macs:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

Although the first couple of versions of Tahoe presented themselves to older apps and scripts as macOS 16, since beta 3 it has been thoroughly macOS 26 regardless of how it’s asked. As this hasn’t been mentioned in Apple’s release notes, it’s unclear what it will do in the final release. If you have apps or scripts that could break when they discover the version of macOS running is 26, now is the time to send Apple feedback to make your case for it to report as version 16.

Older Macs

Open Core Legacy Patcher, OCLP, is being updated in the hope that it will be able to run macOS Tahoe on at least some unsupported models, although that probably won’t be available until the end of this year. You can follow progress here, where you’ll see some of the challenges its developers are facing. Another site worth watching is Mr. Macintosh on YouTube.

Next stop, probably in September, should be:

• macOS 26.0 Tahoe
• macOS 15.7 Sequoia
• macOS 14.8 Sonoma

if Apple remains consistent with previous numbering. Farewell to Ventura, old friend!

Somewhen around late versions of macOS Monterey, and certainly by the release of Ventura, macOS started to use cryptexes to load Safari and parts of the operating system including dyld caches, rather than installing them to the Data volume. Over a period of three months, cryptexes were also used to install Rapid Security Responses (RSRs) in an experiment that was quickly discontinued. What I hadn’t realised until recently was that they are also used to deliver much of the additional components required to support Apple Intelligence features in Apple silicon Macs. This article looks as how that works.

Cryptexes

These first appeared on Apple’s customised iPhone, its Security Research Device, which uses them to load a personalised trust cache and a disk image containing corresponding content. Without the cryptex, engineering those iPhones would have been extremely difficult. According to its entry in the File Formats Manual from five years ago (man cryptex), ‘A cryptex is a cryptographically-sealed archive which encapsulates a well-defined filesystem hierarchy. The host operating system recognizes the hierarchy of the cryptex and extends itself with the content of that hierarchy. The name cryptex is a portmanteau for “CRYPTographically-sealed EXtension”.’

In practice, a cryptex is a sealed disk image containing its own file system, mounted at a randomly chosen location within the root file system during the boot process. Prior to mounting the cryptex, macOS verifies it matches its seal, thus hasn’t been tampered with. Managing these cryptexes is the task of the cryptexd service with cryptexctl. Because cryptexes aren’t mounted in the usual way, they’re not visible in mount lists such as that produced by mount(8).

System cryptexes

Once kernel boot is well under way, APFS mounts containers and volumes in the current boot volume group, followed by others to be mounted at startup. When those are complete, it turns to mounting and grafting the three standard system cryptexes:

• os.dmg, around 6 GB (macOS 15.5), containing system components such as dyld caches;
• app.dmg, around 23 MB, containing Safari and supporting components;
• os.clone.dmg, apparently a copy of os.dmg and the same size.

AI cryptex collection

About 5 seconds later, and over 14 seconds after APFS first started work, it checks and grafts a series of 23 cryptexes primarily involved with Apple Intelligence features. These are handled one at a time in succession, each reported in a sequence of log entries as follows (times in seconds after an arbitrary start).

First the Image4 file containing the cryptex is validated
9.434431 root_hash_execution_cb_mobile_asset:3066: image4_trust_evaluate: successfully validated the payload and the manifest

Then it’s grafted into the file system of the Data volume as a ‘PFK volume’. In this extract I omit the bulk of the cryptex’s name using […] for the sake of brevity.
9.434465 apfs_graft:695: disk3s5 Grafting on a PFK volume
9.434509 graft_dev_init:480: disk3 UC_[…]_Cryptex.dmg GRAFT (compiled @ Apr 22 2025 19:49:43)
9.434514 graft_dev_init:484: disk3 UC_[…]_Cryptex.dmg device_handle block size 4096 real block size 4096 block count 11264 features 0 internal VEK
9.434695 nx_mount:1308: UC_[…]_Cryptex.dmg initializing cache w/hash_size 512 and cache size 512
9.437484 nx_mount:1630: UC_[…]_Cryptex.dmg checkpoint search: largest xid 15, best xid 15 @ 7
9.437497 nx_mount:1657: UC_[…]_Cryptex.dmg stable checkpoint indices: desc 6 data 31
9.438117 er_state_obj_get_for_recovery:8420: UC_FM_LANGUAGE_INSTRUCT_3B_CONC No ER state object for volume RevivalB13M201388.UC_[…]_Cryptex - rolling is not happening, nothing to recover.
9.438124 apfs_log_op_with_proc:3263: UC_FM_LANGUAGE_INSTRUCT_3B_CONC grafting volume RevivalB13M201388.UC_[…]_Cryptex, requested by: mobileassetd (pid 457); parent: launchd (pid 1)
Note the volume name starts with Revival. Names of all other cryptex volumes in the AI collection start with the same code name, except for the PKI cryptex examined below, which uses Creedence instead. Perhaps these are a reference to Creedence Clearwater Revival?

The root hash of the cryptex file system is then authenticated
9.438156 graft_dev_blockmap_lut_switch_to_metadata_based_if_needed:1312: UC_FM_LANGUAGE_INSTRUCT_3B_CONC lut contains 26 extents, 3 of which contain metadata
9.438160 is_root_hash_authentication_required_osx:387: UC_FM_LANGUAGE_INSTRUCT_3B_CONC Release kext with internal build: 0, ARV disabled: 0, booting xid: 0
9.438164 is_root_hash_authentication_required_osx:418: UC_FM_LANGUAGE_INSTRUCT_3B_CONC strict graft, root hash authentication failure is required
9.438167 is_root_hash_authentication_required:557: UC_FM_LANGUAGE_INSTRUCT_3B_CONC Strict Graft, root hash authentication is required
9.438179 authenticate_root_hash:642: UC_FM_LANGUAGE_INSTRUCT_3B_CONC successfully validated on-disk root hash
9.438191 apfs_lookup_ge_jobj_id:5028: disk3s5 Found OBJID 0x66a1b8 type 3

The graft is then completed.
9.438195 apfs_graft:1045: disk3s5 Graft ino 6557986, jobj_id range 6725836+76
9.438396 apfs_graft:1138: disk3s5 successfully grafted ino 6557986 on dir 6725835, dev_name [UC_[…]_Cryptex.dmg]

Fortunately, these log entries provide the inode number for the location of the grafted cryptex, and that can be used in Mints to obtain its full path.

Among the AI cryptex collection is a secure public key infrastructure (PKI) trust store, located at
/System/Library/AssetsV2/com_apple_MobileAsset_PKITrustStore/purpose_auto/[…].asset/AssetData/Restore/SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
In the log, this is recorded as being 4.2 MB in size, and that is the same size as reported for the .dmg file by the Finder. Disk images are in APFS (Case-sensitive) format, and might be identical to their equivalents provided for iOS and iPadOS.

When mounted, that disk image becomes a volume named Creedence11M6270.SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex. That contains many property lists, certificate data, a SystemRootCertificates keychain, and two property lists that are grafted into /System/Library/CoreServices.

The names of all 23 cryptex disk images included in the macOS 15.5 AI cryptex collection are given in the Appendix. All are given as being compiled at Apr 22 2025 19:49:43, the same as the system cryptexes, implying that they were installed as part of the macOS 15.5 update. The whole sequence of processing the AI cryptexes took 0.78 seconds to complete, and the total size of disk images mounted in that period was 7.2 GB, which is similar to the reported size of additional files required to support AI.

Conclusions

• Apple silicon Macs running macOS 15.5 with AI enabled load 23 additional cryptexes to support AI, totalling 7.2 GB.
• Those AI cryptexes are grafted into the Data volume, in paths starting /System/Library/AssetsV2.
• All except one have volume names starting with Revival
• One cryptex is a secure PKI trust store, whose volume name starts with Creedence instead.
• These cryptexes are installed and updated as part of macOS updates, although they could also be installed or updated separately, for example when AI is enabled.
• If a Mac shows an unusual mounted volume with a name starting with Creedence or Revival, that’s almost certainly the respective disk image, which should normally be hidden and not visible in the Finder.

Appendix

Disk image names for the AI cryptex collection in macOS 15.5 (Apple silicon):

• UC_FM_LANGUAGE_INSTRUCT_3B_CONCISE_TONE_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_PROOFREADING_REVIEW_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_VISUAL_IMAGE_DIFFUSION_V1_BASE_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_BASE_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_IF_PLANNER_NLROUTER_BASE_EN_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_DRAFTS_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_SUMMARIZATION_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_AUTONAMING_MESSAGES_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_URGENCY_CLASSIFICATION_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_MESSAGES_REPLY_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_PROFESSIONAL_TONE_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_SAFETY_GUARDRAIL_BASE_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_CODE_GENERATE_SMALL_V1_BASE_GENERIC_H16_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_MAGIC_REWRITE_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_CODE_GENERATE_SAFETY_GUARDRAIL_BASE_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• UC_FM_LANGUAGE_INSTRUCT_3B_FRIENDLY_TONE_DRAFT_GENERIC_GENERIC_H16S_Cryptex.dmg,
• SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg.

Given in the order that they are grafted.

Starting up a Mac, iPad or iPhone begins a series of processes progressing from their small boot ROMs to user login, starting up the services required for the operating system and booting the array of hardware in the chip. Early phases, before the kernel is booted, leave little in the way of records, just a few ‘breadcrumbs’ in NVRAM, but the kernel and processes it starts write a great many entries in the log. This article describes a few of those, concentrating on macOS 15.5, with additional information on iPadOS and iOS 18.5.

Logs

These were obtained from logarchives made soon after normal startup on:

• Mac mini M4 Pro, booting macOS 15.5 in Full Security mode from the internal SSD;
• iPad Pro 11-inch (4th generation)(Wi-Fi), with an M2 booting iPadOS 18.5 normally;
• iPhone 15 Pro, booting iOS 18.5 normally.

Logarchives were opened in LogUI and all log entries (excluding Signposts) were extracted for the first 5 seconds following the start of kernel boot and saved to a LogUI JSON file. Following correction for time adjustments (see below), those contained:

• for macOS, 20,000 entries in a total of 5.7 seconds;
• for iPadOS, 10,000 entries in a total of 5.7 seconds;
• for iOS, 10,000 entries in a total of 5.6 seconds.

Each set of entries opens with an entry recording the first moment of the boot process, for example
08:23:33.343017 === system boot: CCB8E0AC-5B94-4789-B951-BF0B893FF45F
following which there is a gap of over 5 seconds during which preboot is completed. The next entry then records the start of kernel boot, for example in macOS with
08:23:38.536777 kprintf initialized

Periods between those two entries were 5.2 seconds for macOS, 5.3 seconds for iPadOS, and 5.1 seconds for iOS.

Times and their correction

One potential source of major error in using log entries during startup results from clock time corrections. When started up, Macs and Apple’s devices appear invariably to have clock times about 6 seconds in advance of UTC. This is corrected about 4 seconds into kernel boot, and marked in two log entries such as
00.827884 === system wallclock time adjusted
00.860742 === system wallclock time adjusted
The first adjustment normally sets the clock back slightly more than necessary, but the second corrects that more accurately.

Effects on timestamps in log entries can appear confusing, as entries prior to time adjustment are given later timestamps than entries written after the adjustments have been made. This may give the impression that the order of log entries is incorrect, and any time calculations that depend on times recorded before and after adjustment require compensation by the two adjustments made. All times given below are taken from records made before system wallclock time adjustment, thus don’t require correction.

Time adjustments may need to be taken into consideration when accessing Endpoint Security events, as some may be written before adjustments are made, so might appear to be out of kilter with later events. This could apply to boot events for the launchd Subsystem, for example.

Log entries

Shortly after the start of kernel log entries with the initialisation of kprintf, the kernel banner is written, but only in macOS
Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041

Virtual memory, logging and other fundamental features are then prepared, and in macOS (not iPadOS or iOS) TXM, the Trusted Execution Monitor, is started
TXM [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.3
followed by the announcement of two stages of preboot, at 0.11 seconds after the start of kernel boot:
iBoot version: iBoot-11881.121.1
iBoot Stage 2 version: iBoot-11881.121.1

It’s notable that macOS gave an iBoot version of 11881.121.1, but iPadOS and iOS gave a slightly later version of 11881.122.1.

According to Apple, TXM (together with SPTM) is active on all three platforms, although it only appears to be well-reported in macOS. Apple explains: “Secure Page Table Monitor (SPTM) and Trusted Execution Monitor (TXM) on iOS, iPadOS, macOS and visionOS are designed to work together to help protect page tables for both user and kernel processes against modification, even when attackers have kernel write capabilities and can bypass control flow protections.” TXM then enforces the policies that govern code execution.

The kernel then turns its attention to loading Core Crypto support, reported in detail in all three platforms, and support for Image4 files, used extensively during and after boot:
0.295967 Darwin Image4 Extension Version 7.0.0: Tue Apr 22 19:44:19 PDT 2025; root:AppleImage4-320.100.22~1926/AppleImage4/RELEASE_ARM64E
and security policy is loaded (reported in macOS only).

AMFI and credential management

All three platforms then report loading of Apple Mobile File Integrity (AMFI), which obtains the model designator from the device tree:
AMFI: queried model name from device tree: Mac16,11
AMFI: queried model name from device tree: iPad14,3
AMFI: queried model name from device tree: iPhone16,1
which is probably the simplest way to confirm the model identifier from the log at this stage. On iOS only, AMFI next reports disabling Swift Playgrounds JIT:
AMFI: disabling Swift Playgrounds JIT services on iPhone devices

The kernel then turns to management of credentials with Credential Manager, which works with secrets managed by the Secure Enclave Processor (SEP) (all platforms). One key log entry to look for is the report of SEP Key Store startup,
"AppleSEPKeyStore":326:0: starting (BUILT: Apr 22 2025 19:45:09) ("normal" variant 🌽 , 1827.120.2)

Startup of hardware systems continues, with Bluetooth reported early, followed by IOThunderboltFamily, and the Apple Neural Engine ANE. In macOS only, the remains of an old copyright notice will then appear:
Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved.
iPadOS and iOS report Backlight startup in
AppleARMBacklight::start: Using new Backlight Architecture 1

CPU cores

After those, in macOS only, the log records registration of CPU cores and their clusters, then starts each in turn. Prior to this, all code has been run on a single core, but once the others have been started, multiple cores are available. The exact log entries recording this may vary between different M families, but typically run as follows:

• ml_processor_register>pset_find(cluster_id=0) returned pset -1
• ml_processor_register>pset_create(cluster_id=0) returned pset 0
• ml_processor_register>cpu_id 0x0 cluster_id 0 cpu_number 0 is type 1
• repeated to create each cluster and allocate CPUs to them, then
• cpu_start() cpu: 0
• arm_cpu_init(): cpu 0 online
• for each CPU in turn.

Although the iPad tested has an M2 chip, no such sequence was reported for its CPU cores in the log.

Security policy

macOS reports Gatekeeper status and the start of AppleSystemPolicy:
AppleSystemPolicy GK status: enabled
AppleSystemPolicy Per file changetime scans: enabled
Security policy loaded: Apple System Policy (ASP)
AppleSystemPolicy has been successfully started

APFS

APFS follows, with differences between log entries according to platform. Initial loading is announced in each, giving the version number
apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.120.31, apfs-2332.120.31.0.2, 2025/04/22
In macOS only, NFS is announced shortly afterwards
com_apple_filesystems_nfs: successfully loaded NFS module
and handling individual file system devices follows.

Boot devices are recorded in full:
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16GFamilyIO/ans@9600000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP2048Z Media/IOGUIDPartitionScheme/Container@2/AppleAPFSContainerScheme/AppleAPFSMedia
/AppleAPFSContainer/Macintosh HD@1 (macOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleT811xIO/ans@77400000/AppleASCWrapV4
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0512Z Media/IOGUIDPartitionScheme/Container@1 (iPadOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16IO/ans@F9400000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0128Z Media/IOGUIDPartitionScheme/Container@1 (iOS)

Each platform states the BSD root in a paired entry:
BSD root: disk3s1
, major 1, minor 15
By that time, the boot process is well underway and log entries are being made every few microseconds.

Key points

• Log entry times need to be corrected when they straddle clock adjustments marked by === system wallclock time adjusted
• === system boot: marks the start of preboot, following which there are no log entries for over 5 seconds before kernel boot starts.
• Start of Trusted Execution Monitor (TXM) is only logged in macOS, although it’s also active in iPadOS and iOS.
• iBoot versions may differ between macOS, and iPadOS/iOS.
• An early log entry from AMFI reports the model designator.
• AMFI reports disabling Swift Playgrounds JIT services on iPhones.
• In macOS only, CPU clusters and cores are registered, and started up individually.
• macOS then reports Gatekeeper (GK) status and the start of AppleSystemPolicy.
• The boot device is reported in full.
• Throughout these, many other services and hardware features are started up.
• During early kernel boot, macOS writes 20,000 log entries in about 5.7 seconds, iPadOS and iOS 10,000.

Volume structure of internal startup disks has grown increasingly complex during the transition from Intel to Apple silicon Macs. There also seems to be little information on iOS and iPadOS to compare against. This article briefly reviews structures of macOS 15 Sequoia on Apple silicon, iOS 18 and iPadOS 18.

Information for macOS is derived from the diskutil command tool, and from APFS entries in the log when booting a Mac mini M4 Pro in macOS 15.5. That for iOS is drawn from APFS entries in the log when booting an iPhone 15 Pro in iOS 18.5. That for iPadOS is drawn from APFS entries in the log when booting an iPad Pro 11-inch (4th generation)(Wi-Fi) in iPadOS 18.5. All three had Apple Intelligence enabled prior to booting. iOS and iPadOS logs were obtained from sysdiagnoses, and all logs were read using LogUI.

macOS 15 (Apple silicon)

The boot volume group consists of six volumes in a single container (partition). Two other containers are normally hidden from the user:

• the first container of around 524 MB is reserved for preboot and secure boot support.
• another container of about 5.4 GB is used for fallback recovery frOS, and in Big Sur was the primary recovery system, until the introduction of paired recovery volumes in macOS 12 Monterey.

The boot volume group contains:

• System, left unmounted after booting from its Signed System Volume (SSV) snapshot;
• Data, the only encrypted volume in the group, with numerous cryptexes grafted into it, and firmlinked to the SSV at multiple points;
• paired, primary Recovery, containing a disk image of the Recovery system;
• VM, the backing store for virtual memory;
• Preboot, for early stages in the secure boot process, with cryptexes grafted into it;
• Update, used as a working volume for macOS updates.

There are two groups of cryptexes grafted onto those volumes:

• system cryptexes, including the large SystemCryptex or os.dmg of about 4.3 GB mainly containing dyld caches, and the smaller AppCryptex or app.dmg containing Safari and supporting components;
• PFK volumes containing support components for Apple Intelligence features. These are numerous, and some are listed in the Appendix at the end.

If you’re wondering what a PFK volume might be, so am I. But this is what Google’s AI had to say: “Mac PFK” likely refers to a combination of MAC knives and Practical Fishkeeping (PFK) magazine. MAC knives are known for their high-quality, sharp blades and are popular among chefs and home cooks. Practical Fishkeeping is a magazine focused on fishkeeping, covering various aspects of the hobby.

These are summarised, without the help of Practical Fishkeeping, in this diagram.

iPadOS 18

In contrast to macOS since Big Sur, iPadOS and iOS only appear to have two containers (partitions) on their internal storage. The first is presumed to be similar in purpose to that in macOS, in supporting preboot and secure boot, although there is a xART volume in the boot volume group. In iPadOS, this container is smaller, at around 367 MB.

The boot volume group contains a slightly different range of volumes:

• there is no Recovery volume;
• there is no VM volume, as iPadOS doesn’t ordinarily support swapping/paging, although M-series models can in certain circumstances;
• User, a second encrypted volume, appears unique to iPadOS;
• xART and Hardware volumes are additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

iOS 18

This is similar to iPadOS, with a first container/partition of around 351 MB, and the following differences in the boot volume group:

• there is no User volume, and no Update volume;
• Baseband Data is additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

Conclusions

• Volume structure of internal startup disks differs considerably between macOS, iPadOS and iOS.
• As would be expected, iPadOS and iOS are most similar, but even they have substantial differences.
• They each run their systems from a Signed System Volume firmlinked to an encrypted Data volume.
• They each graft on two sets of cryptexes, one supplementing the system with dyld caches and Safari, the other providing components for AI.
• There are now at least 24 cryptexes used to support AI.

I welcome corrections and explanations, please.

Appendix: Some PFK volumes from cryptexes

• UC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_300M_BAUC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_DRAFTS_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_CONCISE_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROFESSIONAL_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_SUMMARIZATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROOFREADING_REVIEW_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MESSAGES_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_AUTONAMING_MESSAGES_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_URGENCY_CLASSIFICATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_FRIENDLY_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_MULTILINGUAL_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_VISUAL_IMAGE_DIFFUSION_V1_BASE_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAGIC_REWRITE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_IF_PLANNER_NLROUTER_BASE_EN_GENERIC_H14G_Cryptex.dmg

Source: iPadOS 18.5, configured with AI enabled for British English.

There are several well-known methods for excluding items from Spotlight search. This article details one that, as far as I can tell, has remained undocumented for the last 18 years since it was added in Mac OS X 10.5 Leopard, when Spotlight was only two years old, and can still catch you out by hiding files from local Spotlight search. This was discovered by Matt Godden, who has given his account here.

Well-known exclusions

There have been three general methods of excluding folders from Spotlight’s indexing and search, although only two of them still work reliably:

• making the folder invisible to the Finder by prefixing a dot ‘.’ to its name;
• appending the extension .noindex to the folder name (this earlier worked with .no_index instead);
• putting an empty file named .metadata_never_index inside the folder; that no longer works in recent macOS.

Additionally, System Settings offers Spotlight Privacy settings in two sections. Search results won’t normally prevent indexing of those items, but does block them from appearing in search results. Spotlight’s indexing exclusion list is accessed from the Spotlight Privacy… button, where you can add items that you don’t want indexed at all.

Extended attribute

Matt Godden investigated repeated failure of Spotlight search to find some images in his large media library, and discovered that the extended attribute (xattr) named com.apple.metadata:kMDItemSupportFileType was responsible. Images that weren’t returned in a search of that library all had that xattr attached, and when that was removed, those images were found reliably.

According to Apple’s documentation, that xattr was available in Mac OS X 10.5 and has since been deprecated. No further information is given about its function or effect, nor does it appear in an older list of Spotlight metadata attribute keys.

Search of previous mentions of this xattr reveal that it has been found with either of two values, iPhotoPreservedOriginal as described for Matt’s images, and MDSystemFile used with several apps that have proved equally inaccessible to Spotlight search. Images that have this xattr attached appear to have originated in old iPhotos libraries, which may have been migrated to Photos libraries. Searches for files with this xattr suggest that even old collections of images seldom have the xattr present, in my case on only 9 files out of over 800,000 checked, and the MDSystemFile variant wasn’t found in over 100,000 application files.

The mere presence of this xattr is sufficient to exclude a file from Spotlight search: setting its value to the arbitrary word any, for example, was as effective as setting it to either iPhotoPreservedOriginal or MDSystemFile.

Strangely, the method used to search is important: files with the com.apple.metadata:kMDItemSupportFileType xattr can’t be found when using Local Spotlight search in a Find window, but can be found by Mints using a standard search predicate with NSMetadataQuery.

Detection and removal

The simplest way to detect whether your Mac has files with the com.apple.metadata:kMDItemSupportFileType xattr is to use the Crawler tool in my free xattred, with Full Disk Access. Open its window using the Open Crawler… command in the Window menu, paste the xattr name into the Xattr type box. Click on the Scan button and select the volume or folder to check. xattred then crawls the full directory tree within that and reports all files with that xattr.

The xattr can then be removed by dragging the file onto one of xattred’s main windows, selecting the xattr, and clicking on the Cut button. That change will be effective immediately, and the file made available through Spotlight search within a few seconds.

If you have more than a handful of files with the xattr, use xattred’s Stripper to remove them all. Paste the xattr name into the Xattr type box. Click on the Strip button and select the volume or folder to process.

Recommendations

• If your Mac is likely to search old images that might have the com.apple.metadata:kMDItemSupportFileType xattr attached, search for and remove all such xattrs to ensure those files aren’t excluded from search.
• Whether this behaviour is intentional or not, it’s clearly an undesirable legacy, has been deprecated for many years, and should be removed from Spotlight search.

I’m extremely grateful to Matt Godden for his painstaking research and keeping me informed.

Apple pre-releases some of the components for the next major version of macOS in the previous version. For example, when macOS Monterey 12.3 was released on 14 March 2022, a new XProtect.app bundle appeared in /Library/Apple/System/Library/CoreServices, and passed almost unnoticed until it was updated to version 2 in macOS 12.4 on 16 May 2022. By June that was being updated frequently, and is now a significant part of macOS protection against malware.

This article looks back at versions of Sequoia that have brought new components to identify those we might see more of next month, when the first betas of macOS 16 reach developers.

Officially announced

One new feature that Apple has already made available in macOS 15.4 and later is privacy control of access to the pasteboard, described here. It’s likely that a new Pasteboard item will be added to Privacy & Security settings in macOS 16, allowing you a choice between:

• automatically allowing all pasteboard access without notifying the user (as previously);
• always denying all pasteboard access, unless the user explicitly chooses to access the pasteboard for pasting;
• asking the user for permission to grant pasteboard access, although that will automatically be granted when the user explicitly chooses to access the pasteboard for pasting;
• the default, to ask the user for permission when an app rather than the user seeks access to the General pasteboard; all other pasteboards would always allow access.

This appears complicated, and I expect may need simplification during beta-testing, or users could be baffled. Apple’s note details a default setting you can use to preview this behaviour in macOS 15.5 for individual apps in testing.

To celebrate the 40th birthday of its accessibility support, Apple has announced some new features we can expect in macOS 16. Among them is a Magnifier app that will use an iPhone running iOS 19 through Continuity Camera as a live video magnifier. Others include:

• Vehicle Motion Cues, already available in iOS and iPadOS;
• Braille Access, a full-featured braille note-taker;
• Accessibility Reader, to make text easier to read across a wide range of disabilities.

New apps

macOS 15.5 introduces a new app in CoreServices named Apple Diagnostics. This is currently non-functional, but appears to give access to some form of online diagnostic service in the future.

New kernel extensions

Three kernel extensions to watch for in macOS 16 are:

• AppleDisplayManager, introduced in 15.2, and still at version 1.0
• AppleAOP2, introduced in 15.4, and still at version 1.0; AOP is the Always On Processor in Apple silicon Macs;
• AppleProcessorTrace, introduced in 15.4, and still at version 1.0.0.

New public frameworks

Two were added to 15.4, and remain at version 1.0, for CLLogEntry which appears to be part of Core Location, and SecurityUI which hasn’t yet been mentioned anywhere.

New private frameworks

Many new private frameworks have been added by updates to Sequoia. Although most of these remain at their initial build of 1.0, some have seen surprising increases, including:

• AppSystemSettings, introduced in 15.2, now at build 3.3.5
• CryptexKit and CryptexServer, introduced in 15.4, now at build 493.120.7
• DeepVideoProcessingCore, introduced in 15.4, now at build 1.17
• various GameServices, introduced in 15.4, and already at build 819.4.46
• OSEligibility, introduced in 15.2, now at build 181.120.32.

Among the new private frameworks with intriguing names that remain at their initial version are: Bosporus, Morpheus and MorpheusExtensions, an OnDeviceStorage group, and most recently CodableSwiftUI.

Your guess is no doubt better than mine as to what these all do, but I expect some of them will appear in macOS 16, in one guise or another.

The update to macOS Sequoia 15.5 is likely to be the last to include remaining enhancements and fixes before engineers are more committed to the beta-releases of macOS 16.0 from early June onwards. It’s therefore unfortunate that Apple chose to provide only limited information about what it addresses.

Correlating the general release notes with those for Enterprise results in a short list of:

• one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used;
• large network shares should enumerate correctly in the Finder;
• the Pro Display Calibrator utility should work properly on M4 MacBook Pros, without causing a kernel panic;
• apps registering helper executables should now do so correctly.

Most important for many is that AFP is now deprecated and “will be removed in a future version of macOS”, according to notes for Enterprise.

Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are believed to have been exploited already. Eight of those vulnerabilities are in WebKit.

The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).

Version changes seen in bundled applications include:

• Books to version 7.5
• Freeform to version 3.5
• Music to version 1.5.5
• News to version 10.4
• Notes to version 4.12.6
• Passwords to version 1.5
• Safari to version 18.5 (20621.2.5.11.8)
• Stocks to version 7.3
• TV to 1.5.5
• Tips to 15.5
• Weather to version 5.1.

Those in /System/Library are more extensive, and include:

• Audio Plug-Ins HAL MacAudio driver to version 550.4
• In CoreServices, there’s a new Apple Diagnostics app at version 1.0, which currently doesn’t appear functional
• The XboxGamepad driver extension has a build increment
• AGX kernel extensions all have version increments
• AppleUSBAudio kernel extension has a version increment
• AudioDMAController kernel extensions have version increments
• APFS is updated to version 2332.120.31
• Most of the major public frameworks have build increments, with SwiftUI at version 6.5.4
• Many Private Frameworks are updated.
• A new Private Framework CodableSwiftUI has been added at version 1.0
• New Private Frameworks NDOAPI, NDOUI, SUDocAssets and SensorAccess have also been added at version 1.0.

The new Apple Diagnostics app looks particularly interesting, but appears to attempt a remote connection that is denied, so reports the error and does nothing else.

Overall, this appears to be a substantial update with many fixes included. It’s a pity that Apple hasn’t been prepared to tell us more in its haste to move on to 16.0.

Apple has just released the update to macOS Sequoia to bring it to version 15.5, and security updates for 14.7.6 and 13.7.6.

The Sequoia update for Apple silicon Macs is just under 3 GB in size, and just over 2 GB for Intel Macs.

Apple’s general release notes for Sequoia 15.5 only mention one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used. Otherwise, it’s the usual “enhancements, bug fixes, and security updates”.

Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are reported as believed to have been exploited already. Those for 14.7.6 are here, and for 13.7.6 are here.

One important entry in the Enterprise release notes concerns the future of AFP: “Apple Filing Protocol (AFP) client is deprecated and will be removed in a future version of macOS.” I can hear the howls of anguish already.

Developer release notes claim three bugs are fixed:

• large network shares should enumerate correctly in the Finder,
• Pro Display Calibrator should work properly on M4 MacBook Pros,
• apps registering helper executables should now do so correctly.

The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).

Safari is updated to version 18.5 (20621.2.5.11.8), and there are 8 security bugs fixed in WebKit (15.5).

Last updated at 1845 GMT 12 May 2025.