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.