Overview

AVCaptureSession.startRunning() triggers AVCaptureSessionRuntimeErrorNotification with AVError.unknown (-11800), underlying OSStatus 2003329396 → fourCC 'what', every cold launch, but only when an audio AVCaptureDeviceInput is attached. Removing only the audio input makes the error disappear. Same code in a fresh project records audio fine — bug only appears in this app's binary. AVAudioApplication.shared.recordPermission == .granted. Info.plist has NSMicrophoneUsageDescription. No interruption notifications fire. Test device: iPhone 16 Pro, iOS 26.4.2. iOS deployment target 17.1. Minimal reproducer import AVFoundation let session = AVCaptureSession() session.beginConfiguration() let camera = AVCaptureDevice.default(.builtInWideAngleCamera, for: .video, position: .back)! session.addInput(try AVCaptureDeviceInput(device: camera)) // Removing ONLY this line makes the error disappear: let mic = AVCaptureDevice.default(for: .audio)! session.addInput(try AVCaptureDeviceInput(device: mic)) session.addOutput(AVCaptureMovieFileOutput()) session.addOutput(AVCapturePhotoOutput()) session.commitConfiguration() NotificationCenter.default.addObserver( forName: .AVCaptureSessionRuntimeError, object: session, queue: nil ) { print($0.userInfo ?? [:]) } session.startRunning() // -11800 / 'what' fires within ~2 sec Observed state at error time AVError.unknown (-11800) underlyingError = NSError(NSOSStatusErrorDomain, 2003329396) userInfo[AVErrorFourCharCode] = 'what' captureSession.isRunning = false ← never came up captureSession.isInterrupted = false captureSession.preset = .high captureSession.inputs = [Back Triple Camera, iPhone Microphone] AVAudioSession.sharedInstance(): category = .playAndRecord mode = .videoRecording sampleRate = 48000.0 isInputAvailable = true isOtherAudioPlaying = false availableInputs = [MicrophoneBuiltIn] (no BT/Continuity/AirPods) currentRoute.inputs = [] ← EMPTY currentRoute.outputs = [Speaker|Speaker] 2003329396 = 0x77686174 = 'what'. From a few SO threads this maps to AURemoteIO::StartIO returning a HAL-bring-up failure. The smoking gun: currentRoute.inputs is empty even though availableInputs contains the built-in mic, isInputAvailable is true, the category is .playAndRecord, and isOtherAudioPlaying is false. The HAL never routes the mic into the session, then 'what' follows. Nothing observable from AVAudioSession indicates a competing client. Environment / SDKs linked Firebase (SPM: Crashlytics, Performance, Messaging, Analytics, AppCheck, RemoteConfig, DynamicLinks), FBSDK, Kingfisher, MetalPetal. Multiple Google ad mediation pods present, but their audio session takeover is already disabled (audioVideoManager.isAudioSessionApplicationManaged = true, IMSdk.shouldAutoManageAVAudioSession(false)). What I've ruled out (all still produce 'what') Audio session config: .playAndRecord/.videoRecording, .playAndRecord/.default, .record/.measurement, .record/.default. With/without .defaultToSpeaker, .allowBluetooth, .allowBluetoothA2DP, .mixWithOthers. setActive(true) before vs. after attaching audio input. setPreferredInput(builtInMic) (verified accepted). 200ms Thread.sleep between setActive(true) and startRunning(). Setting usesApplicationAudioSession = false swaps the fourCC to '!rec' but produces the same outcome. Topology: sessionPreset = .high / .hd1920x1080 / .hd1280x720 / .medium. Camera = .builtInTripleCamera / .builtInDualWideCamera / .builtInWideAngleCamera. AVCam-style always-attached graph. Setting sessionPreset before vs. after adding inputs. Threading: All session mutations on a single dedicated DispatchQueue (vs. Swift actor). 1× and 2× full stopRunning()+startRunning() recovery cycles ("do it twice" pattern) — both re-fail with 'what'. SDK takeover prevention: GoogleMobileAdsMediation pods (Vungle, Mintegral, Pangle, Unity, InMobi), Google-Mobile-Ads-SDK, MediaPipeTasksVision removed via full pod uninstall + clean build — 'what' persists. Notifications during the failure window: 3 × AVAudioSession.routeChangeNotification reason categoryChange before the error fires, even though category stays .playAndRecord/.videoRecording. Disabling automaticallyConfiguresApplicationAudioSession drops this to 1, but the runtime error still fires. No AVAudioSession.interruptionNotification. No AVCaptureSessionWasInterruptedNotification. Symbol audit otool -L and nm of the bundle confirm none of the linked frameworks reference AVAudioRecorder, AudioComponentInstanceNew, AURemoteIO, or AudioUnitInitialize in their symbol tables. Only the app's own files reference any audio API. Yet adding AVCaptureDeviceInput(.audio) reproduces 100% in this binary and 0% in a fresh project. My questions Who is most likely holding the audio HAL in a process where no linked framework references the AudioUnit / HAL APIs directly? Are there framework load-time audio initializations that don't show up in symbol tables (e.g., dynamic dlopen, CFBundleLoadExecutable) that could grab the HAL? Is there an os_log subsystem / category that surfaces the underlying AURemoteIO::StartIO failure reason at runtime? com.apple.coreaudio shows 'what' but not the originating cause. currentRoute.inputs is empty at error time even though availableInputs = [MicrophoneBuiltIn], isInputAvailable = true, and the category is .playAndRecord. What does an empty input route under those conditions imply, and what other system-level holders could be preventing the HAL from routing the mic in? Has anyone seen 'what' resolve with a device reboot, an iOS update, or by removing a specific framework? Happy to share a sysdiagnose. Thanks!

