App architectures can enable or constrain. My previous log browsers, Consolation and Ulbow, have been document-based, so each window represents a different log extract. As there seemed little reason to open two document windows on a single extract from the log, I’ve normally tweaked and fiddled with each window to display the entries I want to browse, an inevitable compromise that usually leaves me scrolling through thousands of entries.

LogUI is lighter in weight and not based on documents, merely windows and views. Although they’re backed by the data of a log extract, there’s no reason that you shouldn’t open several windows on the same data if that makes analysis easier. And it does, particularly when used with Search. Here’s an example.

Over the last couple of weeks, I’ve been looking at many log extracts covering app launch, one of the busiest events in macOS. In the first few seconds following a double-click to run an app, the log can accumulate well over 25,000 entries. No matter how experienced you are in dealing with them, or how efficiently you can look for milestones marking progress, it can take hours to read the launch process thoroughly in the log. This is partly because of the sheer volume of entries, but most of all because so many subsystems in macOS are involved. Any given period of tens of milliseconds can have long volleys in TCC, interspersed with a series of RunningBoard assertions, and occasional progress reports from LaunchServices. They’ll suddenly be interrupted by DAS dispatching an unrelated background activity, Wi-Fi updates, and other everyday tasks.

Try this instead.

Watch your Mac’s clock until it’s about to change minute. Just as the seconds count changes to 00, double-click the app and take your hands away from mouse/trackpad and keyboard. Once the clock reaches 10 seconds, assuming the app launch is complete, quit that app and start up LogUI. Its new window should show the time when you launched the app, so ensure its time period is correct, say anything between 5 and 30 seconds, and allow it to collect up to the 5-10 seconds required. When that’s ready, click on its Get Log button and check that it contains all the entries you require. Open second, third, fourth, and fifth windows likewise, with the same start times and settings. Once they’re all open, Get Log in each of them, and check that the number of entries is identical, indicating that each has the same log entries.

In my case, launching Pages brought over 40,000 log entries in the first 5 seconds, ending with the app running and prompting me to open a document. Even if you speed-read those at one entry every second, that would take you nearly 12 hours to work through. Let’s reduce that to a few minutes to see each of its important phases.

In a second window, type sendaction: into the Search box at the top right and press Return. That will find all entries marking the clicks/taps you triggered the launch with.

There are two paired entries 0.237 seconds apart, representing my double-tap. So we now know that we can safely ignore everything in the log that happened before the time 11:55:00.767. Leave that window open with just those entries showing, as a reminder.

Normally the first subsystem on the scene to handle those actions is LaunchServices. In the third window, change the search field popup menu to Subsystems, type launchservices in the Search box, and press Return.

Sure enough, from a time of 00.779 seconds, only 0.012 seconds after the second tap, LaunchServices reports that it’s getting ready to launch Pages through RunningBoard, and constructs its EnvironmentDictionary for the purpose. This is the cue to move onto the fourth window, where we set the popup menu to Subsystems again, enter runningboard into the Search box, and press Return.

This details the launch request being handled by RunningBoard, which a few moments later constructs and reports an extensive job description for Pages. Another early arrival during the launch process is TCC to check the new app’s privacy access. In the fifth window, set Subsystems again, and search on tcc.

So far we’ve ignored another group of subsystems and processes that are more interesting than the drudgery of TCC, security. For a first look at how this is checked, switch the popup to Processes and search for amfid, the service for Apple Mobile File Integrity (AMFI) checking.

This shows its check entering first the path to the main executable at 00.805 seconds, two immediate security checks being called, then entering the path for one of the frameworks inside the Pages app bundle 0.05 seconds later. We can readily trace each framework check through the rest of the launch process in this view.

A more general summary of security checking milestones is provided by com.apple.syspolicy.exec, so switch the popup to Subsystems, and search on syspolicy.

This reveals how syspolicyd called a Gatekeeper process assessment on Pages, showed that the code had already been evaluated (despite it not having been run previously in this session), and allowed the launch to proceed without any further checks like an XProtect scan being made.

Finally, for a permanent record of this launch, in any of the windows click on the Save button to write all 41,712 log entries to a Rich Text file. That turned out to be 9.3 MB in size, so I’m glad I’m not still trawling through that trying to make sense of its contents.

To do this, LogUI will require a little more memory: in this case, working with five windows, each with over 40,000 log entries, LogUI took 520 MB. I think the convenience is worth that small cost, but I am going to return to Xcode to see if that can’t be managed better and reduced in size.

At the moment, LogUI doesn’t use any tricks to share a single log extract across different windows, and I’m wondering why and how that could be improved. One approach might be to obtain a single log extract as a Project, from which you can open individual windows for different searches. Although that shouldn’t be difficult to code, it would make LogUI more complex to use, and limit the flexibility of each window. Please try this out yourselves and let me know what you think. For now, I’m surprised at how useful search can be across several open windows.

In two-dimensional visual art, particularly painting, the term frieze is used to describe an arrangement of figures that are flattened into a plane parallel to the plane of the picture, thus resembling those seen in architectural friezes. These returned to fashion in the late nineteenth century for their unusual visual effect.

John Roddam Spencer Stanhope’s Why seek ye the living among the dead? (St Luke, Chapter 14, verse 5) (1896) refers to the account of the Resurrection 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.

In 1902 Gustav Klimt painted a frieze of 24 metres in length for the fourteenth exhibition of the Vienna Secession, his Beethoven Frieze, of which the above is a section known as The Hostile Powers, and that below is Nagging Grief. This is not only a frieze in the sense of a flat wall painting, but its composition is flattened as well.

Another frieze or mural painted at this time is Hodler’s Unanimity from 1913, in the Neue Rathaus in Hanover, Germany. This has survived adverse criticism, the Nazi regime, and the bombing of the city during the Second World War. At its centre is the figure of Dietrich Arnsborg (1475-1558), who on 26 June 1533 brought together an assembly of the (male) citizens of Hanover in its market square, by the old town hall. Together they swore to adhere to the new Reformation doctrine of Martin Luther, as shown here in their unanimous raising of right hands.

Evelyn De Morgan’s Cadence of Autumn from 1905 shows five women in a frieze against a rustic background. From the left, one holds a basket of grapes and other fruit, two are putting marrows, apples, pears and other fruit into a large net bag, held between them. The fourth crouches down from a seated position, her hands grasping leaves, and the last is stood, letting the wind blow leaves out from each hand.

There are also a few paintings in which a frieze forms the background rather than figures in the foreground.

Frederick Sandys shows Medea (1866-68) at work, preparing a magic potion for one of Jason’s missions. In front of her is a toad, and other ingredients. Behind her, in a gilt frieze, is Jason’s ship the Argo.

Dante Gabriel Rossetti’s painting of Arthurian legend, How Sir Galahad, Sir Bors and Sir Percival Were Fed with the Sanct Grael; but Sir Percival’s Sister Died by the Way from 1864, awards haloes to what at first appear to be secular women. In fact he has stretched this legend to include the Virgin Mary, in the left foreground with her white lilies, also given haloes, and a host of angels with wings forming a background frieze.

Finally, paintings may incorporate a frieze above or below a more conventional three-dimensional image.

Félicien Rops’ notorious Pornocrates (1878) shows a blindfolded and nearly-naked woman being led by a pig tethered on a lead like a dog. Below is a frieze containing allegories of sculpture, music, poetry and painting. Make of them what you wish.

This coming autumn it’ll be five years since Apple started shipping its first Apple silicon Macs, and it’s already four years since the first M1 iMac. As prices of used Intel Macs are tumbling, more Apple silicon models are coming onto the used market. With a total of 15 basic M-series chips now available, this article tries to help you decide which new or used Apple silicon model to buy.

CPU cores

With such a wide choice, this is perhaps the most complex feature to understand, and it’s likely to make the biggest difference to what your Mac will do. M-series chips have anything from 2-8 Efficiency (E) cores, and 4-24 Performance (P) cores across four different families.

Although folk are usually more concerned with the number of P cores, E cores are responsible for doing much of the routine work, and shouldn’t be ignored. They run most of the background tasks in macOS, from Time Machine backups to indexing all your images and documents for Spotlight. P cores are largely responsible for running the code in your apps, so determine how fast it feels in use.

Most M-series chips have at least 4 E cores, but two, the M1 Pro and M1 Max, have only 2. They compensate for that by running those E cores at higher frequencies when working on heavy background tasks, but subsequent designs have set the comfortable minimum at 4, and the latest base M4 comes with 6. Of the two core types, E cores are the more versatile, as they can run all types of task, background or user, and when running at their maximum frequency can deliver a high proportion of the processing power of a P core. As an E core’s energy use is much lower than that of a P core, they’re a better option when running a laptop Mac on its battery.

The four E cores in this M4 Pro are kept fully occupied in the minutes after starting up, leaving the P cores free for running apps smoothly.

P and E core performance has increased with each new family. This is illustrated in different types of computation, when running one thread on a single core.

The Y axis here gives loop throughput per second for my four basic in-core performance tests, a tight assembly code integer math loop, another tight assembly code loop of floating point math, NEON vector processor assembly code, and a tight loop calling an Accelerate routine run in the NEON unit. Pale blue bars are results for the M1, purple for the M3, and red for the M4, the higher the bar the faster.

