想买一个接近 mac 屏幕 的显示器，Studio Display 太贵了，看网上说 LG UltraFine 也挺好，但都是 3,4 年前的二手了，转了一下都 4,5 千，不知道和现在的显示器比这个价格还能打么，而且逛了几个帖子都说遇到了质量问题
我在用 mac 进行 facetime ，每次打开 notes 查看一些东西时候，右上角就会弹出常驻通知，问我要不要 collaborate 这个 note ，这也太烦人了吧，也没有个开关关闭这个。
老婆的手机空间老是提示满了, 有什么离线存储或者本地存储 live 格式照片的软件吗, 无损的那种
实测用绿联的双 HDMI typeC 扩展坞只能识别出一个显示器
由于落魄了，还在用 mbp 2015 mid ，这个本子最新系统只能跑 MacOS12.7.6 ，在今年年初，大部分的 brew 包都已经不再提供 12 版本系统的软件包支持，这导致刚刚我 brew update 的时候，所有的索引都同步到了最新，导致再安装一些依赖的时候，都需要通过编译源码方式安装最新的版本。
我看 port 为每个系统都构建了对应的软件包，想问下直接换到 port 有什么坑吗？
1.我有一个 Macbookpro 2014 款 2.现购入了一个 MacminiM4
在不新增屏幕键盘触控板的情况下，通过 Macmini 的屏幕共享，在 MacBook Pro 上远程办公使用，但是昨天连接后挺卡的，效果不是很好。 办公室环境：两台机器都是通过 wifi 连接互联网在同一局域网中，但是局域网 ip 之间无法通信，互联网带宽最大每秒 1M 。我是通过方案 1：tailscale 虚拟组网，方案 2：连接同一个手机的网络，把两台设备置于同一个局域网下，进行屏幕共享的。
1.兄弟们有没有别的办法能组装这两台机器，通过 MacBook Pro 的键盘和触控板、屏幕操控 Macmini 。 2.如果不行，只能二手卖掉，在提高预算入 MBA 了（提高预算得费很大劲）。
求助
我买了个 Mac mini 丐版 256g 想着用来剪视频，然后从我的 pocket 3 直接导入视频，把文件丢在了桌面。 然后因为爆容量了剪完之后也没管它 电脑自动帮我上传到 icloud 里面。 这两天我的移动硬盘到了 想把素材拖到移动硬盘 就一直在下载。。然后下载着不行就又提醒容量已满 咋办啊 TT
最近发现通知中心占用非常高，关闭这个进程就好了，好像也没有什么其他的影响 
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5293. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds a single new rule for MACOS.SOMA.J.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5293.
This update has also been released for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then enter your admin password. If that returns version 5293 but your Mac still reports an older version is installed, you can force the update usingsudo xprotect update
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
rt ，型号是 h27p3 ，支架很拉垮但支持壁挂，国补到手 2124 ，目前 b 站上基本都是商单，也没看到真人分享，有大佬试过吗，能讲讲使用体验吗，老实说有点心动。
分享一些苹果iPhone手机等iOS设备使用的小技巧。
一、关闭锁屏搜索
设置-面容ID与密码-今天视图和搜索，关闭即可。
二、关闭桌面搜索
设置-主屏幕与App资源库-在主屏幕上显示，关闭即可。
三、关闭半屏模式
设置-辅助功能-触控-便捷访问，关闭即可。
四、自动抠图
长按照片中的人像，可以快速自动抠图。
五、撤销操作
如果不小心删除了文字或照片，可以摇晃两下手机，可以撤销操作并找回。
六、拼音声调
键盘长按字母，可以打出拼音声调。
七、扫描文稿
长按备忘录，选择扫描文稿，可以扫描纸张和身份证件等。
估计国行 iPhone 大概率是 iPad 那个策略：
只能在境外添加非大陆运营商 esim ；
非国行在境内无法添加大陆 esim
那么港版 iPhone 等单实体卡的在大陆巨亏，双卡变单卡。
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5292. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version removes the macos_toydrop_b rule for MACOS.ADLOAD, and amends the rules for MACOS.ADLOAD.I, MACOS.BUNDLORE.MDPLST and MACOS.ADLOAD.IN.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5292.
This update has now been released for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then enter your admin password. If that returns version 5292 but your Mac still reports an older version is installed, you can force the update usingsudo xprotect update
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released the update to macOS Sequoia to bring it to version 15.4, and security updates for 14.7.5 and 13.7.5.
The Sequoia update for Apple silicon Macs is about 6.2 GB in size, and 3.9 GB for Intel models, making it one of the largest intermediate updates for some years. For Apple silicon Macs, the update to 14.7.5 is about 3.7 GB, and to 13.7.5 about 3.3 GB.
Among the changes listed by Apple for 15.4 are:
Enterprise release notes are here.
Software Update settings will be automatically changed to enable future macOS updates to be downloaded and installed automatically: if you don’t want that, you’ll need to change that setting once your Mac boots in 15.4.
Security release notes are available for Sequoia, Sonoma and Ventura updates. There are a total of 131 vulnerabilities fixed in 15.4, which must be a record. None is reported as being suspected of exploitation in the wild, and the security updates for Sonoma and Ventura are almost as numerous.
Firmware updates include iBoot (Apple silicon) to version 11881.101.1, and T2 Macs to 2075.101.2.0.0 (iBridge 22.16.14248.0.0,0). The macOS build number is 24E248.
The new version of Safari in 15.4 is 18.4 (20621.1.15.11.10). APFS is updated to version 2332.101.1.
As so much has changed, I won’t be posting a separate article listing significant changes: it looks like pretty well everything has!
Just for reference, the Sequoia 15.0 major version upgrade from Sonoma was 6.6 GB for Apple silicon, and 4.9 GB for Intel – those aren’t that much larger than this ‘minor version update’.
Those intending to update Apple silicon Virtual Machines currently running 15.3.2 should be prepared for the 15.4 update to fail. I’ve tried with two VMs now, one with a fresh copy of 15.3.2, and both have failed early during installation with a kernel panic. However, 15.4 does install correctly from the latest IPSW image file. Older VMs with 14.7.4 and 13.7.4 do update correctly to 14.7.5 and 13.7.5 respectively.
[Last updated 1715 GMT 1 April 2025.]
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5291. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version amends the Yara rule for MACOS.PIRRIT.OBF.DROPPER, but doesn’t add any new rules.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5291.
This update has also been released for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then enter your admin password. If that returns version 5291 but your Mac still reports an older version is installed, you can force the update usingsudo xprotect update
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Macs have developed their own mythology, and this week I unintentionally came across a myth that developed over a year ago. Like so many it was born from a chance observation, this time of a new background process that appeared on 25 October 2023 in macOS Sonoma 14.1, and was reported in 9to5Mac on 3 November 2023.
The process in question is liquiddetectiond, and as 9to5Mac’s headline claimed, it meant that “Macs can now inform Apple if any liquids have been detected in the USB-C ports”. That article argued that “it seems more likely that the data collected by this daemon will be used for technicians to determine whether a Mac is eligible for free repair.” “Putting a digital liquid detector on USB-C ports is just another way to ensure that technicians are right about claiming that a Mac has been exposed to liquids.”
That, and a couple of linked reports elsewhere, brought a small flurry of comments about how typical this was of Apple, then all went quiet until 9to5Mac’s article was picked up by Hacker News on 9 January 2024 and generated 340 comments. Predictably, most either castigated Apple’s behaviour or disappeared down rabbit holes about unrelated topics. Among them, though, was one precious insight: “It prevents the device from applying/draining power from any pin in such a state, mainly to reduce corrosion of the contacts and increase longevity.”
By the middle of January last year, the story had gone cold, and everyone must have gone away with their worst fears confirmed. You couldn’t even get a USB-C port damp in your Mac any more, as Apple would use that as an excuse to void your Mac’s warranty.
Apple’s first word on the subject seems to have been in a support note published on 23 November 2024, which passed largely unnoticed. This announced liquid detection as a feature new to macOS Sequoia when running on only the following models:
none of which had been released at the time of 9to5Mac’s report, although the second were released four days later, on 7 November 2023.
If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, this new sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry.
This is in addition to, and separate from, what Apple terms Liquid Contact Indicators (LCI), that have long been fitted to laptop Macs and some Apple wired and wireless keyboards “to help determine if these products have been exposed to liquid,” according to this support note.
Was Apple just making excuses, or was this new liquiddetectiond service intended to benefit the user?
I stumbled into this innocently last week when I was looking at Accessory Security, a feature confined to laptop Apple silicon models. By chance, the laptop I was using was a MacBook Pro M3 Pro, one of the few in which liquid detection works. There, on several occasions in its log, after connecting a Thunderbolt cable, its liquid detection system checked that the USB-C port was dry, in a series of log entries like:0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
(Times given in seconds elapsed.)
But on my more recent Mac mini M4 Pro running Sequoia, all I saw was that LDCM is not supported on this device.
Attempts to connect over the network are obvious in the log, and on not one of the occasions that liquid detection was performed did that MacBook Pro try to connect to any remote site. Maybe its reports could have been embedded in other analytics data passed to Apple later, but there was absolutely no evidence that the results of liquiddetectiond went beyond the confines of my Mac.
This demonstrates the importance of testing out hypotheses, and of reading the log. Even without the benefit of Apple’s recent support note, it should have been easy to demonstrate this behaviour, yet no one seems to have attempted to.
Claims made of the role of liquid detection in USB-C ports also don’t make sense. As with most laptop manufacturers, Apple already builds Liquid Contact Indicators into components of laptop Macs within their case. These are most frequently affected by spillage of drinks on a laptop’s keyboard, resulting in any of a wide range of water-based liquids from coffee to cognac entering the case. That often results in extensive damage to the logic board and other components, that are expensive to replace.
But a damp USB-C port is quite a different matter. It could occur in a laptop that had been out in the cold and was then brought into a warm and more humid environment, the same sort of conditions that steam up your spectacles. Over time, that could lead to corrosion of the contacts in the USB-C ports, and unreliable connections.
Because each release of macOS is identical across all models of Mac, although only a few of the most recent models feature liquid detection sensors in their USB-C ports, the liquiddetectiond service runs in the background of all Macs running Sequoia. It’s to be found inside /System/Library/CoreServices/liquiddetectiond.app, which isn’t even a bundle, just its Mach-O binary and an image of the warning sign displayed. It’s run through its LaunchDaemon com.apple.liquiddetectiond.plist, which you’ll also find in the SSV of every Mac.
As is so often the case, the truth behind the myth is more prosaic, and doesn’t involve Apple secretly capturing data from your Mac, nor conspiring to dodge warranty repairs. In fact, if you look at the warranty terms of pretty well every other laptop manufacturer, they too exclude damage caused by liquid ingress, as demonstrated by their Liquid Contact Indicators. And some are also starting to fit similar liquid detection sensors in their USB-C ports. But don’t let those get in the way of a good myth.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5290. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds a single new Yara rule for MACOS.SLEEPYSTEGOSAURUS.SYM.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5290.
This update has just been released for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then enter your admin password. If that returns version 5290 but your Mac still reports an older version is installed, you can force the update usingsudo xprotect update
Hurrah!
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Updated 1840 GMT 11 March 2025, announcing iCloud release!
Apple has just released an update for macOS Sequoia bringing it to version 15.3.2. There are also Safari updates available for Sonoma and Ventura.
The update for Apple silicon is about 1.45 GB in size, while that for Intel Macs is around 600 MB.
Security release notes are already available, and list a single WebKit vulnerability, that Apple states is a supplementary fix for an attack that was blocked in iOS 17.2, and in iOS had been exploited before it was fixed in iOS 17.2.
Updated with Safari info, 1930 GMT 11 March 2025.
2018 年，我被那条「What’s a computer?」广告忽悠，把早已不记得年份的老 iPad，换成了第二代 iPad Pro。
现在有一台刚发布的 iPad Air (2025) 放在我面前，我在思考：为什么需要一台新机？
很多 iPad 用户跟我的观感相似，无论刷网页、修图、追剧看电影、轻文档处理，还是视觉创作，以及玩点轻游戏，我们手上的那台 iPad 都足够应付。iPad 实在是太经用了，买一台真的能坚持好多年。
但消费主义充满陷阱。换个角度看，如果我今天购买最新款的 iPad Air，同样完全不用担心过个几年它会过时。买 iPad 时，我们从来不会有这种顾虑。
七年之痒，也许是时候换一台 iPad Air，然后再七年？
如果只看参数表，新 iPad Air 和前两代相比确实没什么进步，挤牙膏说的并不夸张。
但你可能没注意到，新 iPad Air 相比去年的 M2 版本，发布价格降价了 400 元。是不是觉得牙膏也挺香的？
毕竟 M3 芯片的提升还是存在的，这也是除了新 iPad Pro 的 M4 外，你能在平板上用到的最强芯片了。
得益于技术迭代，以及苹果在 M 系列研发生产上的经验积累，新 iPad air 的 GPU 和 CPU 算力都有所进步；神经网络引擎也是，官方宣称和 M1 相比，处理 AI 工作流提速达到 60%。
M3 内置的 9 核 GPU，与最高级的苹果图形架构在 iPad Air 上合了体。基于硬件的光线追踪终于来了（之前只有软件加速）：游戏的光线、反射、阴影等效果逼真度有所提高；能效也有相应优化，我玩了半天《逆水寒》，发热程度可以接受，到了晚上还剩一些电量够加个班。
如下图所示，iPad Air 在 Geekbench 6 GPU 测试中获得 45935 分，追平上一代 M2 芯片 iPad Pro（2022 年）；Geekbench AI 性能量化得分 5670，物体识别、风格迁移、超分辨率、机器翻译等经典任务，精度平均 98% 上下。
在 3DMark 光追性能压力测试里，iPad Air 得到平均分 8253，循环到一半的时候开始性能下滑，应该是由降频导致。
第二天我用 iPad Air 测试更依赖 CPU 的工作场景。多开浏览器、IM、视频会议、文档表格等应用，切换的过程更流畅。
目前 iPadOS 的多任务用户界面的操作，还是有点繁琐，在「分屏侧拉」和「台前调度」之间切换，还得打开控制中心添加快捷方式，或者在设置里切换。希望未来苹果可以优化这一点。
新 iPad Air 本体目前唯一值得说的东西，就是这些。
有人要问，「不提一下 Apple 智能吗？」
iPad Air 的确支持 Apple 智能，最快今年夏天就在中国大陆上线。但在所有官方宣传渠道中，Apple 智能都被「一嘴带过」，新闻稿里只有结尾一段，和「没有为 Apple 智能准备好」的基础款 iPad 篇幅相当。
你可能会说 Apple 智能还没正式上线，但美国科技媒体的感受也一样——要知道自从去年 6 月官宣以来，Apple 智能一直是苹果营销的一大重心，和所有新产品官宣的关键信息点。
苹果在最前沿技术的商业化上从来不是最快的，这种稳妥而非激进的路线也被人们接受。但毕竟 iPad Air 和 iPhone 16e 是 Apple 智能最低门槛的硬件载体，从渗透市场的角度站位很关键。
iPad Air 都为 Apple 智能准备好了，但 Apple 智能自己准备好了吗？
比 iPad Air 本身更让我兴奋的，就是这次苹果配套推出的全新妙控键盘 (Magic Keyboard)，增加了一行功能键：
我在打车时把 iPad Air 拿出来用了一下，放在膝盖上的重心挺稳，不会有很明显的「头重脚轻」感觉。而老 iPad 的用户的键盘，一般都是那种带支撑架的，需要大腿足够长，或者把键盘朝着自己拉，否则 iPad 很容易倒过去。这种键盘一般放在台面上才真的「能用」。
配上新妙控键盘除了稳，屏幕离眼睛也更近，特别对于 11 英寸的机主更友好。iPad Air 终于成为一台字面意义上的「Laptop」（放在膝盖上），从外观、用法、使用感受，都更像一台笔记本电脑。
唯一遗憾就是键盘掌托还是之前的柔性面料，舒服、不冰手，但易脏易磨损，不适合手汗大的朋友。
这次新妙控键盘还更比上一代降价了 200 元。当然一台售价 2199 元（11 英寸）的键盘仍然不便宜。
11 英寸 iPad Air 128GB Wi-FI 版 + 妙控键盘，总价 6998 元，而新 M4 芯片 13 英寸 MacBook Air 256GB 售价 7999 元（同样较前代降价了发布价）——少花 1000 块钱，你可以得到一台更加灵活的「准 MacBook」。
作为「准 MacBook」来说，M3 芯片的性能上限早已足够；拆下键盘它还是那个更灵活的平板电脑。e-SIM 机型更贵，但想节约预算完全可以直接用手机热点或移动 Wi-Fi。
更何况今年国补还在继续。
顺着这个思路，这台新 iPad Air 的购买推荐来了。
没必要换机的用户：
可以考虑购买的用户，大概符合下面几点：
那么这台搭载 M3 芯片，搭配新妙控键盘的 iPad Air，适合你购买。遇到大型工作任务的时候，不至于没有机器可用，日常的工作和生活场景交给 iPad Air 也完全可以。不管 Apple 智能啥时候准备好，至少 M3 芯片为 AI 准备好了。
在我过去的几份工作中，遇到过各种各样的「典型」iPad 用户，他们使用 iPad 的方式五花八门，但需求都非常明确。
比如我认识一位实体零售店长，每天筋疲力尽，下班只想刷剧放空，但时不时还要按照公司要求做一堆表格。于是他给 iPad 配了个便宜的键盘盖，反正只是凑合用一下。
还有文娱行业的艺人企宣和经纪，他们每天的工作主要就是奔走剧组驻地，修图、做 ppt、做视频，然后拿给导演看，也是一台 iPad 可以完美嵌入的工作流。
典型的 iPad 用户，往往也是非典型的科技产品使用者。他们对性能参数的多寡毫无感知，很多时候只是要一台便携好用的大屏幕。核心使用场景满足就足矣，多个键盘、笔这样的外设还能加点分。他们不会年年换新，但也要考虑二手设备的残值，差不多时候就可以换了。
而对于这样的 iPad 用户，现在到时候了。
#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。
Over the last nine years, few of my articles here have been about XProtect, other than those announcing its updates. Until September 2024 and the release of macOS 15 Sequoia. This is now the tenth article I have written about the problems brought by XProtect updates in Sequoia over those six months, when there have been just 13 updates. The result of the last, on 4 March, was that for two days afterwards, many Macs running Sequoia were still using its data from 26 February rather than that in the new version 5289.
This not only affects XProtect, but the other front-line tool in macOS to detect and remove malicious software, XProtect Remediator (XPR). Earlier this year, I reported that at least 17 of the 24 scanning modules in XPR now use Yara definitions provided by XProtect’s data. All those Macs still running the superseded version of XProtect would also have had XPR scans run using that old version of the Yara rules.
XPR is a recent addition to these tools, introduced just three years ago, but XProtect goes way back before Yosemite in 2014. Although there have been occasional brief glitches in delivery of its updates, they have almost invariably completed quickly and reliably, leaving very few Macs stuck with an outdated version 24 hours after an update.
I have now come to dread XProtect updates because of the problems we encounter, and the latest update to 5289 was a good example. There’s a flurry of comments and emails from those whose Macs had failed to complete the update, previously a rare exception. For XProtect 5287 on 5 February, for example, there were 33, including my responses. For version 2184 exactly a year earlier there’s not one comment about that XProtect update.
Sole documentation provided about XProtect’s updates in Sequoia is the man file for its command tool, xprotect, which refers only to updates provided via iCloud, and doesn’t explain how those delivered via the traditional mechanism in softwareupdate might be involved. Yet we know there is a relation: the latest update has still not been supplied via iCloud, not even four days later, but relied instead on XProtectUpdateService working with an update obtained via softwareupdate. Previously that could be invoked using the xprotect update command, but that no longer works, leaving users with two versions of XProtect data, of which the copy used by XProtect and XPR is the older.
Late last year, when xprotect update appeared to be working as expected, I decided that my app SilentKnight would need to use that command in order to download and install updates. As that requires elevated privileges, I have been looking at how to implement a privileged helper app to perform that. With the latest update, that approach would have failed until the version in iCloud had been brought up to date. Instead we’re now reduced to restarting our Macs and hoping that, some time in the next day or two, they might update.
There’s a further problem emerging with the updates of 4 March. Many users have noticed subsequent XPR scans being terminated before completion. Although in most cases that fault appears to go away in later scans, in some Macs it prematurely terminates every set of XPR scans, leaving several of its scanning modules unused.
For example, this iMac Pro has failed to scan using ten of its 24 modules. This occurs because XPR apparently runs a timer, and when a round of scans is deemed to be taking too long, that timer fires and brings XPR to an abrupt halt. Indications are this is most likely when there are many Time Machine backups accessible; as those are all immutable snapshots and haven’t changed since they were made months ago, this is strange behaviour, and hadn’t occurred prior to the updates of 4 March.
Six months ago, if anyone had told me that macOS security protection in Sequoia was going to become less reliable, I wouldn’t have believed them. The truth is that, for many, it now has. As things stand in 15.3.1, a Mac is now more likely to be using an out of date version of XProtect’s detection rules, and for XPR scans to detect and remove malware. And there’s nothing you can do about that until Apple returns to using an update mechanism that’s both timely and reliable. Is that really too much to expect of this front-line security protection?
Selected previous articles:
What is happening with XProtect updates?
XProtect tormentor
How XProtect has changed in macOS Sequoia
A simple guide to how XProtect installs and updates in Sequoia
XProtect has changed again in macOS Sequoia 15.2
What happened with XProtect?
What has happened to XProtect in Sequoia?
Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5289, and to XProtect Remediator for all macOS from Catalina onwards, to version 151. As usual, Apple doesn’t release information about what security issues these updates might add or change.
Yara definitions in this version of XProtect add two new rules for MACOS.TAILGATOR.RST.CT and MACOS.TEPIDTEA.
XProtect Remediator doesn’t change the list of scanner modules.
There is a new Bastion rule 13 for the behavioural version of XProtect (Ventura and later). This watches for execution of PasswordManagerBrowserExtensionHelper in CoreServices, in the App Cryptex, and makes an immediate report with the Signature Name of macOS.PasswordExtension.Exec if that occurs.
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-151 and XProtectPlistConfigData_10_15-5289.
This update hasn’t yet been released for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then enter your admin password. If that returns version 5289 but your Mac still reports an older version is installed, you can force the update usingsudo xprotect update
This version is currently only available via Software Update, softwareupdate, or in SilentKnight, and not via iCloud. If your Mac is running Sequoia and you download it that way, the xprotect update command might take a while to use that downloaded version to update your Mac properly. As a result, the version of XProtect shown may remain at 5288, but should later change to 5299.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Updated 1720 GMT 5 March 2025 following a ‘spontaneous’ update at 1631, although sudo xprotect check is still reporting the old version.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5288. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds two new rules for MACOS.TAILGATOR.UPD and MACOS.TAILGATOR.INLASCLDR.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5288.
This update is also available for Sequoia via iCloud. If you want to check that manually, use the Terminal commandsudo xprotect check
then entering your admin password. If that returns version 5288 but your Mac still has an older version installed, you can force the update usingsudo xprotect update
This version is now available via Software Update, softwareupdate, or in SilentKnight as well. If your Mac is running Sequoia and you download it that way, rather than using iCloud, then once it’s installed you’ll need to run the update command for that to take correctly.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Last week, in a quiet village nestling between golf courses in the Green Belt of Surrey, to the south of London, a huge void opened up in its High Street. Some of the older locals recalled there were old mine workings in the area, making it plausible that sinkhole may be due to the collapse of those abandoned mines or tunnels. What has shocked the residents of Godstone is unfortunately not uncommon, the result of failure to restore the land and what’s under it before developing on top.
Last week, after a long period of deliberate abstinence, I returned to the subject of permissions, privacy and security protections, and how they conspire to prevent us from accessing our own documents and files. In this case, there’s a warren of underground tunnels that can collapse when you’re least expecting it, although most aren’t disused but still active and poised to turn into voids of misunderstanding.
Privacy controls over locations started in macOS Mojave back in 2018, and ~/Desktop, ~/Documents, ~/Downloads, removable volumes and others were added in Catalina the following year. These have become so “transparent”, to use Apple’s well-worn euphemism, that developers have criticised them relentlessly since, and most users are still completely at sea with them, over five years later.
Apple’s Mac User Guide for Sequoia now lists 32 protection categories from Location Services to Lockdown Mode, but explains remarkably little. It passes over in silence the distinction between settings for Files & Folders and those for Full Disk Access. Presumably it leaves each individual app with the task of explaining those to the user, in the context of that app’s potential access.
This is the extent of its current explanations for users:
For once, information given in Apple’s Platform Security Guide is briefer, and it does come a bit closer to making that distinction, even if it avoids using the term Full Disk Access, and muddies the waters by referring instead to “full internal storage access”, which isn’t accurate.
Nowhere does Apple explain how those privacy settings interact with permissions, or any of the unexpected behaviours that we’ve become used to since Mojave. For example, some still report that an app that has been able to open a document without problems is unable to save that document, even though that file and its folder have appropriate permissions set. This has been associated with documents whose default app has been changed from that set for that document type, and undocumented extended attributes such as com.apple.macl, which is even protected by SIP to prevent the user from trying to rectify the behaviour.
For developers, there’s a long series of WWDC presentations reporting the many changes that have been made to extend privacy protection without addressing its user interface, and Apple’s Developer Forums. But if your app wants to discover whether it has been given Full Disk Access by the user, “Except in very limited circumstances, there’s no good way to:
What if alongside its concerted effort to deliver us Apple Intelligence, it were to devote a little time to design and implement a consistent and integrated interface to permissions, privacy constraints and other limitations to what we can open and save on our Macs, and deliver it in the Finder rather than by trial and error? If Apple doesn’t address this soon, these cracks could open up like that sinkhole in Godstone.
If the Mac is to be the computer for the rest of us, it also needs to give access to more advanced controls by scripting its actions. This article traces some of the more significant attempts to bring scripting to the rest of us.
Over the last forty years there have been dozens of programming and scripting languages that have been developed for, or ported to, Mac OS. The great majority have had no pretensions of use by regular users. The first intended to be used by anyone and everyone was HyperTalk, released three years after the original Mac.
Apple’s hypertext authoring environment HyperCard contained its own scripting language HyperTalk. For many of those who built brilliant HyperCard stacks, this new scripting language was the first programming language they had used. Sadly, although seriously cool in its day, HyperTalk was both limited and limiting, as most came to discover.
If you’ve written AppleScript, HyperTalk has a distinct familiarity in its informal language, often mistakenly claimed to resemble normal English. This code snippet illustrates that:on mouseUp
put the value of card field "age" into theAge
end mouseUp
HyperTalk spawned many imitators, and some like SuperCard went on to outlive it, but by 2000 HyperCard and HyperTalk were all but dead.
In 1988, Dave Winer started developing a scripting language that became UserTalk in Frontier, released in 1992. Built around an object database, Winer took his early work to Apple. In 1988-89, Jean-Louis Gassee, then president of Apple Products Division, announced the formation of a HyperTalk Standards Committee to develop a scripting language, and Apple agreed with Winer that they would each develop their own mutually compatible scripting systems.
After Apple’s release of AppleScript, Frontier’s UserTalk declined in popularity. By 1994, Winer was burnt out, and the following year Frontier moved on to become a cross-platform Web content management system.
In some respects a successor to HyperTalk, AppleScript was released in October 1993, with System 7 Pro version 7.1.1. Despite all the odds, and several determined attempts to strangle it, it’s still supported in macOS Sequoia.
The concept behind AppleScript is simple: scripts that compile to a series of instructions for dispatch by macOS to their destination application, which in turn is controlled by those commands to perform a co-ordinated sequence of functions. At their simplest, these can open a document and print it, for instance. At their most complex, they can automate intricate and repetitive tasks that are messy in a GUI.
As a minimum, every application supports a core of commands to play clean with the Finder and macOS. Those, and the suites of additional commands that bring joy to the scripter, are documented in standard formats within each application’s dictionary, which can be browsed by the bundled Script Editor and other tools. Rather than having to locate additional documentation sets specific to each application, all a scripter should need to do is open the dictionary.
Complexity comes because AppleScript is in fact an object-oriented language as sophisticated as Objective-C; don’t be deceived by its apparently relaxed and informal style, with examples such astell application "System Events"
set mailIsRunning to application process "Mail" exists
end tell
if mailIsRunning then
-- do one thing
else
-- do another thing
end if
You might use that code to set up a script that interacts with the Mail app. It first asks macOS whether it knows that Mail is running, and depending on the answer it executes the code that you insert where the comments (prefaced by ‘--‘ characters) are placed. Unlike the majority of programming languages, punctuation marks are used sparsely in AppleScript, making it considerably easier to write code that works, rather than tripping over a missing semicolon.
When ready to test your script, it compiles into intermediate code, and the editor automatically checks, formats and colours your source code, reporting any errors that it finds. When run, the intermediate code works through macOS to fire off AppleEvents (AEvents) to trigger the target applications to perform the actions.
For the more serious AppleScript coder bundled support was too limited, and it was the arrival of Mark Alldritt’s Script Debugger in late 1994 that unleashed its full power. Sadly, Script Debugger is retiring this year after over 30 years of innovative development.
Although AppleScript was integrated into Apple’s Xcode as AppleScript Studio, in recent years it has been left to languish, with occasional rumours of its demise.
In 1989, the visual programming language Prograph was launched on the Mac. Sometimes described as a dataflow language, and thoroughly object-oriented, it won awards, was ported to Windows in the late 1990s, but was last seen running as Marten.
In this example method, data flows from the top to the bottom. Normally terminals on the top ‘shelf’ of the method diagram represent the inputs to that method. Data then flows from the top shelf through the intermediate processes, until it reaches the bottom. If there are outputs from the method, they are gathered by connections made to terminals on the bottom ‘shelf’ in the method. Order of execution is not prescribed, and can take place whenever data is available; this allows for inherent concurrency, and the potential to exploit multiprocessor systems without the need for language primitives.
With the advent of Mac OS X 10.0 Cheetah came Terminal and shell scripts, inherited from NeXTSTEP. Although powerful and popular with those who prefer this Unix-based approach, they have predictably had limited impact on the regular user wanting to script actions on their Mac.
Even ‘natural’ programming languages like AppleScript have to be learned, a task that many find too verbal and mechanical. Recognising this, Apple introduced Automator in OS X 10.4 in 2005 to produce custom workflows and apps using more intuitive visual tools.
Although often assumed to be a development of AppleScript, apart from its ability to run AppleScript objects, Automator is very different. Instead of relying on AppleEvents and dictionaries, Automator’s modular actions are separate code objects installed in the Automator folder in a Library folder. macOS comes with a huge free library of actions that can accomplish tasks you might pay good money for, so familiarity can save cost.
Automator is highly extensible, as its actions can include both AppleScript code and Terminal shell scripts. Thus if you cannot find a standard action to do what you want, if it can be expressed in a suitable script, you can build that into your workflow. Nevertheless, in 2021 Apple announced that Automator was to be succeeded by Shortcuts.
From the early days of the Mac, Apple has invested in programming languages designed to make best use of its APIs. In Classic times, that was Object Pascal, and its open-source class library MacApp. In 2014, Apple released a new language intended to be the preferred choice across all its platforms, Swift. From those early days, Swift has had an interactive mode, based on the read-eval-print loop (REPL) popularised by Lisp. This versatility has been developed in Swift Playgrounds, recently renamed in the singular, both within Xcode and as a standalone app targeted at those learning to code for the first time.
As an introduction to Swift in education, this has been impressive, but it hasn’t yet proved a gateway for those who didn’t really want to learn how to use Xcode in the first place.
Shortcuts started out in the winter of 2014-15 as Workflow by DeskConnect. Apple bought it in 2017, and it became Shortcuts the following year, when it was integrated into Siri in iOS 12. Its arrival in macOS 12 was announced at WWDC in 2021, as Automator’s intended successor.
While Shortcuts on macOS can run AppleScript and shell scripts, the mechanisms involved in Shortcuts’ actions are completely different from AppleScript and Automator. For an app to support all three well requires it to present four different interfaces: one for the user in the GUI, AppleEvents for AppleScript, Automator actions, and now Shortcuts actions.
While Shortcuts has attracted quite a following, particularly in iOS and iPadOS where it’s the first real scripting environment, its impact in macOS has so far been limited. Like all its predecessors, it still hasn’t brought scripting to the rest of us.
HyperTalk: Dan Winkler
UserTalk: Dave Winer and Doug Baron
AppleScript: William R Cook and many others
Script Debugger: Mark Alldritt and Shane Stanley
Prograph: Tomasz Pietrzykowski, Jim Laskey and others
Automator: Sal Soghoian and other Apple engineers
Swift Playgrounds: Chris Lattner, Doug Gregor, John McCall, Ted Kremenek, Joe Groff and others
Shortcuts: Ari Weinstein, Conrad Kramer and Nick Frey
HyperCard Pantechnicon, in the Internet Archive
Dave Winer’s Story of Frontier and AppleScript
Apple’s AppleScript Overview, last revised 31 October 2007
Apple’s Mac Automation Scripting Guide from 7 June 2018
Script Debugger history from Mark Alldritt
Wikipedia on Prograph
Automator and other automation
Apple’s Swift Playground page
Apple’s Shortcuts User Guide for macOS
苹果在 2025 年 2 月 11 日推出了一项新功能：将购买项目从一个 Apple 账户迁移到另一个 Apple 账户。
不支持于欧盟、英国或印度的用户。
从 Apple 购买的 App、音乐和其他内容迁移到首选 Apple 账户。
苹果并没有解释其他内容具体是什么。
如果你不符合条件，则可能看不到「迁移购买项目」。
看起来，这项功能更适合在同一区域拥有多个账号的用户，它为用户提供了一个手动合并多个账号的功能，并把你买过的内容转移至主力账号的方式。
之后备用账号就可以抛弃不用了。
Login