Hi AVFoundation team, I'm seeing a uniform 90° offset in AVCaptureDevice.RotationCoordinator's reported angles between iPhone 17 Pro and iPhone 14 Pro using the front-facing .builtInWideAngleCamera (Center Stage on 17 Pro), and I'd like to confirm whether this is by design and what the recommended consumption pattern is when the rendering surface is an AVSampleBufferDisplayLayer rather than an AVCaptureVideoPreviewLayer. Here is the github repo of sample project. Setup Devices: iPhone 14 Pro (iOS 26.5) and iPhone 17 Pro (iOS 26.4.2) Camera: front, AVCaptureDeviceTypeBuiltInWideAngleCamera Active format: 1920×1080 Three RotationCoordinator instances are created on the same AVCaptureDevice, varying only the previewLayer: argument: - previewLayer: nil - previewLayer: AVSampleBufferDisplayLayer (the surface receiving frames from AVCaptureVideoDataOutput) - previewLayer: AVCaptureVideoPreviewLayer (with .session = captureSession, not displayed) Each instance is KVO-observed for videoRotationAngleForHorizonLevelPreview and videoRotationAngleForHorizonLevelCapture. Observed angles Device / Orientation: 14 Pro · Portrait (interface=1) RC[nil] prev / cap: 0° / 90° RC[AVSampleBufferLayer] prev / cap: 90° / 90° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 90° ──────────────────────────────────────── Device / Orientation: 14 Pro · LandscapeRight (interface=3) RC[nil] prev / cap: 0° / 180° RC[AVSampleBufferLayer] prev / cap: 180° / 180° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 180° ──────────────────────────────────────── Device / Orientation: 17 Pro · Portrait (interface=1) RC[nil] prev / cap: 0° / 0° RC[AVSampleBufferLayer] prev / cap: 0° / 0° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 0° ──────────────────────────────────────── Device / Orientation: 17 Pro · LandscapeRight (interface=3) RC[nil] prev / cap: 0° / 90° RC[AVSampleBufferLayer] prev / cap: 90° / 90° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 90° The −90° offset on 17 Pro is uniform: it appears in every RC variant, in both the preview-angle and the capture-angle properties, at every orientation tested. It is not specific to the previewLayer: argument.

