missing package product

Core Problem: VoIP push notifications are not delivered to the application when it is in the background or terminated. After reviewing existing discussions on the forum, I concluded that the cause might be related to CallKit not having enough time to register. Yes, that's sort of correct. I think root of the problem is actually here: private let voipRegistry = PKPushRegistry(queue: .main) private var provider: CXProvider? ...and is tied to the dynamic of how static object initialization occurs. Basically, your PKPushRegistry object is going to be created IMMEDIATELY after your AppDelegate object is created and before basically any normal app methods are called, including didFinishLaunchingWithOptions. I'm not sure how the full process plays out from there, but I think the net result is that you're losing the initial push because of the time gap between PKPushRegistry's creation and when didFinishLaunchingWithOptions is called and the rest of your initialization completes. One thing to note here is th

No, I am not activating or changing anything in AudioSession. I have pretty straightforward setup; recording an audio using AVAudioEngine and sending to the server (which is running locally for now). And when PTT notification arrives saving url to audio file in incomingPushResult, then downloading and playing that sound using AVAudioPlayer when didActivate is executed. It's working fine on foreground, but when app goes to background incomingPushResult is called as expected but didActivate is not for some reason. Am I missing anything in my setup?

I'd like to +1 the need for an official compatibility list. If you haven't already, you're welcome to file a bug on this and please send me the bug number if you do. However, I'm not sure that's something that’s likely to happen, as the main reason we use runtime checks like BGContinuedProcessingTaskRequest.Resources.gpu is that it gives the engineer team the flexibility to change what devices are supported (generally by expanding) without needing to worry about keeping the documentation in sync, particularly if the supported device set varies with OS version. Most of our APIs use this approach and don't explicitly describe what hardware they support. Case in point, the form here: (something like this, for example). ...is a specific exception because UIRequiredDeviceCapabilities is used for an install-time check of the entire app, not just a specific app feature. It's also tied to functionality that was inconsistently implemented across our product lines and system versions, which makes it much more

I also have the same problem on a MacStudio M1Max (and not on a MBP M1Max) after upgrading to Xcode 26.1.1: no MetalToolchain accessible from this application. Running on Tahoe 26.1 Running today xcodebuild -downloadComponent metalToolchain gives: `Beginning asset download... Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/68d8db6212b48d387d071ff7b905df796658e713.asset/AssetData/Restore/022-20369-066.dmg Done downloading: Metal Toolchain 17B54.` Then when I run xcrun metal --version, I got an error message: error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain Last when I run: xcodebuild -showComponent metalToolchain, I got: 2025-12-12 18:34:14.045 xcodebuild[27394:1591467] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.2.54.0.BttmuJ” couldn’t be opened because you don’t have permission to view it. 2025-12-12 18:3

Hello, I'm using MulitpeerNetworking in an App for Long- and Tripplejump (JumpControl). A camera is located close to the take-off-board and is controlled by another device connected via Multipeer-Networking-API. Usually this works fine even for several meters distance. In real events, when there are more other devices around the connectivity becomes more and more unstable. Connection is lost or cannot be established again. Is there a way to make this connection more stable or at least get more information about the circumstances that makes it unstable? Is there a possibility to connect two iOS-Devices via cable-connection to improve stability?

[quote='869055022, Yvan.d, /thread/809534?answerId=869055022#869055022, /profile/Yvan.d'] could this type of Keychain item design … lead to the kind of attribute inconsistency [/quote] It’s certainly possible. My experience is that there’s a lot of really bad keychain code out there )-: That’s partly because the SecItem API is way more subtle than people think, and partly because Apple’s initial documentation and sample code for it was… well… less than ideal. Moreover, the keychain is a persistent database where it’s important to not lose user state. So if your app has been around for a while, debugging a keychain problem means that you have to understand your current code and all the previous iterations of that code. There’s a few ways to tackle a problem like this: You could use source control to resurrect old versions of your keychain code, put all that code in a test app, and then try it out. You could use telemetry to understand the state of your users’ keychain items in practice. You could do w

My response on that other thread still applies here. Can you reproduce this on a clean machine? Or are you only seeing this on specific Macs? Specifically, I recommend that you run this test: Install your target OS in a VM. Take a snapshot of the clean VM for the benefit of future tests. Install your product as a user would. Update your product as a user would. Does that reproduce the problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Actually it's even worse. I submitted the app together with the in-app purchases. You reject the app and I answer before resubmitting. On the next review the app is rejected again because in-app purchases are missing. I thought I made a mistake in the beginning but you did. I cannot reassign the in-app purchases. they are waiting for review and will be rejected eventually because the app is missing, the app is rejected because the in-app purchases are missing. They are stuck in limbus.