In yesterday’s guide to dealing with apps that crash immediately you open them, I carefully avoided mentioning what you might find in the log. This article puts that right.

The list of common causes I gave is:

• macOS intentionally crashed the app because of an error in code signing, or another serious security failure;
• the app failed because it was in translocation;
• the app couldn’t open a damaged or incompatible document;
• the app had a problem with its Preferences.

Investigating these in the log is among the simplest tasks for those learning to access it, providing the app crashes reliably. Show the seconds value in the menu bar clock, and open the Applications folder containing the app. Select it as the seconds reach about 45, to allow time for its icon to be displayed, then double-click the app to run it as the seconds reach 00, but not a moment earlier. Don’t touch the mouse/trackpad or keyboard for at least 5 seconds, by which time the crash should have occurred and the notification or crash log should have been displayed.

Then open LogUI (or a substitute), and set it to extract and display all the entries for 5 seconds from 00 seconds. If you open a new window in LogUI the start time will be preset to the time you opened the app, all ready to get the log extract.

The double-click is easy to spot in the log, as it’s marked by four almost identical Activity entries with a yellow softball emoji, each reading something like
AppKit Finder sendAction:
short entries that are quick to locate. Entries following the fourth of those then report what happened next.

Code signing errors

These are normally easy to recognise, as they start with a call to verify the signature,
00.940943 Finder sendAction:
00.963228 syspolicyd SecTrustEvaluateIfNecessary
00.963982 trustd SecKeyVerifySignature
that’s followed by an error that’s repeated many times,
00.981296 lsd com.apple.securityd MacOS error: -67030

Follow those down a bit further and you’ll see this reported in other subsystems
01.013084 com.apple.launchservices Error -67030 validating the signing information for [private], error=Error Domain=NSOSStatusErrorDomain Code=-67030 "(null)" UserInfo={SecCSArchitecture=arm64}

Normally, this will be checked again by AMFI (Apple Mobile File Integrity)
01.030162 amfid Entering OSX path for /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd
01.031629 amfid SecKeyVerifySignature
01.036291 amfid com.apple.securityd MacOS error: -67030
01.048491 error amfid com.apple.MobileFileIntegrity.framework Code failed basic validity check (error: -67030): Error Domain=NSOSStatusErrorDomain Code=-67030 UserInfo={SecCSArchitecture=[private]}
01.048857 amfid /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" UserInfo={NSURL=file:///Users/hoakley/Documents/
000aa/DelightEd.app/Contents/MacOS/DelightEd, NSLocalizedDescription=The signature on the file is invalid}

That’s confirmed and actioned by the kernel
01.048950 kernel AMFI: code signature validation failed.
01.052968 amfid com.apple.MobileFileIntegrity [private]: Broken signature with Team ID fatal.
01.053043 kernel AMFI: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053052 kernel mac_vnode_check_signature: /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: code signature validation failed fatally: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053059 kernel validation of code signature failed through MACF policy: 1
01.053061 kernel check_signature[pid: 2718]: error = 1
01.053066 kernel proc 2718: load code signature error 4 for file "DelightEd"
01.053461 kernel AMFI: hook..execve() killing xpcproxy (pid 2718): Attempt to execute completely unsigned code (must be at least ad-hoc signed).
01.053624 kernel ASP: Sleep interrupted: ref 29, signal 0x100, pid: 2718
with the conclusion
01.053627 kernel ASP: Security policy would not allow process: 2718, /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd

You’re not likely to miss those.

Common error codes from signature validation include:

• -2147409652 CSSMERR_TP_CERT_REVOKED, the certificate has been revoked
• -67007 resource envelope is obsolete (version 1 signature)
• -67008 unsealed contents present in the root directory of an embedded framework
• -67013 resource envelope is obsolete (custom omit rules)
• -67021 nested code is modified or invalid
• -67023 invalid resource directory (directory or signature have been modified)
• -67030 invalid Info.plist (plist or signature have been modified)
• -67054 a sealed resource is missing or invalid
• -67056 code has no resources but signature indicates they must be present
• -67061 invalid signature (code or signature have been modified)
• -67062 code object is not signed at all, which is by far the most common.

In this case, I had changed a single character in the app’s Info.plist, which broke its CDHashes, and resulted in the correct error code of -67030.

App translocation