Xcode iig hangs. In the best case, the project will be in error - and Xcode cannot recover. To recover restarting Xcode may not help (force quit Xcode) - most of the time a restart of the Mac is required. Its speaks to software quality when "Clean build folder" is your best friend. Xcode iig hangs, and while its only using two of my MacStudio's 10 cores - the whole mac hangs (Activity monitor confirms, if it opens at all). If you are not quick enough to reboot the Mac will hang and require power down using power button. Don't use Finder to reboot because Finder hangs too and will not reboot - use terminal (sudo shutdown -r now). see screen dump below: super useful! After restart, Xode may refuse to launch. This is something I notice with my Java apps (jar launcher): If the app ends with an exit code (1, not 0 like normally) - it will not launch until I restart the Mac, in the meantime must launch the app from Eclipse. After restart, the crash reporter comes up - asking me to type a reason. When I type "iig" the auto-correct will change that to "big". This is so totally useful! MacOS 26.4.1 Xcode 26.3 apologies - its a lousy day when your Mac hangs and requires a restart - repeatedly; until I got my iig fixed up and Xcode fully aware with the actual content. iig error reporting is lousy; which makes fixing so extra hard.

Hi everyone. I’m building a macOS-first desktop app where music drives the app's behavior loop. The app is currently an Electron prototype. The blocker: we’re testing Apple Music inside an Electron app. MusicKit JS authorization works, catalog search works, and setting the queue works, but playback does not actually start in Electron. What we tried: Created Apple Developer / MusicKit credentials. Generated Apple Music developer tokens successfully. Retrieved a Music User Token through MusicKit JS. Confirmed Apple Music API calls work. Confirmed /v1/test and /me/storefront return 200 OK. Built a local HTTP auth/playback window inside Electron instead of using file://. Tested music.setQueue() with both: { song: songId } { url: catalogUrl } In Electron, the queue loads correctly: queueEmpty=false queueLength=1 volume=1 playbackRate=1 But after music.play(), playbackTime stays at 0 and no audio plays. Then we ran the same MusicKit playback test in normal Chrome using the same token, same local origin, same catalog track, and same queue descriptor. Chrome played successfully and playbackTime advanced. We also checked Electron directly and found navigator.requestMediaKeySystemAccess is missing, so our current theory is that stock Electron lacks the protected media / EME support Apple Music web playback needs. Important: we are not trying to bypass DRM or extract audio. We just want a legitimate way for a user-authorized macOS app to control Apple Music playback or observe playback state. What we’re considering next: Use the native macOS Music app as the playback engine and control it from our app. Test AppleScript / Automation permissions for play, pause, next, current track, player state, etc. Later, possibly build a native Swift helper using Apple Music / MediaPlayer APIs and communicate with Electron over IPC. Avoid relying on Electron MusicKit JS playback if this is a known dead end. Questions: Has anyone successfully made Apple Music / MusicKit JS playback work inside Electron? Is the missing EME/protected-media layer the expected blocker here? Is controlling the native macOS Music app the more realistic path? Any gotchas with AppleScript, MusicKit native APIs, or Electron + native helper architecture for this use case? Any pointers from people who have dealt with Electron + Apple Music / protected media would be appreciated.

Hello, I am posting regarding my app, Apple ID 6755677576. My app was rejected on April 2, and I resubmitted it. After several weeks without any progress, I had to cancel the submission because the delay had become highly abnormal. I resubmitted the app again on April 23, and it is still stuck in “Waiting for Review.” This situation is critical because the live version of the app has contained a severe blocking bug since January 23. Due to these unusually long App Review delays, I have been unable to release the fix, and users continue to leave negative reviews because the app remains broken. In addition, for months, TestFlight builds have also remained pending review for unusually long periods. This means I no longer have any practical way to provide affected users with a corrected version while waiting for App Review, even though they are actively complaining about the blocking bug in the live version. I would like to know whether other developers are currently experiencing similarly unusual delays for both App Store review and TestFlight review. Thank you.

Hi everyone, Hope all are doing well. So I'm facing the issue with my apple developer account registration. I applied before with the duns number I got from apple and it keeps on saying it's a wrong number. Now when I get the new duns I went there to enroll for the developer account it doesn't let me fill the field "Legal Entity Name" and "D-U-N-S® Number" and the other it let me fill and when I click on continue I get this error "We are unable to process your request. An unknown error occurred." I sent apple an email but still didn't get a response it's been a week so if someone also faced the same issue I will really appreciate a help. Thanks for your time reading this.

