The use of colour to add meaning to images is longstanding practice, and can be traced back to ancient Egyptians, who tended to use it to distinguish males from females. Most probably the result of their belief system, females were often depicted with paler or even white skin, while men were more swarthy in appearance.

In this fresco of a funeral procession from the tomb of Ramose, dating from about 1353–1336 BCE, there’s a clear distinction in skin colour between the central group of women, and the men on the left and right.

This passed through into the Renaissance.

This can be most apparent in paintings of Adam and Eve, here that made by Maerten van Heemskerck in about 1550, where Eve is as white as ivory.

Annibale Carracci’s Latona and the Lycian Peasants, probably from 1590-1620, shows the near-white goddess Latona placing her curse on the swarthy-skinned locals.

After the Renaissance, this colour-coding largely disappeared, only to return at the end of the nineteenth century.

Evelyn De Morgan’s Boreas and Orithyia from about 1896 shows the darker Boreas, the north wind, bearing the paler Athenian princess Orithyia aloft.

In the early twentieth century, the former Nabi artist Félix Edouard Vallotton painted a series of narrative works, including his Perseus Killing the Dragon, from 1910, a thoroughly contemporary interpretation with a marked contrast in skin colour. This is most evident where their feet are close together at the lower edge of the painting.

Independent of that coding, paintings of hell and devils developed their own colour schemes.

This detail from Giotto’s fresco of The Last Judgment in the Scrovegni Chapel in Padua, Italy, was painted in 1306. It follows the early convention that its humanoid demons are colour-coded blue, with some in brown, in contrast to its densely-packed and near-white victims seen undergoing punishment. There’s no colour-based distinction between men and women here, though.

Luca Signorelli’s large fresco in the San Brizio Chapel in Orvieto shows the seething mass of The Damned (1499-1502). His colour-coding is richer, and there’s precious little sign of flames, fire, or even rocks, just a dense mass of people being tormented.

Bonifazio Veronese’s St Michael Vanquishing the Devil from 1530 shows a dark-skinned humanoid with draconian wings, which may have descended from older images in which the Devil (with the definite article) is shown as a straight dragon. This artist isn’t the great Paolo Veronese, but a Venetian painter whose work influenced Tintoretto.

This visual distinction extends to more recent paintings, including Henry Fuseli’s The Nightmare from 1781. The daemonic incubus seen squatting on the torso of a young woman is swarthy in colour compared to his victim’s pallor.

Ary Scheffer used clear colour coding in his Temptation of Christ, from 1854, where the fallen angel is trying to get Christ to jump from a pinnacle so that he could rely on angels to break his fall.

Most recently, some have tried to interpret this as racialism, but these codings have older origins, and only appear in skin colour, not overall appearance. It would be nonsense to suggest that any of these devils were intended to represent North Africans, for instance.

The versioning system built into macOS for the last 14 years must be among its least used features, with many simply ignoring it, and some even blocking it from working. Yet among those who do use its features, it’s probably used more often than backups, and to greater effect.

A couple of weeks ago, when I was working on the code for AppexIndexer, I realised that the changes I was making to enable its search feature were getting out of hand, and should I need to undo them would have required a lot of work. Because the code editor in Xcode supports macOS versioning, I paused my editing for a few moments, opened that document’s versions and stepped back through them to reach the version saved just before I had started making those changes. I then saved that version as a separate fallback copy and resumed my editing.

All this had happened since the last Time Machine backup, which would have been of little use had I needed to revert all those changes. Even automatic hourly backups are too infrequent to capture changes as we make them in active documents. This is just what the versioning system is intended to capture, although to make best use of it, you’ll need third-party software.

Standard access

Most apps that edit documents now support the macOS versioning system by default. Some allow you to auto-save documents as you’re working on them, but all should create a new version each time you save a document. Normally, you might access saved versions using the Revert To… command in the app’s File menu, where you can Browse All Versions… in a full-screen window resembling Time Machine’s interface to it backups.

Although the design looks impressive, it’s not the only means of browsing a document’s saved versions, and in many respects doesn’t support the power and flexibility in the versioning system.

How it works

Many macOS apps that edit documents are based on AppKit, supporting actions in their File menus including Save and Revert To…. Each time you save a document, that automatically uses the Foundation API to save a copy in the hidden version database located in the folder .DocumentRevisions-V100 at the root of the volume on which that document is stored. When you Browse All Versions macOS finds all the previous versions of that document in the volume’s database and displays them, making them available to revert to. Although document-based apps developed using SwiftUI are still relatively unusual, they too should provide full support for versions and the same menu commands.

This relies on:

• support in the editing app;
• the document being stored in a volume in APFS or HFS+ format; ExFAT, MS-DOS and other file systems don’t normally work, and can’t save versions;
• the hidden folder .DocumentRevisions-V100 containing the local version database for that volume.

Although a document’s versions are normally accessed through an app that can edit that document, that isn’t a requirement, and there are several alternatives that can access and manage any versions, including Versions from the App Store, and my own free utilities Revisionist, Versatility and Deep Tools, whose use I will explain in further articles.

On APFS volumes, the version database appears to use clone files to good effect, in preserving changed storage blocks for each saved version, so using a minimum of space.

How it doesn’t work

The biggest limitation of versions is that they don’t move with the document. When you copy or move a document with versions to a different volume, its versions don’t go with it, although moving it within the same volume preserves them intact. Any document only retains the versions created during its editing on its current volume.

Say you have been working on a file named MyBigDocument when it’s stored in your ~/Documents folder, and there are versions saved for it there. Copy that to an external disk, and that copy now has no versions at all. Edit it there, and it will build its own collection of versions on that disk, but you won’t be able to access those if you open MyBigDocument from your ~/Documents folder. You can use my utilities to move its versions around from volume to volume, or to another Mac, but left to its own devices, macOS doesn’t do that for you.

Versions become complicated in iCloud Drive. iPhones and iPads also use versions, but their behaviour in iCloud storage has changed over time. I will explore current behaviour in Sequoia in a separate article.

One common fear of using versioning is that the database can accumulate a seemingly unlimited number of versions of files, and consume large amounts of space. You can get a good estimate of how large a volume’s version database folder is using the Terminal command
sudo du -sh [pathtovolume]/.DocumentRevisions-V100
followed by authentication. The correct path to use for that on the current Data volume is /System/Volumes/Data/.DocumentRevisions-V100.

macOS doesn’t provide any means of editing what’s stored in the versions database, nor of weeding old versions. On one of my Macs, its internal Data volume currently has several documents for which there are more than 100 versions, with a maximum of 153. However, the versions database on that volume is only 38 MB for a total of more than 35,000 files in ~/Documents.

Practical use

In addition to my example at the start of this article, I quite frequently use versions as an extended undo. Some minutes into an editing session I might realise that an earlier change such as deleting paragraphs needs to be undone. Rather than working my way back through a long series of Undo commands, the easiest way to fix that is to open the document’s versions using Revisionist, locate an earlier version containing the deleted paragraphs, copy those from that version and paste them into the current document that I’m editing.

Some documents have important previous versions that I want to preserve when I move them across to another Mac or to external storage. For those I drag and drop the document onto Versatility to create a folder containing all that document’s versions, move that to the other Mac, and drop that folder onto Versatility there. That recreates the original document with all its versions stored safely in its new location.

When certain documents have been very active, and are now complete so I don’t want to preserve all those old versions, I can clear them all by moving that document to another volume, and moving it back again. If I want to reduce the versions but keep some of them for posterity, then I open them using Revisionist and delete the old versions I don’t want to retain any longer.

Most important of all, I know that so long as I have saved a document, if I want to recover any previous version I can do so using Revisionist without having to look through my Time Machine backups. With macOS versioning, Command-S doesn’t just save my work, it also maintains that document’s change history.

Key points

• Many apps support macOS versions. They normally feature a Revert To… command in their File menu, although not all do.
• Save (Command-S) creates a new version of a document automatically, and maintains its change history.
• Use additional apps like Revisionist and Versatility to get the most out of versions.
• A document’s versions don’t move with it to another volume or Mac, but can be preserved using Versatility.
• Documents can accumulate a large number of versions when they’ve been saved many times.
• Delete all a document’s versions by moving it to another volume, then moving it back again.
• Using versions gives you finer detail of changes that are lost in backups.

Macareus, one of the survivors from the Odyssey, has been giving his account of the sojourn of Ulysses and his men on Circe’s island. Having told of their arrival and transformation into pigs, he concludes with a cautionary tale of what happens to those who don’t submit to Circe’s desires. One of Circe’s assistants showed Macareus a marble statue of a youth with a woodpecker on his head. When Macareus asked why that was in the shrine, the assistant explained that it all came about as a result of Circe’s magic powers.

Picus had been the king of Latium, and drew admiring glances from nymphs wherever he went. He fell in love with a beautiful young woman who sang so wonderfully that she was named Canens (Latin for singing), and they lived together in marital bliss. One day when Picus was out hunting on his horse, Circe caught sight of him from the undergrowth. Her desire for him was immediate and intense, so she worked her magic to lure the king into a thicket, in pursuit of a phantom boar she had conjured up.

Circe confronted him and told him of her desire, but he refused her in faithfulness to Canens. Despite Circe repeatedly pleading with him, Picus stood firm and refused her time and again. The sorceress became angry, warning him that he would pay for his obstinacy and would never return to his bride. She cast a spell and touched him with her wand, transforming him into a woodpecker.

When his courtiers searching for the king, they stumbled into the sorceress, and accused her of being responsible for his disappearance. She promptly transformed each of them into a wild animal as well. Picus’ wife Canens was beside herself with worry, and roamed the countryside looking for her husband. She pined away in her grief and vanished into thin air at a place now named after her. With that Macareus concludes his story.

The only dedicated account available of this myth is Luca Giordano’s Picus and Circe, probably painted around 1670. This shows Circe trying to seduce Picus, and the king resisting her advances. By their expressions, she has just told him that he will pay for his refusal, and is working her magic to transform him into a woodpecker. Already he has grown feathery wings, and at the upper right there is the silhouette of a woodpecker as an ominous reminder of the fate that awaits him at any moment.

There are more paintings showing Circe in the company of various enchanted birds and animals, including the former King Picus. Two of the more remarkable examples are both by Dosso Dossi, one painted in about 1515, the second probably fifteen years later.

Dossi’s Circe and her Lovers in a Landscape (c 1514-16) is a remarkably early and realistic mythological landscape, with deep rustic lanes, trees, and a distant farmhouse. Circe leans naked at the foot of a tree going through spells on a large tablet, with a book of magic open at her feet. Around her are some of the men who she took a fancy to and transformed into wild creatures. There’s a spoonbill, a small deer, a couple of dogs, a stag, and up in the trees an owl and what could well be a woodpecker, in the upper right corner.

Dossi’s later painting of Melissa (Circe) (c 1518-1531) is also set in a richly detailed landscape. Circe sits inside a magic circle, around which are inscribed cabalistic words. In the upper left corner are small homunculi apparently growing on a tree. On the left is a large dog, and perched on top of a suit of armour is a bird, most probably a woodpecker.

Once Aeneas has buried his nurse in a marble sepulchre, he and his crew set sail on the final leg of their journey from Troy to Latium in Italy.

Once they arrive, Aeneas and his former Trojans have to fight Turnus, king of the Rutuli, for Latinus’ throne and the hand of Lavinia in marriage. This proves a long and bitter struggle, in which Aeneas is aided by others, but among those who refuses to assist him is Diomede in Apulia. In defending his refusal to aid Aeneas, Diomede tells the story of his return from the Trojan War, which proved a desperate journey. His colleague Acmon had rashly speculated what more Venus could have done to harm them, and taunted her, for which she transformed them all into white seabirds. Venulus, Aeneas’ envoy to Diomede, also saw a grotto where a shepherd had offended Pan and been turned into an oleaster tree.

Antonio Tempesta’s etching of Acmon and his Friends Changed into Birds by Venus from about 1600 is the only pictorial representation that I have been able to find of that story told by Diomede, and for its period it tells it well.

During the war with Turnus, enemy forces are sent to burn Aeneas’ fleet of ships. As they were built with pinewood frames, they burned well. But Juno intervenes, brings a hailstorm, drags the burning ships underwater, and transforms them into sea-nymphs. The city of Ardea falls to Aeneas when he kills Turnus, and from its ashes and ruins comes the heron.

The single illustration that I have been able to find of the transformation of the burning Trojan ships into nymphs comes from one of the most precious documents featured in this series: the Vergilius Vaticanus manuscript of Virgil’s works dating back to about 400 CE. Three ships are seen already transformed into the head, arm, and body of nymphs at the far right, although there is no sign of any fire or hailstorm. The left and centre show Aeneas fighting Turnus.

The Vergilius Vaticanus is very special, as one of the oldest surviving sources for the text of the Aeneid, and one of only three ancient illustrated manuscripts containing classical literary works. At one time it belonged to Pietro Bembo, an Italian scholar who is commemorated in the font name.

Luca Giordano’s Aeneas and Turnus from the late 1600s is one of the few paintings showing the battle between Aeneas and Turnus. The Trojan hero here has Turnus on the ground, under his right foot. At the lower left is one of Aeneas’ ships, which hasn’t been transformed into a nymph. Venus, Aeneas’ mother, and Cupid, his half-brother, are at the upper left, and the goddess at the upper right is either Minerva (with her owl), or Juno; as losers in the Judgement of Paris, both bore a grudge against the Trojans.

With the end of Aeneas’ life drawing near, his mother Venus campaigns among the deities for him to be transformed into a god when he dies. They agree, as do Jupiter and Juno, allowing Venus to descend in her chariot drawn by doves. Aeneas is then washed thoroughly by the river Numicius before the goddess anoints him with nectar and ambrosia to transform him into the new god Indiges.

Peter Candid’s Aeneas Taken to Olympus by Venus from around 1600 shows Venus at the right, in her chariot with Cupid, anointing Aeneas, on the left, with nectar and ambrosia. Above them is the pantheon, arrayed in an imposing semicircle, and above them Jupiter himself, clutching his thunderbolts and ready to receive the new god.

Tiepolo’s sketch for a fresco ceiling in the Royal Palace in Madrid, The Apotheosis of Aeneas from about 1765, is another impressive account. The artist made this a little more elaborate by combining the apotheosis with the presentation of arms to Aeneas by his mother Venus. Aeneas is to the left of centre, dressed in prominent and earthly red. Above and to the right of him is his mother, Venus, dressed in white, ready to present the arms which have been forged for him by Vulcan, her partner, who is shown below supervising their fabrication. Aeneas’ destination is the Temple of Immortality, glimpsed above and to the left of him, through a break in the divine clouds.

Ovid then lists successive rulers of Latium and Alba, the city founded by Aeneas, up to the reign of King Proca, the setting for his next story.

I hope that you enjoyed Saturday’s Mac Riddles, episode 305. Here are my solutions to them.

1: One on each hand stores in a flash for a receptacle.

2: Flexible back component spun until the millennium.

3: Fastener for super 2 until its click of death.

The common factor

I look forward to your putting alternative cases.

Comparing Macs by their clock speed, the frequency of their CPU, can mislead badly. Because my Intel Mac has 8 cores running at 3.2 GHz doesn’t bring it close to the 6 P-cores running at 4.1 GHz in my M3 Pro, or even its 6 E-cores ambling along at no more than 2.7 GHz. One everyday function where you may notice this most is in computation of hashes.

