已稳定开车 4 年多 年付 170 联系绿色：d2hpemN6Yw==

众所周知，使用 Chrome 插件「 iCloud 密码」时，在注册新账号或者修改密码时，一直无法自动生成新密码。

而 Chrome 自带的密码管理器，以及 1Password 等插件都可以正常生成新密码。

这个功能有什么技术难度吗？

iphone16 来了，为了将来的 ai 破解（如果用可能得话），和一些不好说的原因，打算抛弃国区 id ，如果默认用外区的话，体验怎么样，有没有什么坑？

macOS 15.0 Sequoia brings several new features for lightweight virtualisation on Apple silicon Macs, including most importantly support for iCloud at last. This article explains how to build a macOS VM on an Apple silicon Mac that can access iCloud and iCloud Drive, and its quirks and limitations.

Why so late?

Whether support for Apple Account (formerly Apple ID) had been intended for macOS lightweight virtualisation, isn’t known. However, it wasn’t until after its release, when many users asked for it, that Apple appears to have started work to implement support. Because those secrets are normally protected by the Secure Enclave, a mechanism had to be found to provide access to those from within the VM, using an exclave. That wasn’t ready to include in virtualisation for Sonoma, therefore was only released in Sequoia 15.0 on 16 September.

How to build a macOS VM with Apple Account support

For this to work, there are two essential requirements:

• The host is running macOS 15.0. That can be the result of upgrading an older version of macOS.
• The VM is built from an IPSW image file for macOS 15.0. It cannot work on a VM that has been upgraded to 15.0 from an older version of macOS.

It’s possible to build a VM running 15.0 on a recent version of Sonoma, but that can’t support Apple Account. It may be possible to build a VM running 15.1 beta on a 15.0 or 15.1 beta host; however, that hasn’t worked reliably on hosts running 15.1 beta. For best results, use the release 15.0 on a release 15.0 host.

Building the VM is performed normally. In Viable, set the size of the Virtual Disk and the remainder of the settings to those you want for the VM when you start it. Then click the Install… button, select the 15.0 IPSW file, then save the VM using the name and location that you want. I normally do this using a duplicate of the IPSW file, so the original remains in place. Being an APFS clone, it takes no real disk space to do that.

Once installation has succeeded, check the settings again ready for the VM’s first run, then click on Start VM… button and select the VM you just made. You will be taken through its personalisation and configuration in the normal way. Ensure that you there enter your Apple Account name, then its password.

At the end of that process, you should see this summary, including FileVault enabled if that’s the host configuration. The VM will then open, and sync with iCloud Drive. If you take a look in Privacy & Security settings, you’ll see that FileVault is disabled. If you try to enable it, whether you opt for iCloud recovery or a Recovery Key, you’ll see that it can’t be turned on there.

Apple Account settings warn you that “some features are unavailable”, most obviously the Media & Purchases item, which is greyed out.

However, many iCloud features are active, including Passwords and iCloud Drive.

The official list of unsupported features reads:

• Apple Media Services, most importantly the App Store. Apart from some of Apple’s free apps like Pages, Numbers and Keynote, no App Store apps will run in a VM. Still.
• iCloud Mail.
• Apple Wallet.
• Find My.

Apple also includes iCloud Backup, although as far as I’m aware, that still isn’t a feature of macOS.

Installing XProtect data

One of my first tasks with a fresh VM is to bring it up to date with security data updates, and that’s now more complicated. I copy SilentKnight across from the host, then run it in the VM.

This is typical of a fresh Sequoia system, with the version of XProtect shown as 0, indicating that XProtect has no installed data. In this case, an update isn’t offered in SilentKnight, so I open Terminal and type in
sudo xprotect update

The response here indicates that Software Update had already downloaded and installed the XProtect bundle, but it hadn’t been installed into the new XProtect and activated, which was accomplished by that command.

With all greens, apart from FileVault, that VM is now ready for use.

One final tip: I often use VMs to test what’s potentially destructive or damaging to them. To save me from having to build each individually, I set one up, with all the apps I need, then shut it down. When I want to use that as a disposable VM, I simply duplicate it and run the copy, leaving the original unharmed. Because duplication is performed as much as possible by APFS cloning, this is really quite economical on disk space.

我使用 icloud 主要就是用来备份同步照片，跟家人共享图库用的。

鉴于目前 icloud 又又又涨价了，能否使用 immich 来替代 icloud 来用来同步照片，要达到如下效果：

1.同一个账号下多设备照片同步。 2.多账号之间部分照片共享，类似于照片 app 的共享图库。

不知是否有大佬深度使用过 immich ，能否给予解惑。

I was sorely tempted to pre-order an Apple Vision Pro, but it wasn’t the cost that was the decider. When I checked, I realised that Apple has locked in its most exciting new technology to running only what’s provided through its App Store. Not that I don’t buy through Apple’s App Stores, but if there’s one thing that stultifies innovation, it’s a bureaucracy that obsesses with its rules.

It took Steve Jobs a while to accept that iPhones needed third-party apps, and Apple launched its iTunes App Store for iOS in 2008, just over a year after the first iPhone had been released. Early in 2011, the Mac followed suit, but as an addition to well-established direct distribution. At first it provided a convenient central platform for Apple’s own products.

Although promoted for its curation, security and trustworthiness, over the last 13 years each has been profoundly undermined. You don’t have to spend long looking in the App Store app to appreciate that it’s as well curated as a painting exhibition requiring all frames to be gilded and more than two inches wide, let alone the prevalence of scam apps on iOS App Stores.

