© Mohamed Sadek for The New York Times
© Kobe Wagstaff for The New York Times
© Arash Khamooshi/Polaris for The New York Times
© Danielle James/The Flint Journal, via Associated Press
© via Joseph Perkovich
© Doug Mills/The New York Times
© Eric Lee for The New York Times
© Ilana Panich-Linsman for The New York Times
© Jordan Vonderhaar/Getty Images
© Brenda Bazán/Associated Press
One of the design features of macOS is that a file’s metadata can be stored separately from that file’s data. This is normally achieved by extended attributes, xattrs, and to aid that there’s a rich and extendable range of them. This article explains what you can and can’t do with them, as of macOS 26.4.1.
More generally, most metadata are stored within a file’s data, to accommodate operating systems and file systems that don’t have such rich features. Most image formats, for example, incorporate standard collections of metadata such as EXIF information, which are saved with the image data. PDF and Word documents have similar features. These have the disadvantage that changing the metadata results in the file data being altered, and that makes it difficult to track and to guarantee the data’s integrity. This can result in damage or corruption to the data in a PDF file during editing of comment metadata, for example. When possible it’s far better to separate metadata.
Distinguishing between data and metadata can also be tricky at times. This is easiest with non-verbal data like images and audio, where text is clearly separate from data, but it can appear more arbitrary with written documents. Some content such as copyright information or an index is universally accepted as metadata, but abstracts and appendixes may vary. Some types of document, such as official standards, draw explicit distinctions, using qualifiers like normative and informative, to assist.
These are the two standard types of metadata currently best supported in macOS, both being readily accessible in the Finder and applicable to any file or folder.
The main problem with Finder Comments is that they are primarily stored separately in the hidden .DS_Store file in the same directory as the item, although a secondary copy is written to a xattr attached to that file/folder. They’re easily accessed in the Finder’s Get Info dialog, and can be shown in List view windows, although that doesn’t work for multi-line comments. On balance, their strange storage makes them fragile and unsuitable for many uses.
Finder Tags are stored properly in a xattr, and are most widely distinguished by the coloured tag displayed. Although they can be repurposed to store text, their main value remains in categorisation. There’s a practical limit of 20-25 characters before their text label is cropped in most views, and labels for multiple items can only be shown in the Finder’s List view layout. For the majority, they are best used for allocating items to a limited number of categories, distinguished foremost by their tag colour, and aren’t suitable for more substantial text like even a brief summary.
To be generally suitable for storing text metadata for a file or folder in macOS, these should:
Of the dozens of xattrs available, I’m aware of just three that come closest to meeting all those requirements:
These are sufficiently persistent as to be preserved in iCloud Drive, and when transferred between Macs using AirDrop. Although they can be displayed in the Finder, they each require third-party software for creation and management. As explained below, this doesn’t apply to image files, which are expected to store their metadata in EXIF information within the file, and not in xattrs.
All three can be created and managed using my free Metamer, as well as with the more extensive features of xattred.
Metamer is a lightweight drag-and-drop utility to create, edit and view many different types of xattr, including the three recommended. It uses a Combo box offering 16 of the most commonly used xattrs, and you can enter the full name of any other if you need. Although it can be used to edit multi-line text, it’s designed to work best with single lines.
xattred is a general xattr editor with more extensive capabilities, and ideal for checking all the xattrs attached to a file or folder. It doesn’t offer the conveniences of Metamer, though.
Each of these three xattrs is displayed in the More Info section of the Get Info dialog, and depending on settings, they can also be shown in the Finder’s preview pane when enabled in Preview Options for that file type. The latter is explained in more detail here, and can appear counter-intuitive at times. However, they can only be added and displayed for supported file types. For example, JPEG and PNG image files can’t display these three xattrs in Get Info dialogs or in the preview pane, but PDF, RTF, text and many other file types can.
None of the three can be listed for multiple files in any of the Finder’s view layouts.
All three are available in the list of search terms available in the Other item at the foot of the search term menu in a Finder Find window, as listed above.
When researching this article, I discovered some odd behaviours that render some xattrs both invisible and undiscoverable by Spotlight search. I hope to describe those fully tomorrow if I can get my head around them.
Extended attributes aren’t unique to macOS and Apple’s other OSes, but they have the longest and richest history, going right back to the first versions of Mac OS. Until the advent of Mac OS X they were resource forks, structured metadata that stored everything from executable code to keyboard layouts. After a shaky first four years in early versions of Mac OS X, 10.4 introduced extended attributes, xattrs, that steadily became used more extensively.
All files in HFS+ and APFS (and other file systems) contain a fairly standard set of metadata known as attributes, information about a file such as its name, datestamps and permissions. Xattrs are extensions to those that contain almost any other type of metadata, the first notable xattr coming in Mac OS X 10.5, named com.apple.quarantine. That contains quarantine information for apps and other files downloaded from the internet, in a format so ancient that the quarantine flag is stored not in binary but as text.
The quarantine xattr demonstrates some of the valuable properties of xattrs: it can be attached to any file or folder without changing its data, and isn’t included when calculating CDHashes for code signatures. It can thus be added safely without any danger of altering the app or its code, although it does change the way that macOS handles the code, by triggering security checks used to verify it isn’t malicious. Once those have been run, the flag inside the quarantine xattr can be changed to indicate it has been checked successfully.
Far from being a passing phase, or dying out as some had expected, xattrs have flourished since those early days. This has happened largely unseen by the user: few alter anything revealed in the Finder’s Get Info dialog, although they’re used to store some forms of visible metadata such as Finder tags, and the URL used to download items from the internet.
Xattrs are named using a reverse-URL format like com.mycorp.setting. There’s no official name registry, as that should suffice to ensure each type remains unique. Editing xattrs is normally performed silently: you’re not made aware of changes in the quarantine xattr, and in most cases the only way to manage xattrs is to use the xattr command tool, or one of very few apps like xattred that can edit and manage them.
Xattrs aren’t stored with a file’s data, nor with its normal attributes.
For smaller extended attributes up to 3,804 bytes, their data is stored alongside the xattr in the file system metadata. Larger extended attributes are stored as data streams, with separate records, but still separate from the file data. Apple doesn’t give a limit on the maximum size of xattrs, but they can certainly exceed 200 KB, and each file and folder can have an effectively unlimited number of them.
Metadata varies in its useful lifetime. Some xattrs are intended to have a short life and then either be rewritten or discarded, while others are expected to be more or less permanent. Files that are copied to non-native file systems including FAT and ExFAT volumes can preserve xattrs in hidden shadow files, but those copied to NFS will have all their xattrs stripped.
Moving a file with xattrs within the same volume shouldn’t affect those xattrs, as they remain within the same file system, but copying them to another volume, even if both use APFS, may leave some of them behind if they’re considered to be ephemeral.
At least two xattr types may be protected by System Integrity Protection, SIP, and thus can’t be directly removed by the user. This is most widespread in the MACL xattr, com.apple.macl, but can also be seen sometimes in provenance, com.apple.provenance. The way that works is quite distinctive, in that cutting or deleting the xattr is successful for an instant before macOS adds the xattr back. As SIP protection doesn’t survive copying to another volume, when you need to remove a MACL xattr you can do so on a copy of the file on a different volume.
The most complex situation is when a file with xattrs is moved to iCloud Drive. The Mac that originated that file is likely to retain most if not all of its xattrs, because the local copy remains within the same volume and file system. However, not all xattrs are copied up to iCloud storage, so other Macs accessing that file may only see a small selection of them. The rules for which xattrs are to be preserved during file copying, including in iCloud Drive, are baked into macOS, and are outlined in the Appendix at the end.
In 2013, as part of its enhancements for iCloud in particular, Apple added support for flags on xattrs to indicate how those xattrs should be handled when the file is copied in various ways. Rather than change the file system, Apple opted to append characters to the end of the xattr’s name.
If you work with xattrs, you’ve probably already seen this in those whose name ends with a hash # then one or more characters: those are actually the flags, not part of the name, what Apple refers to as a ‘property list’. To avoid confusion I refer to them as xattr flags. A common example of this is com.apple.lastuseddate#PS, which is seen quite widely.
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.
This is a kludge, as you normally have to refer to the xattr name including its flags, although the flags aren’t really part of its name. 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. One notable example of those is the quarantine xattr com.apple.quarantine, which is handled by macOS as if it has the PCS flags attached, although those are never used when referring to it by name.
There are also lower case flags that can be used to override those set in system tables, although those appear to be used exceedingly rarely, and I don’t recall ever coming across them. In theory, if you were using a new type based on the standard com.apple.metadata: family, com.apple.metadata:kMDItemNew, you could alter its behaviour to some similar types with the flags psB, as in com.apple.metadata:kMDItemNew#psB. I have no idea whether that would be respected in practice. For the rest of this article, I will ignore the existence of those lower case flags.
File operations involving decisions about the preservation of xattrs are simplified into the following intents:
Login
cp, is labelled XATTR_OPERATION_INTENT_COPYXATTR_OPERATION_INTENT_SAVEXATTR_OPERATION_INTENT_SHAREXATTR_OPERATION_INTENT_SYNCXATTR_OPERATION_INTENT_BACKUP.As of macOS 15.0 (including 26.0), the following flags are supported:
XATTR_FLAG_CONTENT_DEPENDENT ties the flag with the file contents, so the xattr has to be recreated when the file data changes. This may be appropriate for checksums and hashes, text encoding, and position information. The xattr is then preserved for copy and share, but not in a safe save.XATTR_FLAG_NO_EXPORT doesn’t export or share the xattr, but preserves it during copying.XATTR_FLAG_NEVER_PRESERVE ensures the xattr is never preserved, even when copying the file.XATTR_FLAG_SYNCABLE ensures the xattr is preserved during syncing with services such as iCloud Drive. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this flag overrides that.XATTR_FLAG_ONLY_BACKUP keeps the xattr only in backups, including Time Machine, where there’s no desire to minimise what’s backed up.XATTR_FLAG_ONLY_SAVING keeps the xattr only when saving and in backups, including Time Machine (macOS 15.0 and later only).There’s another system limit that must be adhered to: total length of the xattr name including any # and flags cannot exceed a maximum of 127 UTF-8 characters.
These are hard-coded in source, where * represents a ‘wild card’:
com.apple.quarantine – PCS preserved in copy, sync, backupcom.apple.TextEncoding – CS copy, share, sync, backupcom.apple.metadata:kMDItemCollaborationIdentifier – B backupcom.apple.metadata:kMDItemIsShared – B backupcom.apple.metadata:kMDItemSharedItemCurrentUserRole – B backupcom.apple.metadata:kMDItemOwnerName – B backupcom.apple.metadata:kMDItemFavoriteRank – B backupcom.apple.metadata:* (except those above) – PS copy, save, sync, backupcom.apple.security.* – S or N depending on sandboxing, see belowcom.apple.ResourceFork – PCS copy, sync, backupcom.apple.FinderInfo – PCS copy, sync, backupcom.apple.root.installed – PC copy, backup.System defaults for com.apple.security.* depend on whether the app performing the file operation is running in an app sandbox. Non-sandboxed apps apply S to preserve the xattr for copy, save, share, sync, backup; for sandboxed apps N is applied so the xattr is never preserved, even when copying the file.
We can now revisit the list of intents, and establish the effects of xattr flags on each, as:
XATTR_OPERATION_INTENT_COPY preserves xattrs that don’t have flag N or B or XXATTR_OPERATION_INTENT_SAVE preserves xattrs that don’t have flag C or N or BXATTR_OPERATION_INTENT_SHARE preserves xattrs that don’t have flag P or N or B or XXATTR_OPERATION_INTENT_SYNC preserves xattrs if they have flag S, or have neither N nor BXATTR_OPERATION_INTENT_BACKUP preserves xattrs that don’t have flag N.Finally, Apple provides separate information on how xattrs are synced by FileProvider, for iCloud Drive and third-party cloud services using that API. This confirms that the S flag should sync a xattr, but is vague on other flags, simply stating “some older attributes are also synced”. However, a cap is applied on the maximum size of xattrs that are syncable, at “about 32KiB total for each item”. If the xattrs exceed that limit “the system automatically makes some of the attributes nonsyncable.” More puzzlingly, it states “the resource fork is content and isn’t included in the extended attributes dictionary.”
xattr_flags.h, xattr_flags.c, xattr_properties.h in copyfile source, e.g. at Apple’s OSS Distributions Github
man xattr_name_with_flags(3), included in copyfile source
FileProvider (Apple).
For those working with Rich Text without embedded images, my free editor DelightEd offers a suite of unique features. I wrote it when macOS Mojave introduced Dark appearance mode, with the primary purpose of composing Rich Text documents that work independent of appearance. For that it can set styled text on a background that ensures perfect readability in both Light and Dark modes.
Since then it has gained other unique features, including support for creating interlinear text, in which different translations or versions of the same document are interleaved line by line. It will also open PDF documents and automatically extract all their text content.
General features supported include Writing Tools (Apple silicon Macs), case transformations, and a full suite of substitutions. However, until this new version of DelightEd, substitution settings haven’t been saved in DelightEd’s app settings. Version 2.5 now puts that right: to set the app’s default substitutions, set them up using the Substitution command in its Edit menu, for instance enabling Smart Links.
Then save those to its settings using the Save Defaults command in the app’s menu. Each time you open DelightEd after that, its substitutions will start from those saved defaults.
DelightEd version 2.5 for macOS 11.5 Big Sur and later, including Tahoe, is now available from here: delighted25
from Downloads above, from its Product Page, and through its auto-update mechanism.
I’m very grateful to Manuel for asking for this to be fixed.
Many discovered how long 5 minutes could last when they updated from macOS 26.3.1 to 26.4. Right at the end of its Preparation phase, Software Update showed there were only 5 minutes remaining for far longer. This article reveals what went wrong with that update.
My observations come from a Mac mini M4 Pro running a vanilla installation of macOS Tahoe, being updated from 26.3.1 (a) with the BSI installed, to 26.4. Times and details are taken from log extracts covering the final 14 minutes of the update, immediately prior to the reboot for its installation.
At almost exactly 18:43:00, softwareupdated reported that the PREPARING_UPDATE phase was in progress, with 70% complete on the progress bar, and 20 minutes remaining. Periodic preparation activities were then reported in the log, mainly verifying components to be installed as part of the update. One of the longest of those, /usr/standalone/i386/Firmware.scap, took nearly 6.5 minutes alone, although you might wonder why that’s required on an Apple silicon Mac!
Eleven seconds later, softwareupdated changed the progress bar to display 10 minutes remaining, with 71% completed. Just 1.5 seconds later that changed again to display 5 minutes remaining with 94% complete. Six seconds after that, with 5 minutes still displayed, the log records 98.6% was complete.
The log and progress bar then remained stuck at 5 minutes remaining and 98.6% complete for the next 11 minutes and 47 seconds, before changing to 99.9% complete and no time remaining.
These are plotted in the chart below.
The final 5 minute period started at 18:43:12, and lasted until 18:55:04, as reflected in the long period of 98.6% completion (upper line) and 5 minutes remaining (lower line).
The “5 minutes” remaining actually took 12 minutes and 7 seconds, although log entries make it clear that preparation continued throughout that time, with further verifications and “Preparing system volume…”. Those details were reported as ActionText for progress monitoring, but curiously aren’t accessible to the user at the time.
Log entries record softwareupdated keeping detailed records of progress over this period, though. For example:18:51:32.924688 softwareupdated PrepareUpdate PROGRESS (Continue) | state:{
ActionText = "Preparing system volume...";
ElapsedTime = 490;
ExpectedTime = 1335505;
PercentBytesComplete = "48.05373989419242";
PercentComplete = "4.701870471432042";
}
But those aren’t reflected in the progress bar.
Once the update had completed that preparation phase, extensive checks were performed to ensure it was correctly configured, and components were moved into place in the ‘stash’ to be used during installation. One second after successful completion, softwareupdated locked the controller state and waited for the reboot to start installation. Rebooting followed less than two minutes later.
The macOS 26.4 update for Apple silicon Macs was large, and the work required to verify its contents and complete its preparation was incorrectly reported in both percent completion and time remaining. Even in smaller updates, some form of progress needs to be shown in the progress bar during these later stages of preparation, or users may be mislead into thinking the update has frozen or failed, and could for example restart their Mac to try updating again.
When an update claims there’s only 5 minutes left, that could readily extend to longer, possibly on slower Macs as long as 30 minutes or more. Unless there’s evidence that the update has gone wrong at this stage, you should leave your Mac to complete it, as it almost certainly will. If you’re still in doubt and want to confirm that the update hasn’t frozen, open Activity Monitor and look for around 100% CPU from softwareupdated or related processes, and disk activity.
Unfortunately, there’s nothing the user can do to accelerate macOS updates.
One of the longstanding jokes in computing is how misleading progress indicators can be, and last week most of us had a timely reminder when we updated macOS. However much we might like a perfectly accurate linear indicator for macOS updates, this is one of those situations where the best we can expect is a compromise, as I tried to explain here.
There are two types of progress indicator, determinate and indeterminate, depending on whether the task is quantifiable and progress is measurable. Determinate indicators are always preferred, as they inform the user whether they need only wait only a few moments, or they have time to enjoy a leisurely meal, but that requires quantifiability and measurability.
The simple example is copying a file from one disk to another: although macOS doesn’t know in advance how long that might take, it can quantify the task as the size of the file to be copied, then keep track of how much of that has already been completed. When half the size of the file has been copied, the progress bar can be set to half-way along its total length, so providing an accurate indication of progress.
However, with some copy operations that breaks down: when copying a sparse file between APFS volumes, for example, only the sparse data is copied, not the whole file size. As a result, copying sparse files often results in progress bars that jump from a low point to completion in the twinkling of an eye. This also relies on the quantities involved being linearly proportional to the time required, an assumption that often breaks down when downloading from a remote server.
Updating macOS consists of a series of many tasks (see references at the end), of which only one, downloading, is both quantifiable and has measurable progress, and even that may be far from linear. Apple therefore has a choice of:
As downloading is the one task that is quantifiable and its progress is measurable, I’ll start there.
For this, the progress bar starts an an arbitrary 15%, and softwareupdated assumes the total size of that download is the magnitude of that task.
When the download has been completed, the progress bar reaches an arbitrary 55%, and its caption then changes to reporting progress with preparation.
There is a weakness in the assumption that becomes obvious when downloading from a local Content Caching server, as the final 1 GB or so normally isn’t provided from the cache, but has to be freshly downloaded from Apple’s servers. However, that isn’t normally apparent when caching isn’t available and the whole of the download comes from the same remote source.
For the remainder of the progress bar, between 0%-15% and 55%-100%, the task is neither quantifiable nor measurable. Instead, softwareupdated divides it into a series of subtasks, each of which has a fixed progress level. One list of subtasks and levels obtained from the log is given in the Appendix at the end.
The disadvantage of that strategy is that time required by each subtask varies with the update and the Mac being updated. Inevitably, computationally intensive subtasks will proceed more rapidly on newer and faster Macs, while those mainly constrained by disk speed should be more uniform. Large updates should take significantly longer, and that will vary by subtask as well.
A particular problem with some more recent macOS updates, including that from 26.3.1 to 26.4 last week, has been unmarked progress over the final “5 minutes” of preparation. While indeterminate progress indicators continue to move over that period, and reassure the user that the task hasn’t ground to a halt or frozen, the progress bar shown had no intermediate points, making it easy to misinterpret as failure to progress. If this is going to be a feature of future macOS updates, Apple needs to insert some intermediate points to let the user know that the update is still proceeding.
A progress bar that combines different measures of progress, such as download size and substages, can work well, but only if the user is aware of how to read it. As we only update macOS a few times each year, that isn’t sufficient exposure, and how it works needs to be made explicit.
How macOS 26 Tahoe updates 1
How macOS 26 Tahoe updates: 2 Finite state machines
How macOS 26 Tahoe updates: 3 Catalogues and preparing to download
How macOS 26 Tahoe updates: 4 Download, preparation and installation
Read the macOS update progress bar
Progress bar percentages set for some subtasks during updating macOS 26.2 to 26.3 on an Apple silicon Mac:
Note the majority of the progress period (79%) is assigned to downloading (15%-55%) and preparing (60%-99%).
In my account of how Tahoe updates macOS, I had reached the stage when Rosetta and the main update had started downloading from Pallas, Apple’s software update server (see the Appendix at the end for further explanation of terms used).
Currently, the main update download (at least) is compressed using Zip, and is decompressed as a stream during download, so there’s no delay decompressing during the preparation phase later.
In this case, downloading the main update was completed within 8 minutes. The source of the Zip archive was originally given as a path on [https://]updates.cdn-apple.com/2026WinterFCS/patches, and that was written to a local path on /System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/ In my case, though, I have a local Content Caching Server running, and immediately before the download started com.apple.AssetCacheServices substituted a download URL on that server to ensure the update was obtained through the local caching server. At the same time, an Event Report was sent back to Apple, recording the start of download.
Progress was updated every second during the download, and brought the progress bar from 16% to 53.9% over the following 8 minutes, with little other activity taking place.
Activity then changed to what is repeatedly referred to as Preflight FDR Recovery, and is the first entry point for the UpdateBrainService, downloaded for MobileSoftwareUpdate rather than softwareupdated.
This runs an Event Recorder and begins to perform preflight checks to “recover FDR SFR”, and to perform a “firmware-only update”. To prepare for that, it retrieves various nonces and their digests for LocalPolicy, RecoveryOS boot policy, and others. Following those is the first of many attempts to determine purgeable space, in preparation for installation of the update. Those are performed by com.apple.cache_delete.
Pallas was then checked to see if there was any more recent version of RecoveryOS UpdateBrain, but there wasn’t. A further check for any newer recoveryOS was also made, before the main macOS update was prepared, at a progress level of 60% as set previously.
The first step of the main preparation phase is to purge staged assets with com.apple.cache_delete. With that complete, UpdateBrainService recalculates cryptex size requirement for the update, and the install target prepare size:
UpdateBrainService then checks volume free sizes, and confirms that they’re sufficient to complete the update. It next creates a ‘stash’, which is protected by keys in the stash keybag, handled by the Secure Enclave Processor. There is then another round of purging with com.apple.cache_delete.
Much of the preparation phase is spent verifying the protection of installation packages, cryptexes, then the contents of /System/Applications and /System/Library. As progress is about 64% complete, System volume preparations are started, and there’s another round of purging by com.apple.cache_delete. There’s surprisingly little log activity as progress passes 70% complete.
With progress reaching 84% complete, UpdateBrainService starts unarchiving files in parallel, taking just under 5 seconds to complete those. Following that, there’s another brief period unarchiving data files in parallel, then working with the contents of /System/Volumes/Update/mnt1/private/var/MobileAsset/PreinstalledAssetsV2 as progress reaches 87% complete.
When there’s 87.5% completed, UpdateBrainService reports it’s creating hard links in parallel, then is searching for new paths and verifying files, such as those in the Ruby framework. The Recovery volume is unmounted, and there’s yet another purge with com.apple.cache_delete. After those, key volume locations are checked.
The high water mark of disk usage during update is prepared. This reveals some of the steps to be undertaken during installation, including:
There’s a further round of purging with cache_delete before declaring PrepareUpdate as successful, then suspending the update briefly. When update resumes, the Update volume is mounted and prepared, and there’s another round of purging. The System volume is then mounted, checked, and prepared. Progress is now at 98.5% complete, and once 100% is reached, the countdown to restarting the Mac is begun.
During the download and preparation phases, apart from repeated purging, the log is generally quiet. This changes dramatically once the Mac starts preparing for shutdown and installation. WebKit is cleaned up and shut down, as are many other processes. The ‘stash’ of update components is then committed, and final scans and checks are completed.
The update is then applied, followed by Rosetta, RecoveryOS, UpdateBrain and finally minor documentation. After that period of nearly 20 seconds, this phase is declared complete, and a restart is notified before waiting for the essential reboot.
Once rebooting by root has been initiated, the boot chime is muted to ensure the update continues in silence. The last log message is written a few seconds later, and UpdateBrain then runs the update.
Less than 3 minutes later, the system boot is recorded in the log, and kprintf is initialised 5 seconds later. About 3 minutes afterwards softwareupdated is started up, and runs various clean-up routines to complete the update sequence in conjunction with ControllerSetup and a Finite State Machine.
How macOS 26 Tahoe updates 1
How macOS 26 Tahoe updates: 2 Finite state machines
How macOS 26 Tahoe updates: 3 Catalogues and preparing to download
為什麼高能量通量會比較好？到底怎樣才算進入高能量通量？
今年認真減脂、備賽，並參加了三場健美比賽（詳情可見這裡）；在觀察不同流派的備賽方式後，我留意到一件事：雖然大家幾乎都同意（或至少不反對）減脂時要保持「高能量通量」，甚至有選手會在減脂時仍然每天吃到 3000 大卡以上，但卻比較少看到大家認真討論高能量通量背後的原理、是否真的有效、以及怎樣才算高能量通量。
畢竟，只要能創造一樣的熱量赤字，吃進多少對減脂效果真的會有差別嗎？
今天，就來透過科學研究，帶大家更認識高能量通量的觀念，並解釋為何從科學或實務，都會比較推薦用高能量通量的方式來減脂。
一個人能減脂，通常就代表他消耗的能量比吃進去的能量還多（i.e.熱量赤字），所以身體只好燃燒脂肪來製造能量。因此，不管是吃1500大卡、消耗1700大卡，還是吃3500大卡、消耗3700大卡，都是創造200大卡的赤字，也都可以減脂。而「吃多、動更多」的方式，即是所謂的「高能量通量」。
先不管任何其他變數，理論上「只要有創造熱量赤字，不管吃多吃少都可以減脂」。那高能量通量有什麼其他優勢嗎？
我們要先建立一個背景知識：
肥胖到底是天生的還是後天的呢？確實，目前已經能找到一些跟肥胖有關聯的基因，且同卵雙胞胎的研究也顯示同樣的飲食下，雙胞胎會有較相近的體重變化（跟其他陌生人相比）。因此，肥胖跟基因是有些關聯的沒錯。
不過，基因對肥胖的影響遠遠不及環境因素。當我們脫離嚴格控制的實驗室環境，把眼光放遠到整個人口的觀察時，反而難以找到會影響肥胖的基因模式；這代表，雖然基因可以影響一個人在特定飲食下的身材變化，但現實生活中實際影響身材的主要是環境、而非基因。
除此之外，也有人類與靈長類的生態學研究發現，TDEE（每日總消耗熱量）和體型大小主要是被「食物可取得度」與「活動需求」所決定，而熱量攝取又跟 TDEE 和體型有關。簡而言之，身處越容易取得食物的環境，自然而然就會吃越多，而這多出的熱量要嘛被消耗掉、要嘛變成增加的體重。
也就是說，在現代社會這個食物可近性如此高的環境，要採取超低熱量攝取的減脂策略是很困難的，因為我們很容易就會接觸到過多的熱量。因此，從這個角度來看，高能量通量的減脂法已經先拿下一勝了。
在理想的狀況，我們消耗多少熱量，就會產生多少食慾，這樣自然而然就會處於熱量平衡。但問題是，當活動量太低時，這個正相關的食慾控制可能就會出差錯，變成活動量低時，食慾還會很高，導致吃太多而變胖。
早在1956年，Mayer et al. 就發現了工廠員工的熱量攝取會依據活動量呈現 U 字型：雖然通常來說，勞動越多的人會吃越多，但處理靜態工作、整天都坐著的員工，吃的熱量卻跟負責最大量勞動的員工相同。
Hagele et al. 在 2019 的隨機控制試驗進一步證實了活動量可以影響食慾：當受試者的活動量低下時，較容易產生飢餓相關的賀爾蒙，且吃進的熱量比高活動量時還多了 17.5%。
總結來說，活動量不足時，食慾會失去正常調控，因而容易吃進比身體所需還更多的食物，導致體重增加。從這個角度來看，高能量通量的減脂方法，再度勝利。
雖然我們通常習慣把高能量通量當成「高攝取、高活動」，但更精準的描述其實是「高攝取、高消耗」才對。這兩者有什麼不同呢？
熱量消耗可以分成：活動消耗＋非活動消耗（包含基礎代謝、食物熱效應）；不管是脂肪細胞或肌肉細胞都需要能量，所以體重較重的人，基礎代謝率其實是比較高的。因此，無論是增加活動量、還是增加體重，都可以達到高熱量消耗、也都可以變成高能量通量的狀態。這也是為什麼前述的靜態生活工人，並不會在熱量攝取變高後，體重無限增加；而是體重增加後，消耗也會隨之提高，並再次回到熱量平衡。
不過，我們在意的是減脂議題，因此通常不會把增加體重來當作高能量通量的方法。這就是為什麼我們實務上可以把「高攝取、高活動」當成「高攝取、高消耗」。
其實，只透過「多活動以增加熱量消耗」來減重並不是容易的事。根據實證指引，對多數人而言，要減重主要還是得靠飲食控制，運動只是輔助。再更進階一點的分析，甚至有所謂的 Constrained Total Energy Expenditure Model（總能量消耗限制模型）表示，超過一定的活動量後，再怎麼運動也不會增加更多熱量消耗；最顯著的例子，就是高活動的原始部落族群，每天的熱量消耗其實跟現代人差不多。（註：這個模型有很多可以討論的，如果現在會覺得奇怪、不合理，是正常的；但本文就先不細述了）
但相對的，若已減重，那高活動量就有顯著的效用：避免復胖。會復胖，就是身體想回到一個更高的能量通量，而最簡單的方法正是增加體重。不過，我們也可以透過提高活動量來達到高能量通量，這樣就不會復胖了！
老實說，就算不理會上述的一堆科學概念，高能量通量的減脂法還是有很明顯的優勢：可以正常跟家人朋友聚餐！若能量通量太低，每餐都只能吃少少幾口，那對一起吃飯的親友也是一種麻煩或壓力。若可以在高能量通量的狀態下減脂，雖然對你而言可能飢餓程度相仿（畢竟赤字相同），但至少吃的量是跟別人類似的，這樣就可以照常跟大家一起吃飯聊天了。
講到這邊，細心的讀者可能會發現，怎麼好像都還沒有定義到底要多高才算高能量通量？這是因為，高能量通量其實沒有絕對數值的定義，而是跟每個人的基礎代謝率有關。原本就體重較重、基礎代謝率較高的人，就會需要更高的熱量平衡才會處於高能量通量的狀態。
雖然還沒有精確的認定，但透過有限的研究可以估計，TDEE 比基礎代謝率高 1.7–1.8 倍就可以說他是高能量通量。所以一個基礎代謝率為 1500 大卡的人，TDEE 抓 2550 大卡就算高能量通量了。如果想減脂，那再扣 200~300 大卡，就是每天吃 2250–2350 大卡。
高能量通量的減脂方式，不只可以更自在地執行、不會給親朋好友壓力，也更適合現代社會這種食物取得度極高的環境。此外，透過提高活動量來減脂，既能調控食慾、也更能避免復胖。雖然沒有確切的數值，但大約抓 TDEE 為基礎代謝率的 1.7–1.8 倍，就能當成是高能量通量了。
主要參考資料：Melby, C. L., Paris, H. L., Sayer, R. D., Bell, C., & Hill, J. O. (2019). Increasing Energy Flux to Maintain Diet-Induced Weight Loss. Nutrients, 11(10), 2533. https://doi.org/10.3390/nu11102533
若喜歡這種健身科學解說，請追蹤我的 Medium 和 Instagram（＠vin_training），才不會錯過最新內容哦！
之前有这么一个段子，说川端康成问他的几个学生，英文的“I love you”如何翻译成日语。学生们翻译成“私はあなたを爱する”之类的Google翻译体之后，川端大师抬头望了一下天，说，你们翻译得完全不对，如果是日本人的话，只要翻译成“今夜月色很好”，就可以了。
不知道为什么，假设这个事情是真的，我并不觉得它矫情。事实上，这个故事很真实，很令人信服。
学跨文化管理的时候，学到了“高语境”这么个概念。在高语境文化下，人们的真实意思并不能直接从语言的内容中推断出来，而要根据语气、表情、动作、氛围等等综合进行判断。
在商务环境下，“请问您觉得这个报价合适吗？”“听起来很合理呢，我要回去跟老板商量一下”，也许意味着后者根本无法接受这个价格。
而在恋爱环境下，“我还以为琴子是哥哥喜欢的类型呢”，“不可能，除非我智商变负”，就是个典型例子。嘴上说着不可能，但脸上藏不住的幸福感暴露了真实的心理。
————
日本和中国都是明显的高语境文化的国家，也就是说，往往话里有话，言不由衷。而在男女关系中，女性比男性要更含蓄、敏感多思，难以捉摸。试想，葬花坡上若无宝玉喊一句“只说一句话，从此撂开手”，黛玉岂不是要当下就哭死了？
高中的时候看《源氏物语》，印象最深刻的场景是，源公子从别的女人那儿回来之后，看到紫姬侧卧在床上，背朝外，只能看到她长长黑发的一个背影。
倘若这个时候，源公子没有sense地跑去问，“你是不是难过了？”贤惠的紫姬一定会否认的，也许会说，最近天气太热，不想起床。然而源公子之所以受到这么多女人的爱和等待，也是因为他很能体谅。看到紫姬无声的背影，源公子走向她，坐在床边，抚着她的头发说，“以后我都陪你”。情商之高令人发指。
高语境的爱恋有时是很困难的，有时却很有意思。来回地印证、反复地确认，若有似无地传达某个信号，努力捕捉微表情。倾城之恋里面，范柳原说喜欢流苏的理由是“一个真正的中国女人”，而流苏最大的特长则是低头。低头是一个很强大的隐藏真实信息的动作。对方讲了一个趣事，你低头；对方向你表白，你低头。不展示真心，才够矜持。
然而，这种模棱两可暧昧的态度，可能会被不了解高语境的人误读。比如，恋人电话里吵架的时候，女生说“你再也不要打电话来了!”就把电话挂了。男生再打过去，挂断，再打，关机。这个男生于是觉得女生是真的生气不想理会自己了，放弃电话，想明天再好好解释。
“你再也不要打电话来了！”和“讨厌！”是一个感觉的。这个语境是“我很生气，除非你一直一直打电话给我，我才会原谅你。”
————
我看《情书》，无论看到哪儿都恨不得会哭。日本的审美是很招人恨的。最美的是失去。最美的是死亡。樱花是美丽的，只因为它的凋谢。情书里面，男孩子对女孩的爱恋一直表现得浅浅的完全没有被察觉，而到死后，才被一点一点回忆起来。而《追忆似水年华》给人的深深的怅然，则是最好的读者反应。
上个暑假的时候，我读了两三个最后自杀的日本作家的书，真是抑郁得很。三岛由纪夫的《金阁寺》就是一本让我备受打击的书，其打击不啻于目击最心爱的人跳楼。郁闷到暴。这大概就是日本的悲剧美学的极致了吧。
为毛讲到悲剧美学了。。既然提到这个，就随便再一说。高语境的爱恋很容易出现问题，信息不对称的情况下，需要很强的互相理解与信任。远距离的恋爱之所以不易，就在于朦胧了高语境的背景。失去了眼神表情动作氛围，原本一个拥抱能解决的问题，原本撒娇卖萌的“你再不回来我就不等你了”，就会被误解放大成一场大危机。
因此心有灵犀、心心相印之类的话，都是非常高水平的恋爱程度。很高级。
傲娇是怎么一回事呢？好像在性格中就存在这种保守的态度。不愿意表明自己的态度。
因为在不知不觉中喜欢上了对方，潜意识里大喊“不好！陷进去了！”，感觉自己属于感情中的弱势者，对方的一举一动都会影响自己生活。于是反而表现出一副很强硬，很不屑的态度，以免被对方抓住痛脚。“我可没有先喜欢你哦。是你先喜欢我的呀“，是弱者自以为能够凭借立于不败之地的大把柄。
我有一阵子觉得高语境的爱恋实在是太高难度了，于是尝试着直言不讳。但在高语境成为公共知识的背景下，所有的语言都会被转译，从而造成了更大的误解。
————
有些人说，自尊心害死人。有时候自尊心是会让人受苦的。但人类之所以实现了一些文明上的辉煌，也是因为尊严，pride。物质、宝贵的生命，都可以因为尊严而放弃。
我认为，正是这种短期的似乎”不理性“，才实现了更大的理性。
高语境的使用者，莫沮丧，多沟通，多信任；高语境的”受害者“，莫否定，莫悔痛，自尊自有其代价，而人生无常，也许哪一天好事会发生。