Although not something we often choose to do, parts of macOS rely on that, and make the difference apparent in everyday tasks, like opening an app. This article explains how older Macs can perform poorly relative to Apple silicon models, and how that can affect you. It also brings an update to my integrity-checking utility Dintch that you may find interesting.

Checking hashes

Although we associate code signing with security certificates, as I pointed out in my brief history, in recent years its use has come to focus more on CDHashes within the signature, as a means of identification and verification of executable code.

Checking the integrity of files such as those containing executable code is simplest performed using a checksum, by adding all the data together as if it were mere numbers, using modular arithmetic, and comparing that sum with what’s expected. The snag with doing that using checksums is that they can all too easily result in false negatives, and fail to detect changes. More sophisticated checksums (Fletcher 64) are used to verify file system metadata in APFS because of their ease and speed of computation, but they’re not strong enough to use for security.

Their replacement for security purposes is the family of hash functions known as Secure Hash Algorithms. SHA-1 uses 160 bits, but was withdrawn from use after weaknesses were discovered, and replaced in most uses by SHA-256. That uses a more complex method to generate a 256-bit number using a one-way process, so there’s no way you can tell what the original contained from its hash, and each hash can fairly safely be assumed to be unique.

Inside each macOS code signature is a data structure containing SHA-256 hashes for all the code and other data protected by that signature, and that code directory is itself hashed to produce Code Directory Hashes, CDHashes (or cdhashes if you prefer). macOS security systems check the integrity of the code directory by comparing its saved CDHashes with fresh hashes of its contents, and can check the integrity of the code itself by comparing its hashes in the code directory with fresh hashes of the contents. There’s a lot of hashing going on.

Hashing performance

We tend to take hashing for granted and assume that it just happens almost instantly. In fact, even when optimised in the likes of CryptoKit in macOS it’s computationally intensive, and throughput can be significantly slower than that of reading data from a fast SSD. To compare SHA-256 hashing performance on a range of Macs, I have modified my free file integrity utility Dintch to report the time taken by hashing operations. Details of this new version are given below.

I created files of standard sizes between 1 MB and 10 GB, tagged them with SHA-256 hashes using Dintch, then checked those hashes with time measurements. To check hashes, Dintch streams a file from disk while CryptoKit computes the hash on that stream, as shown in the source code in the Appendix at the end. Another advantage of using Dintch is that it has control over which CPU cores it’s run on, in Apple silicon Macs, by setting the QoS for that thread.

My iMac Pro proved far slower than either a MacBook Pro M3 Pro or Mac mini M4 Pro, even when the hashing was performed at minimum QoS and run on the E cores of the latter two Macs. At its fastest, with a high QoS, the iMac Pro took 2.4 seconds to hash a 1 GB file, which took only 2.1 seconds on the M3 Pro’s E cores, or 0.34 seconds on the M4 Pro’s P cores. Other results are illustrated in the chart below.

This shows times required to hash files of between 1 and 100 MB size, with linear regressions fitted with additional values for 1 and 10 GB. Points and lines in red are those at high QoS, and those in blue at low QoS. The iMac Pro points are filled circles, those for the M3 Pro crosses, and the M4 Pro open diamonds. The upper pair of lines are from the iMac Pro, and slower than even the E cores in the M3 Pro. The almost coincident lines closest to the X axis are those for P cores in the M3 Pro and M4 Pro.

Converting those regression coefficients into hashing rates gives the following:

• iMac Pro 0.41 / 0.18 GB/s (fast / slow)
• M3 Pro 2.71 / 0.52 GB/s
• M4 Pro 2.92 / 0.64 GB/s.

All of these rates are slower than the read speeds of the SSD containing the files being hashed, indicating that performance limitation is the result of the hash computation.

Mitigations

When looking at slow launches of apps, I recently used Pages and Calibre as examples. If they were required to undergo full verification of their stored CDHashes, including the whole protected contents, that would take significant time. Considering just the Frameworks folder in Pages’ app bundle, that amounts to nearly 250 MB, taking well over 0.5 seconds running at high QoS on an iMac Pro, but that could be less than 0.1 seconds on an M4 Pro.

Although the Mach-O binaries in Calibre’s MacOS folder are only just over 2 MB in size, its Frameworks folder is almost 1 GB, so would take over 2.5 seconds on the iMac Pro, but only around 0.4 seconds on the M4 Pro.

In practice such hefty computational tasks are avoided. macOS uses cached values for hashes as much as possible, and doesn’t appear to verify the whole protected contents of its CDHashes even during first run security checks. Hashes for protected contents are also saved in the code directory in per-page form, so that each page can be verified individually, without having to compute the hash for an entire Mach-O binary. As explained in Apple’s Tech Note, “This allows the system to run a code-signed executable and check its code signature lazily (in the computer science sense of that word).” “macOS doesn’t always check code as it’s paged in.”

But when a hash does need to be verified, expect substantial performance differences between Macs that might appear to have similar numbers of cores and clock frequencies.

Dintch 1.7

Dintch is one of three components of my file integrity system. This new version is recommended for those running Big Sur and later, as it optimises code for those more recent versions of macOS, and for Apple silicon Macs.

In addition, this new version 1.7 shows the time taken to check each file that has already been tagged with a SHA-256 hash. Even if you don’t want to use the app to protect file integrity, it can provide you with SHA-256 performance figures. To do that, click on the Tag button and select the folder whose files you want to use in the test. Once they have been tagged, tick the Verbose option, click the Check button and select that folder. The app’s window will show the time taken to check the SHA-256 hash on each tagged file in that folder. You can then compare the performance of your Mac against the figures I have given above for my Macs.

Dintch 1.7 is now available from here, for Big Sur and later: dintch17
from Downloads above, its Product Page, and via its auto-update mechanism.

Its siblings are:
Fintch 1.3 (Universal App for High Sierra to Sequoia) for drag-and-drop use on small folders and individual files, and
cintch 3 (Universal binary for Big Sur to Sequoia), a command tool with similar features.
Fuller details are on their Product Page.

Enjoy!

Reference

Apple TN3126: Inside Code Signing: Hashes

Appendix: Source code

This uses CryptoKit to hash a file stream using a buffer of size theBufferSize.

func getHash(thePath: String) -> SHA256Digest? {
var hasher = SHA256()
var theDigest: SHA256Digest?
if let theFileStream = InputStream(fileAtPath: thePath) {
theFileStream.open()
let theBuffer = UnsafeMutablePointer.allocate(capacity: theBufferSize)
while theFileStream.hasBytesAvailable {
let read = theFileStream.read(theBuffer, maxLength: theBufferSize)
if read >= 0 {
let theBufferPointer = UnsafeRawBufferPointer(start: theBuffer, count: read)
hasher.update(bufferPointer: theBufferPointer)
}
}
theDigest = hasher.finalize()
theBuffer.deallocate()
theFileStream.close()
}
return theDigest
}

In the first of these two articles, I showed some of the series of Pre-Raphaelite landscapes painted by John Brett (1831–1902) prior to 1870. This article continues by looking at his paintings from 1871 onwards. By this time, Brett had the first of his yachts, enabling him to concentrate on painting the British coastline in a style that progressively departed from the Pre-Raphaelite.

In the summer of 1870, Brett sailed around the south-west coast of England making detailed notes, sketches, and studies as he went. The British Channel Seen from the Dorsetshire Cliffs (1871) is a large canvas apparently painted from those during the later part of that year. Although not geographically specific in any way, it’s thought to have been painted from the cliffs above Lulworth Cove in Dorset. When it was exhibited at the Royal Academy, debate was focussed on whether the azure colour used for the sea was appropriate.

A couple of years later, Brett painted another large maritime canvas of A North-West Gale off the Longships Lighthouse (1873), in which the lighthouse and rocks are the only clues as to its location. Again it was painted in his studio after notes and preparatory sketches, and was well-received when exhibited at the Royal Academy that year.

Southern Coast of Guernsey (1875) was the smaller of two substantial canvases painted after Brett’s cruise around the Channel Isles in the summer of 1874, and shows his returning interest in the coastline. Exhibited at the Royal Academy in 1875, Ruskin wrote a mixed comment, criticising its loss of subtlety and size, but complimented Brett on the atmosphere of its extreme distance, and his “science” in alternations of colour.

Brett’s superb view of Caernarvon (1875) does appear to have been completed in front of the motif, during his summer campaign around the Welsh coast that year, being significantly smaller and dated in October. It conforms more strongly to his earlier Pre-Raphaelite style, with intricate detail in the foreground waterfront, bright colours, and geological passages.

He continued to paint some pure seascapes, such as the highly successful Britannia’s Realm (1880), although by now these were products of his studio in Putney, London, and based on earlier notes and sketches. Exhibited at the Royal Academy in 1880, this was purchased ‘for the nation’ from the Chantry Bequest even before it had been seen by the public. As a result, he was able to order a larger yacht, and spent the summer painting the rugged coast of Cornwall in more Pre-Raphaelite style. He was elected an Associate of the Royal Academy the following year.

On the Welsh Coast (1882) is an example of one of his smaller oil sketches from this time: a fine painting, but by now quite divorced from his Pre-Raphaelite beginnings.

A few of his later paintings did hark back to his works showing the Italian coast: Man of War Rocks, Coast of Dorset (1884) is smaller than his large commercial canvases, and returns to Pre-Raphaelite characteristics of foreground detail, meticulous geology, and bright colours.

It isn’t as clear how much, if any, was painted in front of the motif. Much seems to have been based on notes and a watercolour sketch made back in 1870, before Brett had started producing his lucrative seascapes.

In his later years, Brett painted more coastal views, some of which were as good as earlier, but generally their quality declined with time. Like his Seascape (1887), they became more formulaic and less inspired, and were far from Pre-Raphaelite. However, Brett was probably the only artist to have built his reputation on Pre-Raphaelite landscape paintings, and was almost certainly the last of that rare breed who continued painting pure landscapes in Pre-Raphaelite style.

References

Barringer T (2012) Reading the Pre-Raphaelites, revised edn, Yale UP. ISBN 978 0 300 17733 6.
Newall C (2012) Review of Payne (2010), Burlington Mag. 154, July 2012, pp 498-499.
Payne C (2010) John Brett: Pre-Raphaelite Landscape Painter, Yale UP. ISBN 978 0 300 16575 3.
Prettejohn E (2000) The Art of the Pre-Raphaelites, Tate Publishing. ISBN 978 1 854 37726 5.
Staley A (2001) The Pre-Raphaelite Landscape, 2nd edn, Yale UP. ISBN 978 0 300 08408 5.

I looked in the macOS cupboard last week and opened yet another can of worms, in those Macs that take many seconds or even minutes to launch some apps. In common with many other thorny problems, there’s little consensus about many of the details, other than this mostly affecting Intel Macs running macOS Big Sur or later, although I have seen reports of similar problems in M1 Macs.

Although some have apparently found solutions, such as Jeff Johnson’s recommendation to disable SIP, the only consistent answer appears to be moving the app to another location and moving it back again. Even that’s only a temporary measure, and sooner or later those apps will launch slowly again.

Last week I thought I might have a chance to get to the bottom of the problem, when Kristian kindly sent me some log extracts from his Mac’s slow launches, and patterns started to emerge. But like every other good can of worms, the deeper I dig into the can, the more worms there are. This article is a convenient opportunity to reveal some of those.

What takes time?

Looking at three test launches of Pages, greatest differences were seen in the time taken to check the many frameworks in the app bundle, shown in purple in the bar chart below.

In the slow launch provided by Kristian, total time was just over 4 seconds, within which checking frameworks took 3.2 seconds, 80% of launch time. A similarly slow launch in my test VM took just over 3 seconds, with 2.5 seconds on frameworks, while a fast launch completed in just over half a second, with less than 0.1 seconds spent in framework checks.

Cache misses and SIP

What I didn’t mention in those log extracts was the role of cache misses in framework checks in the slower launches. At that stage, it looked as if differences were down to whether each framework had to be checked from scratch as its previous assessment couldn’t be found in cached security checks.

I have therefore repeated the VM tests in two further conditions, with SIP disabled, and with Gatekeeper/XProtect checks disabled.

When launched after a restart, with SIP fully disabled, Pages did indeed launch quickly, in a total time of 0.34 seconds with less than 0.05 seconds checking frameworks. However, disabling Gatekeeper resulted in a total launch time that was only slightly quicker than normal at 2.4 seconds, and 1.8 seconds checking frameworks.

Behaviour with SIP turned off was odd, in that no Gatekeeper process assessment was recorded, and there was no mention of any cache misses for framework checks. In contrast, when Gatekeeper was turned off, there was a Gatekeeper process assessment using a previous code evaluation, and cache misses were recorded for all the frameworks checked. My previous experience with disabling Gatekeeper is that its checks still take place and are logged normally, but their results are ignored, so that wasn’t as paradoxical as it might appear.

Calibre

Pages is an atypical example, being an App Store app signed by Apple, so I then turned to the other log record provided by Kristian, from Calibre. This is remarkable for having 68 frameworks, and took a total of 4.6 seconds to launch on his Mac, with nearly 4.4 seconds of that spent checking those frameworks, all of which were cache misses and reported with constraint violations by amfid.

When I tried repeating this in my test VM and with SIP or Gatekeeper disabled, results became far more complicated, so I have summarised them in a table.

Rows in this table record results from each of six launches of the current release of Calibre. The first is that obtained by Kristian on his Mac, the remainder are all obtained from a 4-core VM running macOS 14.7.5 on a Mac mini M4 Pro. Those were:

• first run after installation, with the quarantine flag set;
• second run a minute or so after that first run, without a restart;
• third run after closing the VM and starting it up again;
• after downgrading security to permissive by disabling SIP completely;
• after disabling Gatekeeper/XProtect checks, but still at Full Security, with SIP enabled.

Total launch time is measured from the initial click in the Finder to the app loading its preferences. Time checking frameworks is measured from the start of the first check called by amfid on one of Calibre’s frameworks, to the completion of the its check on the last framework. XProtect scan is measured between the announcement of the start of Gatekeeper’s XProtect scan, and its completion.

The fastest launch by far was in the second run, when none of the checks were performed, there were hardly any log entries from security subsystems or processes, and it completed in 0.158 seconds. The slowest was the first run, when the XProtect scan took over 6 seconds, and accounted for 77% of the total launch time of almost 8 seconds.

Remaining results fall into two groups: Kristian’s original slow launch, with almost 4.4 seconds taken checking frameworks, all of them being recorded as cache misses, and the three VM tests. The latter were remarkable as launch time was uniform at just over 0.5 seconds, and a fifth of the time spent checking frameworks. That occurred because macOS proceeded to run the app before checking of frameworks was complete. In those three tests, no cache misses were recorded, and time was independent of whether a previous Gatekeeper assessment was used. Two of them even included brief local checks against the app’s notarization ticket.

Neither disabling SIP nor disabling Gatekeeper had any effect on the time taken to check frameworks, nor on the total time taken to launch the app.

Diagnosing slow launches

I have given details of my results because, if there’s one thing they demonstrate, it’s the complexity of determining app launch times. In Pages, much of the delay seems to result from cache misses slowing framework checks, and disabling SIP restored rapid launching, as Jeff Johnson reported. In Calibre, launches proceed without waiting for framework checks to complete, and disabling SIP doesn’t result in any acceleration.

This reflects the complexity of app launch. I’ve here concentrated on security checks, as they have been most commonly blamed for this problem. Other processes that have to be completed during launch include:

