As I promised here last Sunday, this was a week of updates. The same day that we were busy updating Sonoma, Ventura and/or Monterey, many developers were puzzling as to why they were being offered a beta-release of Sequoia 15.1, long before 15.0 was even ready for baking. There has been speculation as to whether Apple might skip past 15.0 and go straight to 15.1 when it comes to the autumn/fall. This isn’t the first time that Apple has done this during beta-testing, though, so let me hypothesise a little to explain what’s going on, as Apple seems to forgotten to do that yet again.

From September, there are three appointments that Apple can’t miss, two of which already have dates fixed: the release of 15.0 and next major versions of Apple’s other operating systems, and the release of the next batch of new Macs. The third is more flexible, and depends on when Apple Intelligence is ready to go public.

For the next new Macs, Apple wouldn’t dream of shipping them with Sonoma, and there may well be hardware support ready in Sequoia to handle their new chips, whether M3 Ultra or the first of the M4 family in Macs. That means having a decent release of Sequoia to pre-install on the stocks that will shortly be rolling off production lines. That sets the timetable for the release of 15.0, which looks like September.

For many Mac users, 15.0 brings the most important new feature in iPhone mirroring; as they don’t yet have access to Apple silicon, its forthcoming AI means little, at least until Apple has persuaded them to move up to a new Mac. Apple thus needs the completion of 15.0 to meet its timetable for general release and for pre-installation on those shiny new Macs. It has already informed us, though, that 15.0 won’t bring AI in final release form, but most probably as a public beta.

AI needs as much beta-testing as possible to ensure that, when released, it doesn’t become the laughing stock that ChatGPT and other AI have been in their time. While many may marvel at the good things in your AI, it’s the silly and dangerous things that rapidly become most prominent. It’s no good protesting that those are edge cases, as the stigma will have stuck.

That leaves Apple with a problem: it needs two releases of Sequoia to be beta-tested, so its only solution is to fork them at this stage, in the hope that it will continue to get bug reports on the more significant issues remaining in 15.0, and find those rough edges in AI that could give it a bad name when the public first gets its teeth into it.

For developers with just one Mac they can dedicate to beta-testing, so long as it’s Apple silicon, there’s a convenient solution: install the 15.1 beta as the primary system, and then test 15.0 in a virtual machine, which will now at least do iCloud even if other Apple ID services aren’t available yet.

For those of us who want our apps to support AI features like Writing Tools, this is a good way ahead, despite the extra testing and work that it creates. Although only three of my apps do much with text that would benefit from access to Writing Tools, I am keen that those work well when 15.1 is released, maybe in October or November, depending on progress with beta-testing. But I found what was said at WWDC about the requirements was confusing: in places, it seemed that most apps working with text should work fine, but there was also the spectre that apps have to support TextKit 2, which remains an unknown quantity for many, I suspect.

In his presentation at WWDC, Liu Dongyuan stated: “The good news is, if you are using a UITextView, NSTextView or WKWebView, it just works. Keep in mind that UITextView or NSTextView has to use TextKit 2 to support the full Writing Tools experience. If you are using TextKit 1, you will get a limited experience that just shows rewritten results in a panel.” Would I then have to convert DelightEd, Podofyllin and Nalaprop to use TextKit 2, and if so, how would I go about that?

I tried to assemble source code to do this job, but the snippets from WWDC got me nowhere. I downloaded example code from a previous WWDC, and predictably that failed to run correctly in Sonoma and crashed. It looked as if getting my apps to work with Writing Tools was going to take me until the release of 15.1 to get right.

So, like all lazy programmers, I cheated. My three apps had largely been developed well before TextKit 2 was released, and I hadn’t fiddled with the settings for their views since. I was delighted to find a new popup menu at the foot of the Attributes Inspector for NSTextView that could set the view’s Text Layout to one of three options: Default, TextKit 1, and TextKit 2. By default that had of course been set to Default, so my first check was to set it to TextKit 2, build DelightEd, and see how well that worked. As I should have expected, it rendered the view unusable because no content could be selected, although the Select All command still worked, and that enabled Writing Tools to work as well.

As my attempt to cheat macOS had failed, I went back to the Text Layout popup, abandoned the pretence and set it to TextKit 1, as it should have been. macOS duly rewarded me for my honesty, allowing both my view to work correctly, and Writing Tools to function. Not only did they work, but they worked fully in the way that they do for other apps, without any apparent penalty for being TextKit 1, apart from losing the wizzy visual effects seen in TextEdit, for example.

All it took to make three text-handling apps get full benefit from Writing Tools was setting a single popup menu and rebuilding each. In the end it took me longer to update their documentation than it had taken to fix the apps.