input[type=number] mapped to AXTextField instead of AXIncrementor/UIAccessibilityTraitAdjustable in Safari (macOS and iOS). According to ML-AAM 1.0, <input type="number"> is required to map to the ARIA spinbutton role, but it is not being mapped as expected on WebKit (macOS and iOS) to the platform accessibility APIs: the element is reported as AXTextField on macOS and lacks UIAccessibilityTraitAdjustable on iOS. As a consequence, VoiceOver announces the element as a textfield rather than a spinbutton, does not increment with arrow keys on macOS, and does not respond to the swipe up/down gesture on iOS. This affects every <input type="number"> on the web (quantity steppers, age inputs, year pickers, etc). Authors are currently forced to work around it by reimplementing the spinbutton with role="spinbutton", which force the authors to emulate the native HTML solutions with JavaScript, contradicts the First Rule of ARIA Use and presents another interaction issues in WebKit (will create an issue about this and update this post later). References: HTML-AAM 1.0, input type=number: https://www.w3.org/TR/html-aam-1.0/#el-input-number ARIA 1.2, spinbutton role: https://www.w3.org/TR/wai-aria-1.2/#spinbutton First Rule of ARIA Use: https://www.w3.org/TR/using-aria/#firstrule Reproduction: https://codesandbox.io/p/sandbox/beautiful-hofstadter-vn7nj3 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>spinbutton techniques</title> </head> <body> <main> <h1>Spinbutton pattern</h1> <section aria-labelledby="html-solution"> <h2 id="html-solution">HTML solution: spinbutton</h2> <label for="qty">Quantity</label> <input id="qty" type="number" min="0" max="10" value="1" /> </section> </main> </body> </html> Expected behavior: AX role on macOS: AXIncrementor (mapped from spinbutton) AX trait on iOS: UIAccessibilityTraitAdjustable VoiceOver on macOS announces "[value], [name of the input], stepper" and then "you are currently on a stepper. To begin interacting with this stepper, press Control-Shift-Down Arrow", after pressing the combo should announce "in stepper" and inmmediately should announce "you are currently in a stepper. To decrease this value, press Control-Option-Down Arrow. To increase this value, press Control-Option-Up Arrow. to exit this stepper, press Control-Option-Shift-Up Arrow" One-finger swipe up/down on iOS increments/decrements the value Actual behavior on Safari: AX role on macOS: AXTextField AX trait on iOS: standard textfield, no Adjustable VoiceOver announces "[value], insertion at the beginning/end of the text, [name of the input], number field" and then "you are currently on text field. To enter text in this field, type". Omitting the native functionality of a spinbutton One-finger swipe up/down on iOS does nothing Cross-platform comparison (same HTML, same spec): Firefox + NVDA on Windows: Chrome + NVDA on Windows: same as Firefox Safari + VoiceOver on macOS: broken as described above Safari + VoiceOver on iOS: broken as described above Environment: macOS: maOS Tahoe 26.4.1 Safari: 26.4 (21624.1.16.11.4) iOS: iOS 26.4.2 Device: iPhone 15 VoiceOver: default settings

