This broke for me in 26.5. No "Handoff" messages at all from sharingd. Drowning in 10's of messages per second, mostly triplets with the exact same: 'BLE NearbyInfo changed SFBLEDevice ID xxx, RSSI -65 (-62)t~F, Ch 37, AdvD <491d89922448>, Nm 'yyy', Paired no, Cnx no, WiFiP2P, OBC=?' 26.5 display UI no longer shows the other display, but the bluetooth menu lists the other computer. Connecting, even reciprocally, has no effect. Continuity was essential to my workflow.

Seeing this when building swift package from command-line, but not Xcode (macOS 15, Xcode 16) Put Xcode toolchain bin dir first on PATH, to use that swift swift build of package Not setting TOOLCHAIN It's unclear to me how swift discovers libraries in Xcode or from the command-line, or how better to configure the swift toolchain used for command-line builds

Thank you, I understand (and tried to say) that I'll be booting off the internal drive. The question presented assumes I'm booting from the internal drive, and asks what else needs to be true. Would you please answer the questions presented? Even just links to appropriate resources (that I haven't been able to find) would help.

As another data point, this is on an external drive with two volumes, and the other volume has 14.6.1 installed. Seems like a serious issue?

Understood - thank you for the quick reply. My goal is to build a solution. It helps to know I'm not missing the API. USBDriverKit et al is beyond my skill-set.

Update: tart does not support suspending Linux VM's, so I have no evidence this is possible. Also, my VM crashes when using the "Suspend" command from inside ubuntu Linux guest.

FWIW, I have been able to uninstall an OS only by deleting the volume, but that has worked reliably, so now I maintain a separate volume for any OS I plan to delete, like a beta.

Many thanks for a quick reply! Make sure to export the digital identity, not just the certificate I interpreted that to mean using Keychain Access app to export "My Certificate" labeled Apple Development {name} ({id}) to a .p12 file, copy file and import into KeyChain on the destination User/OS, and then validate in Xcode: Given configurations: source: machine & user with xcode account for the developer id with e.g., Apple Development signing cert in keychain app using that developer id (signing cert) destination: same, without cert In the source configuration: in Keychain Access application, login keychain, My Certificates table find Apple Development: {name} (Id) (same as Xcode signing for app) Select and use context menu to export to .p12 file Create password (used just for export and import of that file) In the destination configuration: Copy exported .p12 file to dest machine e.g., drag via Handoff to machine (but cannot drag directly to keychain) In App Keychain Access, login keychain, My Certificates table Drag file into table to import (giving same password) In Xcode with associated developer account, select Team and Manage Certificates... You should see the id enabled Xcode then signed my app successfully.

For the record, installing any MacOS version on an external may require updating the firmware security settings in the Restore mode. If you do an OS install but are unable to select the startup disk or booting to it fails, this might be the issue. Additionally, getting to Restore mode (via Command-R on startup) may require detaching all other USB/TB devices before the key-combination is recognized. In the Restore UI, the firmware security settings are not listed among the ~4 apps presented to the user, but under a menu item. It's likely that you'll need to permit BOTH booting from externals AND relaxed verification. Further, the OS should be installed to APFS volume. Also, in disk utility, if you get info on the install partition, it will show whether the required "System Integrity Protection" is supported. If not, recheck your firmware security settings.

As for VM deploys, Apple's Mac virtualization API's are arm64 only (i.e., #if arch(arm64) So the workaround is to install Ventura to an external, and update to Sonoma beta from there.

Oy! Just as I was giving up, I solved it. In case it helps others... The problem was an intermediate library targeting iOS 13. The XCode error was confusing. Scenario: MyCoreLib swift package targeted iOS 14 MyUILib swift package targeted iOS 13 (and used MyCoreLib) MyApp targeted iOS 14, and used both MyCoreLib and MyUILib When building MyApp, the error said: The package product 'MyCoreLib' requires minimum platform version 14.0 for the iOS platform, but this target supports 13.0 I could not find iOS-13 referenced anywhere in MyApp or MyCoreLib. So I guess I should make a feedback assistant feature request to clarify that error message. It should indicate the target triplet/SDK and how it was derived. (In this case it took the minimum of the imported packages).

Same result in released XCode 14.0.1 (14A400). Catalyst is not an option if/since it doesn't work, which will send me to Flutter or something equally horrible. Please help

Thank you for the suggestion. If the UI launches the back-end, the TCC request would actually come from the UI, so that doesn't present the TCC issue. But I don't know enough about Apple code signing and validation to know if I can sign and deploy (on the app store?) an app with an embedded java native binary, since it wasn't built with Apple's Clang. Currently our deployment constraints permit a JDK (notwithstanding the enhanced risk) because we validate the java, but it would be a lot less hassle if we could deploy the native binary in the app. So homework there. For this app, it's easier to just rewrite the back-end in swift. But we have a lot of backend Java, I'd hoped to redeploy in a similar manner.