Icloud 可以单独用一个 id 吗?
app store 可以用不同的我知道,现在想单独把 icloud 用土区 id ,设置里面和 app store 用美区 id ,这样可以吗? 主要土区里有几千里拉不用浪费了!
app store 可以用不同的我知道,现在想单独把 icloud 用土区 id ,设置里面和 app store 用美区 id ,这样可以吗? 主要土区里有几千里拉不用浪费了!
我使用 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.
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.
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:
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.
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:
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.
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.
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.