I’m hoping now that those three apps will prove good enough to use in macOS 15.0 and 15.1, giving me time to see where else AI might take them. That will most probably require a visit to the alien land of App Intents. Each time I have attempted to read my way into them I have run out of neurones before they make any sense to me, so grasping the basics could take me a little while. There’s now a small suite of intents aimed at word processor apps that look worth investigating.

For text-based apps, support for Writing Tools is going to be critical. If well executed they should prove the biggest thing for Macs since Mac OS X. For anyone who writes, from school kids to eminent professors, this year should be truly transformative.

最近几个月 Ai 绘画这个话题很火，但基本上大家都只是看个热闹，跟普通人的生活没多大关系。或者说，大家感觉不到它和自己有什么关系。只有相关从业者，感受到了巨大的生存压力和身份危机。

但和当年支付大战的春晚红包类似，能让普通人都参与进来、玩起来的场景可能才能让大家感受到：Ai 绘画意味着什么，能做什么。

尽管众多以文生图的 Ai 工具已经大幅度降低了创作门槛，但是在那之前，各种咒术、法门终究是拦住不少普通人接触 Ai 绘画的一块巨石。我自己也曾在用过某些 Ai 工具后，在一条展示初次接触的创作成果的视频里提醒大家，不要忽视它，但也不要过分害怕它。它一定会给我们的生活带来巨大的变化，只是目前还没积累到那一刻，仅此而已。

如果说有什么场景，类似发红包那样简单明了，人人都可以参与，我觉得有一个非常合适的应用场景，那就是用 Ai 生成定制头像。对于不具备绘画能力、不懂念咒语、不会使用绘图软件的大多数人而言，Ai 画头像就是各类修图美容软件一级的场景，既有尝新和娱乐，也有充分的社交属性，和红包非常相似。

最近试用了一下漫镜，一个感觉是，神情抓得不错，风格也足够多，用它来探索自己不同造型的可能性，还是挺有启发的！因此中途我想到一件事，如果这类产品的效率再高一些，跟各大连锁发型屋合作，预约时就上传几张照片，生成几套发型方案，人到了现场就让托尼老师根据效果图来剪，这不是非常好的体验升级么？谁说 Ai 必然逼得人失业呢？还得是看人怎么用。

除了头像，你觉得还有哪些场景，适合普通人体验 Ai 绘画呢？

When Apple offers us the first Macs with M4 chips they should please those who want more precise timing. As their CPU cores use the ARMv9.2-A instruction set architecture, they should feature 1 GHz timers, introduced in ARMv9.1-A. One of the surprises of the first three families of M-series chips has been their relatively coarse-grained time resolution: their Mach Absolute Time increments every 41.67 nanoseconds, while the M4 should be capable of 1 nanosecond increments, as supported by Intel CPUs.

If such momentary time intervals are hard to envisage, we’ve long been able to measure brief moments in time. Second hands on clocks were an occasional feature over four centuries ago, and became commonplace in the nineteenth century, when the advent of railways synchronised time across continents so that trains could run on schedule.

Date Pickers

Macs have multiple clocks, and a common way to access date and time using the Date structure from Foundation. Apple infers that this resolves to ‘sub-millisecond’ times, and Dates are commonly set down to the second. Look in Ulbow and some other of my apps and you’ll see the AppKit interface for this, in a Date Picker with NSDatePicker. Much of those date back to Mac OS X 10.4.

In this case, I set its style to textFieldAndStepper to let the user specify year, month, date, hours, minutes and seconds precisely. As with many other apps, second resolution is essential when working with the log, as a Mac can accumulate thousands or even tens of thousands of log entries in each second.

This has its equivalent in SwiftUI, using the same term of Date Picker, shown here in my prototype log browser LogUI. What’s missing here are the seconds, which are only allowed in watchOS.

In SwiftUI, a Date Picker comes with set components, and those including seconds, hourMinuteAndSecond, aren’t available in macOS, iOS or iPadOS, only in watchOS. The others have to make do with hourAndMinute without seconds, which explains why I’ve had to tag on a separate view to handle seconds.

Not only is there no support for entering seconds in the SwiftUI Date Picker for macOS, but times set using it pick their own value for seconds, which appears to be random, rather than fixing the seconds value at zero. Thus, its value in any Date entered using SwiftUI could range between 0 and 59.

Using AppKit, obtaining the Date set using its Date Picker is simple: for a picker of
@IBOutlet var textBaseDate: NSDatePicker!
the code
let startDate = self.textBaseDate.dateValue
returns the date and time set, including seconds, in startDate.

Adding support for seconds