• LaunchServices registration and coordination
• RunningBoard registration and resource management
• TCC privacy controls
• sandbox and container preparation
• iCloud connection
• checks for app updates
• all other app initialisations

several of which can involve their own security checks.

Although most of those are well recorded in log entries, disentangling them when watching Activity Monitor or in spindumps is more demanding, and there’s ample opportunity to gain false impressions.

But none of these tests or logs represent what happens in the slowest of launches that can take several minutes. Even the 8 seconds total launch time taken on Calibre’s first run pales in comparison to the 300 seconds that some report. There’s a difference of two orders of magnitude, suggesting that really long launch times are different from all the observations and measurements here. There must be something seriously wrong for an app to take several minutes to launch. Investigating that is also a great challenge.

Tackling slow launching

Results above demonstrate how subtle factors can result in fairly modest apps launching in anything from less than 0.2 to almost 8 seconds. If an app regularly takes several seconds to launch, and that irks you, try pre-warming it first. Longer times are more likely to occur after a Mac has been started up from cold, and apps usually launch fastest when they’ve already been run in the same session. Even if your Mac doesn’t have sufficient memory to leave that app running, that could make subsequent launches quicker.

If an app not infrequently takes more than 30 seconds to launch, then finding the cause becomes more important, and if it takes several minutes, you really need to investigate further.

Capturing an excerpt of the whole log for several minutes isn’t going to help, but will just overwhelm you with many MB of inscrutable data. If you know your way around spindumps, you may find them helpful, although they too can only cover brief periods of time. There are some basic steps you can take that can also help you diagnose and address performance problems more generally:

• Measure launch time carefully and record it. Counting icon bounces in the Dock is better than nothing, and gives you an objective measure of time to launch.
• Try in Safe mode. That disables most customising software, and any improvement in launch times points the finger at extensions, startup items and other software you have installed.
• Create a new user and see if that account has the same problems. This can detect user-specific customisations that might be the cause.
• Build an external bootable SSD with a ‘clean’ system, install the app(s) there, start up from it, and see whether it still launches as slowly. You can also try this using a more recent version of macOS, to see whether that helps.

The best way to preserve a record of what happened during a slow launch is to wait until the app is running properly, then perform a sysdiagnose, as that saves much of the log in a logarchive. You can initiate that in the Options … popup menu in Activity Monitor, or by pressing Command-Option-Control Shift-. (period or full stop). That logarchive can be browsed using Ulbow or even Console, but not (yet) LogUI.

I’m also keen to look at log records from one of these much slower launches. If you’re interested in cooperating, please comment below or send me an email (see the About page).

By about 1862, most artists had abandoned trying to paint Pre-Raphaelite landscapes because of their impossible demands. To conform to the prescriptions of critic John Ruskin required long weeks painting painstaking details of a view in front of the motif, and an independent income. The only artist who proved able to sustain this was John Brett (1831–1902), who continued to produce paintings conforming to Ruskin’s ideals and keeping the same ‘look’ until at least 1870. This weekend’s two articles look at those exceptional landscapes, and how they changed later.

Brett was a relative latecomer to the Pre-Raphaelite circle. Although he and his older sister Rosa started painting professionally from about 1850, John Brett wasn’t admitted to the Royal Academy Schools for training until early 1853, by which time the Pre-Raphaelite Brotherhood was dissolving. When in London, he made contact with artists of the Pre-Raphaelite movement, and discussed their art and techniques with Holman Hunt in particular. He read Ruskin, and admired the paintings of John Constable.

After painting portraits to bring in some income, he went to Switzerland in the summer of 1856, where he ascended to the glacier above the village of Rosenlaui, and painted his first real landscape work.

Glacier of Rosenlaui (1856) is an extraordinarily accomplished first landscape painting. Influenced by the fourth volume of Ruskin’s Modern Painters, and the nearby work of John William Inchbold, who was painting about ten kilometres away at the time, it appears to have been painted entirely en plein air, in front of the glacier. Despite its great detail, particularly in the foreground, as prescribed by Ruskin, he signed and dated it 23 August 1856.

He also painted a few impressive watercolours before returning to England. In December, this painting had impressed Dante Gabriel Rossetti and Holman Hunt, and had even received praise from Ruskin himself. But the painting didn’t sell.

The following summer, Brett started work on a less technically-challenging and hopefully more marketable painting, which was possibly inspired by Gustave Courbet’s now-lost painting of stonebreakers, first shown in 1851.

The Stonebreaker (1857-58) was painted closer to home, at a popular beauty spot in the south of England, near Box Hill, which dominates the distance. The milestone at the left shows the distance to London as 23 miles, and David Cordingly considers this places it along a historic track known as Druid’s Walk, leading from the Pilgrim’s Way over the Leatherhead Downs to Epsom and London.

This time, perhaps following his experience in Switzerland, Brett made extensive sketches and studies of the motif, worked on the final oil painting for at least twenty days en plein air, but then completed it in the studio during the following autumn and winter. The painting was shown at the Royal Academy in 1858, where it aroused considerable critical interest.

In the summer of 1858, Brett set off again to the Alps, where he ended up painting a second remarkable mountain view, this time at Val d’Aosta in north-west Italy.

Val d’Aosta (1858) was painted from a hill about a kilometre north-east of where Brett was lodging, according to Christopher Newall. In contrast to Glacier of Rosenlaui, Brett augments the geological details in the foreground with a sleeping woman and a brilliant white goat. Surprisingly, it omits the fortress of Châtel Argent and the Château de Saint-Pierre, although they appear in sketches he made at the time. The only buildings shown are smaller rustic farms and dwellings, set among finely detailed orchards, vineyards, and pastures.

Probably started in a series of studies and sketches, Brett seems to have worked on the oil version in front of the motif, then brought it back to England for completion during the late autumn of that year. He considered it finished by Christmas, and it was exhibited at the Royal Academy in 1859. Ruskin’s remarks were uncommitted, and the artist wasn’t made a single offer for its purchase.

Brett then tried for success with figurative and genre painting, and it wasn’t until 1861 that he returned to attempt any more proper Pre-Raphaelite landscapes. He first visited Florence in November 1861, and a year later left England to work on his next major work, a view encompassing almost the whole of the city that had been the cradle of much of the southern Renaissance.

He probably started on Florence from Bellosguardo (1863) in January 1863, and painted without the aid of significant preparatory studies, working entirely from the motif. Even with Brett’s apparent eye for fine detail at a distance, much of it must have been painted with the aid of a telescope, and it has been suggested that he may also have used a camera lucida and/or photographs. Regardless of how he managed to paint such great detail, it’s a triumph of painting, both technically and artistically, and it came as a shock when it was rejected by the Royal Academy in 1863.

Thankfully for Brett, the painting was purchased in May that year by the National Gallery, and he was acclaimed in the press as “head of the Pre-Raphaelite landscape school”, although by that time he must have been the last of its practitioners. Brett had also intended the painting as homage to the Brownings, as he had enjoyed the support of Robert Browning through that difficult period.

Brett didn’t hang around in England after this, but later that summer was back in Italy working again.

Near Sorrento (1863) is a watercolour that Christopher Newall believes to have been painted from the Via del Capo, and shows the coastline at least five kilometres from that point, making it almost certain that its fine foreground detail was painted with the aid of a telescope. It still conforms to the basic requirements of a Pre-Raphaelite landscape, with fine detail, bright colours, and its careful rendering of geology.

Massa, Bay of Naples (1863-64) is perhaps the most spectacular of the oil paintings Brett completed during this Mediterranean campaign, and appears to have been painted from a vessel on the water.

He had travelled there on board the SS Scotia, although it’s unclear whether that ship served as his floating studio, or he transferred to another vessel. The Scotia arrived in the Bay of Naples by 9 September, following which he went to stay in Sorrento, then on to Capri by November. It’s therefore probable that he continued to work on this canvas during the following winter.

To his delight, Alfred Morrison bought this painting on 6 May 1864, for the substantial sum of £250, although Morrison may actually have paid in guineas. Brett was to benefit further from Morrison’s generous patronage, and by August in 1865 could afford to buy his own yacht. That enabled him to concentrate on painting in British waters.

During the winter of 1865-66, Morrison remained on or near the Isle of Wight, where Brett’s new boat had been built. He painted two watercolour landscapes of the Island, of which only February in the Isle of Wight (1866) has been traced. Although a superb painting, its style is starting to drift away from the principles laid down by the Pre-Raphaelites.

References

Barringer T (2012) Reading the Pre-Raphaelites, revised edn, Yale UP. ISBN 978 0 300 17733 6.
Cordingly D (1982) ‘The Stonebreaker’: an examination of the landscape in a painting by John Brett, Burlington Mag. 129, March 1982, pp 141-145.
Newall C (2007) ‘Val d’Aosta’: John Brett and John Ruskin in the Alps, 1858, Burlington Mag. 149, March 2007, pp 165-172.
Newall C (2012) Review of Payne (2010), Burlington Mag. 154, July 2012, pp 498-499.
Payne C (2010) John Brett: Pre-Raphaelite Landscape Painter, Yale UP. ISBN 978 0 300 16575 3.
Prettejohn E (2000) The Art of the Pre-Raphaelites, Tate Publishing. ISBN 978 1 854 37726 5.
Staley A (2001) The Pre-Raphaelite Landscape, 2nd edn, Yale UP. ISBN 978 0 300 08408 5.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: One on each hand stores in a flash for a receptacle.

2: Flexible back component spun until the millennium.

3: Fastener for super 2 until its click of death.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Mac OS didn’t require or even support the signing of apps or executable code for its first 23 years. Apple announced its introduction at WWDC in 2006, and it appeared in Mac OS X 10.5 Leopard the following year. This happened in conjunction with the release of the first iPhone, on which only code signed by Apple could be run, and could be the first instance of an iOS feature being implemented in Mac OS.

In Mac OS, it was an Apple engineer known as Perry the Cynic, probably Peter Kiehtreiber, who claimed to have been responsible. As he told Jeff Johnson later, “I do work for Apple, and I designed and implemented Code Signing in Leopard. If you think it’s going to usher in a black wave of OS fascism, you have every right to blame me – it was, pretty much, my idea.”

Third-party developers were rightly concerned about Apple’s plans. In 2008, developers were told that “signing your code is not elective for Leopard. You are *expected* to do this, and your code will increasingly be forced into legacy paths as the system moves towards an ‘all signed’ environment. You may choose to interpret our transitional aids as evidence that we’re not really serious. That is your decision. I do not advise it.”

Despite those ominous remarks, it wasn’t until Gatekeeper was introduced in 2012 that code signing became of general importance. With Gatekeeper came the quarantine of apps downloaded from untrusted sources, and first run checks made on all quarantined apps, including ascertaining signing identity and code integrity.

Certificates

From the outset, there were two types of code signature: self-signed using an ad hoc certificate that has no chain of trust back to a root, and those using a certificate traceable back to Apple’s root certificate. While ad hoc certificates can provide a weak form of identification, almost all the value of code signing requires traceability to a certificate authority.

Apple therefore provides registered developers (who pay an annual subscription) with certificates for signing their code, but macOS doesn’t recognise certificates provided by any other authority. Certificates are also specific to their purpose: those used to sign apps for distribution outside the App Store, for example, are known as Developer ID Application certificates, and are distinct from those used to sign installer packages.

Until 2018-19, macOS stored information about valid certificates in a local ‘Gatekeeper’ whitelist database at /private/var/db/gkopaque.bundle, updated every couple of weeks. Since the release of macOS 10.15 Catalina that became effectively disused and wasn’t updated after 26 August 2019. Gatekeeper started performing online checks, to determine whether a certificate had been revoked by Apple as the certificate authority, probably from before El Capitan in 2015, but until Catalina those were only performed on quarantined apps undergoing their first run. From around July 2019 and macOS 10.14.6 those were extended to include apps that had already cleared quarantine.

Checks with Apple to verify certificates are made using the Online Certificate Status Protocol, OCSP, which came under fire in November 2020, when Apple’s OCSP service failed, leaving many unable to launch apps. It was subsequently realised that online checks weren’t encrypted and could have been used by man-in-the-middle attacks to identify users and their apps. Although Apple made some changes, its initial promises don’t appear to have been fulfilled.

CDHashes

When code signing was introduced, most attention was paid to the certificates it required, although Apple also stressed the importance of the cryptographic hashes in the code directory that’s actually signed. This is a data structure containing hashes for pages of executable code, resources, and metadata such as entitlements and the Info.plist property list, that are protected by the signature. The hash of each code directory is known as a cdhash, although here I’ll perversely refer to it as a CDHash for readability.

CDHashes were originally computed using SHA-1, but that was replaced by SHA-256 in macOS 10.12 Sierra, when SHA-1 became deprecated. Apps signed to work with 10.11 and earlier will therefore contain SHA-1 hashes, in addition to SHA-256 hashes if they’re intended for 10.12 and later.

Because hashes are unique and sensitive to the slightest change in data, they have become increasingly used to check the integrity of signed apps and code, and to identify it. Make a tiny change in a signed app’s Info.plist and a CDHash check will report the error and refuse to open that app.

Errors detected following launch normally result in macOS crashing the app, with a code signing error.

Privileges and entitlements

From the outset, code signatures have been used by Apple to determine access to some privileges. Among those were keychain access, code injection, access to an app sandbox, and Parental Controls. Since then, they have extended to include kernel extensions and many controlled features such as the ability to use snapshot features in APFS, and even access to bridged networking in virtualisation on Apple silicon.

This was anticipated by Mike Ash in 2008, when he wrote “Perhaps initially there will be some APIs which are only available to signed applications. At some point Apple will decide that there are some areas of the system which are too dangerous to let anyone in, even when signed. Perhaps you will begin to need Apple approval for kernel extensions, or for code injection, or other such things.”

Mach-O binaries

Code signatures are suited to the app bundle structure, where they can be stored in their own folder. Single-file Mach-O executables don’t have that flexibility, but their signatures and CDHashes can be appended to the binary, or, when necessary, added in extended attributes (xattrs). Apple discourages the latter, as xattrs are prone to get stripped when transiting some file systems, so are less robust.

Notarization

From the outset of the iOS App Store, and later that for macOS, apps provided through those stores have been signed not by their third-party developers but by Apple. That gives Apple full control over their contents and their CDHashes, and enables it to revoke an app by checking those, rather than having to revoke the signing certificate. However, as Apple doesn’t have any record of apps or code signed by developers using their certificates, it has no means of verifying those distributed outside its App Stores. This changed with the introduction of compulsory notarization in macOS Mojave 10.14 in 2018.

Although the App Store process and notarization have common objectives, of ensuring that apps and code aren’t malicious, and providing Apple with CDHashes and a copy of the app, they are also fundamentally different. Apps distributed through the App Store are reviewed by Apple, must conform to its rules, and are signed by Apple; notarized apps distributed outside the App Store are only checked for malware, aren’t required to comply with rules, and are signed by their developer.

This diagram shows the evolution of code signing on Macs, from pre-2007, 2007-2018, and from 2018 onwards. In 2024, the release of macOS 15 Sequoia now effectively blocks developers from distributing apps that aren’t notarized by closing the simple Finder bypass that could be used to launch unnotarized apps.

Apple silicon