I’m trying to build and run a brand-new Xcode project created from the Audio Unit Extension App template for local macOS development on a brand-new Mac, and I’m blocked by a signing/keychain issue. Environment: macOS on a brand-new Mac Xcode 26.4.1 Build version 17E202 Personal Team Targeting My Mac Project type: Audio Unit Extension App Main symptom: During build/run, Xcode repeatedly shows this prompt: codesign wants to access key "Apple Development: Sam Magnant (...)" in your keychain It asks for the login keychain password. Important detail My current Mac password successfully unlocks the login keychain manually in Keychain Access every time. So the issue seems specific to Xcode / codesign using the Apple Development private key, not a general inability to unlock the keychain. What I’ve already tried Reset the default keychain Logged out and back in after reset Changed my Mac account password to a new password Confirmed the login keychain unlocks manually with the current Mac password Deleted and recreated local Apple Development certificate/private key where possible Removed and re-added my Apple account in Xcode Checked the private key in Keychain Access Confirmed the private key exists under the Apple Development certificate Confirmed Allow all applications to access this item is already checked on the private key Removed App Groups and other extra capabilities to simplify the project Tried security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k '' ~/Library/Keychains/login.keychain-db Tried switching the project to simpler signing configurations, then switched back to standard Apple Development signing What’s confusing Xcode appears to know about an Apple Development certificate/private key Keychain Access shows the identity under login > My Certificates The login keychain unlocks fine manually But codesign still prompts, and the machine reports 0 valid identities found Questions What would cause Keychain Access to show the Apple Development identity, but security find-identity -v -p codesigning to report 0 valid identities found? Is this most likely a broken certificate/private key pairing, trust chain issue, or something specific to Personal Team signing? Is there a recommended way to fully repair the local Apple Development signing identity on the current macOS user account without creating a new macOS user? Are there known issues with the Audio Unit Extension App template and Personal Team local development on macOS?

I'm hitting a persistent build/upload failure when trying to submit my first app for review. Hoping someone has seen this specific issue. Setup App: ShiftSelf (an AI-guided self-coaching app) Bundle ID: app.shiftself.mobile Apple Developer account: active, paid, fully verified (Switzerland) App Store Connect: app created, Version 1.0 in "Prepare for Submission" Build pipeline: Expo-based (using a hosted Expo build service for the IPA upload) The error Every upload attempt fails with: exportArchive Error: Downloading App Information This has now occurred 14 times over the past 5 days, with no configuration changes between attempts. What is already configured correctly Two auto-renewable subscriptions (Monthly $9.99, Annual $59.99) — both in "Ready to Submit" state Subscription Group with English localization ("ShiftSelf Pro") created Both subscriptions attached to Version 1.0 under In-App Purchases and Subscriptions Privacy Policy URL, Terms URL, and Account Deletion URL all live and reachable DSA verified, Banking and Tax information active App icon, screenshots, and metadata all uploaded Age rating questionnaire completed (4+) App Privacy answers fully submitted No pending agreements in Account → Agreements, Tax, and Banking What I have already tried Recreated the subscription group localization Detached and reattached subscriptions to the version Multiple rebuild attempts at different times of day and across multiple days Verified all metadata fields are filled Apple Support engagement Currently working with Apple Developer Support (Case #102880953484). Guidance so far: Subscriptions must be "Ready to Submit" → done Subscriptions must be attached to the version → done Both confirmed. Builds still fail with the same error. Questions for the community Has anyone else seen "exportArchive Error: Downloading App Information" specifically during the metadata fetch step of an automated upload? Is there a known App Store Connect API issue that causes the metadata download to fail silently for first submissions? Would uploading the IPA manually via Apple Transporter bypass this step entirely, or does Transporter rely on the same metadata fetch? Is there any way to get more verbose logs on what specific "App Information" the export step is attempting to download? Any pointers from anyone who has hit this would be hugely appreciated. Happy to share more details if useful. Thanks 🙏

I am coding in Perl and I want to create Environment Variables (External to the app) specifically for this app only, however my custom ENV variables are deliberately blocked by the OS for security purposes (as described in documentation).

I'm trying to find where to buy the Vision Pro Developer Strap Gen 2. I've looked all around this site and cannot find it. Help