Dates are opaque structures, and don’t give direct access to components within them such as seconds. To cater for SwiftUI’s shortcomings, more code is required. In the view, the Date obtained from the Date Picker has to be supplemented by a separate value for seconds:
@State private var theStartDate = Date()
@State private var theSecs = "00"
DatePicker("Start", selection: $theStartDate, displayedComponents: [.date, .hourAndMinute])
TextField(":", text: $theSecs)
sets theStartDate to the date with uncontrolled seconds, and theSecs to the number of seconds entered separately by the user.

Then the code that incorporates the seconds into the Date has to work through an intermediate Calendar to do so. It first deconstructs the Date into its components:
let calendar = Calendar(identifier: .gregorian)
var components = calendar.dateComponents([.year, .month, .day, .hour, .minute], from: date)
then sets the seconds correctly, and reconstructs the corrected Date:
components.second = theDateSecs
let dateWithSecs = calendar.date(from: components)!

SwiftUI

SwiftUI was first released for macOS Catalina and iOS 13 in 2019, so celebrated its fifth birthday last month. That makes it only two years younger than APFS, but the contrast in maturity between them could hardly be greater. AppKit may have the advantage of age, in that it was released with the first Mac OS X in 2001, but by the time it was five, midway between 10.4 Tiger and 10.5 Leopard, it was both extensive and mature. AppKit didn’t face the challenge of being cross-platform, though, and parallels with UIKit in iOS came later.

SwiftUI has also rushed forward in novel fields, laying greatest emphasis on iOS. Without sound foundations, though, it risks failure. If it still can’t perform basic functions long-supported by AppKit, then few macOS apps will adopt it, and it will stay playing second fiddle. That would be a bad outcome for all those involved, not least users expecting consistency and high quality in the human interface across Macs and Apple’s devices.

Any good five year-old should be able to tell the time including seconds. Yet SwiftUI hasn’t yet caught up with those German clockmakers of the sixteenth century and their second hands, and seems stuck in the age of sundials. How can it possibly cope with the first Macs based on M4 chips with their nanosecond resolution?

The Macintosh was intended to be different in many ways. One of them was its file system, which was designed for each file to consist of two forks, one a regular data fork as in normal file systems, the other a structured database of resources, the resource fork.

Resources came to be used to store a lot of standard structured data, such as the specifications for and contents of alerts and dialogs, menus, collections of text strings, keyboard definitions and layouts, icons, windows, fonts, and chunks of code to be used by apps. You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps.

Apple’s engineers developed a resource editor that quickly became one of the best-known apps on the Mac: ResEdit, last seen in version 2.1.3 way back in 1994. This was the power user’s quintessential tool: if you didn’t like a particular dialog in an app, ResEdit could be used to change it; if you wanted to create your own custom keyboard layout, it was the first choice for that too. If you were wicked enough to want to mess someone’s Mac up, you could go into their system files and change things around when they were out at lunch. Not that anyone ever did that, of course.

Each resource type had a four-character name, such as ALRT for an alert definition, CODE for executable code, DLOG for dialogs, KCHR for keyboard layouts, MENU for menus, STR for text strings, and so on.

You could have many different KCHR resources, each numbered, so that changing your keyboard layout was a matter of switching from KCHR number 2, the standard British layout, to number 26 for Dutch, for example. Adding your own custom keyboard layout was then merely a matter of defining a new KCHR resource with a unique ID number, here 128, and editing it to map the keys how you wanted.

Many resource types had custom editors: that for KCHR has a simple keyboard layout and tabular form. The highlighted (black) keys indicate that the Euro character € being shown would be generated by holding the Opt (Alt) modifier key and pressing the 2 key on the top row of the main keyboard, but not the 2 on the numeric keypad.

Customising the icon displayed for QuarkXPress was another fun job for ResEdit.

In those days, it was ResEdit that displayed the Get Info dialog for folders and files, where the sizes of resource and data forks were revealed. Note the vital Type and Creator fields shown: those used four characters that determined the icon to be used for documents, and which app would open them when double-clicked. They were used to build the Desktop Databases, mapping files to their icons and apps.

Resource forks and the thinking behind them are ingenious and empowering, but open up many security issues. In the days when there was Classic Mac OS malware, it often came in resource forks, and took advantage of their features. Although it was possible to lock and protect individual resources, armed with a copy of ResEdit you could soon change that, and almost anything else that you wished to, just as malware could and did.

This is demonstrated in the names seen in this malware library: WDEF preyed on windows resources, MDEF on those for menus, and several of these malicious files are shown with the icon for ResEdit’s resource files.

With Mac OS X, resource forks went into hiding, soon becoming extended attributes. App resources were split out into bundles, folders containing standard structures of files and more folders. Within those, the data structures that would have gone into resources are now folders full of files with standard data forks. In many cases, structured data are set out in XML, which is far less efficient than those old resources, and less suitable for power users to tamper with.