In this case, you’re looking for two related pieces of evidence, that a process mentions the act of translocation, and that the app is run from a translocation location. Again, these normally aren’t hard to find.

Shortly after the double-click,
00.968186 Finder sendAction:
you should see mention of the creation of the translocation directory
01.040587 lsd com.apple.securityd SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/x4/
x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app

A little further down the log you’ll see the app being referenced in that long path
01.069877 amfid Entering OSX path for /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd
01.090927 com.apple.runningboard _executablePath = /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd
and so on.

If you’re struggling to find those, select the Messages item at the right end of the toolbar in LogUI, type the app name into the search box there and press Return, to filter entries.

Failed to open document

Of the four common causes of early app crashes, these are hardest to find evidence in the log. This is because the only process likely to know what went wrong is the app itself, and few third-party apps write anything useful to the log. You might find a useful entry or two by setting that menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return. However, in many cases there will be little or no useful information.

Preference file problems

My previous article referred only to standard preferences that are handled by cfprefsd. Some apps run their own preferences using their own code, and neither cfprefsd nor the defaults command covers them. If they have a problem when accessing those custom files, it’s most unlikely to be recorded in the log.

In other apps, you should look for evidence that the crash happened shortly after the cfprefsd service is connected to the app, to support the standard features.

Starting once again with the double-click
01.579559 Finder sendAction:
it may take some time for the opening stages to complete. You should then see the XPC connection between the app and cfprefsd being set up for both root and the user
01.638428 DelightEd com.apple.xpc [0x102cf6980] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.daemon
01.638504 DelightEd com.apple.xpc [0x102cf7960] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.agent
01.638563 cfprefsd com.apple.xpc [0xa252bdb00] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.daemon.peer[2910].0xa252bdb00
01.638659 cfprefsd com.apple.xpc [0x86f2d3600] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.agent.peer[2910].0x86f2d3600

The app will normally crash during or shortly after the loading of preferences, marked by entries like
01.641152 DelightEd Loading Preferences From User CFPrefsD
01.706158 DelightEd Loading Preferences From System CFPrefsD

These too can be found more easily by setting the menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return.

Happy hunting!

One of the first things that strikes you when you look at a log extract from a Mac, is the number of entries that have some or all of their contents censored with <private>. Another is the sheer number of entries; even when your Mac is doing little, there’s a constant stream of them. This article explains how you can get control of both.

Logging preferences

The keys to controlling what gets written to the log in macOS are property lists stored inside /Library/Preferences/Logging. By default you’re likely to see few files there, which may include a high-level policy in com.apple.system.logging.plist. If present, that’s likely to set just two keys, Enable-Logging to true, and Locked to true as well. But that property list doesn’t tell the whole story.

To discover full top-level policy, you need to enter the command
sudo log config --status
which is likely to return
System mode = INFO

Step one down from there with
sudo log config --status --subsystem com.apple.system.logging
and that might report
INFO PERSIST_DEFAULT
or could extend to include
SIGNPOST_PERSISTED_OFF SIGNPOST_ENABLED_ON SIGNPOST_BACKTRACE_ENABLED_OFF OVERSIZE_ENABLED_OFF
as well.

Now try a more specific subsystem with
sudo log config --status --subsystem com.apple.network
and you’re likely to see something similar, unless there’s a property listed named com.apple.network.plist in the Subsystems folder there, in which case it should reflect the settings in that.

Those settings largely concern two features:

• Levels of log entry recorded, set as default, info or debug. The first of those includes all entries of default or higher level, the second of info, default or higher, and the third of debug, info, default or higher. Default global level is normally info, so that debug entries don’t appear in the log.
• Whether the entries are saved to persistent storage (disk), using the same hierarchy of levels.

Thus INFO PERSIST_DEFAULT means that all log entries of info level and above, but not debug, will be collected, and the default setting is used to determine which get written to disk.

Apple explains those basic settings in man log, and its documentation for developers.

Signpost and Oversize settings aren’t explained there, but are in man 5 os_log. Signpost log entries are intended for use by developers to assess performance, and are rarely of any use to others. Oversize log entries can be many pages long, and are stored separately when enabled.

Controlling logging preferences

There are three ways to control logging preferences, which all converge on those same property lists:

