“DTiPhoneSimulatorErrorDomain Code 2”

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.addOutpu

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. Whe

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

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,

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 +

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?