My Xcode project fails to run with the following crash log any time I use a new SwiftUI symbol such as ConcentricRectangle or .glassEffect. I've tried using the legacy linker to no avail. It compiles perfectly fine, and I've tried targeting just macOS 26 also to no avail. This is a macOS project that's compiled just fine for years and compiles and runs on macOS going back to 13.0. Failed to look up symbolic reference at 0x118e743cd - offset 1916987 - symbol symbolic _____y_____y_____y_____yAAyAAy_____y__________G_____G_____yAFGGSg_ACyAAy_____y_____SSG_____y_____SgGG______tGSgACyAAyAAy_____ATG_____G_AVtGSgtGGAQySbGG______Qo_ 7SwiftUI4ViewPAAE11glassEffect_2inQrAA5GlassV_qd__tAA5ShapeRd__lFQO AA15ModifiedContentV AA6VStackV AA05TupleC0V AA01_hC0V AA9RectangleV AA5ColorV AA12_FrameLayoutV AA24_BackgroundStyleModifierV AA6IDViewV 8[ ]012EditorTabBarC0V AA022_EnvironmentKeyWritingS0V A_0W0C AA7DividerV A_0w4JumpyC0V AA08_PaddingP0V AA07DefaultgeH0V in /Users/[ ]/Library/Developer/Xcode/DerivedData/[ ]-grfjhgtlsyiobueapymobkzvfytq/Build/Products/Debug/[ ]/Contents/MacOS/[ ].debug.dylib - pointer at 0x119048408 is likely a reference to a missing weak symbol Example crashing code: import SwiftUI struct MyView: View { var body: some View { if #available(macOS 26.0, *) { Text("what the heck man").glassEffect() } } }

I'm exploring using the CARemoteLayerClient/Server API to render a layer from another process as is described in the docs, but can't seem to get a very simple example to work. Here's a very simple example of what I'd expect to work: // Run with `swift file.swift` import AppKit let app = NSApplication.shared class AppDelegate: NSObject, NSApplicationDelegate { let window = NSWindow( contentRect: NSMakeRect(200, 200, 400, 200), styleMask: [.titled, .closable, .miniaturizable, .resizable], backing: .buffered, defer: false, screen: nil ) func applicationDidFinishLaunching(_ notification: Notification) { window.makeKeyAndOrderFront(nil) let view = NSView() view.frame = NSRect(x: 0, y: 0, width: 150, height: 150) view.layerUsesCoreImageFilters = true view.wantsLayer = true let server = CARemoteLayerServer.shared() let client = CARemoteLayerClient(serverPort: server.serverPort) print(client.clientId) client.layer = CALayer() client.layer?.backgroundColor = NSColor.red.cgColor // Expect red rectangle client.layer?.bounds = CGRect(x: 0, y: 0, width: 100, height: 100) let serverLayer = CALayer(remoteClientId: client.clientId) serverLayer.bounds = CGRect(x: 0, y: 0, width: 100, height: 100) view.layer?.addSublayer(serverLayer) view.layer?.backgroundColor = NSColor.blue.cgColor // Background blue to confirm parent layer exists window.contentView?.addSubview(view) } } let delegate = AppDelegate() app.delegate = delegate app.run() In this example I'd expect there to be a red rectangle appearing as the remote layer. If I inspect the server's layer hierarchy I see the correct CALayerHost with the correct client ID being created, but it doesn't display the correct contents being set from the client side. After investigating this thread: https://bugs.chromium.org/p/chromium/issues/detail?id=312462 and some demo projects, I've found that the workarounds previously found to make this API work no longer seem to work on my machine (M1 Pro, Ventura). Am I missing something glaringly obvious in my simple implementation or is this a bug?

I'm wondering how one might be able to securely load bundles signed by a developer ID into a parent app. Here's my use case, we have a series of plugin-like bundles that each contain some compiled C code and some wrapper code. They are loaded at runtime to perform some function and maintained in memory for the lifetime of the app. These bundles can be rather large (10-15Mb each), and our app size is growing large as we add them. Right now these are baked into a framework that is embedded in the app, but we're looking at using a Bundle to load each one individually on demand. We've been successful implementing the on-demand loading. But, we're concerned about maintaining security while loading these into the parent app. Each bundle is signed by the parent app's developer ID, and it's feasible that we could verify a code signature before loading them without running into performance issues as usually only one is needed at a time. What we'd like to try and prevent is a bad actor injecting some code into the bundle, and the parent app loading it leading to a compromise of user data. It seems like code signing could help prevent this by verifying that each bundle has not been modified and has been signed by us. To verify code signature we'd be using SecCode objects and SecCodeCheckValidity to verify them. So here's the question, is just verifying a code signature enough to prevent breaches of security like the one's we're concerned about? Is this the correct model for this type of use case on MacOS?

I have an intent whose flow looks like this when performing the action: 1. Get details from user 2. Add items to local db 3. Get return value from db -- if user is signed in 4. Send new data to API -- In these steps I can finish the intent at step 3, but in some cases I'll need to send the new data to an API so it can be propagated to other user's devices. If I simply wait until the API returns, some users may notice a delay after being signed in, eg: after signing in, the task now takes a few seconds when it used to take only a split second. Is there a way I can return the intent while continuing the background process? Or is it okay to simply call the completion handler, then continue my script in the func handle(intent:

In App Store Connect I can't access any of my apps' in app purchase information. This includes apps that are live on the app store and is very worrisome. When I click on 'Manage' under 'In-App Purchases' it brings me to a page that says "There was a problem retrieving the data for this page. Please try again." Then, in my apps, I'm just not finding any products. All requests for in-app purchases fail. Is there something I'm missing? I've looked at my agreements and such, and there's no alerts on my account. I shouldn't have to renew my developer account for 9 months.