I'm on macOS 26.4 (SwiftUI + SwiftData + AppKit bridging). I have a SwiftUI canvas where each child view (a card) carries a per-card AppKit context menu via an NSViewRepresentable overlay (a small NSView subclass that overrides menu(for:) and returns an NSMenu whose items invoke a Swift closure). The closure for the "Delete" item removes the underlying model object. SwiftData mutates → SwiftUI re-emits the canvas → the card containing the menu's anchor NSView unmounts → that anchor NSView is removed from the AppKit view hierarchy. After this happens, the entire window's SwiftUI gestures stop receiving mouse events: pan, zoom, taps on a separate background Color view all go silent. The window's first responder ends up at the NSWindow itself. The wedge persists across switching to a sibling SwiftUI view in the same window (different SwiftData root), so the bad state is at the window/event-routing level, not in any one SwiftUI subtree. The wedge is reliably cleared by another right-click that successfully shows + dismisses any menu — strongly suggesting AppKit's menu/event-tracking cleanup is left in a half-finished state because the anchor view went away during the cleanup window. I've already verified: Switching from explicit NSMenu.popUpContextMenu(_:with:for:) to overriding menu(for:) does not change the behavior. Deferring the model deletion via DispatchQueue.main.async, asyncAfter (30 ms), or RunLoop.main.perform(inModes: [.default]) either doesn't help or only avoids the wedge if the delay is long enough to be perceptible (seconds), implying the cleanup window is event-driven, not time-driven. Triggering the same deletion from a SwiftUI Button (no AppKit menu involved) never wedges. My current understanding is that the standard AppKit pattern (e.g., NSTableView, NSOutlineView) attaches the context menu to a stable parent view, never to the per-row view itself, precisely so the menu's anchor outlives any single row's deletion. Restructuring my code so a single canvas-level AppKitContextMenuRegion returns the appropriate menu via hit-testing in menu(for:) should avoid the issue, but I'd like to confirm: Is the assumption that an NSMenu's anchor view must outlive the menu's tracking-end cleanup documented anywhere, or is it implicit? Is there a supported way to safely use a per-row anchor view that gets deleted by the menu's own action, or is the canvas-level / parent-level menu attachment the only correct pattern? 3. Are there any post-tracking notifications or APIs that guarantee AppKit's cleanup is complete before the anchor view is allowed to be torn down (so a per-row anchor could be made safe with the right ordering)? Thanks!

On devices configured to use the Buddhist calendar (primarily Thai users) Transaction.currentEntitlements returns an empty async sequence even when the customer holds a legitimate, non-revoked, non-expired entitlement for a non-consumable in-app purchase or subscription. The same transaction is correctly returned by Transaction.all. Switching the device calendar back to Gregorian immediately restores correct behavior: the entitlement is yielded by currentEntitlements again. No reinstall, sign-out, or AppStore.sync() is required. The defect is purely client-side, deterministic, and reproducible at will. Is this a known bug introduced in iOS 26? It is causing me significant problems with in-app purchase validation and restore flows in that market. Is anyone else experiencing this issue?

Hi everyone, We are currently experiencing a strange issue with our PWA on iOS and I wanted to ask if anyone has seen something similar before. Setup Around 1,200 active users ASP.NET backend/server PWA hosted on a subdomain: user.PLACEHOLDER.de The app has two main areas: User area: /User Admin area: /Customers Most users install the PWA normally through Safari using “Add to Home Screen”. The Problem The issue only happens on iOS when the app is installed as a real PWA. Steps to reproduce: Admin opens the installed PWA Admin navigates to the admin section (/Customers) Admin closes the PWA while still being inside /Customers When the admin reopens the app, the entire app is broken and nothing works anymore However: If the admin navigates back to the normal user area (/User) BEFORE closing the app, everything works fine The issue only happens if the app is closed while inside /Customers At this point, the only fix is: uninstall the PWA reinstall it login again The Weird Part If the user only adds the website icon to the home screen WITHOUT installing it as a standalone PWA, everything works perfectly. So the issue seems to happen specifically in iOS standalone PWA mode. Additional Notes Only happens on Apple/iOS devices After latest IOS-Update Android works perfectly Has anyone experienced something similar or knows what could cause this behavior? The cookie settings in ASP.NET: options.Cookie.Domain = ".PLACEHOLDER.de"; options.Cookie.IsEssential = true; options.Cookie.HttpOnly = true; options.Cookie.SameSite = SameSiteMode.None; options.Cookie.Path = "/"; options.Cookie.Name = ".AspNet.SharedCookie"; options.Cookie.SecurePolicy = CookieSecurePolicy.Always; EDIT: I currently suspect that the issue is related to cookies/session handling, but I’m not sure. Unfortunately we cannot properly debug iOS because we only have Windows devices available. The mainfest.json: { "manifest_version": 3, "name": "Name", "short_name": "Name", "description": "Buchen von Kursen", "icons": [ { "src": "/images/192x192.png", "sizes": "192x192" }, { "src": "/images/512x512.png", "sizes": "512x512" } ], "display": "standalone", "start_url": "https://user.PLACEHOLDER.de/User", "scope":"/", "content_scripts": [ { "js": [ "service-worker.js" ] } ] }