Although Apple had long maintained that users would remain able to run completely unsigned code in macOS, that too changed with the release of the first Apple silicon Macs in November 2020. All code run natively on ARM processors is required to be signed, although that could still be using ad hoc signatures, as originally allowed in 2007. Xcode, build tools and other systems for developing executable code for Macs have been modified to ensure that, when building apps and other executables that aren’t signed using a developer certificate, they are at least ad hoc signed. It’s thus well nigh impossible to build code that isn’t signed at all.

Ad hoc signatures are also used in codeless apps such as Web Apps introduced in macOS Sonoma in 2023. These provide a property list defining the app’s scope in terms of its domain URL, its Home page within that, and an icon to use. LaunchServices registers them against a UUID, applies an ad hoc signature, and keeps a record of the app bundle’s CDHashes from that signature, against which to validate its contents before trying to run it in the future.

Abuse

Before notarization became widespread, some malicious software was signed using Apple Developer ID Application certificates. Obtaining a developer ID on the ‘black market’ hasn’t been costly or difficult, but until recently relatively few have gone to the trouble. This may be the effect of certificate revocation: once signed malware has had its certificate revoked, it’s dead and can’t be run on a Mac again, while ad hoc and unsigned malware has been harder to block.

With notarization becoming more compulsory, particularly in macOS Sequoia, there have been occasional malicious apps that have slipped through Apple’s checks, and been notarized. This is more demanding, and requires techniques to obfuscate code to evade detection. Even when successful, the lifetime of notarised malware is likely to be short, and for most not worth the effort.

Conclusion

Seventeen years ago, Mike Ash expressed his concern that code signing would lead to Apple having to approve the apps we can run on our Macs. Although in certain respects Apple does control what our apps can do, we can still run many apps that I’m sure wouldn’t meet its approval, and code signing has played an important role in preventing those that are malicious. Things could have been far worse.

References

Mike Ash, Code Signing and You, 7 March 2008, an invaluable contemporary summary
Apple’s Code Signing Guide, last updated 13 September 2016
Apple’s Inside Code Signing series:
TN3125 Provisioning Profiles
TN3126 Hashes
TN3127 Requirements
TN3161 Certificates

I’d like to acknowledge the help of Jeff Johnson of Underpass App Company in providing information this brief history, although all errors are mine alone.

As more people were drawn from the surrounding countryside to populate growing towns and cities, the density of people within them rose. Accommodation became crowded, the streets were often full of people, and vehicle traffic threatened the safety of pedestrians.

The people that cities thrived on for their labour force were also its greatest threat. Outbreaks of infectious disease were common: in London, over fourteen thousand died from cholera in 1849, and a further ten thousand in 1853. From the middle of the nineteenth century, cities across Europe improved their sanitation and water-borne diseases became infrequent. The biggest killer of young adults remained ‘King Death’, tuberculosis, which spreads well in densely populated urban areas, and there were also local outbreaks of diseases like smallpox.

Extensive redevelopment of central Paris retained many of its open spaces, although in fine weather these got crowded, as shown in Adolph Menzel’s Afternoon in the Tuileries Gardens from 1867. This appears to have been painted in homage to Manet’s Music in the Tuileries of 1862.

Many cities were just as crowded at night, as seen in Lesser Ury’s view of Leipziger Straße in Berlin, painted in 1889. Although street lighting was becoming increasingly common, it was inadequate for this hazardous mixture of electric trams (introduced in 1881), horse-drawn carriages and pedestrians. Accidents were frequent, and deaths not uncommon.

City markets such as Les Halles, the central market in Paris, depicted here by Léon Augustin Lhermitte in 1895, were packed with buyers and sellers for much of the day, as described by Émile Zola in his novel Le Ventre de Paris (1873).

Painting the crowded city streets was a challenge mastered by few, including Camille Pissarro for Paris and Colin Campbell Cooper for New York.

Pissarro’s Boulevard Montmartre, Spring from 1897 is a landscape composed primarily of buildings and streets, a plethora of figures, and countless carriages to move those people around.

In 1902, just a year before his death, Pissarro painted this amazing view of crowds on The Pont-Neuf bridge in Paris.

In Cooper’s The Rush Hour, New York City from about 1900, the canvas is literally teeming with people, who are pouring along the street, packing the stairways and walkways to a station, and seething around booths and tramcars.

Cooper followed those crowds onto The Ferries, New York (c 1905), where they are as densely packed as they were in The Rush Hour above.

Cooper’s Broadway from the Post Office (Wall Street) (c 1909) is one of his most famous skyscraper cityscapes. This shows the Singer Building or Tower, at Liberty Street and Broadway, that had only just been completed, and was still the tallest building in the world. Below in Broadway itself the street is packed with people.

George Bellows’ New York (1911) has a human horizon of figures walking past a white background, dividing the canvas into two. Above is a vague blur of buildings, below a cacophony of vehicles, stalls, and people.

Among the immigrants to arrive in New York City from Italy in 1896 was Giuseppe Michele Stella. Born in the small town of Muro Lucano, with a population of about ten thousand, he changed his name to Joseph, abandoned his medical studies, and became a painter of international renown. The shock of living and working among those crowds must have run deep, and between 1909-11 he had to return to Italy to recover.

Berlin’s Spittelmarkt, painted here by Paul Hoeniger in 1912, mixes early motor cars, horse-drawn wagons, trams, and people walking in every direction, all without any road markings or traffic controls.

Winter weather was no deterrent either, as Maximilien Luce demonstrates in his painting of The Gare de l’Est in Snow from 1917.

Apps, frameworks and other items come in bundles, structured hierarchies of folders and files that look like a single file in the Finder. This article explains what bundles are and shows how they are structured.

Bundles came to Mac OS X from its NeXTSTEP parent, not Classic Mac OS. The latter assembled its apps from many resources stored in the app’s resource fork. NeXTSTEP and Mac OS X instead built their apps from component files arranged in a series of directories. Those bundles gathered together all the files required for apps and similar items, into what was then presented to the user as a single item. Modern app bundles are descended from ‘new-style’ bundles introduced in Mac OS X, which had a minimum requirement of a top-level folder named Contents, and inside that a property list named Info.plist.

Bundles and packages

When a folder has a name with an extension for a standard bundle type, such as .app, .bundle, .plugin or .kext, the Finder will display and treat it as if it were a file, also offering to Show Package Contents in its contextual menu. For historical reasons, bundles with the extension .framework aren’t treated as bundles, but are displayed and navigated as if they were still folders.

Although bundles have similarities with packages, Apple draws a clear distinction between them, even if the Finder doesn’t. Directory-based documents and similar items that are used to contain multiple files for Rich Text Format Directory (RTFD) and other documents don’t conform to the rules for bundles, and should be referred to as packages to avoid confusion. Look inside an RTFD package, for example, and you’ll see the structure:

• Contents, a directory containing a PkgInfo file
• files containing graphics to be included within the documents
• TXT.rtf, a Rich Text Format file containing the styled text.

which has some common features, but is structured differently and lacks both an Info.plist file and executable code.

Apps and frameworks

The fundamental requirements for an app or related bundle, including those for app extensions or appexes, are:

• The whole bundle’s contents are within a single top-level folder named Contents.
• Within Contents is an Info.plist property list containing information and settings for the bundle.
• There’s executable code, normally in the form of a Mach-O binary inside the MacOS folder.
• For historical and compatibility reasons, there’s a PkgInfo file containing a Classic Mac OS type and creator code for the bundle, e.g. APPL and ???? for an app.

However, frameworks have a different and more complex structure, lacking a Contents folder, providing at least one version of the framework, and burying the Info.plist file deeper in the hierarchy. This is shown in full later.

App bundles can contain frameworks and other app bundles, as can framework bundles. In the worst case you may need to dive deep into a series of folder hierarchies to reach your goal.

Info.plist

The information property list Info.plist contains key-value pairs in XML format, for attributes such as:

• bundle name (CFBundleName),
• name of bundle executable (CFBundleExecutable),
• version (CFBundleShortVersionString),
• document types handled by the app (CFBundleDocumentTypes),
• app identifier (CFBundleIdentifier),
• other metadata.

Because of the importance of its contents, code signatures protect the Info.plist from being changed in any way.

App bundle

In addition to the minimum requirements of an Info.plist, executable code, and PkgInfo file inside its Contents folder, apps almost invariably contain several additional folders, among them:

• Resources is universal, and contains any of a rich range of images, localised versions of menu and other text contents, the app icon and any for custom document types, storyboards for GUI elements, Help books, and more.
• PlugIns is now common, to contain appexes in particular.
• Library, containing one or more sub-folders with QuickLook and Spotlight support for custom document types, any login items or property lists for LaunchServices, and other support and extensions for the main app.
• Apps obtained through the App Store should contain a _MASReceipt folder with the store receipt inside it.
• Signed apps will have a _CodeSignature folder containing the CodeResources file with signature data.
• Notarized apps may have a notarization ticket in a CodeResources file, but that isn’t required for notarization to work.
• Some apps may have an embedded.provisionprofile file containing their provisioning profile.
• Other folders, such as Frameworks for nested framework bundles.

This layout is shown below, with the essentials in light red.

Framework bundle

In comparison, framework bundles are deeper, lack a top-level Contents folder, contain at least one version of the framework (although two or more are now exceptional), and come with symbolic links. This is shown below, again with the essentials in light red.

Three symlinks merit explanation:

• Versions/Current links to A, the current (and only) version of the framework.
• a symlink with the same name as the framework’s code is at the top level of the bundle, alongside the Versions folder. That links through the Current symlink, giving the path Current/A/.
• a symlink named Resources is also at the top level of the bundle, alongside the Versions folder. That too links through the Current symlink, giving the path Current/A/Resources.

Thus paths to the Info.plist file include Resources ➜ Info.plist via the top-level Resources symlink, Versions/Current ➜ Resources via the Current symlink, and Versions/A/Resources without using any symlinks. This demonstrates how confusing this layout can appear in the Finder.

Frameworks commonly include other nested frameworks, appexes in their PlugIns folder, and a diverse range of other resources including localisations in the Resources folder.

Conclusions

• Bundles are formal structures of folders and files used for apps and their relatives, and for frameworks. Packages used for RTFD and other documents have different structural requirements.
• App bundles have a top-level Contents folder, inside which is an Info.plist property file, and executable code inside a MacOS folder.
• Framework bundles don't have a Contents folder, but contain versions of the framework, normally only one named A. They use important symlinks to provide standard access paths to their contents, and their Info.plist file is inside their Resources folder.
• Info.plist files and other contents are protected by code signatures and can't be modified without breaking the signature. However, they contain valuable information about the app or framework.
• Building bundles by hand is prone to error, causing bugs. When possible, leave it to Xcode.

Reference

Apple's instructions for developers.

Growing plants indoors is an ancient tradition, but it wasn’t until the nineteenth century that it became popular among the middle classes. While some were grown for their flowers, foliage plants became common, and in the later part of the century Aspidistra elatior became so widespread in Britain that it was a symbol of dull middle-class respectability and the bourgeoisie.

The potted houseplants straggling up for light from the window in John Roddam Spencer Stanhope’s Thoughts of the Past (1859) are anything but respectable, though. Here they form part of the stereotype of one of London’s many prostitutes.

In 1887, the young Swedish artist Carl Larsson painted The Toy Corner inside his family home. His wife Karin was a talented artist who concentrated on interior design, and was responsible for most of the interiors shown in her husband’s paintings. At the left is a collection of plants in red earthenware pots.

At about the same time, Paul Signac pictured the bourgeoisie at table in La salle à manger, variously known as Breakfast or The Dining Room from 1886-87, perhaps his first major Neo-Impressionist painting. The man seen in profile with his cigar is Signac’s grandfather Jules, and the woman drinking coffee may be Signac’s mother. This is thoroughly middle class, with its uniformed maid, a spotless tablecloth, plush curtains and a potted plant in the window.

Sunday, which Signac started in October 1888 and completed in March 1890, is perhaps the best-known of his interiors, and continues their theme of the humdrum life of the bourgeoisie. Its static, stultified composition and atmosphere are intentional, and pervade its every detail down to the potted palms at the left.

Harriet Backer’s Woman Sewing (1890) shows a woman (a wife in the Norwegian title) sat at her sewing. This appears to have been a quick oil sketch, with its gestural depictions of potted plants, table, and chair.

The potted plants in Anna Ancher’s Fisherman’s Wife Sewing (1890) are in flower, and shown in their shadows cast on the wall by the sunlight pouring through a window to the left.

In 1895, Christian Krohg painted one of his more enigmatic works, a throwback to his social narratives, and something of a ‘problem painting’: Eyewitnesses. It is nighttime in a living room. Two fishermen stand in front of a door. Still wearing their soaked and soiled oilskins, they appear to have entered the room straight after coming ashore from the sea. One stares in shock towards the viewer, the other looks down and away. Both appear full of unease, silent and immobile.

At the right, a young woman is standing, leaning forward towards the men, as if listening to them. She looks anxious, with her hands clasped in front of her chest. Behind her an oil lamp burns brightly, there are the leaves of a large potted plant, and a couple of paintings on the wall behind a large blue settee.

In another world three years later, the Danish painter Laurits Andersen Ring’s wife Sigrid sits reading the ‘leftist’ daily newspaper Politiken At Breakfast in 1898. The furniture is modern, designed rather than thrown together, and colour-coordinated. By the window on the right is a small stack of potted plants enjoying the light.

Thorvald Boecks bibliotek (Thorvald Boeck’s Library) (1902) is one of Harriet Backer’s few interiors that is devoid of people, here replaced by books from floor to ceiling. Alongside the intricate detail of their many spines, furniture, and other decorations is a high potted plant at the left.

The windowsills in Nikolai Astrup’s Interior Still Life: Living Room at Sandalstrand are full of plants enjoying the sheltered climate indoors.

Further north still, homes in Iceland’s capital Reykjavik had room for ample foliage, as shown in Þórarinn Þorláksson’s view of The Artist’s Home in 1924.

The aspidistra is still flying in domestic interiors today.

It’s no miracle that a 10 GB disk image can be shrunk down to a few MB of sparse file. This article explains how APFS works that magic, first on a normal read-write disk image, then in the disk image inside a Virtual Machine.

What is a sparse file?

In essence a sparse file is any file whose allocated storage is smaller than the nominal size of that file. In APFS, this imposes two requirements:

• the INODE_IS_SPARSE flag is set for that file’s inode,
• the sparse byte count is given in its extended field.

As a result, the total size of storage allocated to that file’s data in its file extents is smaller than the total required to store the file at its nominal size. This is because the file contains empty data that isn’t stored on disk, saving disk space. This becomes clearer when we consider how this works with regular read-write disk images.

How a disk image becomes sparse

To demonstrate how this works, create a read-write disk image, which APFS will then turn into a sparse file. For the sake of simplicity, I’ll ignore all overheads such as the file system in that disk image.

APFS uses 4 KB storage blocks on SSDs. Creating a 4 GB disk image using DropDMG or Disk Utility therefore uses one million blocks. For this example I number those starting from 0000 0001 in hexadecimal, rising to 000F 4240 at the end of that disk image file, a million blocks later.

Once that has been created, copy a 4 MB file into the disk then unmount it, and mount it again. When it’s mounted that second time, APFS Trims it, and marks all its storage blocks apart from those 4 MB as being unused. That leaves my file occupying blocks 0000 0001 to 0000 03E8, and 0000 03E9 to 000F 4240 unallocated. APFS therefore sets the disk image file’s INODE_IS_SPARSE flag to TRUE and writes the sparse byte count to its extended field: the disk image is now a sparse file.

