“We are unable to process your request”

We are trying to intercept raw reports from the built-in MacBook haptic trackpad using a DriverKit IOUserHIDEventDriver dext. Our dext installs and activates successfully: OSSystemExtensionRequest finishes with result 0 systemextensionsctl list shows the dext as activated enabled the dext is embedded correctly in the app bundle However, it never attaches to the built-in trackpad IOHIDInterface. ioreg shows the built-in trackpad interface still matched only by Apple’s HID dext. We also observed that Apple’s own HID dext appears to use com.apple.developer.driverkit.builtin, while that entitlement is not available in our provisioning profile. Our dext specifically relies on: IOUserHIDEventDriver::handleReport(...) SetProperties() with kIOHIDEventDriverHandlesReport Questions: Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface? Is that entitlement public/requestable, or Apple-internal only? At what stage is it enfo

Hi everyone, I recently got rejected under Guideline 1.1.1 - Safety - Objectionable Content and I'm struggling to understand how my app falls under this category. Looking for advice from anyone who's dealt with similar rejections. What the app does: AutoSignal is a vehicle notification app designed for the Bulgarian market. It solves a very common real-world problem - needing to contact a car owner when their vehicle is double-parked, blocking you in, has its lights left on, or has been hit/damaged while parked. The core flow is: A user scans a license plate using their phone camera If the car owner is registered in the app, they receive an anonymous push notification (e.g., Your car with plate XX 1234 XX is blocking someone or Your lights are on) The car owner can then take action Users can also report vehicle damage cases with temporary witness notes that auto-expire after 7 days. Why I believe it doesn't violate 1.1.1: The app does not expose any personal information. Notifications are fully anonymous - th

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good foundational documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: Making sense of IOKit error codes,, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the IOKitPersonalities is cal

I've been unable to enroll in the Apple Developer Program and am posting here after exhausting the standard support channels. The situation: When I attempt to enroll in the Apple Developer Program as an individual, I receive the error: Your enrollment could not be completed. Your enrollment in the Apple Developer Program could not be completed at this time. No additional explanation is provided. I have contacted Apple Developer Program Support multiple times by both phone and email. Each time, I was told there is nothing they can do. I asked for escalation and was told escalation is not possible. At no point was I given a specific reason for the rejection. One possible cause I identified on my own is that the name on my developer profile may not match my legal name. My Apple ID at appleid.apple.com shows my correct legal name, but I'm unsure whether my developer profile reflects the same. I have not been able to confirm whether this is actually the issue, because support has not told me what the prob

We're seeing a sporadic crash (~2-3% of spawns) when launching a large Mach-O binary via posix_spawn(). The crash happens inside libsystem_malloc.dylib during __malloc_init, before any application code runs. The process never reaches main(). Environment: macOS 26.3.1 (25D2128), Apple Silicon (ARM64) Crash signature BUG IN LIBMALLOC: pointer range initial reservation failed, Abort Cause 3 #0 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups.cold.1 #1 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups #2 libsystem_malloc.dylib: xzm_main_malloc_zone_create #3 libsystem_malloc.dylib: __malloc_init #4 libSystem.B.dylib: libSystem_initializer #5 dyld: dyld4::Loader::findAndRunAllInitializers The binary It's a Chromium component-build test binary (browser_tests): ~1.5 GiB on disk, 5.54 GiB total VA footprint (__TEXT 517 MiB, __LINKEDIT 1.04 GiB, __PAGEZERO 4 GiB) Links 527 dylibs via @rpath All images span ~16.4 GiB of VA when loaded A simple loop that spawns this binary 200 times v

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 Application with identifier is not associated with domain The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agen

After iOS app overlay installation widget process killed OSLaunchdJob | handle= start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments,widget kill and liveactivity dismiss ，infomation ： 默认 chronod [com.jd.jinrong.JDJRWidget] Creating session... 默认 chronod [DFB1D11C]: activityHandler ended 默认 iconservicesagent [0x5e2812320] activating connection: mach=false listener=false peer=true name=com.apple.iconservices.peer.0x5e2812320 默认 runningboardd : start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments 错误 runningboardd Process start failed with Error Domain=NSPOSIXErrorDomain Code=111 Unknown error: 111 UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd : remove failed with error 144 Requestor lacks required entitlement 错误 runningboardd Job remove after failed start failed with Error Domain=OSLaunchdErrorDomain Code=144 Requestor lacks required entitlement UserInfo={NSLocalizedFailureReason=Requestor

Hey everyone, I’m completely stuck and hoping someone here (or an Apple rep) can help, because Developer Support is just sending me the exact same template replies at this point. I submitted a standard version update for my app (Hadiyyati - Luxury Gifts) back on February 7th. It has now been over 45 days, and the status is still permanently frozen on Waiting for Review. Here is the loop I am stuck in: I've had an Expedited Review requested and approved 3 separate times. Support gives me a case number, says they contacted the App Review Board, and tells me to wait. Weeks pass, nothing happens, and when I follow up, I get: At this time, your app review is proceeding normally, and there is no further action you need to take. 45 days for a store update is not proceeding normally. I strongly suspect my submission (ID: aeadea76-8fb4-437c-9c04-60171b909f3e) is bugged, corrupted, or locked in a ghost state on the App Store Connect backend. Has anyone dealt with a completely frozen submission like this? Is th

Background We're building a macOS application that acts as a CryptoTokenKit software token. The architecture follows the documented pattern: a container app (a long-running agent process) manages token registration and identity updates via TKTokenDriverConfiguration, and a separate appex extension process handles the actual signing operations for client sessions. What we're doing At agent startup, the container app calls [TKTokenDriverConfiguration driverConfigurations] to obtain our token driver, then registers a token instance ID: NSDictionary *driverConfigurations = [TKTokenDriverConfiguration driverConfigurations]; TKTokenDriverConfiguration driver = / first value from driverConfigurations */; [driver addTokenConfigurationForTokenInstanceID:@setoken]; When the agent renews a certificate, it pushes updated TKTokenKeychainItem objects to ctkd by setting keychainItems on the TKTokenConfiguration: TKTokenConfiguration *tokenCfg = driver.tokenConfigurations[@setoken]; tokenCfg.keychainItems =