missing package product

Thanks again for your inputs. Yes, I started with a test app, and it worked as expected. Then I moved on to the authorization plugin, where the detection part isn’t behaving as expected. I later thought of checking with Apple in case there’s any limitation around the monitoring part within securityd. I’ll review it again based on your suggestions to see if I missed anything.

I understand that it is not necessary to include this com.apple.developer.driverkit.allow-any-userclient-access in the driver's Entitlements. I have a new question: I include Capabilities in the Provisioning Profile that might not be used, just in case. If I don't list all these Capabilities in the driver's Entitlements, will it cause the driver to behave abnormally? To issue vendor-specific commands, I created a driver class inheriting from the IOUserSCSIPeripheralDeviceType00 class in the SCSIPeripheralDriverKit Framework. I then created a UserClient inheriting from the IOUserClient class to access it from the app, but IOServiceOpen fails with code 0xe00002d7 and cannot open. The driver's entitlements are as follows. com.apple.developer.driverkit.transport.usb com.apple.developer.driverkit.family.scsicontroller com.apple.developer.driverkit.communicates-with-drivers com.apple.developer.driverkit.allow-third-party-userclients com.apple.developer.driverkit And in the driver's Info.plist, the following de

@App Store Commerce Engineer I understand that before release, accessing the production endpoint returns HTTP 401 Unauthorized. Q1. I would like to confirm: at what point does access to the production App Store Server API become available? (A) Immediately after App Review approval (when the app status is “Ready for Sale,” but before it is actually published on the App Store), or (B) After the app is actually released and visible on the App Store? Also, since purchases during App Review must go through the sandbox environment, I plan to implement a fallback mechanism where, if I receive a 401 from the production API, my server will retry verification using the sandbox API. Q2. For the pre-release (App Review) phase, is this understanding correct — that I should detect 401 and fallback to sandbox? Q3. After the app is released and production API access becomes available, if a sandbox transactionId is sent to the production API during a post-release review, is it cor

That sample doesn't quite work out of the box. Here is how you can get it to work on macOS 26 with Xcode 26 (and earlier versions of both, but that's what I'm using). Download the sample from https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app?. Follow only some of the directions under Configure the sample code project: (turn off SIP) - skip this, it is no longer necessary Set Automatically manage signing for both the driver and the app targets Select a development team. Xcode will tell you that you cannot select an individual for this type of signing. ignore the advice about Sign to run locally and AD_HOC_CODE_SIGNING_ALLOWED. ignore all the other stuff. You don't need to make profiles, add capabilities, manually download profiles or add them to Xcode. Now go the Build Settings for the driver and app target, and change the Product Bundle Identifier. The download project uses a disambiguation string that doesn't work, and you end up with ve

We are setting the expiration header as following apns-expiry=0, so from my understanding it should not be delivered if the device was not able to receive the notification in the first attempt. Theoretically, yes, it does that and it certainly does better than setting a longer expiration. However... I have read the following thread https://developer.apple.com/forums/thread/778512, from which I understand this is a long-standing issue. Yes, it is. If you haven't already, please file a bug on this and then post the bug number back here. As part of that bug, please note how long you think a push submission should last after our server receives it before being discarded. For example, is 15s too long? I'd like to get this fixed this year and additional bug reports help drive that process. Hence my question is, is there any way we can notify the call kit that the call is actually no longer valid, and do not display the call to the user at all? No, there is not*. You can report the call and immediately end it, but t

I tried many things, but I can't seem to be able to pass through the check to allow the application to communicate with the dext. What am I missing? So, as it happens, I have a post here that's specifically about getting this sample to work. Try what that post suggests and let me know if you're still having issues. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Apologies I am now having troubles getting this to recreate again even using the exact same submission. I will keep trying and hopefully get you something you can work with. What do you consider building with Apple tools? This is our process for building as we are a golang application developed outside of xcode. For each inner PKG: create universal binary sign and verify the binary codesign --sign Developer ID Application: --deep --timestamp --options=runtime codesign --verify --verbose build and sign the inner pkg pkgbuild --root ConcealBrowse.pkg --scripts --sign Developer ID Installer: --install-location /Applications --identifier io.conceal.helper --version pkgutil --check-signature signed-installers/ConcealBrowse.pkg Notarize and staple the PKG xcrun notarytool submit --key --key-id -i ConcealBrowse.pkg --wait xcrun stapler staple ConcealBrowse.pkg After we repeat the above process for all three of our inner PKGs I build and sign the Distribution PKG

Until you have a release in production, access to the production APIs is not allowed. Once you have a release in production this will be unlocked.