Creating a VM disk image

Unlike that read-write disk image, a disk image used for a Virtual Machine (on Apple silicon, at least) is created a sparse file in the first instance, using code like
let diskFd = open(diskImagePath, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR)
var result = ftruncate(diskFd, sizeDisk)
result = close(diskFd)
(error handling omitted) where sizeDisk is the size in bytes. Similar can be achieved in Terminal using the command
dd if=/dev/zero of=Disk.img bs=1m count=0 seek=10240
where the number given for seek is the size in blocks.

Maintaining the VM disk image

A read-write disk image is mounted and Trimmed by APFS on the host Mac. That used for a VM is different, as it’s the guest OS that has the task of Trimming the disk image from inside, and that works just the same as when macOS is booted on a Mac.

Read the entries made in your Mac’s log by APFS during startup. Those appear early with the start of APFS, when the version is given:
33.263 apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.101.1, apfs-2332.101.1, 2025/04/11

A little later, APFS Space Manager (Spaceman) Trims the first partition/container with log entries like:
34.012 spaceman_scan_free_blocks:4106: disk1 scan took 0.002064 s, trims took 0.000443 s
34.012 spaceman_scan_free_blocks:4110: disk1 101104 blocks free in 47 extents, avg 2151.14
34.012 spaceman_scan_free_blocks:4119: disk1 101104 blocks trimmed in 47 extents (9 us/trim, 106094 trims/s)
34.012 spaceman_scan_free_blocks:4122: disk1 trim distribution 1:14 2+:18 4+:8 16+:2 64+:1 256+:4

A couple of seconds later it trims a second partition:
36.391 spaceman_scan_free_blocks:4106: disk3 scan took 1.749635 s, trims took 1.147491 s
36.391 spaceman_scan_free_blocks:4110: disk3 351308484 blocks free in 319729 extents, avg 1098.76
36.391 spaceman_scan_free_blocks:4119: disk3 351308484 blocks trimmed in 319729 extents (3 us/trim, 278633 trims/s)
36.391 spaceman_scan_free_blocks:4122: disk3 trim distribution 1:118376 2+:48105 4+:82602 16+:42698 64+:24673 256+:3275
36.391 spaceman_scan_free_blocks:4130: disk3 trims dropped: 10469 blocks 10469 extents, avg 1.00

The following matching entries are taken from a macOS VM as it boots on an Apple silicon Mac:
02.557 apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.101.1, apfs-2332.101.1, 2025/04/11

03.278 spaceman_scan_free_blocks:4106: disk2 scan took 0.001036 s, trims took 0.000770 s
03.278 spaceman_scan_free_blocks:4110: disk2 126731 blocks free in 15 extents, avg 8448.73
03.278 spaceman_scan_free_blocks:4119: disk2 126731 blocks trimmed in 15 extents (51 us/trim, 19480 trims/s)
03.278 spaceman_scan_free_blocks:4122: disk2 trim distribution 1:4 2+:4 4+:5 16+:0 64+:0 256+:2

03.570 spaceman_scan_free_blocks:4106: disk4 scan took 0.295283 s, trims took 0.285527 s
03.570 spaceman_scan_free_blocks:4110: disk4 19188027 blocks free in 9939 extents, avg 1930.57
03.570 spaceman_scan_free_blocks:4119: disk4 19188027 blocks trimmed in 9939 extents (28 us/trim, 34809 trims/s)
03.570 spaceman_scan_free_blocks:4122: disk4 trim distribution 1:6010 2+:1072 4+:1775 16+:700 64+:244 256+:138
03.570 spaceman_scan_free_blocks:4130: disk4 trims dropped: 4252 blocks 4252 extents, avg 1.00

Just as the Trims performed on the host free up unused blocks of storage on the boot disk, so those in the VM do the same for the VM disk image. To demonstrate how those maintain the VM disk image in sparse format, I wrote two files inside the VM when it was running. One was a plain 10 GB file taking 10 GB on disk, the other a 10 GB sparse file taking a few MB. I then closed the VM and measured its size on disk, opened it again, deleted those two files and closed it again. During this I also took screenshots to verify changes recorded by Disk Utility in the free space inside the VM.

Before writing the two test files, the VM’s disk image size on the host was 107 GB, and it took 23.98 GB on disk as a sparse file. When it contained the two test files, its size remained the same, and it took 34.01 GB on disk. After deleting the files inside the VM, the disk image’s size remained the same, but it only took 24.01 GB on disk, and internally the VM reported that it had returned to 78.9 GB of storage available, the same as it had started with.

As expected, when the VM Trimmed it freed up storage space no longer used by the deleted files, as a result of which the VM disk image required less space on disk.

How the magic works

• Read-write disk images are created as normal files. They’re Trimmed by APFS on each subsequent mount, and may then become sparse files when there’s sufficient unused space in them.
• VM disk images are created as sparse files. They’re Trimmed by APFS in the VM during each boot and on demand, maintaining their sparse format when they have sufficient unused space.

By the late nineteenth century, the classical format of the triptych that had been developed for altarpieces, was being used to tell secular stories as well as more traditional religious ones. Some artists had abandoned the use of three hinged panels intended to stand unsupported, and set three paintings within a single frame to be hung on a wall instead. Popular layouts included a central theme with subordinate wings, and a sequence read from left to right.

Constantin Meunier’s undated Triptych of the Mine is intended as a tribute to long-suffering underground workers, and makes a parallel with triptychs showing the Crucifixion. The left wing shows their descent, the centre their ascent of Calvary, and the right their ascent to surface at the end of their working day.

Akseli Gallen-Kallela’s Aino Myth (1891) is set in a gilt frame with quoted text from the Kalevala inset, similar to Arthur Hughes arrangement from 1856. This shows scenes from Songs 4-5 of the Finnish national epic, the Kalevala.

The left panel shows the first meeting between Väinämöinen, the central figure and hero of the epic, and the young Aino, Joukahainen’s sister, in the forest. The perpetually ancient Väinämöinen there asks Aino to be his wife, to her shock and anger. The girl runs back to her mother in tears, but she offers no sympathy, telling her to stop crying, and to rejoice at the offer.

Aino remains distressed at the prospect of marrying such an old man, so wonders off, and becomes lost in the forest. She comes across the shore of a strange lake, where she sees the maids of Vellamo playing in the water, as shown in the right panel. She enters the water to wash, and drowns.

In Song 5, Väinämöinen goes to fish for Aino in the lake, and catches a salmon, which he tries unsuccessfully to cut up, so the fish slips back into the water. It then changes into Aino, who mocks Väinämöinen that he may have held her in his hands, but he cannot keep her, shown in the centre panel. She then disappears, and Väinämöinen travels to Pohjola to court the Maiden there.

In 1894, Édouard Vuillard painted this large triptych of Public Gardens, where its panels form a continuous landscape view and divide its figures into three groups. At the left is a group of carers with children; in the centre is a trio of ladies, one of them cradling an infant, and at the right is an older woman sat alone wearing the black of widowhood.

Léon Frédéric’s Ages of the Worker from about 1905 is set in the crowded streets of a Belgian town. The left panel shows men engaged in manual labour, including two who are moving heavy props from a mine. In the centre, a group of young boys are enjoying an improvised meal on the pavement as young couples and a miner move around them. At the right, women are feeding and caring for their infants. I suspect that Frédéric may have intended the work to be read from right to left, rather than in the more usual direction.

Fedir Krychevskyi painted this triptych of Life in the latter half of the 1920s, and its centre panel was the most acclaimed work among paintings by Ukrainian artists shown at the Venice Biennale in 1928. From the left, its panels are titled Love, Family and Return. It blends his own distinctive approach with Art Nouveau, Klimt and mediaeval wall painting.

The Memorial was painted by Henri-Jean Guillaume Martin in 1932 as a public commission for the town of Cahors in southwest France. Its single continuous scene shows a commemoration of the dead of the First World War, centred symmetrically on the town’s war memorial.

In the early decades of the twentieth century, Kazimierz Sichulski painted several large triptychs of the Hutsul peoples, including this Adoration of the Shepherds in 1938. Although modern in style, this is laid out as a traditional Nativity, with the Virgin and Child in the centre, and shepherds looking on from its wings.

Reading larger polyptychs can be a greater challenge.

Among the most remarkable is The Ghent Altarpiece painted by the van Eyck brothers and their workshop in about 1432 for Saint Bavo Cathedral in Gent, Belgium. Its twelve panels are arrayed around the central panorama of the adoration of the Lamb of God. Its upper register features an array of figures with Adam and Eve outermost, and either Christ the King or God the Father at its centre. The lower register includes a gathering set against a continuous landscape background.

Polyptychs are also common outside Europe, including in East Asia where they were popular on screens. Some were also made from groups of woodblock prints.

Kitagawa Utamaro’s (喜多川 歌麿) Girl Fishers and Bathers from 1791 shows seaside activities at Enoshima. Although composed as a triptych with a continuous motif, the same topless woman appears in each of the sheets, making the whole a multiplex narrative. It’s not clear, though, whether it was intended to be read from left to right, or in reverse.

With well over 400 app extensions and plugins managed by PlugInKit in Sequoia 15.4.1, this article tries to give an overview of their management and control, as well as the diversity of their functions. This follows:

• a general introduction
• an account of discovery and management by PlugInKit
• AppexIndexer to examine appexes known to PlugInKit
• Apple’s appex Home page for developers.

Appex types

Although Apple refers to the type identifier for appexes as NSExtensionPointIdentifier in its developer documentation, where it lists some of them, in macOS this is also synonymous with NSExtensionPointName. In pluginkit dumps, it’s referred to as the SDK, and LaunchServices dumps use both terms, NSExtensionPointName in NSExtensionsAttributes, and NSExtensionPointIdentifier in NSExtension. This is even more confused in the log, where PlugInKit’s entries use the term NSExtensionPointName, but use NSExtensionIdentifier to refer instead to the appex-specific identifier, such as com.apple.iCal.CalendarWidgetExtension.

For the sake of clarity and consistency here, I’ll refer to the appex type identifier as NSExtensionPointName.

Appex locations

Many appexes supplied in macOS are stored as bundles inside dedicated collections such as /System/Library/ExtensionKit/Extensions or in frameworks. Where they are supplied in an app or similar bundle, they’re normally in a PlugIns folder, although according to this article QuickLook generators should be installed in Library/QuickLook, and Spotlight importers in Library/Spotlight.

Types and management

The rest of this article lists appex types, omitting the universal prefix com.apple., according to their management and discovery by PlugInKit during startup. I provide for each, as far as I’m able to tell, the type-specific manager, any controls provided in System Settings or elsewhere, and illustrative examples and other relevant information.

Type-specific managers are those services or subsystems that PlugInKit hands over to during discovery. For example, when it discovers appexes that extend QuickLook by providing either thumbnails or previews, PlugInKit hands those over to com.apple.quicklook.ThumbnailsAgent to manage.

Many appex types aren’t exposed in System Settings, are managed by PlugInKit, but don’t appear to undergo startup discovery. I have relegated those to the appendix at the end. Most of those are single-appex types, and others are only used by macOS.

Appex types that are managed in System Settings and by PlugInKit, and undergo startup discovery:

• FinderSync, managed by the Finder, and controlled in File Providers settings, e.g. Keka Finder Integration
• quicklook.preview, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• quicklook.thumbnail, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• ui-services, managed by the Finder, and controlled in Actions settings, includes Markup, ShareSheetUI (not exposed in settings)

Appex types that aren’t managed in System Settings, but are managed by PlugInKit, and undergo startup discovery:

• AppSSO.idp-extension, managed by AppSSOAgent, includes Kerberos and Sign In With Apple; these are single-sign-on extensions
• appstored-services.testflight, managed by appstoreagent; these handle App Store TestFlight
• AudioUnit, managed by AudioComponentRegistrar and axassetsd, for WardaSynthesizer
• AudioUnit-Speech, managed by AudioComponentRegistrar and axassetsd, include KonaSynthesizer and AUSPs
• AudioUnit-UI, managed by AudioComponentRegistrar
• cache_delete_extension, managed by deleted; these support app-specific cache management
• contacts.donation, managed by contactsdonationagent; these exchange info with Contacts
• ctk-tokens, managed by ctkd, include CryptoTokenKit and PlatformSSOToken; these handle tokens for CryptoTokenKit
• diagnosticextensions-service, managed by ControlCenter and diagnosticextensionsd, includes many service-specific Diagnostic Extensions
• email.extension, managed by maild, e.g. SpamSieve; these are Mail plugins
• fileprovider-nonui, managed by the Finder, includes iCloud Drive and PhotosFileProvider
• services, managed by the Finder; none listed
• spotlight.import, managed by mdbulkimport, includes PDFImporter
• spotlight.index, managed by corespotlightd, includes system extensions but not mdimporters
• textinputmethod-services, managed by imklaunchagent, includes many Input Methods
• usernotifications.content-extension, managed by NotificationCenter, includes ContentExtensions
• widgetkit-extension, managed by chronod, includes system and third-party widgets.

Significant appex types that are managed by PlugInKit, but don’t undergo startup discovery:

• appintents-extension, multiple instances
• intents-service, many IntentsExtensions
• photo-editing, Photos editing, controlled in Photos Editing settings
• Safari.extension, Safari extensions, managed in Safari settings
• share-services, many Share extensions, managed in Sharing settings
• widget-extension, only a couple, e.g. iStat Menus.

Appex types that apparently aren’t managed by PlugInKit, but are controlled in System Settings:

• Dock Tiles
• Finder, these are services offered in the Finder’s Services menu
• Spotlight, these are mdimporters.

also Safari.content-blocker, which is managed in Safari settings rather than System Settings.

Appex types that aren’t apparently managed by PlugInKit or controlled in System Settings:

• authentication-services-account-authentication-modification-ui
• authentication-services-credential-provider-ui
• broadcast-services-setupui
• broadcast-services-upload
• callkit.call-directory
• classkit.context-provider
• dt.Xcode.extension.source-editor
• fileprovider-actionsui
• identitylookup.classification-ui
• identitylookup.message-filter
• intents-ui-service
• keyboard-service
• networkextension.app-proxy
• photo-project
• tv-top-shelf

Appendix:

Appex types that aren’t exposed in System Settings, are managed by PlugInKit, but don’t undergo startup discovery

System, multiple appexes:
followup-extension – multiple FollowUpExtensions
lighthouse.SAOrchestratedExtension – multiple Ingestors
message-payload-provider – multiple
mlhost.worker – many ML-related
mlruntime.extension-point-high
mlruntime.extension-point-ondemand
mlruntime.extension-point-restricted
screensaver – several ScreenSavers
Settings.extension.ui – System Settings
storagemanagement – many apps
usernotifications.service – several NotificationServiceExtensions
wallpaper – several Wallpapers