Maximum core frequencies have increased from 3.2 GHz in the M1’s P cores to 4.5 GHz in the M4. One crude comparative measurement of overall computing capacity is to total the maximum frequencies for each of the CPU cores in each chip. Those are shown as Σfn in the table below, and the chart that follows it.

These are also complicated by sub-variants and binned versions, where one or two cores have been disabled by Apple, to produce a cheaper chip.

If you’re looking for CPU performance, the M3 Max, and M4 Pro and Max stand out and approach the performance of Ultra chips. But those assume that the software running is able to make full use of all the cores available. There’s no point in paying for the 32 cores in an M3 Ultra if the app you run most can’t use many of them.

Another detail that’s easily overlooked is the instruction set (ISA) supported, notably that of the M4, which includes new features for accelerated matrix and other computation. In this respect, the M2 family has been underrated, as I’ve explained here.

GPU

For most, the choice of CPU cores determines the GPU provided, and for general use they’re well matched. Exceptions to this are when high GPU performance is essential, and to support external displays. In either case you’ll need to check carefully with Apple’s specifications or Mactracker to ensure support. That’s particularly important when driving multiple high-resolution displays.

Memory

Memory options are determined by the chip, with some starting at only 8 GB, which is insufficient even for the lightest use. There was a myth that the use of Unified memory would result in substantial economy in memory use, but in practice that doesn’t work out, and demand for memory has increased with the introduction of new features such as AI.

The danger with this is that using substantial amounts of swap storage is deceptively fast because of the high speed of the internal SSD. As models with 8 GB memory often have small SSDs as well, this is likely to lead to rapid ‘wear’ of the SSD, and some early adopters saw worryingly rapid changes in wear indicators. Fortunately, Apple has recognised this problem, and all M4 models now come with a minimum of 16 GB.

If you’re interested in buying an older model with only 8 GB, at least check its SSD size and wear indicators before parting with your money. Further information about memory requirements is here.

SSD

While it’s possible to enjoy using an Apple silicon Mac with only 256 GB internal SSD, unless you’re frugal in its use you’ll find yourself buying a more substantial external SSD to supplement that. You can start up an Apple silicon Mac from macOS on an external SSD (or even a hard drive, if you must), but that’s more fussy than with an Intel Mac. If you want to consider relying on external storage, this article explains how best to do that.

For most users, a minimum internal SSD requires 512 GB for comfort and a long life.

Buy to upgrade

Until recently, all Apple silicon Macs have been stuck with the CPU cores, GPU, memory and internal SSD that they came with. That may be changing with some now offering SSD upgrades for the M4 Mac mini. However, those are likely to invalidate your warranty, and aren’t likely to be available for other popular models, apart from the Mac Pro.

Recommendations

• Prefer a later Pro or Max chip over an M1 Pro or Max, to get at least 4 E cores.
• E cores are more versatile than P cores, and an advantage when a laptop is powered by its battery.
• If you need to use external displays, check the model’s support for their number and resolution.
• Look for a minimum of 16 GB of memory.
• When buying a model with 8 GB of memory, check the wear on its SSD.
• Prefer a minimum of 512 GB SSD to avoid relying on external storage.
• Don’t rely on upgrading any Apple silicon Mac’s internal hardware.

Enjoy your new Mac!

In architecture, a frieze is a section of a building above the columns or walls and below the roof, commonly the location of decorative sculpture or a bas-relief.

This is the monumental hall of Walhalla, commissioned in the nineteenth century as a memorial to the great figures of German history. On its north side is this pediment frieze showing the victory of Arminius and the Germanic tribes over the Romans at the Battle of Teutoburg Forest. This is an unusual frieze as it adds more depth to the figures than would appear in a normal relief.

The most famous is shown in Lawrence Alma-Tadema’s beautiful painting of Phidias Showing the Frieze of the Parthenon to his Friends (1868), whose admiring figures include Pericles (at the right), Aspasia, Alcibiades and Socrates.

In two-dimensional visual art, particularly painting, the term frieze is also used to describe an arrangement of figures that are flattened into a plane parallel to the plane of the picture, thus resembling those seen in architectural friezes.

Among the most spectacular wall-paintings of Pompeii are those in the Villa of the Mysteries showing Dionysian Rites from before about 62 CE. Room 5 contains a frieze of 29 figures at nearly life size, apparently depicting a sequence of ritual events involving a mixture of Pompeiians and deities.

In the period before three-dimensional linear projection became widely adopted in European art, many paintings adopted a similar approach for groups of figures. But long afterwards the frieze continued to be used in the right circumstances.

Masaccio’s Adoration of the Magi (1426-7) delivers a frieze-like view of this popular subject. The Virgin Mary is sat on a golden portable folding chair decorated with lion heads and paws, the infant Christ on her knee. To the left of her is the standard group of ox and ass in a shed, and behind her is Joseph, holding one of the gifts from the Magi. Hints at depth are given in the heights of some figures, but they are confined to a shallow plane parallel to the picture plane.

When Raphael painted The Marriage of the Virgin known by its Italian name of Il Sposalizio (‘the marriage’), in 1504, he combined the frieze of figures in the foreground with grand architecture expertly projected in depth. This demonstrates the contrast between the flat frieze in the foreground and the depth of the building behind.

Some motifs are prone to creating frieze effects, and painters have gone out of their way to avoid that.

William Blake Richmond’s An Audience in Athens During Agamemnon by Aeschylus from 1884 is a study of the enraptured audience of a play. Its classical setting has strong formal symmetry, with its central figure perhaps representing the playwright himself. Richmond uses greatly exaggerated aerial perspective, with intense chroma in the foreground falling off rapidly towards the back of the theatre, to give depth to what would otherwise have appeared flat and frieze-like.

Late in the nineteenth century some artists like Ferdinand Hodler adopted frieze effects.

Hodler’s World-Weary (1891-92) was an important early work in the development of his style of Parallelism, with its emphasis on the symmetry and rhythms seen in society. He painted this frieze from models who sat for him in a local cemetery during the autumn of 1891.

The Disappointed Souls (1892), another in this series, also shows five older men, this time dressed in black robes and sat on a bench in barren fields.

The biggest shortcoming of the first versions of LogUI has been their lack of search or find. If you needed to look for anything, the best approach was to save an extract as Rich Text and search through that. I’m delighted to offer a solution in LogUI 1.0 build 42.

Ulbow already supports Find for its log extracts, but that just searches the text contents regardless of which field the text appears in. Sometimes that works well, but if you want to look for specific field entries it’s highly inefficient. When working with its Lists, SwiftUI is different, and its regular Search doesn’t just find text, but only displays those items in the list that contain the text in a given field.

What I’ve attempted to do here is follow the SwiftUI model, so search returns only those log entries that contain the search text, but provide support for searching four different fields:

• the contents of the message,
• the process name responsible,
• the name of the sender,
• the subsystem.

All searches are performed as case-insensitive for simplicity and speed.

The best way to see how this works is to try it.

Here I’ve simply obtained a 20 second period of recent log, with Max entries set to accommodate them, a total of over 13,000 entries, far too many to search through manually.

I left the search field, in the popup menu next to the magnifying glass symbol , set to Messages, then typed cfprefsd into the search box at the top right, and pressed the Return key to initiate the search. This returns all the entries in that log excerpt that contain the text cfprefsd in their message field.

SwiftUI can perform live incremental search, so that as you type characters into the search box, the search is performed. While that can be impressive on shorter lists, and minimises the number of characters you have to type in for a useful result, it’s costly when performed on large lists, and with log extracts can be quite distracting. If you want to see live search in action, I’ve used that in AppexIndexer, where it only has to deal with a few hundred rows at a time.

I then select one of those.

Having found all those entries containing cfprefsd in the messages, I switch the popup menu to Processes and press the Return key again. If the search box has lost the focus, the Mac will ‘beep’, so all you do is click on the search box and press Return to perform the search.

Now the window contains all those log entries containing cfprefsd in their process name. Note how the previously selected entry is still highlighted: selections in log entries should be preserved throughout searches.

For the final search I set the popup menu to Senders, and press the Return key.

This time there are no log entries that meet the search criterion, and the window informs you of that.

To return to the full log extract at any time, empty the search box, perhaps using its 🅧 tool, and press Return.

When you save a log extract in the midst of searching, the file should still contain the whole of the extract, not just what’s currently visible in the search. You should be able to copy only selected entries from a search, though.

As it stands, LogUI now has a toolbar containing the search box and two rows of settings and controls below that. I’m open to suggestions as to how that could be changed or reordered, ideally to reduce it to two rows without increasing minimum window width.

LogUI 1.0 build 42 is now available from here: logui142
and from its Product Page.

I hope you find it useful and more productive.

Following the apotheosis of Aeneas, Ovid lists a succession of rulers of Latium and Alba, the city founded by Aeneas, until he reaches King Proca, who prompts his next stories of transformation, starting with the delightful cautionary tale of Pomona and Vertumnus, who lived during that king’s reign.