• The log config command, as used above. This is quick and simple, but limited, and perhaps best used to check effective settings for individual subsystems and processes.
• Write your own property lists and install them in the appropriate folder in /Library/Preferences/Logging. Although this is powerful, as there’s limited guidance on what can be included, you’ll probably want to start from existing property lists. There’s further information in Peter Steinberger’s post and man 5 os_log.
• Install a custom log profile, which you can also use as a model to develop your own property lists and profiles.

Custom logging preferences take effect almost immediately, and don’t require restarting, but they only apply to log entries written once they have been applied, never retrospectively.

Limiting log entries by level

As the Unified log discards old log entries to constrain the space occupied by the logs, the only way to extend the period covered by stored log entries is to limit the rate at which fresh entries are added to the log. You can do this by careful assessment of which subsystems are writing most entries, and changing their logging preferences.

However, that only applies when there’s an excess of log entries at debug or info levels. When there is, adding or modifying the preferences for that subsystem to store entries at a level of default or info should extend the period they cover. Be cautious, though: that excess of entries could reflect a problem, and by excluding them you may well conceal its cause and extent.

Custom log profiles

The simplest alternative is to install a Configuration Profile containing the saved settings to be applied to the property lists in /Library/Preferences/Logging. I provide a signed profile to remove all that <private> censorship in enablelogprivatedata.

To install the profile unzip the archive into a convenient folder and double-click it. You’ll be prompted to review the profile to install it.

Open System Settings > General & Device Management, and inspect it by double-clicking the profile there.

Click on the Install button to accept and install the profile.

To remove it, select the profile and click the – tool below.

If you watch the contents of com.apple.system.logging.plist in /Library/Preferences/Logging you’ll see that change, with the setting of the key Enable-Private-Data to true. If you then run
sudo log config --status
with that profile installed, it should report something like
System mode = INFO PRIVATE_DATA
to confirm that private data is being shown in log entries, and that’s the best way to gain access to their full contents. Remember to remove the profile as soon as you’re done, or your log will continue to leak sensitive data.

There’s a collection of custom log profiles to gather log extracts about specific features in macOS (and Apple’s other OSes). Although they’re listed here, you can only download them if you have a developer (or equivalent) account with Apple. What’s more, Apple describes these as confidential, and explicitly forbids their use or disclosure without its permission. So much as I’d love to explain the undocumented features they use, I regret that I can’t.

Each week brings news of more ClickFix atttacks. Last week’s, dubbed Mach-O Man by Mauro Eldritch and detailed on ANY.RUN’s blog, tricks targets into “fixing” a fake connection problem by pasting a malicious command into Terminal. I have previously argued that these attacks are preventable by changing user behaviour. Here I consider the role of macOS and its increasing reliance on the command line.

This was inspired by Apple’s recent warning to administrators of forthcoming changes in network security, where Apple instructs them to copy and paste a near-unintelligible command in what mimics a ClickFix attack. Although a brief explanation of that command is given, this is bad practice. The reason it’s deemed necessary is that the utility provided in macOS for the last ten years to access the log, Console, simply isn’t up to the task.

I took the lengthy predicate recommended in Apple’s article
"p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|
mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|
remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"
and broke it down into the far more understandable
(subsystem = 'com.apple.network') AND ((message CONTAINS[cd] 'ATS Violation') OR (message CONTAINS[cd] 'ATS FCPv2.1 violation'))
and pasted that to use as a one-off predicate in LogUI.

Over a ten-minute period of network access, that returned a workably small number of log entries for further checking.

A little careful thought suggested a more logical approach, effectively using the predicate
(message CONTAINS[cd] 'violation')
using LogUI’s popup predicate menu, then filtering those few entries using the word network in their subsystem field, with exactly the same results.

It really isn’t that hard to come up with a log browser that can handle such tasks far better than the command line ever could. But from the start it has been clear that Console isn’t intended to assist browsing the Unified log, only to discourage it.

Few of those now working for Apple can remember that for the first 17 years of Macs, until the arrival of Mac OS X, there was no command line at all. We got by with utilities crafted by Apple like ResEdit.

Here ResEdit is displaying the resources of QuarkXPress version 4.11 from around 2000. The app icons shown are stored in a resource of type BNDL, a ‘bundle’, but not in the later sense of the term.