System, single-app extensions:
amsengagementd-extension – Books, News
amsutility-extension – News
app.non-ui-extension – Swift Playground
app.non-ui-extension.multiple-instances – Swift Playground
app.ui-extension.multiple-instances – Swift Playground
applemediaservices.extensions.compose-review – ComposeReviewExtension
askpermission-extension – App Store related
askto.extension – AskToMessagesHost
calendar.EventKitUIRemoteUIService – EventKitUIRemoteUIExtension
calendar.virtualconference – FaceTimeExtension
contact-view – System Service
contacts.avatar-picker-ui – AvatarPickers
deviceactivity.monitor-extension – ScreenTimeDeviceActivityMonitorExtension
deviceactivityui.report-service – DeviceActivityReportService
extension-view-service-sample-rk – RPVideoEditorExtension_macOS, ReplayKit
extensionkit.app-extension-management – AppExtensionManagement
extensionkit.app-extension-settings – ExtensionKit components
facetime.notification – FaceTimeNotificationExtension
feedback.drafting-extension – Feedback
freeform.USD-renderer-remote-UI – USDRendererExtension
fskit.fsmodule – exfat and msdos file systems (File System Extensions)
GenerativePlaygroundUI.remoteUI – Image Playground
groupactivities – FaceTime RemotePeoplePicker
Home.ui-extension.userList – HomeUIUserList
ImagePlayground.NonUIExtension – GPNonUIExtension
ManagedSettings.service – ManagedClientMSExtension
mapkit.private.RemoteUI – MKRemoteUI for MapKit
mobileslideshow.photo-picker – PhotoPicker and PhotosPicker
networkextension.packet-tunnel – network extensions
PaperKit.extension.ui – PaperKitExtension
PassKit.in-app-payment-ui – Wallet
pdfkit-private – PDFExtensionView in PDFKit
people-picker – System Service
people.legacy.extension – PeopleLegacyMessageService
Photos.MacMusicPickerExtension – PhotosMacMusicPickerExtension
preference.security.privacy – Apple Advertising
preference.sharing.service – Media Sharing
private.translation-api-support – TranslationAPISupportExtension
private.translation-ui – Translate
private.voiceshortcuts-ui – three extensions
replaykit.broadcast-picker – RPBroadcastActivityExtension_macOS in ReplayKit
screentime.web-service – ScreenTimeWebExtension.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5296. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new rule for MACOS.DOLITTLE.RDRGOCON, and amends the rules for MACOS.8032420, OSX.HMining.D and MACOS.SOMA.D.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5296.

Sequoia systems only

This update has also been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5296 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Updated 1928 GMT 22 April 2025 – now available fully via iCloud.

One of the common presentations for European paintings has been in the form of a folding, self-supporting group of several panels. As altarpieces these have graced the space above and behind the altar in a great many of the churches across the continent. While they can have anything from two to twenty or more panels, triptychs with three have been particularly popular, and have become widely adopted for secular paintings as well.

Polyptychs are often used to solve the problem of telling narratives in visual art. By providing two or more images they spare the artist the task of composing a single image that refers to two or more moments in time, for example using multiplex narrative. However, the viewer then needs to know in which order to read the panels, and to see how they integrate into a whole. In this and tomorrow’s article I show some examples of solutions.

Masaccio’s Triptych of San Giovenale was painted early in his career, in 1422, and was only discovered in 1961. It adopts a popular if not conventional layout for an altarpiece, with its central panel showing the Virgin Mary and infant Christ, with two winged angels in attendance. The left wing shows Saints Bartholomew and Blaise, and the right Saints Juvenal, patron of the commissioning church, and Anthony Abbot. Figures in the wings are looking at the central panel, although Saint Blaise is glancing furtively towards the viewer.

Robert Campin’s workshop painted this early narrative triptych of The Entombment of Christ in about 1410-1420. The thread runs from the Crucifixion at the left, where Christ’s cross is empty, through the central entombment scene, to the Resurrection with the empty tomb in the right wing. The figure kneeling at the foot of the left wing is the donor.

Hieronymus Bosch was a prolific painter of triptychs, and several of his finest have survived in excellent condition, considering that they’re more than five centuries old. They follow different compositional strategies.

The three panels of Bosch’s Adoration of the Magi from 1490-1500 form a continuous view of the local Brabant countryside, with its low rolling hills, and a city in the distance; this may be based on Antwerp, the donor’s city, or possibly ‘s-Hertogenbosch where the artist lived and worked. The Adoration itself is in the centre panel, while the wings show the donor and his family with countryside behind.

His famous Garden of Earthly Delights from about 1495-1505 follows a pattern distinctive to Bosch, with the left wing showing a scene from the garden of Eden before the fall of man, the centre containing the main theme, and the right wing the chaos and suffering of the apocalypse. This past-present-future layout is repeated in several of his other triptychs, and was adopted by others.

This is perhaps best developed in his late Haywain Triptych from about 1510-16. The left wing here has a multiplex account of the Fall of Man set in the Garden of Eden, with God the Father shown in the narrative content and in Heaven above, and the fall of angels occurring at the same time. The central panel shows a rich cavalcade of figures, including the emperor and Pope, nobility, courtiers, and many peasants, accompanying a huge and heavily-laden wagon of hay, which is processing from left to right. They are being overseen from Heaven by Jesus Christ. Finally, the right panel shows sinners entering into Hell and undergoing physical torments, with its fires destroying all in the distance.

Although religious polyptychs continued through the Renaissance into the nineteenth century, secular triptychs didn’t become popular until the middle of the nineteenth century, when they were adopted by the Pre-Raphaelites and spread to continental Europe.

Dante Gabriel Rossetti painted the story of Paolo and Francesca da Rimini in this watercolour triptych in 1855. At the left the lovers are reading the legend of Lancelot and Guinevere; in the centre are Dante and Virgil, and at the right Paolo and Francesca are being blown in the storms of the Second Circle of Hell in Dante’s Inferno.

The following year Arthur Hughes told the story of The Eve of St Agnes in this triptych, also read from left to right. At the left Porphyro is approaching the castle. In the centre he has woken Madeline, who hasn’t yet taken him into her bed. At the right the couple make their escape over drunken revellers. There is also a second, undated version in the Ashmolean, Oxford, in which the left wing shows a slightly later moment, where Porphyro meets Angela at the entrance to the castle.

Hughes breaks from the tradition of the three panels being hinged, which allowed the wings to be closed over and protect the centre panel, and sets them into a single gilt whole, containing a lengthy quotation from the literary source.

Léon Frédéric’s triptych showing The Legend of Saint Francis (1882) frames the panels individually, but is set in a single outer frame. These show separate episodes from this popular legend, ending at the right with the story of the wolf of Gubbio/Agubbio.

Fritz von Uhde’s setting of the Nativity, The Sacred Night from 1888-89, centres on a modern interpretation of the classic Virgin and Child, with the adoration of the magi on the left, and an angelic choir singing amid the rafters of the barn on the right.

For at least the last couple of years, folk have complained that launching some apps takes forever. It has been common for some to take several seconds of bouncing icon time in the Dock, and in a few cases larger apps can take more than 30 seconds to launch. This has been ascribed to ‘security checks’, with some claiming it’s because of delays in online checks of certificates, others attributing it to XProtect, or something else. This article, based on log extracts generously provided by Kristian, demonstrates what’s really holding up these apps.

App launch in Sonoma & Sequoia

I have written at length in previous articles about what happens during app launch in Sonoma 14.6.1 and Sequoia (links at the end). Although there are significant differences, I concentrate here on 14.6.1, as the crucial log records from Kristian are from Sonoma, and its analysis has been more extensive. Key steps are summarised in the diagram below.

For the sake of simplicity here, I’ll confine this article to launching known apps that aren’t in quarantine, and look in particular at Pages, which isn’t notarized, so will behave slightly differently.

Slow Pages

Launch starts with the click action triggering LaunchServices to start launching the app
16.924 Finder sendAction:
16.927 com.apple.launchservices LAUNCH: Opening <private> with 0 items on behalf of 436 role=e flags=8000001 (null)
and LaunchServices then hands the launch over to RunningBoard
16.941 com.apple.launchservices LAUNCH: _LSLaunchThruRunningboard: com.apple.iWork.Pages / <private>

Security checks start early, with amfid
16.966 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
16.969 amfid SecTrustEvaluateIfNecessary
Then, in accordance with system security policy, a Gatekeeper assessment is started
17.031 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
17.031 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

The security system recognises that the code has already been evaluated, so uses the results from that, and its Gatekeeper scan result returns within 0.01 seconds
17.041 com.apple.syspolicy.exec Code already evaluated, using results.
17.041 com.apple.syspolicy.exec scan returning quickly for code: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
17.041 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
17.041 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

So around 0.075 seconds after starting the security assessment, and only 0.117 seconds after double-clicking to launch the app, it looks like it has approval to proceed. But that doesn’t take into account the frameworks the app bundle contains. There are 17 of those that need to be evaluated before launch can proceed. Each is reported with distinctive lines like
17.564 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
17.567 amfid SecTrustEvaluateIfNecessary
the last of which isn’t reported until 20.593 seconds elapsed time, that’s 3.55 seconds after we thought security evaluation was complete, and over 3.6 seconds since the double-click.

From then until Pages opens its preferences with the log entry
20.998 Pages Loading Preferences From User CFPrefsD
is another 0.3 seconds, making a total launch time of just over 4 seconds, of which almost 90% was spend checking frameworks.

Performing the same launch in a VM running macOS 14.7.5 on 4 P cores with 16 GB memory on an M4 Pro host is a little faster, and only takes 2.5 seconds to check its frameworks.

Fast Pages

Launching Pages in a Mac mini M4 Pro running Sequoia 15.4.1 is, as you’d expect, significantly quicker. Tracing corresponding log entries reveals where much of the time is saved.

00.513 Finder sendAction:
00.715 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
00.741 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
00.741 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

00.751 com.apple.syspolicy.exec Code already evaluated, using results.
00.751 com.apple.syspolicy.exec scan returning quickly for code: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
00.751 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
00.751 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

Framework checks start with
00.772 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
00.773 amfid SecKeyVerifySignature
and progress through to
00.843 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/AppleMediaServicesKit.framework/Versions/A/AppleMediaServicesKit
00.843 amfid SecKeyVerifySignature
with Pages opening its preferences at the end
01.087 Pages Loading Preferences From User CFPrefsD

Here, framework checks took a mere 0.07 seconds, and the total time from double-click to preferences was only 0.574 seconds.

Slow Calibre

Pages is an example of an app that completed its security checks without error or problems. Many of the apps that can be slowest to launch have additional problems, as shown in Calibre.

Progress through early checks proceeds briskly:
31.505 Finder sendAction:
31.567 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
31.576 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 937222), (team: NTY7FVCEKP), (id: net.kovidgoyal.calibre), (bundle_id: (null)), 0, 0, 1, 0, 4, 4, 0

But when its frameworks come up for checking, there’s a problem reported in every one of them
31.614 kernel AMFI: constraint violation /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib has entitlements but is not a main binary
31.614 amfid Entering OSX path for /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib
31.615 amfid SecTrustEvaluateIfNecessary

AMFI runs a total of 68 checks on those frameworks in the app bundle before reaching the last
35.988 kernel AMFI: constraint violation /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib has entitlements but is not a main binary
35.989 amfid Entering OSX path for /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib
35.989 amfid SecTrustEvaluateIfNecessary

And preferences are opened 4.635 seconds after the double-click
36.140 calibre Loading Preferences From User CFPrefsD

Workarounds

Many different workarounds have been proposed blindly to tackle a problem that doesn’t appear to have properly diagnosed in the first place. I believe that it is possible, although difficult, to disable AMFI, but that’s like going out, leaving your front door wide open, and telling everyone you meet to go in and help themselves. Without AMFI’s protection, your Mac is a sitting duck.

As these framework checks are occurring outside Gatekeeper, and without XProtect even being thought about, mutilating any other part of your Mac’s security systems isn’t going to achieve anything other than exposing it to increased risk. Some report subjectively that moving apps around can bring relief, but it seems temporary, as ultimately AMFI will get those frameworks whatever you try to do with them. And so it should, if you want your Mac to remain secure.

I’ve seen no evidence that this is a bug, nor that it’s ‘fixed’ in Sequoia, which it isn’t. At first I suspected it might have been exacerbated or unmasked by launching apps using other apps, rather than in the Finder, but that’s not true either. What is abundantly clear from my results above is that a faster Apple silicon Mac does the trick, but please don’t misinterpret that as designing security to encourage users to upgrade to newer models, which simply doesn’t follow.

Conclusions

• Significant delays in launching apps can result from security checks of their frameworks.
• Known apps that aren’t in quarantine don’t normally undergo online certificate checks or XProtect scans, and normally complete Gatekeeper checks swiftly.
• The most likely cause of delayed launching of a known app that isn’t in quarantine is protracted security checks of its frameworks.
• Those delays are usually negligible in more recent Apple silicon Macs.
• There doesn’t appear to be any lasting workaround to expedite launch.
• Investigating delayed launches requires careful log analysis.

References

Sequoia
Sonoma 14.6.1 Full Security
Sonoma 14.6.1 Conclusions

Once again, I’d like to acknowledge the invaluable help of Kristian, who provided the slow log extracts and helpful discussion.

Aeneas and his crew are ashore at Caieta (Gaeta), midway between Naples and Rome, where two of the survivors of Ulysses’ crew meet to tell stories from Homer’s Odyssey. Following Achaemenides’ account of their encounter with Polyphemus, he hands over to Macareus to tell of their transformation by the sorceress Circe.

Macareus starts with Aeolus and the bag of winds he gave to Ulysses. For nine days, they experienced favourable winds, but on the tenth the crew opened the bag looking for riches. In doing so they released the winds, which promptly blew the ship back to Aeolus. Then there were the cannibal Laestrygonians, who ate one of the three crew sent to meet them. Their chieftain led a party in pursuit of Ulysses, bombarding his ships with trees and rocks and sinking two of the three. The third ship containing Ulysses, Macareus and others escaped to safety.

They sailed on to Circe’s island, where the surviving crew refused to go beyond its beach. Lots were drawn to form a group to go to Circe’s palace, and they set off. On the way they came across enchanted animals, lions, bears and wolves, which rushed at them but didn’t attack.

Dosso Dossi’s Circe and her Lovers in a Landscape (c 1514-16) is a remarkably early and realistic mythological landscape, with deep rustic lanes, trees, and a distant farmhouse. Circe leans, naked, at the foot of a tree going through spells on a large tablet, with a book of magic open at her feet. Around her are some of the men whom she took a fancy to and transformed into wild creatures. There’s a spoonbill, a small deer, a couple of dogs, a stag, and up in the trees an owl and what could well be a woodpecker, in the upper right corner.

Macareus and his party were taken in to see Circe sat on her throne, busy making a herbal concoction that she had served to them in a barley drink. When she touched their heads with her wand they were all transformed into pigs, apart from Eurylochus, who had refused to drink. He returned to Ulysses and warned him of what had happened to his colleagues.

Briton Rivière’s painting of Circe and her Swine (before 1896) has been used as an illustration for several versions of the Odyssey, and unusually casts Circe as a magic swineherd, with her wand resting behind her.

Alice Pike Barney’s painterly portrait of Circe from about 1915 was most probably made in pastels. Her streaming golden hair almost fills the painting, and wraps the head of the large boar she is embracing.

Ulysses brought Circe a flower he had been given by Mercury, and she took him into her hall, where she tried to lure him to drink her concoction. Ulysses drew his sword, forcing her to back off.

Jan van Bijlert’s Ulysses and Circe from around 1640 shows the couple at the banquet, looking intently at one another. Circe holds her wand, and between them is a goblet containing her magic concoction. At the right, one of the serving maids looks directly at the viewer. At her heels are Ulysses’ crew, in the form of pigs.