Pomona is a devoted and highly capable gardener, who cares for her plants with passion; shunning male company, she has no interest in the many men who seek her love. One, Vertumnus, god of seasons, gardens, and plant growth, loves Pomona more than any other, but is no more successful in attracting her. He is able to change his form at will, and in his quest for Pomona’s love he has posed as a reaper, a hedger, and in various other gardening roles. Through these he had been able to gain entry into her garden, but made no progress in winning her hand.

One day Vertumnus comes up with a new disguise as an old crone with a bonnet over her white hair, leaning on her walking stick. This too gets him into the garden, and he is able to engage the beautiful Pomona in conversation. Vertumnus almost gives himself away when he kisses her over-enthusiastically, but manages to control himself and tries giving Pomona some womanly advice about marriage by encouraging her to wed Vertumnus.

The Roman god Vertumnus was most famously painted by Giuseppe Arcimboldo, in his idiosyncratic portrait of Rudolf II of Hamburg from 1590. Given the nature of the god, Arcimboldo’s choice of fruit and flowers couldn’t have been more appropriate.

Most paintings of this story show Vertumnus in his disguise as an old crone, chatting up a beautiful, and quite fleshly, Pomona.

Francesco Melzi’s Vertumnus and Pomona (c 1518-28) follows Ovid’s account carefully, giving Vertumnus quite masculine looks to ensure the viewer gets the message. In the background is a wonderful Renaissance fantasy landscape with heaped-up hills similar to those seen in ancient Chinese landscapes.

Hendrik Goltzius gets close up in his Vertumnus and Pomona from 1613, and arms Pomona with a vicious-looking pruning knife. There is a wonderful contrast between the two women’s faces and hands here, making this a fine study of the effects of ageing.

Abraham Bloemaert’s Vertumnus and Pomona (1620) uses gaze to great effect: while the persuasive Vertumnus looks up at Pomona, her eyes are cast down, almost closing their lids.

Anthony van Dyck and Jan Roos collaborated in painting Vertumnus and Pomona in about 1625, which is remarkable for its rich symbolism and visual devices. Pomona has her left arm around Vertumnus, but in her right hand holds a silver sickle. She gazes wistfully into the distance, as if in a dream. Vertumnus is again looking up, pleading his case with the young woman, and his left hand (on a very muscular and masculine arm) is behind Pomona’s left knee, between her legs. At the right, Cupid grimaces at the deception, his back turned, pointing at what is going on with apparent disapproval. Then at the lower left corner is a melon cut open to reveal its symbolic form, with its juice and seeds inside as an overt anatomical allusion.

Adriaen van de Velde’s fine Vertumnus and Pomona from 1670 has been marred by the fading of the yellow he used to mix some of his greens, turning some of its foliage blue. He avoids any dangerous allusions, and returns to a more distant view of the pair talking together.

Jean Ranc’s startlingly contemporary Vertumnus and Pomona (c 1710-22) clothes the pair in the fashion of the day, but loses all reference to Pomona as a passionate gardener. At least Vertumnus’ hands are those of a man.

Seemingly influenced by the earlier painting of van Dyck and Roos, François Boucher puts the pair into an embrace in his Earth: Vertumnus and Pomona (1749), and Cupid’s mask play alludes to the deception.

Having cunningly promoted his own cause, Vertumnus tells Pomona the cautionary tale of Iphis and Anaxarete to press his case.

Iphis was a young man of humble origins, and unfortunately fell in love with the high-born Anaxarete. Knowing the hopelessness of his love for her, Iphis told her nurse, and persuaded her maids to take notes and flowers for her. Anaxarete’s response was iron-hearted and cruel: she laughed at him, and shut him out. Iphis was broken by this, and after a brief soliloquy, he hung himself from her door. Her servants cut his body down, but it was too late, he was dead. They carried his body to his widowed mother, who led it in funeral procession to the pyre. As she watched this from a window in an upper room in her house, Anaxarete was transformed into the cold stone of a statue.

Antonio Tempesta’s etching of Anaxarete Seeing the Dead Iphis (1606) condenses the story into a single image, in which Iphis hangs dead, and Anaxarete has just been transformed into stone in front of him, in what is really a form of multiplex narrative.

Virgil Solis adheres more rigorously to Ovid’s account, in his Iphis and Anaxarete, which must have been engraved before Solis’ death in 1562. His multiplex narrative incorporates two separate scenes: in the left foreground, the body of Iphis has been discovered hanging outside the door to Anaxarete’s house. In the right distance, Iphis’ corpse is carried to his funeral pyre, with his mother in close attendance, as Anaxarete looks on from her balcony, and is turned to stone.

Having tried trickery and his cautionary tale, Vertumnus is still getting nowhere with Pomona, so he transforms himself back into his own form, as a young man, which finally wins her heart. This brings Ovid’s conclusion that deception will fail, and success can only come through honesty.

It’s that outcome that Peter Paul Rubens hints at in his late oil sketch of Vertumnus and Pomona of 1636. There is now no pretence that Vertumnus is a woman: he lacks breasts, and even has heavy beard stubble. However, the embrace of his right arm still brings Pomona to push him away with her left arm.

Perhaps the outstanding depiction of this wonderful story is Rubens’ earlier and finished Vertumnus and Pomona from 1617-19. Vertumnus has assumed his real form, that of a handsome young man. Pomona looks back, her sickle still in her right hand, and her rejection of his advances is melting away in front of our eyes. Rubens even offers us a couple of rudely symbolic melons, and provides distant hints at Vertumnus doing the work in the garden while Pomona directs him, at the upper left.

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

1: Where I left my heart in our words since 2015.

2: The first windy city from Susan Kare until 1997.

3: Bigelow and Holmes brought great clarity for the millennium.

The common factor

I look forward to your putting alternative cases.

Support for document versions in iCloud Drive has a curious history. Both iCloud Drive and the macOS versioning system were introduced in OS X 10.7 Lion, in 2011, but haven’t fully integrated over those 14 years. Until 2018, versions were only saved locally and never propagated to other Macs and devices through files shared in iCloud Drive. Then sharing of versions was added, but proved patchy and unreliable, although sometimes versions were propagated in a frenzy. By 2023, that experiment had ended, and behaviour reverted to the original. This article explains how it works now.

Demonstration

To show this, I used Versatility to convert a Pages document into a folder containing each of its seven versions, and moved that folder into iCloud Drive. Once there, I dragged and dropped that folder onto Versatility again to convert it back to a versioned Pages document in my iCloud Drive folder. I then dropped that onto Revisionist to browse those versions and confirm that they remained good.

Although the current version is located in iCloud Drive, with a path from ~/Library/Mobile Documents/com~apple~CloudDocs/, each of its previous versions ‘has local contents’ in a path from /System/Volumes/Data/.DocumentRevisions-V100/PerUID/501/, inside the Data volume’s version database.

On another Mac connected to the same Apple Account and iCloud Drive, that document only has the current version, again with ‘local contents’, as its previous versions are left stored on the other Mac.

If you then edit that document on the second Mac and save a new version there, then make more changes and save another version, those previous versions will remain stored in the second Mac’s version database, but only the current version will be synced to iCloud Drive, and appear as the current version on the first Mac. That still sees the six previous versions stored there from before, but can’t see those added by the second Mac.

Conclusion

Thus each Mac and device – as this applies similarly to versions saved in iOS and iPadOS – sees the common current version synced across iCloud Drive, and only those older versions created and saved on that Mac or device. There is no sharing of document versions in iCloud Drive.

While this behaviour is reliable and consistent, unlike the profusion of versions that occurred in macOS Mojave, it demonstrates how readily versions are discarded when they could or perhaps should have been preserved.

Beware Sonoma

In this respect, I have one important warning concerning versions and iCloud Drive: never use those in macOS Sonoma 14.4. That version of macOS has a serious bug that strips all local versions from any document that’s evicted (its download is removed) from iCloud Drive. Apple fixed that swiftly in the update to 14.4.1, so if you are still using Sonoma, ensure it’s 14.4.1 or later.

How to transfer document versions through iCloud Drive

If you need to work on a document with shared versions, the only solution is clumsy but effective, using Versatility. Keep the live document outside iCloud Drive, in local storage, and transfer it in iCloud Drive using its folder archive generated by Versatility:

1. Edit the local document on Mac A. To transfer it, drop it on Versatility and save its folder archive to iCloud Drive.
2. On Mac B, drop the folder archive in iCloud Drive onto Versatility, and save that to its local location for editing there.
3. To return the live document to Mac A, drop it onto Versatility, and save its folder archive to iCloud Drive, ready to reconstitute on Mac A.

Postscript: Use a disk image

I’m very grateful to @Remo_Pr0 for suggesting an alternative method: save the document in a disk image that you keep in iCloud Drive. Provided that’s larger than 1 GB (smaller sizes are unable to create a local version database), versions will be saved inside the disk image, and preserved for all those Macs that access that document within it. This should also work with a sparse bundle either in iCloud Drive, or in a network share.

If you can think of a better way, please let me know so I can code it into Versatility.

