“missing package product”

Followup: filed FB21570087 per Quinn's suggestion. Digging into the behavior for the write-up turned up something my original report missed. The check in xcrun / clang is on the basename of the developer path, not the full path: basename CommandLineTools -> accepted as a CLT install path matches *.app/Contents/Developer -> tried as Xcode (also needs Info.plist + xcodebuild) anything else -> rejected with the unable to find Xcode installation error The parent directory isn't checked. My attempt with /Library/Developer/CommandLineTools-26.2.0 failed because of the basename, not the location. Since DEVELOPER_DIR is a per-process env var, not the global xcode-select selection, parallel multi-version CLT actually works: DEVELOPER_DIR=/opt/clt/17/CommandLineTools clang --version # 17.x DEVELOPER_DIR=/opt/clt/16/CommandLineTools clang --version # 16.x Two shells can run these concurrently and each sees its own CLT. /Library/Developer/CommandLineTools can still point at one of them as the default fo

Quick update with results from a diagnostic build I ran on iOS/watchOS 26.5. To validate the distinction you described between the NSE-returned content path and the locally posted notification path, I shipped an internal TestFlight build where the NSE additionally posts a local UNNotificationRequest via UNUserNotificationCenter.add() in parallel with the standard contentHandler() call. The local notification uses the same title and body as the NSE-returned notification, except for a [L] prefix in the body and a local-z- identifier prefix. The same [L] marker is visible on iPhone and Apple Watch, so the local-route notification can be reliably matched across both devices. Test protocol: Send a message with a known timestamp in the body, for example Timestamp 00:19 Wait for delivery on Apple Watch Turn the Watch screen off Wait approximately 2–3 minutes Wake the Watch and open Notification Center Result on Apple Watch, using iOS 26.5 + watchOS 26.5: Local-route notification, [L] Timestamp 00:19: correct relativ

Thanks for the post. So interesting and there are many SwiftUI people that are probably going to jump into the thread. In my case I wanted to test the use .clear.interactive(), SwiftUI generates a visual highlight layer that responds to user touches. To optimize this highlight animation, the system tries to resolve the shape provided in the in: parameter into a standard primitive. Because .concentric corners are dynamic, the interaction highlight engine currently fails to resolve the exact bezier path for the mask? In this case manifests as a highly rounded rectangle. Sometimes the interaction engine needs an explicit contentShape to properly map the hit-testing and highlight bounds, rather than relying solely on the in: parameter of the glass effect. struct ContentView: View { var body: some View { VStack { Text(Hello, World!) .frame(maxWidth: .infinity, maxHeight: .infinity) .glassEffect(.clear.interactive(), in: .rect(cornerRadius: 32)) .padding(36) .ignoresSafeArea() .preferredColorScheme(.dark) } .paddin

I'm seeing a timestamp display issue on Apple Watch Notification Center, and I'd like to confirm whether this is a known watchOS behavior or whether there's a setup mistake on our side. I'm not aware of any issue like this, and the general behavior you’re describing sounds like a bug. Have you filed a bug on this and, if so, what's the bug number? Also, what system versions are you seeing this on and have you seen it on watchOS 26.5? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? In theory, what you're doing should just work. More specifically, by design, your extension doesn't control the time data of the notification you're returning, so what actually happens is that the UNNotificationContent your extension returned is immediately embedded into a newly created UNNotification object, which is then processed normally. How that would end up creating the situation you're describing is something I can't explain. However, this i

Hello @shigezhino, [quote='886784022, shigezhino, /thread/824827?answerId=886784022#886784022, /profile/shigezhino'] At first, I asked my question on the Apple Support Community. However, I was advised to post it on developer.apple.com since my environment includes beta software, [/quote] I'm sorry to hear that. I know what that feels like and it's definitely not the intended experience. It's important to note that beta software is not final and may introduce unexpected changes or issues. The correct channel for reporting issues with beta software would most certainly be to file a Feedback Report through Feedback Assistant on the device, preferably, and if not through the website, in this case. From the beta software page at developer.apple.com/support/beta-software/ Apple beta software, also referred to as a preview, seed, or release candidate, is for developers to take advantage of the latest advancements in Apple platforms and test apps for compatibility As for getting your Numbers in a working condition:

Hi everyone, Adding our experience, no fix either, but production data that may help triangulate. We've filed FB22638314 corroborating SeoulForest's FB22327481. Context Bird Rise alarm app: a new bird wakes the user up every day. AlarmKit on iOS 26.2+. The bug: The off-hours misfire rate. Across ~13,000 firings in 30 days, <0.5% of users intend evening or night alarms (84% schedule for 06:00–09:59), yet ~10–15% of actual rings land in the 21:00–01:00 window. Same on iOS 26.1 through 26.5. This matches the fires around midnight / fires at random times pattern described upthread. App Store reviews reporting the alarm continues to fire after the app has been uninstalled. 🤯 We've ruled out app-side causes: no EventKit, no server push, no app groups, no third-party schedulers; AlarmKit is the only persistent scheduling we use. Pattern looks similar to the zombie Live Activity on thread 819556. I was never able to catch those issues on my devices. Would appreciate any guidance from anyone who's gotten

Thanks for the quick reply! I was missing the NSPanel bit! I forgot to mention that I added the Application is agent (LSUIElement) key to the info.plist which seems to be equivalent to your first point. Now everything seems to work as you've stated. I tested those scenarios as well and it always stays on top!

[quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] we were posed with the option of choosing a Developer ID Certificate Intermediary [/quote] Oh, that’s a new one. [quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] Can you please let us know which Developer ID Certificate Intermediary we should choose … ? [/quote] I don’t think there’s a one-size-fits-all answer to that, which is why we give you the choice. My general advice is that you pick the new one, but the old one might make sense if: You have infrastructure that relies on ancient versions of Xcode (or the Command Line Tools package). Or infrastructure that’s tied to a specific intermediate. Picking the new one may require you to install the new intermediate on your build infrastructure, but that’s not a particularly onerous task. From a deployment perspective, this choice shouldn’t matter. When codesign signs code, it builds a chain of trust and embeds that full chain into the code signature. So when a Mac goes to verif