Salomon de Bray makes this a more intimate meeting, in his Odysseus and Circe (1650-55). Ulysses is seated clutching a krater-like goblet into which a maid is pouring clear liquid from a bottle. The hero looks quite haggard, and decidedly unimpressed by Circe. Below Ulysses’ left arm, two pigs are drinking more of Circe’s concoction.

Giovanni Andrea Sirani, father and teacher of the great Elisabetta Sirani, painted his account of Ulysses and Circe at about the same time as de Bray, and advances the story a few moments to the point where Ulysses is about to draw his sword. Here Circe is still holding the glass she is trying to get him to drink, with her wand in the other hand. The crew are seen in the background, in the form of pigs. Another woman holding a wand is with them: this could represent their transformation into pigs, or back into humans, so forming multiplex narrative.

The last of the paintings from this period of popularity is Matthijs Naiveu’s Circe and Odysseus from 1702. This is set in a grand banquet inside Circe’s palace, with some peculiar clusters of figures alluding to her role as a sorceress. For example, there’s a table just to the left of the couple at which a satyr and a demon are engaged in conversation. Circe has moved forward from her throne to embrace Ulysses, whose sword is pointing at her body to force her back. The goblet from which she has been trying to get him to drink is held by a maid at the far right. A couple of boars are feeding from fruit laid on the marble floor.

John William Waterhouse’s Circe Offering the Cup to Odysseus from 1891 is perhaps the most complex work showing this story. Circe sits on her throne, holding up the krater for Ulysses to drink, with her wand in the other hand. The viewer is Ulysses, seen in the large circular mirror behind the sorceress, preparing to draw his sword. On the left side of the mirror is his ship, and scattered on the ground at Circe’s feet are the herbs and berries she used to prepare the concoction to transform the crew. To the right, one of those pigs lies on the ground, behind a small incense burner.

Ulysses and Circe then married, and she took him off to her bed. As a wedding gift to him, she transformed his crew back into human form, to their great relief. They remained on Circe’s island for a whole year before resuming their journey.

I hope that you enjoyed Saturday’s Mac Riddles, episode 304. Here are my solutions to them.

1: Glance at a miniature image or foretaste.

2: Desktop gadget should give your beer a creamy head.

3: Merchant of medics ensures indexing of contents.

The common factor

I look forward to your putting alternative cases.

Until last November, lightweight virtualisation of macOS on Apple silicon Macs had behaved uniformly across M-series families. Although I have heard of one report of problems moving VMs between Macs, those were built with custom kernels. In ordinary experience, VMs running on M1, M2 and M3 chips seemed not to care about the host’s hardware, and most of the time just worked, and updated correctly. There was one unfortunate glitch with shared folders that were lost in macOS 14.2 and 14.2.1, but otherwise VMs largely worked as expected.

Then last November disaster struck those of us who had just started using our new M4 Macs: they couldn’t virtualise any version of macOS before Ventura 13.4. Running a macOS VM for any version before that on an M4 Mac resulted in a black screen, and the VM failed to boot. That was fixed swiftly in macOS 15.2, and we no longer had to keep an older Apple silicon Mac around to be able to run those older versions of macOS in VMs.

Like many who virtualise macOS on Apple silicon, I keep a library of VMs with different versions so I can readily run tests on my apps and other issues. This is one of the great advantages of virtualisation, provided that you don’t rely on being able to run most apps from the App Store. When Apple releases new versions of macOS, once I’ve updated my Mac hosts, I turn to updating VMs. I’m normally cautious when doing this, to avoid trashing the original version. I duplicate the most recent, open it and run Software Update. When I’m happy that has worked correctly, I trash the original and rename the updated VM with its new version number.

That worked fine with Ventura 13.7.4 updating to 13.7.5, and Sonoma going to 14.7.5, but Sequoia 15.3.2 failed with a kernel panic, as I’ve detailed. When several of you kindly pointed out that M1, M2 and M3 Macs had no such problem, I confirmed on my M3 Pro that this is confined to hosts with an M4 family chip.

I have since tried updating my 15.3.2 VM to 15.4.1 on the M4 Pro, a surprisingly large update of over 6 GB, and that continues to result in a kernel panic and failure. I have also tried updating from 15.1 to 15.4.1 with an extraordinarily large download of more than 15 GB, only to see a repeat of the same kernel panic, with an almost identical panic log.

The macOS 15.4 update was particularly large, and some Apple silicon Macs were unable to install it successfully, most commonly on external bootable disks. From your reports, the 15.4.1 update seems to have fixed those problems with real rather than virtualised macOS. However, it hasn’t done anything to solve problems with VMs.

If you have an existing VM running any version of Sequoia prior to 15.4, then you’re unlikely to be successful updating that to 15.4 or later using an M4 host.

In contrast, upgrading a VM currently running Sonoma 14.7.5 completed briskly and without error. To my great surprise, that only requires a download of 8.7 GB, a little over half the size of the update from 15.1 to 15.4.1, which seems to be the wrong way round. The snag with upgrading from a previous major version of macOS to 15.x is that VM will never be able to use one of the most attractive features of Sequoia, iCloud Drive. If you want support for that, you’ll have to build a fresh VM using a Sequoia IPSW image file.

So for the time being, M4 hosts have a barrier between 15.3.2 and 15.4 that they can’t cross with an update. If you want a VM running 15.4 or later, then you’ll have to build a new one, or update 15.4 or later.

I don’t know and probably wouldn’t understand what changed in the 15.4 update, but it has certainly upset a lot of apple carts and VMs. And if you’d like a little homework, can you please explain:

• Update 15.1 to 15.4.1, download 15 GB, failure.
• Upgrade 14.7.5 to 15.4.1, download 8.7 GB, success.

This third and final article devoted to paintings of Easter covers the events after the entombment, from Christ’s body in the sepulchre and the harrowing of Hell, to the Resurrection. Although less frequently painted than the Crucifixion, the Resurrection is the whole purpose of Easter.

William Blake’s The Angels hovering over the body of Christ in the Sepulchre; Christ in the sepulchre, guarded by angels from about 1805 elaborates the gospel accounts of Christ’s body in the sepulchre with reference to the description of the tabernacle in Exodus, chapter 25 verse 20:
And the cherubims shall stretch forth their wings on high, covering the mercy seat with their wings, and their faces shall look one to another; toward the mercy seat shall the faces of the cherubims be.
This may have been in the light of Hebrews, chapter 9 verse 5:
And over it the cherubims of glory shadowing the mercyseat; of which we cannot now speak particularly.

Just before the end of the sixteenth century, Jan Brueghel the Elder collaborated with Hans Rottenhammer in Christ’s Descent into Limbo (1597). This is set in a grand vision of a dungeon at the edge of a fiery underworld that could have been painted by Hieronymus Bosch.

William Blake’s Christ Appearing to His Disciples/Apostles After the Resurrection is one of his large colour print series from 1795, referring to the gospel of Luke, chapter 24 verses 36-40:
And as they thus spake, Jesus himself stood in the midst of them, and saith unto them, “Peace be unto you.” But they were terrified and affrighted, and supposed that they had seen a spirit. And he said unto them, “Why are ye troubled? and why do thoughts arise in your hearts? Behold my hands and my feet, that it is I myself: handle me, and see; for a spirit hath not flesh and bones, as ye see me have.” And when he had thus spoken, he shewed them his hands and his feet.

William Holman Hunt’s Christ and the Two Marys is an early Pre-Raphaelite painting from 1847, the year before the formation of the Brethren, and a time when religious themes were popular among them. The two Marys are Mary Magdalene and “the other” Mary, while Christ, his stigmata plainly visible, has cast off the bandages his body was wrapped in for burial.

Nikolai Ge’s Heralds of the Resurrection, from 1867, probably shows Mary Magdalene rushing to tell the disciples of the news that Christ’s body was missing, and that he was resurrected. At the right are the guards who were placed at the tomb, perhaps.

Several impossible legends grew about Mary Magdalene; here Albert Edelfelt’s Christ and Mary Magdalene, a Finnish Legend (1890) dresses her in contemporary clothing, and transports the two to the lakes and forests of Finland, where the first pale leaves of Spring are on the trees.

Fritz von Uhde has a similarly modern approach in Touch me not. John 20:17 from 1894, this time outside a small town in Germany.

John Roddam Spencer Stanhope’s Why seek ye the living among the dead? (St Luke, Chapter 14, verse 5) (1896) refers to the version in which Mary Magdalene and companion(s) return to Christ’s tomb, only to find its door open and the tomb empty. They are then greeted by two men who inform them that Christ has risen from the dead. Stanhope depicts this in the style of a frieze, the four figures arranged across the painting in a single parallel plane. Although part of a complex narrative, he depicts only a limited window from the story, and in doing so makes his painting simpler and more direct.

Late in the nineteenth century, Eugène Burnand’s most successful painting was The Disciples Peter and John Running to the Tomb on the Morning of the Resurrection from 1898, now in the Musée d’Orsay in Paris. Their faces and hands tell so much, surprisingly for an artist who had concentrated for his whole career on landscapes.

Albin Egger-Lienz painted a thoroughly modern account in 1923-24. He developed the study above, known simply as Resurrection, into the finished painting of Resurrection of Christ below.

I close with a wonderful painting of a more recent Easter Sunday, by the Ukrainian artist Mykola Pymonenko.

Waiting for the Blessing (1891) shows the scene at a country church at dawn on Easter Sunday. The local population is crowding inside, while the women gather with their Paska, traditional ornamental bread that must be blessed before it can be eaten as a brunch. Note how defocussed the crowd in the background appears relative to the women and children in the foreground.

May all our Easters be peaceful, wherever we are!

For at least the last decade you’ve been able to discover why a Mac last shut down by finding the cause code written in its log. Last week I finally got round to updating the old information given here about how to read that shutdown cause code in the log. It wasn’t a feature that I’d looked at yet in Apple silicon Macs, where I was disappointed to find no trace of them.

The explanation for this difference from Intel Macs hinges on understanding the origin of those cause codes, as revealed in the log. They come from the System Management Controller, according to their log entry with AppleSMC as the senderImagePath, in Unified log terminology. As it’s responsible for managing Intel Mac hardware, it makes good sense that it should keep track of events such as shutdown and sleep, and have a good idea of why they should have happened. It has thus been puzzling that all those years Apple has never seen fit to acknowledge the existence of the SMC’s cause codes and provide a list of them.

One of the more subtle changes in Apple silicon chips is that they use completely different SMCs, embedded within the chip itself. While I’m sure they too know what’s going on with such major system events, they don’t appear to breathe a word about them in the log. Despite searching through log entries from and about these new SMCs, nowhere did they mention the cause of the last shutdown, even by giving an inscrutable code.

Looking in the most obvious places, such as System Information and NVRAM, drew a blank. Instead, by comparing logs between restarts following a kernel panic in a Virtual Machine with those from normal boots of the host Mac, I was able to discover signs of whether a panic had been responsible for that restart:

• Look for /var/db/com.apple.DumpPanic.panicLogPathBreadcrumb. If that file exists, drag-copy it to your Documents folder and open it with a text or property list editor. It should contain a single dictionary, with a UUID key and a string. If that’s empty, there’s no panic log, otherwise it may give you a further clue as to where the log might have been saved.
• Look for the word paniclog in the eventMessage field for log entries in the minute or two after the Mac restarts. If that extract reads failed to map memory for paniclog output - 0x3 then there’s likely to be a panic log somewhere.
• Browse log entries from the subsystem com.apple.DumpPanic in the minute or so after startup. That subsystem handles generation of the panic log, makes it clear whether there is one, and even reveals its opening line.

While those should be useful for determining whether the last shutdown and subsequent restart were the result of a kernel panic, they still won’t tell you the cause of other shutdowns, for example because of power or other hardware problems.

Since then I have been following another lead, this time in the information provided by sysctl. Although that can be complicated to obtain from the command line, there’s easy access offered in Mints. What I don’t know yet is how consistent or reliable those entries are in Apple silicon Macs, but after a normal shutdown and Power button startup they read:
kern.bootreason: pwrbtn
kern.shutdownreason: wdog,reset_in_1 rst_in,reset_in_1_deassert target_off_restart ap_shutdown

My panic-to-order Virtual Machine doesn’t offer such useful information in sysctl, probably because it only has a virtual SMC.

Another line might have been to read the SMC’s own log using
pmset -g log
or in the Logs item in System Information. Although that provides lots of undoubtedly fascinating information about what it’s up to, there seems to be nothing about reasons for shutdown or startup.

For the time being, at least, Apple silicon Macs don’t seem to provide any equivalent to the shutdown cause code found in the log of Intel Macs. Perhaps it’s time to file a Feedback request for the return of the lost cause code, or would that in itself be a lost cause?

In this second of my three articles devoted to paintings of Easter, I cover the Crucifixion, from Christ’s ascent to calvary bearing his cross, to the entombment of his body.

Way of the cross

Jacopo Tintoretto’s Ascent to Calvary (E&I 128) is unusual among paintings of this phase of the Passion for its inclusion of all three of those to be crucified bearing their crosses. Christ is naturally prominent in the upper half of a composition dominated by diagonals, formed by the winding path and the crosses themselves. He and the two thieves are each given assistants who help them with the burden of the crosses.

In the upper distance are banners declaring the oversight of the Roman authorities, in their inscriptions of SPQR. Tintoretto links this with the Crucifixion with the inclusion of the tradesmen and their tools who were shortly to be responsible for the mechanics of the executions. Here the thick ropes bind the figures together, as they are used to attach the crosses to their bearers, and to draw the three along to their deaths.

Lovis Corinth’s Christ Carrying the Cross (1909) explores Christ’s Passion in real terms. Although this contains most of the usual elements seen in traditional depictions, his language is contemporary, almost secular. Two men, one of them apparently African, are helping Christ bear his exhausting load, while a couple of soldiers are whipping him on, and threatening him with their spears. A third soldier is controlling the crowd at the upper left, and behind is a mounted soldier and one of the disciples.

Crucifixion

Tintoretto’s Crucifixion (E&I 123) (1565) is over 5 metres (17 feet) high, and 12 metres (40 feet) across. The artist makes use of space with a narrative technique based on the traditional ‘multiplex’ form popular during the Renaissance: its single image shows events at more than a single point in time, in an ingenious and modern manner.

Naturally, the painting centres on Christ crucified, but the two thieves executed beside him are not shown, as would be traditional, already hanging from their crosses. Instead, to the right of Christ, the ‘bad’ thief is still being attached to his cross, which rests on the ground. To the left of Christ, the ‘good’ thief is just being raised to the upright position.

Spaced out around the canvas are relevant sub-stories from that whole. At the foot of Christ’s cross is his group of mourners, including the Marys. Each of the crosses has attendant workers, busy with the task of conducting the crucifixion, climbing ladders, hauling on lines, and fastening each victim to his cross. This mechanical and human detail brings the scene to life, adding to its credibility and grim process.

James Tissot’s What Our Lord Saw from the Cross is a uniquely innovative and narrative depiction of the crucifixion.

Descent from the Cross

Peter Paul Rubens painted a huge panel showing the Crucifixion, although in this case it’s strictly speaking a Deposition: this centre panel, Descent from the Cross (1612-14), is from his triptych commissioned by the Confraternity of the Arquebusiers of Antwerp for the Cathedral of Our Lady in that city. This remains one of Rubens’ greatest religious paintings.