Soon after the Commedia dell’Arte had spread across Europe, travelling performers started entertaining the public with a different but related show, that of Punch and Judy. Mr Punch, the lead male, is based on Pulcinella, who is now a trickster figure who batters his wife Judy. The first recorded show in Britain was on 9 May 1662, using marionette puppets. For the last two hundred years or so, a stylised version performed using glove or other puppets has been popular with children visiting British resorts. In 1827, George Cruikshank made a series of sketches of a performance that were turned into the first illustrated and printed script.

Punch and Judy not only developed its own stereotype characters, but evolved its own plots. At first these shows appeared in street circuses around the towns and cities of Europe, then gravitated towards seaside resorts as they became popular in the summer. Characters from the Commedia also appeared as clowns in more established travelling circuses across Europe and North America.

Philip Hermogenes Calderon’s French Peasants Finding their Stolen Child (1859) draws on the troubled lives of those itinerant players. Various characters from a popular street theatre play are seen at the side of their stage. A couple are embracing a young girl, with the girl’s apparent mother kissing her somewhat reluctant daughter on the cheek.

In the background are the audience, and other stalls of a travelling fair. Entertainers in such fairs were vulnerable to crimes such as child abduction, or it may be that the couple and their daughter aren’t part of the fair, but locals who had their daughter abducted by its travelling performers.

Honoré Daumier’s The Parade, or Street Circus from about 1860 shows a group of mountebanks, theatrical performers, musicians, and clowns who drew large crowds. The crocodile is one of several novel characters from these Punch and Judy shows.

One of Émile Friant’s earliest works is this 1881 painting of The Entrance of the Clowns, showing the interior of the Big Top at the moment that the clowns, acrobats, and other entertainers parade. At the front is Pierrot, with Harlequin sprawling on the ground.

Among Paul Cézanne’s figurative paintings is this of Mardi Gras (Pierrot and Harlequin) from 1888.

The smaller of Fernand Pelez’ two paintings of Grimaces and Miseries: the Acrobats follows the pattern of a traditional ‘ages of man’ image, where its figures increase in stature from the start at the left edge, to the centre, then diminish again with advancing years, to the right. Standing in the middle are Pierrot and Harlequin.

Les Saltimbanques (Acrobats) had been a successful show in the theatre fifty years earlier, and had lived on in entertainments staged in fairs around France. Rosenblum summarises this painting as presenting “a glum view of the contrast between the goals of rousing entertainment in a popular Parisian circus troupe and the actual melancholy and isolation of the performers.” That sounds about right for Pierrot, at least.

Pelez’ later La Vachalcade (The Cow-valcade) (1896) is a reversal of a portrait of an affluent family by way of parody. Thirteen young revellers are taking part in a carnival procession, perhaps one of the Vachalcades which took place in Montmartre at the time. Some wear masks, others have the close-shorn hair characteristic of the poor, a measure against endemic parasites.

At the centre is a boy wearing an adult’s jacket and a huge hat. Behind him is a Pierrot character, and in the background a banner bearing the word Misère, misery. Dangling on that is a dead rat, a reference to a well-known café on the Place Pigalle. The ‘vache’ (cow) in the title refers to the French phrase manger de la vache enragée, meaning to live in poverty.

Pierre-Auguste Renoir painted this full-figure portrait of his son Jean as The White Pierrot during 1901-02.

Like Watteau earlier, the British painter Walter Sickert became interested in traditional pantomime, another derivative of the Commedia and Punch and Judy, seen in this gouache of Pierrot and Woman Embracing from about 1901. This is a preliminary sketch for a painting now in a private collection, Venetian Stage Scene.

Sickert spent much of the summer of 1915 visiting Brighton, where he made studies for Brighton Pierrots. This is a commissioned copy of his original, which remains in a private collection, and like that was painted following his return to his London studio. It shows a small group of entertainers who performed daily on a temporary stage set up on the beach.

Although William S Horton was born in Grand Rapids, Michigan, and trained in Chicago, Paris, and New York, he painted almost entirely in Europe. In about 1917, he arrived in Britain, and in 1920 painted this Punch and Judy show taking place on the beach at Broadstairs, Kent, a traditional family seaside resort at the extreme eastern tip of the south-east coast of England.

Edmond Aman-Jean’s Festival of Venice from 1923 is set at an open-air performance involving a Harlequin character with a moustache, who is offering a woman a pink flower, presumably in an effort to woo her. At the right is a chorus of three women, and another sits asleep in a chair at the far right. A young woman seated at the front of the wooden stage is playing a hurdy gurdy, and a girl to the left of her is making a floral decoration.

The descendants of the commedia dell’arte live on, five centuries after the first Pierrots and Harlequins brought laughter to audiences.

Reference

Wikipedia

Many of you have commented that you too find that apps and command tools can now take surprisingly long to launch. Although my previous analyses have demonstrated how those can often be attributed to security checks being made on components including frameworks and dylibs, there remains some dispute over the nature of those checks. Although I believe there’s convincing evidence that those checks are prolonged to recompute hashes and CDHashes, others are adamant that they are in fact ‘malware scans’. This article considers new evidence.

Inspecting and analysing the log during the launch of large apps isn’t the best way of getting a clear view of what happens when macOS runs its security checks. There’s a great deal going on at the time, with multiple security checks being performed for TCC, LaunchServices and RunningBoard in dialog, sandboxes and containers to set up, and iCloud services to connect. Last week I’ve been tackling this more methodically, and here use two launches of a simple command tool to give clearer insights into what’s going on when macOS runs its security checks.

Methods

The command tool in question is my blowhole, just over 200 KB of simple code to write a message to the log, hence directly telling us when it’s run. It has its signing certificate embedded into its Mach-O binary, and is notarized. However, because it’s a single binary and not an app bundle, its notarization ticket is stapled to its installer package, and not to the tool itself.

The two runs I analyse here are:

• On a Mac Studio M1 Max running macOS Ventura 13.4.1 at 14:32 on 4 July 2023. blowhole had already been installed on that Mac, but the copy being run was in a previously unknown location, ~/Documents, which normally forces macOS to perform more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.
• On a Mac mini M4 Pro running macOS Sequoia 15.4.1 at 20:07 on 2 May 2025. Although blowhole had been installed and run some weeks previously, it hadn’t been run since then, and was expected to attract more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.

The first of those was collected using Ulbow, and the second by LogUI. Excerpts giving milestone entries are given in the Appendix at the end. In the diagrams below, each milestone is given with time in seconds elapsed since the first mention of the binary.

Ventura

First mention of the tool to be run comes from AppleMobileFileIntegrity (AMFI), which leads immediately to its daemon amfid starting its assessment of the binary, with the entry SecTrustEvaluateIfNecessary to inspect the signature and the CDHashes it contains. As this takes a mere 0.003 seconds, and the next stage starts 0.01 seconds after amfid entered the path to the binary, all that could have done was confirm the integrity of the signature, its requirements, and that its hashes were already cached.

syspolicyd then records the start of the Gatekeeper process assessment, and initiates the Gatekeeper scan, first starting checks on the notarization ticket, then starting the XProtect scan while ticket checking proceeds. Of those, the XProtect scan completes first, returning its results to syspolicyd at 0.054 seconds after the start.

Ticket checking involves an explicit connection to iCloud using CloudKit, with abundant log entries. The CloudKit Ticket Store is found to be reachable, and the ticket checked for the CDHashes obtained earlier from the tool’s signature.

With both checks completed satisfactorily, at 0.192 seconds the Gatekeeper scan is declared complete, syspolicyd evaluates its result, and is almost ready for the tool to run. Before that can happen, details of the executable are entered into provenance tracking. syspolicyd confirms the evaluation allows the tool to run, and AppleSystemPolicy records the evaluation result.

Sequoia

The sequence here is very similar to that in Ventura, with some significant differences, marked in the emphasised items in the diagram above.

First, there’s a substantial delay of 0.063 seconds between amfid entering the binary’s path and the start of the Gatekeeper process assessment. This started with entries from amfid recording SecTrustEvaluateIfNecessary and trustd SecKeyVerifySignature, indicating that more took place here than in Ventura. However, there’s no evidence of any external signature checks being made, and it’s most likely that the binary’s hashes weren’t cached, so required recomputation to verify them. The delay is woefully inadequate for any form of malware scan to have taken place at this stage.

When XprotectService reports that XProtect is performing the malware scan, it additionally reports the location of the XProtect rules being used. That’s because Sequoia introduced a new location used for those data files, in /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara as recorded here.

Next, the XProtect scan here takes 0.126 seconds, rather than 0.030 seconds in Ventura. This is the result of the huge growth in the number and complexity of the Yara rules used for this scan over the last two years. The Ventura scan was performed using version 2168 of those rules, with a Yara file of 147 KB size and around 218 rules. By version 5296 used in the Sequoia scan, file size had risen to 947 KB with about 381 rules.

Size of the binary being scanned also affects scan time, although in an unexpected way. A great many of the Yara rules used include upper limits to file size, so those larger than a few MB are subject to few rules, probably intentionally. Thus, larger binary files are likely to complete their XProtect scan in shorter time than expected, and maybe more quickly than smaller binaries.