Hi, I submitted ARIA Life (iOS, Version 1.0) on May 4th. It has been stuck in “Waiting for Review” for 5 days with no status change and no emails from Apple. Current average wait time for May 2026 is under 9 hours per live data. I submitted an expedited review request today which was confirmed approved, but the status has still not changed. No messages in Resolution Center, account is in good standing. Is anyone from Apple able to help or has anyone experienced this recently?

Is there any iOS API, framework, or entitlement (public or beta) that lets an app detect when a user disables or removes a Configuration Profile (specifically a DNS-over-HTTPS profile) — without VPN extension, MDM, or supervised mode? Use case: I need to know server-side, in real time, when the user toggles off a .mobileconfig DoH profile they previously installed. Things I've already reviewed and ruled out: NetworkExtension (NEDNSSettingsManager — only fires while app is running) BGTaskScheduler (iOS-scheduled, not real-time) NEFilterDataProvider (requires supervised) VPN / MDM / supervised Anything I'm missing?

Vox Dictum (macOS) submitted for review on May 4, still showing 'Waiting for Review' after 5 days. Support case 20000112075878 raised on May 8 with no response yet. First submission, includes auto-renewable subscriptions. Is this timeline normal for a first macOS app with subscriptions? Thank you, M

Hi all, Reporting an active production issue in case anyone else is seeing the same pattern, or has insight into what could cause this. Symptom As of 2026-05-09 morning, one specific auto-renewable subscription product is silently absent from Production StoreKit responses on our live App Store build. The product is still 'Approved' in App Store Connect, all metadata is intact, no error code is returned — the product simply does not appear in the products array. The other 3 products in the same subscription group continue to work normally. 100% of production users are affected. Setup App: live on App Store, version 1.0.0 (build 8) Subscription group with 4 auto-renewable products: standard_monthly_799 ✅ returns correctly standard_annual_6999 ✅ returns correctly unlimited_monthly_1299 ❌ MISSING from production response unlimited_annual_9999 ✅ returns correctly SDK: purchases_flutter (RevenueCat) → StoreKit Same physical device, same code, same RC config behaves correctly in Sandbox — all 4 products are returned and a sandbox purchase of unlimited_monthly_1299 succeeds. Timeline 2026-05-08: working correctly, purchases succeeding normally 2026-05-09 morning: product silently disappears from production StoreKit responses No app update was submitted between those dates No App Store Connect changes were made Onset was simultaneous across all production users at one timestamp What I've verified App Store Connect: Product status: Approved All territories enabled, all prices configured (no N/A in any territory) Subscription group correctly contains all 4 products No 'Submit for Review' pending changes Product attached to live app version 1.0.0 (8) Tax category: Match to parent app Family Sharing: Off (consistent with the working products) Paid Applications Agreement: Status: Active Banking and Tax forms: Active RevenueCat dashboard: All 4 products show Store Status: Approved Default offering contains all 4 packages iOS attachment for the affected product is intact No warnings or sync errors Sandbox StoreKit (today): flutter run (debug) on physical device → all 4 products returned flutter run --release on physical device → all 4 products returned Sandbox purchase of unlimited_monthly_1299 succeeds Production StoreKit (today, broken): App Store-downloaded 1.0.0 (8) on multiple users' devices Multiple Apple IDs / multiple devices / multiple regions — all reproduce Only unlimited_monthly_1299 affected; other 3 products fine Why this looks server-side Sudden simultaneous onset across all users No code or config change preceded onset Sandbox unaffected, only Production affected Single product affected, not the whole subscription group or app No error returned — silent omission only Cannot reproduce with locally signed builds, only with App Store-distributed binary This pattern is consistent with a server-side product indexing or fronting issue specific to one product in Production StoreKit. As a developer I don't have visibility into Apple's product-serving infrastructure to investigate further — looking for guidance from anyone who has seen this before. Questions for the community Has anyone else seen a single auto-renewable subscription silently drop out of Production StoreKit responses while remaining Approved in ASC, with no error code returned? Is there any internal product-state flag (beyond what's exposed in the ASC UI) that could cause Production StoreKit to silently omit a product? Anything similar to a hidden 'review hold' or 'price tier reconciliation' state? Has the asymmetry between RevenueCat package identifiers (Standard uses RC's $rc_monthly/$rc_annual default identifiers, Premium uses custom premium_monthly/premium_annual identifiers) ever been implicated in this kind of failure? RC support has been notified, but worth asking publicly. For anyone who has resolved a similar issue: what action ended up clearing it — ASC re-save, RC re-sync, Apple Support escalation, or did it self-resolve after Apple-side cache propagation? Filings in progress ASC Contact Us ticket: filed Apple DTS technical incident: filed RevenueCat support ticket: filed Feedback Assistant report: in progress Will update this thread with the resolution path once we have one. Thanks, — Kin Pong Lo (developer, Alice: AI English Tutor)