I feel sure that more engineers will recall the GUI provided in Mac OS X Server, in its Server Admin app that wrapped many of its tricky tasks in a familiar interface, making administration a true joy. One weak area was DNS management, for which there were third-party alternatives including that from Men&Mice, now part of BlueCat.

In later, more consumer-oriented versions, Server.app was more concise but remained rich in function. Its sidebar let you manage users and groups, monitor your server, control its services, manage hardware, and control system, network and storage settings. Below that the Next Steps button provided access to help topics and useful suggestions.

In the years since, Apple has steadily stripped out many of those utilities that provided ordinary users with an alternative to the command line.

Network Utility contained a friendly front-end to a suite of valuable tools to help diagnose network problems. It was deprecated in Big Sur, then removed, with Apple explicitly advising the use of command tools instead.

Other utilities have followed a similar pattern. Initially, some of their more advanced features are removed, then the app is hidden away in /System/Library/CoreServices/Applications to discourage its use, in preparation for telemetry to justify its removal on the grounds of lack of use. Once it has gone all we have left is a clumsy conglomeration of options in a *util command tool, and users forced to copy and paste in training for a ClickFix attack.

This is good news for indie developers like Michael Tsai at C-Command, and Bryan Christianson, who can then build replacement apps such as DropDMG and WhatRoute, and some of my own utilities like Spundle. But they can only reach a limited audience, and the majority are left to rehearse for ClickFix.

At the same time that Apple has been normalising the use of the command line, it has invested heavily in app security, from Gatekeeper and quarantine, to XProtect and notarisation. Predictably, ClickFix attacks sidestep past those and exploit the behaviour that its victims have been conditioned to because macOS doesn’t provide the apps needed for its administration and maintenance.

ClickFix is thus largely self-inflicted by a modern macOS that places greater priority on apps that generate income, and design fads like Liquid Glass.

One of the most contentious questions arising from yesterday’s critical examination of ChatGPT’s recommendations, is how long does the Unified log keep entries before they’re purged? ChatGPT seemed confident that some at least can be retained for more than a month, even as long as a year. Can they?

Traditional text logs are removed after a fixed period of time. One popular method is to archive the past day’s log in the early hours of each morning, as part of routine housekeeping. Those daily archives are then kept for several days before being deleted during housekeeping. That’s far too simple and restrictive for the Mac’s Unified log.

Apple’s logs, in macOS and all its devices, are stored in proprietary tracev3 files, sorted into three folders:

• Persist, containing the bulk of log entries, retained to keep their total size to about 525 MB in about 50-55 files;
• Special, including fault and error categories, whose entries are slowly purged over time until none remain in the oldest log files, so have a variable total size and number.
• Signpost, used for performance measurements, which also undergo slow purging until they vanish.

One simple way to estimate the period for which log entries are retained is to find the date of creation of the oldest log file in each of those folders. On a Mac mini M4 Pro run largely during the daytime, those dates were

• Persist, earliest date of creation 7 March 2026 at 16:54
• Special, 9 February 2026 at 19:41
• Signpost, 3 March 2026 at 16:41

when checked on 10 March. Those indicate a full log record is available for the previous 3 days, followed by a steady decline with age to the oldest entry 31 days ago. That compares with statistical data available in my app Logistician going back as far as 14 January, although all entries between then and 9 February have now been removed and lost.

Retrieving old log entries

The real test of how many log entries have been retained is to try to retrieve them. Although the oldest Special log file was created on 9 February, the oldest log entry I could retrieve was the start of the boot process on 11 February, in Special log files returning a total of over 44,000 entries for that day. However, no further log entries could be found after those until the morning of 24 February, a gap of over ten days.

This chart shows the numbers of log entries that could be found and read at intervals over previous days. Where a total of 500,000 is shown, that means over 500,000 for that 24 hour period. I checked these using two different methods of access, using the OSLog API in LogUI, and via the log show command in Ulbow. In all cases, log show returned slightly fewer than OSLog.

It’s clear that with only 3 days of full Persist log files, very few entries have been retained from earlier than 7 days ago, and beyond that retention numbers are erratic.

Over the period prior to the oldest Persist file, when entries could only be coming from Special log files, those included both regular and boundary types, and categories were diverse, including fault, error, notice and info, and weren’t confined to the first two of those categories. Most subsystems were represented, but very few entries were made by the kernel. There is thus no obvious pattern to the longer retention of entries in Special files.