Its track record of security nearly came to grief in 2015, when hundreds of apps on the China store were discovered to have been victims of a supply-chain attack by XcodeGhost. Just a couple of months later the macOS App Store suffered major problems with its security certificates, causing most of its apps to be unusable and erroneously reported as damaged.

Nevertheless it has continued to attract important apps from major developers, as shown below in 2015, when it was far more navigable.

Despite being mired in controversy since they were unleashed, Apple’s App Stores have prospered, both for Apple and for the precious few developers who achieve success on them. The one growth area that they have so far missed out on has been virtual machines running on Apple silicon Macs, which have been unable to access the macOS App Store, or to run the great majority of apps purchased from it.

Shortly after Apple released lightweight virtualisation for Apple silicon Macs in 2022, those who had started to experiment with them discovered what appeared to be a major blind spot in their design: as they didn’t support signing in with an Apple ID, they could neither access iCloud services, nor run third-party apps supplied through the App Store. Obvious though this shortcoming was to users, it apparently hadn’t occurred to Apple, who hadn’t even started to build in support for Apple ID.

This was completed in time to be included among the new features announced for macOS Sequoia last month, when Apple promised that it “supports access to iCloud accounts and resources when running macOS in a virtual machine (VM) on Apple silicon”. With issues of virtualising what was needed from the host’s Secure Enclave apparently solved, some of us had come to expect that would include App Store access, which is also controlled by Apple ID. It’s now clear that Apple didn’t intend to include its App Store as a “related application”, which was implicitly excluded.

However little you might love the App Store, support in macOS VMs is essential if they are to be of any general use. VMs that can’t run all App Store apps as part of the benefits of signing in with an Apple ID are so stunted as to be of little use. Would it be that difficult to implement, now that those VMs can be signed in to all the other services that depend on an Apple ID? Did Apple really forget its own App Store when deciding what apps should be allowed to run in a VM?

If you consider this to be a showstopper for virtualising macOS on Apple silicon Macs, then please make it clear to Apple through Feedback.

The third developer beta of macOS 15 Sequoia finally brings support for Apple ID in macOS virtual machines (VM). As this is likely to form the first public beta-release next week, here’s a short guide to how to install a Sequoia VM, and what you can do with it. I’m delighted to report that my own free virtualisation apps Viable and Vimy already support Sequoia VMs on Sonoma 14.5 and Sequoia hosts, and I expect that will be true of other virtualisers for Apple silicon Macs.

Installing Sequoia as a VM

When running Sequoia developer beta 3, or the first public beta, download an IPSW image from Apple’s beta support site, or via Mr Macintosh’s compilation. Ensure that you download developer beta 3 or public beta 1 or later, depending on which programme you’ve joined. Then install that IPSW using Viable in the normal way, as detailed here.

If you’re virtualising Sequoia on a Sonoma 14.5 host, you may need to install additional software before installing the Sequoia IPSW using Viable. One way to discover that is to proceed normally using the IPSW you’ve just downloaded. You’ll then be prompted to install a software update.

At present, this will fail, but I expect that Apple will provide that additional software for the public beta.

If it doesn’t, and you’re unsuccessful in installing the additional software, trash that VM (but not the IPSW inside it), install and run the latest beta-release of Xcode 16 from Apple’s beta support site. Once that has been run, you should be able to install Sequoia without any problems.

First run

Open the VM using Viable, and work through its configuration as normal.

If the VM is hosted on Sequoia developer beta 3 or later, you should be able to enter your Apple ID and password, and opt for FileVault on its Data volume during that initial configuration. If it’s hosted on any older version of macOS, then you shouldn’t try entering your Apple ID and password, as that will fail. This is because the minimum requirements for Apple ID support in a VM are:

• the host running Sequoia developer beta 3 or later, and
• the VM running Sequoia developer beta 3 or later.

If your Mac and VM meet those, the VM should then trigger normal 2FA confirmation over iCloud, and then activate iCloud, iCloud Drive, and support for related applications such as passwords, calendar and file sharing via iCloud.

App Store support

In Apple’s release notes for Sequoia developer beta 3, it states that the following issue has been resolved: “Users will not be able to sign-in to iCloud and related applications”. Apple has previously stated that Sequoia “supports access to iCloud accounts and resources when running macOS in a virtual machine (VM) on Apple silicon”. However, that currently doesn’t include access to the App Store or use of apps purchased from it.

At present, “access to iCloud accounts and resources” does include:

• iCloud Drive
• Keychain in iCloud, fully supported in Passwords.app, including passkeys
• syncing shared iCloud databases such as calendars and address book
• shared Photos using iCloud
• third-party apps sharing data using CloudKit.

It doesn’t include connecting to the App Store, and as a result apps obtained from the App Store that check the current user is entitled to run them will fail to open. There appears to be no workaround for this, although some apps including several of Apple’s will run because they don’t appear to perform those user checks. In those cases, copying the app from the host enables you to run the app in that VM, but that doesn’t apply to the great majority of paid-for App Store apps.

If you’re disappointed that Apple still hasn’t opened access to its own App Store in VMs, please request this feature using Feedback.

Nesting virtualisation

Apple has also announced that Sequoia will support nesting on models with M3 chips, where you can run a macOS VM inside a macOS VM. Although Viable is no longer blocked from running in a VM, this feature doesn’t appear to work yet, at least not using Viable on an M3 Pro.

Downloads

Viable version 1.0.12 (beta 12) and Vimy 0.7 (beta 4) are available from their Product Page, and appear fully compatible with Sequoia, although they don’t yet support the suspend/resume feature for closing VMs. I believe that ViableS 1.0.12 is also compatible.