The Deposition (Descent from the Cross) (1895) was one of Lovis Corinth’s major paintings from his time in Munich, and won a gold medal when it was exhibited in the Glaspalast in Munich, in 1895. It shows the traditional station of the cross commemorating the lowering of the dead body of Christ from the cross, attended by Joseph of Arimathea and Mary Magdalene.

This work is a thoroughly modern approach to this classical theme, in its framing, composition, and the faces. Its close-in cropped view suggests the influence of photography, and the faces shown appear contemporary and not in the least historic. These combine to give it the immediacy of a current event, rather than something that happened almost two millennia ago. Corinth returned to the subject of the Deposition, and the theme of the Crucifixion, in many of his paintings.

Pietà

Gustave Moreau painted several versions of the Pietà (c 1876), this one on a tiny panel. It incorporates some of the more radical imagery which was appearing in his mythological paintings, with a blue wing in the centre.

Entombment

William Blake’s The Entombment (c 1805) refers to the gospel of Luke, chapter 23 verses 53 and 55:
And he took it [the body of Jesus] down, and wrapped it in linen, and laid it in a sepulchre that was hewn in stone, wherein never man before was laid.
And the women also, which came with him from Galilee, followed after, and beheld the sepulchre, and how his body was laid.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Glance at a miniature image or foretaste.

2: Desktop gadget should give your beer a creamy head.

3: Merchant of medics ensures indexing of contents.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

When the Mac 128K was launched, the computing world was quite happy working with text composed using single-byte characters, and the full 256 characters of Extended ASCII seemed quite sufficient. In those days, encoding text for each language was based on its code page, a different set of 256 characters according to that language’s needs and conventions.

The Mac’s initial version of Extended ASCII became its standard Mac OS Roman encoding by System 6.0.4 in 1989. Since then it has been modified to add support for the euro currency symbol in 1998, and is still supported in macOS. Other code pages for single-byte character encoding extended to Mac OS Icelandic, for example, which formed the basis of Macintosh Latin used by the popular Kermit file-transfer software.

Many languages can’t be encoded in such small character sets, and required 2-byte encodings instead. Dealing with these complexities and support for different writing directions became the task of the Script Manager, introduced in System 4.1 in 1987.

Another fundamental concept in Mac OS has been that text isn’t just a character set, but has to be drawn on the display with other graphics content. Text handling thus became integrated with its rendering and features such as word breaking and ligatures. Support for handling text using mixed scripts came in two optional extensions: WorldScript I for single-byte encodings, and WorldScript II for 2-byte encodings such as Chinese, Japanese and Korean.

There were two more mundane complications for the Classic Mac OS user: line termination, and string handling in code.

While MS-DOS and PCs used the combination of carriage return and line feed characters (\r\n) to terminate lines, Classic Mac OS used carriage return (\r) alone, then Mac OS X followed the Unix convention of using line feed (\n) alone. Although the better text editors supported each of those, and would convert text files between them, that became tedious.

Much application development for Classic Mac OS was performed in Apple’s Macintosh Programmer’s Workshop (MPW) using the extended implementation of Pascal known as Object Pascal. This had adopted UCSD Pascal string format, in which the first byte(s) in its native strings contained the length of the string in bytes, rather than its first character. This was all the more confusing when combining projects with C, whose native string format didn’t preface its characters with length, but terminated every string with a null byte.

In 1985, while working on KanjiTalk, the heart of the Mac’s Japanese localisation, Mark Davis and Ken Krugler developed ideas that eventually led to Unicode. When Davis hired Lee Collins to join him at Apple from Xerox, they developed their proposals further, and in 1987 Apple was one of the founders of the Unicode Consortium. The following year, Apple decided to build Unicode support into TrueType, the new font standard it released in System 7 in 1991.

In 1998 System 8.5 integrated support for Unicode text, in Apple Type Services for Unicode Imaging, ATSUI, which was still supported until 2022, and has finally been removed altogether in macOS 14 Sonoma the following year. Initial support for Unicode included UTF-16 encoding to the Unicode Standard version 2.1. Conversion between text encodings was provided by the Text Encoding Conversion Manager.

Core Text superseded ATSUI in Mac OS X 10.5 Leopard in 2007, and is part of the Cocoa text system inherited from NeXTSTEP.

One unexpected new feature of Unicode was the LastResort, the symbol shown for a code point that doesn’t exist yet, and the product of garbled text, seen here in 2007.

Even in familiar languages like Greek, Unicode offers exotics such as GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI, whatever that might be used for.

However, Unicode has brought its own problems, among them its acceptance of multiple code points (character encodings) for visually identical characters. In normal text use this can impede searching, but becomes more critical with the naming of files and directories.

The letter Å can be represented in UTF-8 as either C3 85 (Form C) or 41 CC 8A (Form D). Search for the word Ångström using Form C, and you won’t find the same word using Form D instead. A file system that allows both forms to appear independently in file and directory names appears to the user to allow items with duplicate names, and that poses further problems for search.

In Apple’s Macintosh Extended (HFS+) file system, Unicode normalisation is used to map characters to Unicode Form D, but when Apple developed APFS it intended to leave any normalisation to apps. Early releases of APFS thus didn’t perform normalisation, resulting in many problems for app developers and users. This was rectified by incorporating a normalisation layer into macOS to return to the relative sanity of Form D.

It would perhaps be better to close without mentioning the annual additions to emoji supported in Unicode, as announced prominently in macOS updates. It has been a long and sometimes arduous journey from Extended ASCII to the of .

Apple Inside Macintosh: Text (1993)
Pascal string types in the Free Pascal and Lazarus Wiki
Unicode – the beginnings, Mark Davis and others
Apple Core Text Programming Guide (2007-2014)
Apple Core Text, current documentation

Easter is one of the two landmarks in the Christian calendar. This weekend I devote three articles to paintings of the Passion, Crucifixion and Resurrection of Jesus Christ. Although these don’t sync perfectly with the calendar, they should provide better coverage of events that are the most painted in European art. Today, on Good Friday, these cover the Passion prior to the Crucifixion; tomorrow, paintings show the Crucifixion itself, and on Easter Sunday I end with the Resurrection.

Christ’s triumphal entry into Jerusalem

Now known almost exclusively for his fine engravings for books, Gustave Doré was in his time as well known for his paintings. This is a preparatory sketch for one of his several versions of Christ’s Entry into Jerusalem. This shows the conventional Christian account in the Gospels, of Christ entering Jerusalem in triumph, on the back of a donkey, as the start (‘Palm Sunday’ because of the palm fronds usually involved) of the series of processes leading to his Crucifixion. A popular biblical narrative in European painting, few finished works can match Doré’s at 6 by 10 metres size.

Cleansing of the Temple

Gaetano Previati’s undated and sketchy painting of Christ Driving the Money-Changers from the Temple appears to predate his Divisionism. It shows the Cleansing of the Temple, in which Jesus expelled merchants and money-changers from the Temple of Jerusalem, as described in the Gospel of Matthew, chapter 21, verses 12-17.

Anointing of Jesus by a woman

William Blake’s Mary Magdalene Washing Christ’s Feet is one of the biblical series he painted for his patron Thomas Butts in about 1803-05. It shows the scene during the supper at the house of Martha and Mary, which prefigured the Last Supper in several ways. This is told in the gospel of John, chapter 12 verses 1-8:

Then Jesus six days before the passover came to Bethany, where Lazarus was, which had been dead, whom he raised from the dead. There they made him a supper; and Martha served: but Lazarus was one of them that sat at the table with him. Then took Mary a pound of ointment of spikenard, very costly, and anointed the feet of Jesus, and wiped his feet with her hair: and the house was filled with the odour of the ointment.

Then saith one of his disciples, Judas Iscariot, Simon’s son, which should betray him, “Why was not this ointment sold for three hundred pence, and given to the poor?” This he said, not that he cared for the poor; but because he was a thief, and had the bag, and bare what was put therein. Then said Jesus, “Let her alone: against the day of my burying hath she kept this. For the poor always ye have with you; but me ye have not always.”

Presumably the man sat in the centre, wearing blue, is intended to be Lazarus; Mary and Jesus look awkward together: it has been proposed that this results from meanings that Blake attached to left and right, but here it’s almost inevitable given the composition. This does, though, provide a full view of the curved and compacted figure of Mary, and her wiping of Jesus’ feet using her luxuriant hair.

The Last Supper

The most famous painting of The Last Supper, and one of the best-known works in the European canon, is of course Leonardo da Vinci’s. Giampietrino’s copy from about 1520 gives the closest impression today of what the original must have looked like. Even this copy has been horribly mutilated: the upper third was cut off, and its width reduced, but at least what remains gives a better idea of the original’s appearance.

Leonardo’s composition wasn’t entirely revolutionary for the time. Previous paintings of The Last Supper had spread the apostles along the length of a table, with Christ at its centre. However, Judas Iscariot was usually placed alone on the near side, his back to the viewer, and sometimes with his bag of silver visible behind his back.

Leonardo shows the moment of surprise and denial when Christ announces that one of those sat around the table would betray him. In this he was perhaps the first artist to assemble the apostles into small groups, a feature that has been repeated in innumerable images following this. For not only must this be one of the greatest works of European art, it must also have spawned more copies and parodies than any other.

Jacopo Tintoretto’s version from 1563-64 is so radically informal that it still shocked John Ruskin when he saw it three centuries later. Its table is almost square and low-set, with Jesus leaning back and talking quite casually. Twelve apostles sit, lounge, slump and lean around the table, of which one at the right is even eating his meal from his lap. There’s a rough assortment of seating, with a chair resting on its side under the table, as if hurriedly abandoned, which is perhaps a reference to Judas Iscariot.

The Garden of Gethsemane

This has posed the greatest problems for paintings, in that the action in the garden took place in the dark.

William Blake’s The Agony in the Garden is an unusual moment from the popular sequence of the Passion. Although much of it is inevitably dark, Blake’s imagery is as radical as those in his watercolours. The story is a composite from the gospels of Matthew, Mark, and Luke, and shows the instant just before Christ’s betrayal by Judas and his arrest. An angel appeared from heaven, to strengthen Jesus, and “his sweat was as it were great drops of blood falling down to the ground.”

Christ’s head is tilted in the extreme to face the angel, who grasps him under the armpits. The angel has descended from a brilliant red burst at the top of the painting, while the disciples are seen asleep among the dark tree-trunks.

The Trials of Jesus

James Tissot’s huge series of watercolours showing the life of Christ includes the Passion in great, and sometimes graphic, detail. Jesus Before Pilate, First Interview shows the episode from Luke 23:1-4 and John 18:33-38 in which Pilate, the Roman governor at the time, questions Jesus and concludes that there is no basis for any charge against him. Technically one of the most brilliant paintings of the series, it is easy to mistake this for being painted in oils.

Crowning with Thorns

In Hieronymus Bosch’s The Crowning with Thorns from about 1490-1500, there are four men around the head and body of Jesus Christ. At the top left, a crossbowman dressed in a green cloak and wearing full armour on his right hand holds, in that hand, the crown of thorns, so as to place it on Christ’s head. At the top right, an older man, whose right arm rests on Christ’s right shoulder, has a more concerned expression, his brows knitted, almost as if trying to reassure Christ.

At the lower right, another older man is seen in profile, looking up at Christ, and clutching at his white robe with both hands. At the lower left, a much older man also appears in profile, looking up at Christ, his left hand holding the top of a stick, his right touching Christ’s body. Christ looks directly at the viewer, his face appearing calm and resigned. He wears a thin, white linen robe, from which his right hand protrudes.

Antonello da Messina’s Christ at the Column, painted in about 1478, is one of the masterpieces of European oil painting. The head of Christ here is almost identical to that of the artist’s pieta, to the point where he is thought to have used the same cartoon for both, but here showed the eyes open and looking up to the heavens.

Amazingly, this painting didn’t appear until 1863, when it was bought by the chief curator at the South Kensington Museum in London from a dealer in Granada, Spain. It was originally attributed to Andrea Solario, and wasn’t recognised as Antonello’s until the twentieth century. After display in the National Gallery in London, it was bought by the Louvre in 1992.

Presenting complex verbal information in an accessible way remains one of the great challenges in interface design. This article explains how SwiftUI List Views offer solutions that are superior to those provided in AppKit, and why I have chosen to use them in several of my recent apps, such as LogUI and AppexIndexer.

Each of the apps I discuss here has a common problem: it has to display a series of text records consisting of fields whose contents can be completely empty or expand into long paragraphs. Thus the condensed length of each row, representing a single record, can be as short as 30 characters, or as long as hundreds, some with embedded line-breaks. Fields contain contrasting data, such as datestamps, flowing text and UUIDs. The user needs to scan rows rapidly, following patterns in fields and their contents, and to read each carefully.

There are some ground rules, notably:

• rows must remain visually separate,
• the order of fields in each row must be the same,
• each field must be displayed in full and not truncated,
• fields must be visually distinct across each row,
• field width must be adjusted automatically to avoid horizontal scrolling.

There are centuries of experience in print design of tables, to which computers add dynamic resizing of columns and ready use of colour.

In some circumstances, AppKit’s Table View works well, here in Activity Monitor. However, adjustable column widths can’t overcome one problem shown here, where uniform column width wastes space for short process names, and truncates others.

This shows how poorly a Table View copes with log entries in Console.

My best solution using AppKit is for rows of untruncated text, with colour used to distinguish fields within them. Unfortunately, some rows inevitably overflow into multiple lines, and may require very wide windows to remain accessible.

This is SwiftUI’s List View in action with a log excerpt in LogUI. Although it might appear desirable to allow manual adjustment of field width, it’s more practical to provide options to change which fields are displayed, and so accommodate narrower windows. Sometimes line breaking in fields isn’t good, but I think this is a problem of content (computing terms being formed by concatenating series of words) rather than view design.

This is AppexIndexer, where I use an easily distinguished emoji to mark a significant field positioned in the middle of some rows. This aids navigation when scanning rows quickly, but doesn’t rely on the reading of the emoji.

Here’s another example, this time using many icons drawn from SF Symbols rather than pure text. This works well with fewer rows, but rendering many of those icons in thousands of rows may not be as efficient.

For macOS, SwiftUI continues to suffer serious omissions, and in some circumstances isn’t yet a good fit. But its List Views are a compelling reason for using SwiftUI in many native Mac apps. Further details are given in the references below, and the Appendix provides example source code for a basic implementation in SwiftUI.

Apple Developer Documentation

SwiftUI List view
SwiftUI Table view
AppKit NSTableView

Appendix: Example source code

struct ContentView: View {
    @State private var messageInfo = Logger()
    
    var body: some View {
        let _ = messageInfo.getMessages()
        if (self.messageInfo.logList.count > 0) {
            VStack {
                List(self.messageInfo.logList) { line in
                MessageRow(line: line)
                }
            }
            .frame(minWidth: 900, minHeight: 200, alignment: .center)
        } else {
            Text("No results returned from the log for your query.")
                .font(.largeTitle)
        }
    }
}

struct MessageRow: View {
    let line: LogEntry

    var body: some View {
        HStack {
            Text(line.date + "  ")
            if #available(macOS 14.0, *) {
                Text("\(line.type)")
                    .foregroundStyle(.red)
            } else {
                Text("\(line.type)")
                    .foregroundColor(.red)
            }
            if !line.activityIdentifier.isEmpty {
                Text(line.activityIdentifier)
            }
//          etc.
            Text(line.composedMessage)
            }
        }
    }