Ephemeral entries

Log entries are initially written to memory, before logd writes most of them to permanent storage in tracev3 log files on disk.

The first substantial purging of entries thus occurs when logd decides which are ephemeral and won’t be retained on disk. This can be seen by following the number of entries in a short period of high activity in the log, over time, and is shown in the chart below for a sample period of 3 seconds.

When fetched from the log within a minute of the entries being written, a total of 22,783 entries were recovered. Five minutes later there were only 82% of those remaining. Attrition of entries then continued more slowly, leaving 80% after 8 hours. Analysis suggests that over this period in which there were about 6,100 log entries per second written to disk, approximately 1,700 log entries per second were only kept in memory and never written to disk. That suggests about 22% were ephemeral, a proportion that’s likely to vary according to the origin and nature of log entries.

Summary

• A fifth of log entries are likely to be ephemeral, and lost from the log within the first minutes after they’re written.
• Most retained log entries are written in Persist logs, where tracev3 files are removed by age to keep their total size to just over 500 MB. Those should preserve the bulk of log entries for hours or days after they’re written.
• Entries stored in Special log files may be retained for significantly longer, here up to a maximum of 29 days. Although those may contain fault and error categories, retention doesn’t follow an obvious pattern, making their period of retention impossible to predict.
• In practice, the period in which a fairly complete log record can be expected is that applied to Persist files, which varies according to the rate of writing log entries. In most cases now that’s unlikely to be longer than 5 days, and could be less than 12 hours.
• You can’t draw conclusions from the apparent absence of certain log entries from the log prior to the earliest entries in Persist log files, as it’s likely that those entries will have been removed.
• Expecting to retrieve log entries from earlier than 5 days ago is almost certain to fail.

从 2024 年的今天，回望 2019 年的 Apple 和 Ive 团队，我们会发现有些变化和趋势似乎是早已注定的。在过往的观察和分析中，我们所预言的事情正在成为现实和主流。常言道以史为镜可以知兴替，今天再看当时的 Apple 和 Ive 团队，关于产品的演进思路和设计策略的变化都早有端倪，也能预见在 AI 席卷的浪潮下，Apple 将会如何应对。

在这一期，你会听到：

—- 二十年前的专利文件：通体透光的 iPhone

—- 国产厂商和 Apple 在设计上的差异

—- 成功的设计：AirPods 只是剪掉线的 EarPods

—- 塑料手机的设计巅峰：iPhone 5c

—- 刘海与机器视觉：早早布局的 AI 伏笔

—- 未来十年的人机交互：人和人之间怎么交互？

—- 设计策略上的「S型曲线」体现在哪里？

—- 产品路径上迷路的 iPad

—- 光洁的划痕：是矫情还是哲学？

—- 史上最佳手机壳：iPhone 5c 的多彩硅胶壳

—- 拟物化的残党，现在理解扁平化的先进性了吗？

｜相关图片｜

查看更多图片和设计讨论：Mac Pro 2019

｜拓展阅读｜

如何评价 iPhone X 的工业设计？

交互的王，时代的狂！万字详解灵动岛的今生来世！

十年轮回？经典进化！工业设计师深入解读 iPhone12！

从技术寿命 S 曲线，看阳极氧化铝的设计

抽象的产品，用户「界面」的设计

如何看待 Evans Hankey 从 Apple 设计团队离职？

注定会离职的 Jonathan Ive 和科技产品的设计趋势

｜登场人物｜

苏志斌：工业设计师，车联网智能硬件产品经理 / 联创，《设以观复》作者

王汉洋：AI 行业从业者，多档播客主播，《拯救东北1910》《山有虎》作者

｜相关链接｜

若你所使用的播客客户端未能完整显示插图，或遇网络问题未能正常播放，请访问：

荒野楼阁 WildloG 的地址：https://suithink.me/zlink/podcast/

阅读设计相关的各类文章：https://suithink.me/zlink/idea/

｜其他社交网络媒体｜

苏志斌 @ 知乎｜SUiTHiNK @ 即刻 / 微博

苏志斌SUiTHiNK @ Bilibili / YouTube / 小红书

｜联络邮箱｜

suithink.su@gmail.com

欢迎在 小宇宙、Spotify、YouTube、Apple Podcast 收听本节目，期待你的留言。