Instead of the limitless customisations to Mac OS, apps, and almost everything on your Mac, accomplished using ResEdit, apps are now locked down by their signatures, and can’t be tampered with any more. While they lasted, resources and ResEdit were exciting and satisfying, if horribly insecure.

References

Wikipedia on resource forks.
Wikipedia on ResEdit.
Apple reference manual for ResEdit 2.1.

Much of our literature is based on a few legends. When one pirate, William Kidd, was believed to have buried his ill-gotten gains on Gardiners Island, that formed the basis of many adventure stories, including Washington Irving’s Wolfert Webber, Edgar Allan Poe’s The Gold-Bug, and Robert Louis Stevenson’s Treasure Island, and dozens of derivatives. Last week I too was digging for buried treasure, this time in the deep soil of the macOS log.

Following up on my previous observations of Battery Centre (com.apple.BatteryCenter) and its log entries recording checks on wireless input devices and UPS, my first task was to build myself a shovel using SwiftUI, a utility I’ve named Unhidden for several good reasons. Although I’ll be releasing and explaining that tomorrow (Monday) morning, in this article I’ll explain why it, and other log analysis tools, are so valuable.

For the last eight years, since its introduction in Sierra, macOS has written copious entries into its Unified log. Although supported from the start by the log command tool, for the first three of those years, third-party developers were denied direct access to the new log. Even now, reading log entries using Swift is rudimentary to say the least: for example, the API still can’t deliver a collection of entries written during an arbitrary period, which can only be achieved by calling the log command to deliver them in JSON format, and parsing that. Given those limitations, all my previous utilities that retrieve log entries have relied on the log command; Unhidden is the first of them to use the Swift API of OSLog.

If Apple intended the Unified log and its bad habits, like censoring so much key information with <private>, as a means of obfuscating macOS internals, it was hugely successful. Seasoned Mac experts who had previously gained much from browsing the log found themselves submerged in so much log chatter that most abandoned all further attempts. So many developers gave up trying to make use of the log that Apple is still trying to win them back. In High Sierra, using the newfs_apfs command to encrypt a previously unencrypted APFS volume leaked passwords in plain text to the Unified log for six months until Sarah Edwards discovered the bug, and Apple fixed it in 10.13.4.

Those who use my utility T2M2 will be aware of how its analysis of log entries makes them aware of serious problems occurring in their Time Machine backups that are never reported to the user. Two years ago, log entries confirmed the function of a new form of XProtect, Remediator, and how it runs periodic scans looking for malware. The only way to tell if APFS trims volumes is to read the entries it writes in the log, and for many other systems in macOS log entries are the only evidence of their completing key tasks successfully.

This journey into com.apple.BatteryCenter started with chance observations that revealed how macOS may periodically interrogate what Apple terms Human Interface Devices, or HID (hence Unhidden), to discover key information including their battery charge status. As far as I’m aware, there’s no public API to perform that, and the only approach is to dig through the I/O Registry, a task akin to searching for treasure using the clues to a cryptic crossword puzzle instead of a map.

After drawing a complete blank in Apple’s documentation I discovered that BatteryCenter is a Private Framework new to macOS Sonoma 14.0, and didn’t exist in Ventura, where similar information came from com.apple.iohid. Alongside are two related user interface frameworks, BatteryCenterUI and BatteryUIKit, making a total of three of the over 1,600 private frameworks in Sonoma, and presumably destined for Sequoia. Whether they’ll ever make the leap to being part of the public API appears doubtful, so for the time being, the only way to access them is through their entries in the log.

When it comes to searching for buried treasure in macOS, there’s nowhere as rewarding as the Unified log. There may be no maps, and when we need shovels all Apple provides are trowels, but there’s more silver and gold here than there ever were on Gardiners Island.

欢迎收听荒野楼阁 WildloG，这里是设计师苏志斌的个人播客。作为第 0 期，我会与你分享一下做这个播客的动机、这个播客的主题会是什么、起这个名字的缘由、本期封面和播客 Logo 的设计想法，以及后续的节目计划。

在这一期，你会听到：

—- 我是谁？从我家的动物园，工作和话剧的经历，聊到我二十多年的写作习惯。

—- 我对于视频内容的态度？为什么那么久没更新《设以观复》系列？

—- 原本并不想做播客，为什么转变想法呢？动机是什么？

—- 这个播客的主题：一个外星人

—- 荒野楼阁 WildloG 这个名字是什么意思？因为生机勃勃啊！

—- Why not 和 WildloG

—- 封面设计：隐秘的荒野和兔子王国

—- 以两类节目为主：一个人捡树枝，两人以上一起捡树枝

—- 要停更视频？

｜登场人物｜

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

｜相关链接｜

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

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

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

｜其他社交网络媒体｜

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

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

｜联络邮箱｜

suithink.su@gmail.com

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