As a result of these two delays, Gatekeeper’s XProtect results aren’t reported until 0.247 seconds have elapsed since the start, already over 0.05 seconds longer than the whole process in Ventura. However, in this case there’s no mention of provenance tracking, and the blowhole tool is finally run after 0.3 seconds, taking just over 150% of the time in Ventura.

Summary of security checks

• Trust evaluation and signature verification, to confirm hashes and CDHashes if not cached;
• Gatekeeper scan, including simultaneous ticket check and XProtect malware scan;
• CDHash ticket check online using CloudKit with iCloud Ticket Store;
• XProtect malware scan against Yara rules;
• Gatekeeper evaluation for syspolicyd to allow or not;
• Result registered with the kernel;
• Command tool run.

Note that there’s no evidence of any OCSP checks being made with the certificate authority to determine whether certificates have been revoked. Additional time will be required if hashes and CDHashes are to be recomputed, and as a result of increased Yara rules.

Appendix: Log Milestones

Times are given in seconds, adjusted to a start of 0.0. The Ventura extract was obtained with log privacy disabled.

Ventura 13.4.1 2023-07-04 14:32:40 on Mac Studio M1 Max

XProtect version 2168, Yara file 147 KB, 218 rules
0.000000 AppleMobileFileIntegrity Checking in with amfid for DER co.eclecticlight.blowhole
0.001395 amfid Entering OSX path for /Users/howardoakley/Documents/blowhole
0.010608 syspolicyd GK process assessment: /Users/howardoakley/Documents/blowhole <-- (/bin/zsh, /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal)
0.022891 syspolicyd GK performScan: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null))
0.023291 syspolicyd looking up ticket: {length = 20, bytes = 0xe0cad936293cea0807ec2e5193bed5f3f02dc019}, 2, 1
0.023316 syspolicyd cloudkit record fetch: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, 2/2/e0cad936293cea0807ec2e5193bed5f3f02dc019
0.023554 XprotectService Xprotect is performing a direct malware and dylib scan: /Users/howardoakley/Documents/blowhole
0.053971 syspolicyd GK Xprotect results: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), {
XProtectMalwareType = 0;
XProtectSignatureVersion = 4321574501753746074;
}, version: 4321574501753746074
0.170283 syspolicyd CKTicketStore network reachability: 1, Wed Jun 21 19:33:35 2023
0.191576 syspolicyd GK scan complete: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), 4, 4, 0
0.191797 syspolicyd GK evaluateScanResult: 2, PST: (path: /Users/howardoakley/Documents/blowhole), (team: QWY4LRW926), (id: co.eclecticlight.blowhole), (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 4, 4, 0
0.191996 syspolicyd Putting executable into provenance with metadata: TA(917fa0aed8a1a838, 0)
0.191999 syspolicyd Putting process into provenance tracking with metadata: 1410, TA(917fa0aed8a1a838, 0)
0.192054 syspolicyd GK eval - was allowed: 1, show prompt: 0
0.192090 AppleSystemPolicy evaluation result: 17, allowed, cache, 1688477560
0.195467 blowhole Blowhole snorted!

Sequoia 15.4.1 2025-05-02 20:07:00 on Mac mini M4 Pro

XProtect version 5296, Yara file 947 KB, 381 rules
0.000 amfid Entering OSX path for /usr/local/bin/blowhole
0.063 syspolicyd GK process assessment: <private> <-- (<private>, <private>)
0.081 syspolicyd GK performScan: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null))
0.082 syspolicyd looking up ticket: <private>, 2, 1
0.082 syspolicyd cloudkit record fetch: <private>, <private>
0.121 XprotectService Xprotect is performing a direct malware and dylib scan: <private>
0.125 XprotectService Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
0.247 syspolicyd GK Xprotect results: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null)), XPScan: 0,1089725382763820427,2025-05-02 19:07:00 +0000,(null),(null),file:///usr/local/bin/blowhole
0.283 syspolicyd CKTicketStore network reachability: 1, Fri May 2 17:21:52 2025
0.293 syspolicyd GK scan complete: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null)), 4, 4, 0
0.295 syspolicyd GK evaluateScanResult: 2, PST: (path: cc151acaee5bc8cd), (team: QWY4LRW926), (id: co.eclecticlight.blowhole), (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 4, 4, 0
0.296 syspolicyd GK eval - was allowed: 1, show prompt: 0
0.296 kernel evaluation result: 5, exec, allowed, cache, 1746212820, 4, 4, f1f7b76465d358b, 1746212820, /usr/local/bin/blowhole
0.303 blowhole Blowhole snorted!

For comparison, Catalina’s log entries are remarkably similar too.

Stage plays have been the source for many paintings, from the development of the professional theatre across Europe in the mid-sixteenth century in what soon became known as the commedia dell’arte, also Italian comedy in English. Unlike the scripted plays of William Shakespeare, this comedy theatre relied on a mixture of improvisation, stereotype characters, and prepared jokes. It has long been popular in the Venice Carnival, and spread throughout much of Europe during the seventeenth and eighteenth centuries, when it peaked.

This weekend I look first at paintings of its main tradition, and tomorrow at its relative the Punch and Judy show.

One of the keys to the success of the Commedia is its use of costume to identify its best-known characters. This ensured audiences recognised the role of each actor as soon as they walked onto the stage, and proves ideal for paintings too. Among the best-known and most enduring are:

• Harlequin (Arlecchino), a servant wearing a colourful jacket and trousers,
• Pulcinella, a servant wearing a baggy white outfit,
• Pantalone, an older wealthy man wearing a dark cape and red trousers,
• Colombine (Colombina), a maidservant wearing either black and white, or similar colourful dress to Harlequin,
• Pierrot, a servant and sad clown, wearing a voluminous white costume with large buttons,
• Scaramouche (Scaramuccio), a freed servant and skilled swordsman,
• Brighella, an evil servant often paired with Harlequin, wearing a costume trimmed in green,
• The Doctor (Il Dottore), a pedant from Bologna who claims to know everything.

These became increasingly stereotypical over time.

Michelangelo Cerquozzi’s Rehearsal, or A Scene from the Commedia dell’Arte from 1630-40 is an early record, showing more traditional costumes. At the left is a small group containing Scaramouche, Harlequin and possibly Brighella, and at the right are the Doctor and Pierrot, perhaps.

Perhaps the greatest master to develop a particular affection for the Commedia was the French Rococo painter Antoine Watteau. He developed this by 1705, when he had been taken on as an assistant to Claude Gillot.

Watteau’s Foursome from about 1713 shows a Pierrot figure standing with his back to the viewer as he talks to two ladies in fashionable dress.

In his fête galante, Pleasures of Love from about 1718-19, Watteau brings together his novel sub-genre with a Pierrot figure playing a guitar to serenade the ladies in the foreground.

Watteau’s Italian Comedians from about 1720 shows five figures who have just finished performing in a park on the outskirts of Paris. Pierrot, in his baggy white suit, holds his hat ready for donations from the audience. Brighella wears a green-gold suit and cape, and Mezzetin plays his guitar while Harlequin peers over his shoulder. At the far right is Scaramouche, in a Spanish costume of black with a white ruff.

From the same time, and under the same title, Watteau’s stage scene of Italian Comedians puts Pierrot centre-stage, and marked the artist’s last performance of this theme.

At the end of the eighteenth century, Francisco Goya recorded this troupe of itinerant Strolling Players (1793) on the bank of the River Manzanares in Madrid, with a packed audience behind its stage. At the left is Harlequin in his distinctive dress, with a grubby Pierrot towards the centre.

Costumes from the Commedia also became popular wear for masked balls.

If the story behind Gérôme’s Duel After the Ball (1857) is to be believed, on leaving a masked (fancy dress) ball in the winter of 1856-7, an elected official and a former police commissioner fought a duel in a copse in the Bois de Boulogne, Paris. One was dressed as Pierrot, the other as Harlequin. Pierrot was wounded as a result, and the incident became notorious because of the personalities involved, and their comic costumes.

Pierrot leans, as white as his costume, collapsed against one of his team, his face suggesting shock if not imminent death from a wound bleeding onto his chest. His limp right arm still bears his sword, which now drags on the ground. Two other friends are visibly distressed at his condition and trying to console him.

Harlequin, with his second, walks off into the distance at the right. His sword is abandoned on the snowy ground, near four feathers that have dropped from the American Indian headdress of his second. In the murky distance there is a hackney cab, ready to take the combatants away, and a couple walking along the edge of the copse.

Gérôme stages this theatrically, with the absurd grim humour of the participants’ costumes and the comedy of Pierrot and Harlequin.

Stereotypes from the Commedia continue to appear sporadically in more modern paintings, including those of Ukrainian artist Abraham Mintchine who migrated to Paris in 1925.

Mintchine’s Pierrot (1928) is rich in symbols. Against a hilly landscape background, a figure dressed as this character from the Commedia wears a winged cap suggestive of the god Mercury. Resting in front of him are three large seashells.

His undated Child with Harlequin shows a child holding a doll dressed in a Harlequin costume with a black mask.

Mintchine’s Self-Portrait as Harlequin is thought to have been painted shortly before his death in early 1931, and shows another variant of the costume, this time with an exuberant ruff and a starched white linen hat, similar to those worn by Breton women.

Further reading

Wikipedia
Judith Chaffee’s Commedia website

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

1: Where I left my heart in our words since 2015.

2: The first windy city from Susan Kare until 1997.

3: Bigelow and Holmes brought great clarity for the millennium.

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.

The first Macs came with bitmap fonts stored in FONT resources, and those were normally used in the set sizes supplied, as they scaled so poorly. Later in 1984, with the release of the ‘Fat’ Mac 512K and its 128K ROM, Apple moved to NFNT bitmap fonts with a more flexible ID scheme. This continued to change the following year with the introduction of the LaserWriter printer and its built-in PostScript fonts, but those fonts remained in the printer, and Mac displays stayed with bitmap NFNT fonts.

At the outset, Apple had taken a small liberty with the size of the point, the standard unit in typography and print design. In normal US usage there were 72.27 points per inch, which Apple rounded down to 72 for the Mac, where it has remained ever since.

Adobe introduced PostScript Type 1 fonts, still primarily for PostScript laser printers and Adobe Type Manager software. Although competitors reverse-engineered the Type 1 format, Adobe brought them into costly licensing agreements, so limiting access to their rendering. This provoked Apple to start developing a rival outline format, later to be termed spline fonts or sfnt. This project was initially known internally as Bass, then renamed Royal, and was released as TrueType with System 7 in May 1991.

As late as 2002 Mac OS 9.2 still used some bitmap fonts.

Throughout Classic Mac OS, fonts were stored as resources, and in the early years had to be installed using Font/DA Mover, a bundled utility that also performed ID reconciliation. DA stood for Desk Accessory, which also required careful installation.

This is Font/DA Mover 4.1 in 1999.

Individual fonts were grouped into FOND font families, also introduced with the 128K ROM. These could include both NFNT and TrueType sfnt font types. FOND families each had their own ID, but those weren’t unique, so fonts had to be specified by name.

With the success of TrueType, Classic Mac OS became the first operating system to be able to work without the use of bitmap fonts, but still couldn’t itself render PostScript Type 1 fonts to a display. Those using Macs for pre-print design paid for Adobe Type Manager to perform that rendering.

TrueType was revolutionary in opening up font internals in a way that hadn’t been possible with Adobe’s control over PostScript Type 1 fonts. At the time I was writing CAD/CAM apps to support extreme-format cutting systems used by sailmakers and others, who also wanted to cut large characters from fabrics. One of Apple’s TrueType engineers worked closely with me to convert the outline drawing commands in TrueType glyphs into cutter control streams to fabricate letters and numbers sometimes several feet/metres high. I never did work out what point size they would have been.

Microsoft licensed TrueType free from Apple, but Adobe fought back by opening up its Type 1 font format as free to use. Apple enhanced TrueType in 1994, with TrueType GX, bringing Variations to compete with Adobe’s Multiple Master fonts, but it never caught on and few GX fonts were ever released. Its technology was, though, incorporated into Microsoft’s TrueType Open in 1994, and two years later that was merged with support for Type 1 features in OpenType, which became an ISO standard in 2007. The final milestone, for now at least, was the release of OpenType 1.8 in 2016, with its full incorporation of the font Variations of TrueType GX and Adobe’s Multiple Master fonts.

FontLab was originally developed for Windows, and version 3 came to Mac OS 8 in 1988. It’s seen here in 2001, in Mac OS 9.

The release of Mac OS X in 2001 drew Mac fonts away from their previous reliance on resource forks. Font suitcases thus moved to a data-fork format with the extension dfont.

These font suitcases are seen in data-fork format in Mac OS X 10.3 Panther in 2004.

At that time, Apple’s bundled Font Book app had limited features. Here it’s displaying a data-fork format TrueType font Zapfino.

Fontage was a substitute with additional features.

Mac OS X has also brought substantial improvements in Apple Advanced Typography (AAT), a successor to TrueType GX. Mac OS X 10.4 largely completed advanced support for Latin scripts, with later versions of OS X and macOS extending that to Arabic and Asian languages.

Major foundries produced their own software. This is Linotype’s FontExplorer X in 2006, helping to repair a PostScript font suitcase with missing files for download to a PostScript printer.

By 2006, FontLab had developed into FontLab Studio, seen here editing glyphs from my own handwritten font.

Linotype released a Pro version of its FontExplorer X, shown here in 2010. For typographers, designers and font nerds it revealed almost everything there was to know about a font, here a TrueType Helvetica variant.

The other major font design app for Mac OS was Fontographer, developed by James R Von Ehr II, and released by his company Altsys in 1986. This was the successor to an earlier bitmap font editor named Fontastic, and two years later Altsys released the pioneering illustration app FreeHand. In 1995, Altsys was bought by Macromedia, then ten years later Fontographer was bought by FontLab. This shows Fontographer 5.0, released in 2010, and sadly abandoned a few years later.

References

Chapter 4 in Apple’s Inside Macintosh: Text (1993)

Wikipedia’s list of typefaces in Mac OS X
PostScript fonts on Wikipedia
TrueType on Wikipedia
OpenType on Wikipedia

As cities grew during the nineteenth century, what had been countryside in and around them was swallowed up by housing and factories. In the first couple of decades, livestock grazed and cows were milked within a couple of miles of the centre of London.

The American history painter Benjamin West painted this view of Milkmaids in St. James’s Park, Westminster Abbey beyond in about 1801. Two cows and attendant milkmaids are providing a supply of fresh milk for the crowds in this royal park with Buckingham Palace on its edge. This remains 57 acres (23 hectares) of grass, trees and lakes.

John Linnell’s Evening, Bayswater from 1818, only two centuries ago, shows what was then a rural part of London, out to the west of what’s now Paddington Station, in more peaceful times before this area was assimilated into the growing city. Although it has retained some garden squares, this became a densely populated area during the nineteenth century.

Kensington Gardens: Vicinity of the Pond, painted by Paul Fordyce Maitland in about 1907, shows the Oval Pond in the middle of these gardens, another of the royal parks in London, to the west of the Serpentine Lake in the adjacent Hyde Park.

Over the same period, central Paris was extensively rebuilt, but preserved some of its green spaces, including the gardens of the Tuileries Palace.

Camille Pissarro’s Garden of the Tuileries on a Spring Morning from 1890 is an aerial view, with the trees in full leaf, in their brilliant fresh green foliage.

Hans Andersen Brendekilde painted this Summer Day in Villa Borghese in Rome late in his career, in 1922. It shows this large public park, which was originally landscaped in ‘English style’ from a former vineyard. It was bought by the city and made properly public in 1903, and has since hosted many events, including part of the 1960 Olympic Games.

The Austrian Post-Impressionist landscape painter Tina Blau painted her favourite park, Vienna’s Prater Gardens, as its trees were just starting to change colour one autumn, probably around 1890. The Prater covers an area of 1,500 acres (600 hectares) and was opened to the public in 1766.

On the other side of the Atlantic, expansion of cities occurred slightly later, but preserved some notable parks.

This map of New York City and its environs in about 1885-90 shows Central Park on Manhattan Island and Prospect Park, then on the southern edge of Brooklyn.

William Merritt Chase’s view of Prospect Park, Park in Brooklyn from about 1887, shows housing at the edge. This now has an area of 526 acres (200 hectares), and was originally laid out by Frederick Law Olmsted and Calvert Vaux, and completed in 1873.

Olmsted and Vaux were also responsible for the first and most famous New York park of them all, Central Park, now 843 acres (341 hectares). Chase’s View from Central Park shows the park in 1889, and relegates the large buildings of Manhattan to its distant skyline.

Maurice Brazil Prendergast’s view of carriages in Central Park, 1900 (1900) shows how crowded it could become in fine weather.

These and many other views of urban parks have one feature in common: those who took advantage of them were seldom working class. Enjoying these small enclaves of countryside inside cities was almost exclusively for the middle class, who had the time and opportunity. There were also few such parks in industrial cities.

Time Machine and other backup utilities don’t back up absolutely everything. The list of folders and files that don’t get saved in your Mac’s backups is long, and hidden away out of sight. For Time Machine that used to be in /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist but now in .exclusions.plist at the top level of any backup. This article explains the more important in that list, and others that could trip you up. I’ll consider these according to the categories in that file.

TM Backup Exclusions

apiExclusionPaths

These are added by individual third-party apps, by setting the isExcludedFromBackupKey URLResourceKey for that file every time it’s saved. Otherwise this category might be empty.

standardExclusionPaths

This is a long list of standard paths that are set by macOS as not for backup, including:

• .DocumentRevisions-V100 – the version database on each volume, added to this list in Big Sur,
• .Spotlight-V100 – Spotlight metadata including indexes, which will be regenerated after restoring a volume,
• .Trashes – the contents of all Trash folders,
• .fseventsd – the File System Events database,
• /Library/Logs – traditional text log files, not those for the Unified log which are included in backups,
• /Users/Guest – any guest user files,
• /private/var (partial) – various transient files,

among many other ephemeral items.

Of those, only one results in any significant loss of data, the version database. Although this was dutifully copied by Time Machine into backups for several years, the current structure of that database makes it impossible to restore successfully, even when restoring a complete volume. By the middle of the Catalina cycle, it had become a frequent cause of Time Machine choking, so was added to the standardExclusionPaths for Big Sur. As far as I’m aware this was never fixed in Catalina.

stickyExclusionPaths

These are items with an extended attribute of type com.apple.metadata:com_apple_backup_excludeItem attached, including various database and related files inside Photos Libraries. In the event that a library is restored from a backup, they’re freshly regenerated from the library’s contents.

Another interesting exclusion here is the Siri Analytics database included in any sysdiagnose stored in the volume(s) being backed up, in the path
sysdiagnose[datestamp]/logs/SiriAnalytics/SiriAnalytics.db. Presumably that’s for privacy reasons.

systemFilesExcluded

This key is set to true to ensure the whole System volume is always excluded.

userExclusionPaths

These are exclusions the user has set using tmutil or in Time Machine settings, using the Options… button.

By default, volumes on external storage are automatically added to this exclusion list; if you want an external volume to be backed up by Time Machine then you’ll need to remove it from the exclusion list manually.

iCloud Drive

When backing up the current Data volume, by default all files in iCloud Drive that are downloaded to that Mac at the time the backup is made, will be included in that backup. However, any that have been evicted (their download has been removed) will not be backed up, as their data isn’t present locally on the Mac, and that file is dataless. To ensure that those are backed up, download them all prior to the backup starting, and ‘pin’ those you want to remain downloaded in future.

Local snapshots and backups

Any snapshots of a volume aren’t backed up, indeed they can’t be copied to another volume. The same applies to Time Machine backups.

Local snapshot exclusions

All items in the volume at the time a local snapshot is made are included in that snapshot. There are no exclusions from local snapshots, apart possibly from some obscure items internal to APFS.

Third-party backups

Mike Bombich gives a thorough and detailed account of what CCC doesn’t copy on this page. Other backup utilities should also provide full lists on their support site.

Replicated or ‘cloned’ volumes

These should also include the entire contents of the volume as if a snapshot.

What did we do in the evenings before the arrival of TV and radio? People read, talked to one another, played games, and made music. Many middle class homes had a piano, and many children became accomplished musicians. For this, we went into the music room. In one of the houses in which I grew up, we had a drawing-cum-music room containing a wonderful German upright piano that I practiced on daily. Here are some examples from the modest to the grand and regal.

Music features in several of Vermeer’s paintings, in The Concert (c 1663-66) more particularly than any other. Two ladies are making music, one playing a decorated harpsichord (or similar), the other singing. In the left foreground is a cello resting on its back. Tragically, on 18 March 1990 this and a dozen other works were stolen from the Isabella Stewart Gardner Museum in Boston, MA, and it remains unrecovered.

If your home happened to be the palace at Versailles, then you could have a grander music room or two, as shown in François Flameng’s undated painting of a Concert at Versailles.

In the case of Adolph Menzel’s Concert for Flute with Frederick the Great in Sanssouci (1850-52), you could get the composer CPE Bach to accompany you on the harpsichord, and your flute teacher, Johann Joachim Quantz, to listen at the far right. This concert would have taken place in this palace near Potsdam in Germany about a century earlier, in about 1750.

The Music Room, painted by Herman Frederik Carel ten Kate in 1871 also shows a concert from the previous century. While this slightly more modest music room features a couple singing to the accompaniment of the piano, and there are musical instruments in the centre foreground, everyone else in the room is engaged in decidedly non-musical activities.

James Tissot’s Hush! from about 1875 shows a musical performance in a private residence, no doubt attended by the cream of society. Among the honoured guests at the right are two from the Asian continent, but the distinguished host is still awaited, their chair empty, and the violinist poised to begin her command performance once they are ready.

Fritz von Uhde’s Family Concert from 1881 is more typical of a musical evening in a middle class household, apart from the bedraggled crow in the foreground, who seems out of place.

Although the piano in the left foreground isn’t being played, Hanna Pauli’s group portrait of Friends (1900-07) shows an interesting group gathered in her family home. Among those present are the writer Ellen Key (1849-1926), a ‘difference’ feminist and advocate of child-centred parenting and learning, who is reading to the others.

Julius Schmid’s Schubertiade returns to the chandeliers of the past. This was painted in 1897 to celebrate the Austrian composer’s centenary, and shows him performing to a packed music room in the early years of the century.

Music rooms were also features of more compact homes.

Between 1908-26, Édouard Vuillard lived in a fifth floor apartment in Rue de Calais, Paris, overlooking what was then known as Place Vintimille, now Place Adolf-Max. In his Morning Concert, Place Vintimille from 1937-38, a trio of friends are playing for the artist in his apartment.

By that time, some music rooms featured cabinet radios and gramophones for family groups to listen to music performed by those not present.

In my introduction to the macOS document versioning system, I explained that a document could lose all its saved versions when moved to another volume. This sequel provides more detail about how you can preserve or lose those saved versions.

When you save the first version of a document, a record is created in the hidden database on the same volume as that containing that document. That record refers to the file not by its name or path, but by its inode, its unique file system number. Anything that preserves that inode number will thus tend to keep its saved versions; anything that creates a new file with its different inode number is guaranteed to lose all versions.

What’s safe

The following actions are version-safe:

• moving the file anywhere within the same volume;
• renaming the file, changing its permissions, adding extended attributes, adding a custom icon, or editing the file’s data;
• creating a Finder Alias or symbolic link to the file;
• rolling back a local snapshot, which will return the versions to the same state as at the moment that snapshot was made; volume snapshots include the whole version database, and preserve inode numbers;
• ‘cloning’ the whole volume to make an identical copy of everything in it;
• if the file is stored inside a disk image, then that disk image can be copied or moved safely, or backed up; that also applies to files stored inside Virtual Machines.

What loses versions

The following actions are destructive of versions:

• moving the file to a different volume; the original file on its original volume will retain its versions, but they won’t copy across to the new volume;
• duplicating the file; the duplicate, an APFS clone file, will have no versions at all;
• saving the file as a new file, with a Save As command;
• compressing or archiving the file; the copy in the archive won’t have any versions;
• saving the file to a file system like ExFAT or MS-DOS, which don’t support versions;
• backing the file up to another volume, as versions can’t even be backed up by Time Machine;
• moving or copying the file over a network.

If you try to save versions on a file system that doesn’t support them, you aren’t warned when saving those versions, as those appear to remain cached. Normally the first warning is given when you try to close the file.

If you want to keep versions, click on Cancel and save that file to a volume that does support versions.

The version database can only be created on a volume that has sufficient space to support it. This doesn’t normally affect working with regular APFS volumes, but can be a problem if you’re intending to store the file in a disk image or sparse bundle. You should find that a minimum size of 1 GB will support limited versions, but 500 MB is definitely too small for support, and will result in a warning when you try to close the file.

iCloud Drive

The behaviour of versions in iCloud Drive might appear confusing unless you remember the rule that they are saved for that file’s inode number. Here I’ll look at the example of a file that’s in a different folder from iCloud Drive (or Documents in iCloud) and is moved to iCloud Drive.

If that file is already in the current Data volume, that’s the same volume as local copies of what’s in iCloud Drive, so moving it to iCloud Drive keeps it within the same volume, and versions are preserved. If that file is evicted from local storage, that only removes the data for that file, and doesn’t change its inode number. When the file is downloaded again and opened, its versions are still there.

On another Mac connected to the same iCloud Drive, though, the versions are on a different volume on another Mac, so if that opens the file, there are no saved versions available. If that Mac adds its own versions to the file, they will be saved locally, and will be accessible to that Mac.

Saving versions to files already in iCloud Drive is more complex, as different versions of macOS, iOS and iPadOS have saved some into iCloud, so I will look at that in a separate article.

Preserving versions whatever

The only way that I know to preserve all the versions of any file is to save each of them individually in a folder, numbered so that the original versions can be recreated on another volume. While you can use my utility Revisionist to do that, a simpler drag-and-drop approach is provided by Versatility.

There’s no screenshot to show: all you do is drag a file with versions onto Versatility’s blue landing pad. You’ll then be prompted to name and locate the folder it creates containing the file’s versions. Once made, you can move them around like any other Mac folder, back them up, Zip the folder and send it to a colleague.

To reconstitute the original, simply drop the folder onto Versatility’s pad. You’ll then be prompted for the name and location of the file to be saved. That file will contain all the versions saved in the original, ready to use.

If you wish, you can edit the versions in the archive folder created by Versatility. When the file is reconstituted the individual versions will simply be reassembled in numerical order.

I’m also delighted to confirm that both Versatility and Revisionist are fully compatible with macOS Sequoia.

Key point

Versions are linked to the inode number of their file. Actions that preserve that on the same volume should retain those versions. Anything that creates a new inode number or uses a different volume won’t retain those versions.

While the use of colour to encode meaning in terms of sex/gender or devils is relatively unusual, there are other situations where colour conventions are employed in paintings. Among these are standards seen in religious paintings, such as those of the Virgin Mary.

In many paintings of the Virgin Mary, she’s shown wearing a cloak of ultramarine blue, although there are also examples of her wearing green, or a combination of red and green. In Sassoferrato’s The Virgin in Prayer, her cloak looks as if it was painted only yesterday rather than nearly four centuries ago. The choice of ultramarine may have originated from the fact that the pigment was weight-for-weight more expensive than gold, and visually even more stunning.

Dante Gabriel Rossetti’s painting of The Girlhood of Mary Virgin (1848–9) shows her embroidering with her mother Saint Anne, while her father Saint Joachim prunes a vine. Her red embroidery signifies the Passion to come, and the colour is often a symbol of Christ’s blood shed in the crucifixion. It was also adopted as the colour code for cardinals in the Roman Catholic church.

Raphael’s magnificent Portrait of a Cardinal from 1510-11 is notable not only for the lifelike modelling of flesh, but for his attention to the surface textures of the fabrics, something he had developed since his early days with Perugino. Three distinct fabrics are shown in the cardinal’s choir dress: the soft matte surface of the biretta (hat), the subtly patterned sheen of his mozzatta (cape), both in cardinal red, and the luxuriant folds of his white rochet (vestment).

With a limited range of colours available, it was inevitable that there were unfortunate conflicts, as red not only signifies the Passion and crucifixion, and cardinals, but the scarlet woman as a carnal red.

There are two origins proposed for the term scarlet woman: the earlier is the New Testament book of Revelation, in its characterisation of the Whore of Babylon in chapter 17, verses 4-5, where she’s described as being dressed in purple and scarlet, and decked with gold, precious stones and pearls. William Blake’s watercolour of The Whore of Babylon from 1809 follows this literally, although his purple has faded now.

Carolus-Duran’s Portrait of Mademoiselle de Lancey (1876) was exhibited at the Salon, and in its own way became infamous as ‘the lady with the red cushion’. Most of those who attended that Salon knew only too well that she was one of the great courtesans of the Belle Epoque, and could name many of her succession of rich lovers. The scarlets and crimsons and her direct wide-eyed gaze at the viewer left little to the imagination, and the critics were almost as merciless with Carolus-Duran as they had been in 1865 with Manet’s Olympia.

A few artists have used distinctive colour codes in other ways.

Félix Vallotton’s Andromeda Standing with Perseus (1907) shows the sea monster Cetus heading for a defenceless Andromeda, as hero Perseus charges to her aid through a cleft in the black sky. Each figure is colour coded: green for the sea monster, pink for the near-victim, and blue for the hero, against a straw-coloured sea.

Evelyn De Morgan’s Cadence of Autumn from 1905 shows five women in a frieze, against a rustic background. From the left, one holds a basket of grapes and other fruit, two are putting marrows, apples, pears and other fruit into a large net bag, held between them. The fourth crouches down from a seated position, her hands grasping leaves, and the last is stood, letting the wind blow leaves out from each hand. They wear loose robes that are coloured (from the left) lilac, gold, brown, green, and black, the sequence seen in nature.

Colour can be at its most important in multiplex narrative, to indicate each occurrence of an actor, so helping the viewer assemble each part of the story into a whole.

Masaccio’s Tribute Money (1425-8) contains three images of Saint Peter, and two of the tax gatherer, each carefully set and coherently projected into the same single view. Although each is spaced apart from the next, no pictorial device is used to separate them into frames, and they form multiplex narrative. This refers to the Gospel of Matthew, in a story in which Christ directs Peter to find a coin in the mouth of a fish so that he can pay the temple tax. In the centre, the tax collector asks Christ for the temple tax. At the far left, as indicated by Christ and Peter’s arms, Peter (for the second time) takes the coin out of the mouth of a fish. At the right, Peter (a third time) pays the tax collector (shown a second time) his due.

So far, I have looked at slow launching in two apps, Pages and Calibre. Many of the complaints about the slowest to launch have been levelled at apps in Affinity’s popular suite. Thanks to the efforts of Alain, who generously obtained and provided me with log extracts, I can now try to explain why some apps may launch extremely slowly, occasionally taking more than 30 seconds, and on some Macs several minutes.

Previous work

In the first of my investigations, I demonstrated how Pages and Calibre could take a long time checking frameworks in their app bundle, and how that appeared to account for modest delays. I then looked more closely at Calibre, and found an association between slow launching and cache misses when checking frameworks. One possible explanation for that is the recomputation of SHA-256 hashes used to generate the CDHashes that both identify and verify protected code, and in my third article I showed how that could account for large differences seen in older models.

Affinity Designer 2

Alain has provided me with two particularly valuable log extracts from his MacBook Pro M1 Pro running macOS Monterey. Both were collected during launches of Affinity Designer 2, one from a very slow launch taking close to 30 seconds, and the other from a normal, brisk launch taking little more than a second.

Differences between those are stark: the slow launch took 23.5 seconds from mouse-click to loading user preferences for the app, of which 22.3 seconds was accounted for by framework checks, all of which were cache misses. The fast launch took a total of only 1.0 second and didn’t record any framework or other security checks at all, as it was performed about 12 minutes after the slow launch took place.

Framework checks

Framework checks performed during the slow launch consisted of a similar sequence of log entries to those seen in Pages and Calibre:
10.943986 AppleSystemPolicy Waking up reference: 173
10.944007 AppleSystemPolicy Thread waiting on reference 173 woke up
10.944014 AppleSystemPolicy evaluation result: 173, allowed, cache, 1745876410
10.952412 AppleMobileFileIntegrity AMFI: constraint violation /Applications/Affinity Designer 2.app/Contents/Frameworks/liblibpersona.dylib has entitlements but is not a main binary
10.961105 amfid Entering OSX path for /Applications/Affinity Designer 2.app/Contents/Frameworks/liblibpersona.dylib
10.982192 Security SecTrustEvaluateIfNecessary
10.987489 Security SecTrustEvaluateIfNecessary
11.007538 Security SecTrustEvaluateIfNecessary
11.011106 Security SecTrustEvaluateIfNecessary
11.012004 com.apple.syspolicy.exec Recording cache miss for <private>
20.898736 AppleSystemPolicy Waking up reference: 174
Entries here differ slightly from excerpts for Pages and Calibre, as these are from Monterey rather than Sonoma.

In that case, the time interval between ‘waking up’ the two references is the checking cycle time for liblibpersona.dylib in the app’s Frameworks folder, an amazing 9.955 seconds. That dylib is 1.08 GB in size, and the largest of all the components in the app’s frameworks. If that period was accounted for by computing the dylib’s SHA-256 hash, that would represent a rate of 108 MB/s.

Checking cycle times varied greatly, ranging from 0.03-9.96 seconds over a total of 61 frameworks. As the total size of the Frameworks folder is 2.3 GB, the overall rate is 103 MB/s, similar to that for liblibpersona.dylib alone.

What’s being checked?

Log entries don’t provide any information as to what SecTrustEvaluateIfNecessary is likely to perform on these frameworks that can take anything from 0.03-9.96 seconds for each framework. Many of them are far too short to involve any online check, and in any case those are distinctive in their log entries. Malware scan using any known Yara rules is most unlikely, as:

• XProtect Yara rules commonly include file size limits, resulting in few rules applying to larger files, and more rapid completion.
• Known checks using Yara rules are all well-recorded in log entries, and the source of those rules is stated clearly.
• Yara scans are normally reported with their result.
• Scan results are succinct and hardly likely to be lost in a ‘cache miss’.

The most likely activity to account for these long checking times is computation of SHA-256 hashes for the contents of each item in the app’s Frameworks folder. Thus, these occasional extremely long launch times are most probably due to time taken ‘evaluating trust’ by computing hashes for protected code in the Frameworks folder in the app bundle, when those hashes have been flushed from their cache.

Why so extremely slow?

Several events have been credited with causing very long launch times, among them starting the Mac up, and installing updates to XProtect data. It appears most likely that the latter might act indirectly, by flushing at least some of the caches, which may be intentional.

Workarounds

The only strategy that does appear to stop long launch times in most cases is to disable SIP and, in the case of Apple silicon Macs, to set the security mode to Permissive. As I have noted on several occasions, that results in major changes in app security as well. It also disables some features that may be required, including Wallet and Apple Pay. It’s worth being aware that, once so disabled, if those features are to be restored they have to be created from scratch again, and can’t simply be toggled back on. Other side-effects of Permissive Security mode include the refusal of some App Store apps to run.

Those who find the occasional extremely slow app launch unacceptable, but wish to continue to run in Full Security, can pre-warm apps likely to be affected at the start of each session, so making it unlikely that subsequent launches during that session will be slowed. So far, reports of extremely slow launches in Sequoia appear less common, so there may also be benefits to updating macOS if that’s feasible.

Conclusions

• The most likely cause of extremely slow app launches is security checking of frameworks and similar within the app bundle, when cached checks aren’t available.
• Time taken for those checks is dependent on the size of the protected code being checked, and is most probably attributable to the computation of SHA-256 hashes.
• Pre-warming the app by launching it early in each session is a feasible strategy to avoid delays in launching it later.
• Although these extreme delays appear to be most common on Intel Macs, they can still affect older Apple silicon chips such as the M1 Pro.

I’m very grateful to Alain and Kristian who have generously run tests and provided their logs for my analysis, and their discussion.

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.