I want to register a Sandbox account, that it. Please Apple fix this.

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. Symptom The same APNs notification displays the correct time on iPhone Notification Center and on the initial Apple Watch banner. After the Watch screen turns off and the user later opens Notification Center on Apple Watch, the same notification may show an incorrect relative timestamp such as "3 hours ago" or even "yesterday". The drift is per-notification and persists for that notification until it's dismissed. iPhone NC always shows the correct time. WhatsApp tested side-by-side on the same iPhone/Watch pair does not show this drift. Setup iOS 26.4.2 on iPhone 16 Pro watchOS 26.4 on Apple Watch Series 10 App with paired Apple Watch A UNNotificationServiceExtension that decrypts E2EE message previews and applies Communication Notification enrichment via INSendMessageIntent and content.updating(from:) Production APNs environment, TestFlight builds No beta software Isolation tests already performed Test mutable-content NSE invoked Drift on Watch NC Minimal APNs (alert + sound only) no no no drift NSE skips content.updating(from:), INInteraction.donate/delete (still calls them as no-op via diagnostic build) yes yes — modifies content drift NSE bypasses ALL Intents/Communication Notification APIs (no INPerson, no INSendMessageIntent, no avatar, no updating(from:)); just modifies title/body/sound/category and returns the mutable copy yes yes — modifies content drift Production-like APNs payload (thread-id, target-content-id, category, sound, badge, custom userInfo) but WITHOUT mutable-content no no no drift Eliminated as causes: content.updating(from:), INSendMessageIntent, INInteraction.donate, INInteraction.delete(with:), INPerson/INPersonHandle (not even constructed in test 3), avatar fetching, thread-id, target-content-id, category, sound, badge, custom userInfo, custom createdAt timestamp, stale Siri/Apple Intelligence history (cleared manually on iPhone and Watch). The pattern The only consistent variable distinguishing the no-drift cases from the drift cases is whether mutable-content: 1 is set on the APNs payload (i.e. whether the UNNotificationServiceExtension is invoked). Once invoked, the extension's behavior with respect to Communication Notifications does not seem to affect the outcome — the drift reproduces even when the NSE only modifies title/body/sound and returns. Questions Is there a known watchOS behavior where notifications processed by a UNNotificationServiceExtension use a different timestamp source on Apple Watch Notification Center after the Watch screen has been turned off and reopened, while the initial Watch banner and iPhone Notification Center show the correct delivery time? Are there specific UNMutableNotificationContent properties or APNs payload flags that should be preserved (or avoided) when returning content from an NSE to keep the Watch NC timestamp consistent with the delivery time? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? Happy to provide an anonymized snippet of NotificationService.swift and the APNs payload format if useful. Thanks.