“DTiPhoneSimulatorErrorDomain Code 2”

Adding another data point — same symptoms, same lack of resolution. Sharing here in case the pattern helps Apple eventually acknowledge this as a systemic issue. App: ZenTerm (App ID 6760935103, Bundle ID com.zenterm.mobile) Released: 2026-03-31 (45 days ago) Status: Ready for Sale (1.3.2 live) Developer: Individual Symptoms (matches Brutal Time exactly) App Store search for the exact name zenterm → zero results, 45+ days running iTunes Search API (https://itunes.apple.com/search?term=zenterm&country=jp) returns my app correctly Direct App Store URL https://apps.apple.com/jp/app/zenterm/id6760935103 works fine Apple Search Ads campaign creation flow cannot find my app either — neither by name search nor by pasting the canonical App Store URL v1.3.2 (released 2026-05-06, with all third-party trademarks proactively removed from keywords) has now been live for 9 days — no change in search visibility Apple Support response so far Date Action Result 2026-04-11 First written inquiry Templated reply: we don't gu

Thanks for the precise framing — answering each in turn. Q1 — Bayer RAW capture through AVFoundation: Yes, third-party apps can capture Bayer RAW through AVFoundation. Both Bayer RAW and Apple ProRAW formats appear in AVCapturePhotoOutput.availableRawPhotoPixelFormatTypes. The recommended way to discriminate them is through the static query methods: AVCapturePhotoOutput.isBayerRAWPixelFormat(_:) AVCapturePhotoOutput.isAppleProRAWPixelFormat(_:) Apple ProRAW is opt-in: confirm photoOutput.isAppleProRAWSupported, then set photoOutput.isAppleProRAWEnabled = true. With ProRAW disabled, availableRawPhotoPixelFormatTypes exposes only Bayer formats; enabling ProRAW adds the ProRAW format to the same array. Device and format restrictions: Apple ProRAW: iPhone 12 Pro / Pro Max and later Pro models (iOS 14.3+). Bayer RAW: broadly available on devices that support RAW capture. Some virtual / fusion capture devices (for example, multi-cam) may not expose Bayer RAW because there is no single sensor providing the Bayer mos

Thanks for the thorough investigation — using Console.app to pinpoint the gating decision at assetsd (Checked all submitted library bundles. Result: NO with iCloud Photos on, versus YES with it off) is exactly the diagnostic level engineering needs. Based on the public API documentation, the observed behavior doesn't match the framework's documented design. The Uploading asset resources in the background article and the documentation for setUploadJobExtensionEnabled(_:) enumerate two preconditions for the extension to run: full photo library authorization, and registration of the extension point com.apple.photos.background-upload. Neither mentions iCloud Photos. The stronger signal comes from the documented description of PHAssetResourceUploadJob.Type.upload: An upload job type (will download the resource from iCloud if required, then upload). That description is only meaningful if iCloud Photos can be enabled — the framework is explicitly designed to handle the case where photo assets are stored in

Quick update with results from a diagnostic build I ran on iOS/watchOS 26.5. To validate the distinction you described between the NSE-returned content path and the locally posted notification path, I shipped an internal TestFlight build where the NSE additionally posts a local UNNotificationRequest via UNUserNotificationCenter.add() in parallel with the standard contentHandler() call. The local notification uses the same title and body as the NSE-returned notification, except for a [L] prefix in the body and a local-z- identifier prefix. The same [L] marker is visible on iPhone and Apple Watch, so the local-route notification can be reliably matched across both devices. Test protocol: Send a message with a known timestamp in the body, for example Timestamp 00:19 Wait for delivery on Apple Watch Turn the Watch screen off Wait approximately 2–3 minutes Wake the Watch and open Notification Center Result on Apple Watch, using iOS 26.5 + watchOS 26.5: Local-route notification, [L] Timestamp 00:19: correc

Adding my experience here as well. I started getting the same 7000 error code randomly two days ago during notarization. It seems to be triggered with larger builds. I tested out notarizing a small 8kb file, and that took 25 minutes, which is much slower than expected but eventually succeeded. My actual applications are around 500mb, and those either hang forever, or result in the 7000 Team is not yet configured for notarization error. I'm blocked on publishing any new app updates.

FYI: // // ContentView.swift // XRSandbox // // Created by Andy Wyatt on 3/15/26. // import SwiftUI import RealityKit struct ContentView: View { private let rootEntity = Entity() var body: some View { RealityView { content in content.add(rootEntity) } update: { content in updateARState(&content) } .ignoresSafeArea() .onAppear() { configureVirtualCamera() rootEntity.addChild(makeThing()) } .onTapGesture { spinThing() } .overlay { overlayView } } //MARK: - overlay with toggles at bottom @State private var arToggleState: Bool = false @State private var showARView: Bool = false @State private var perspectiveCameraInAR: Bool = false private var overlayView: some View { VStack { Spacer() VStack { Toggle(Enable AR, isOn: $arToggleState) .onChange(of: arToggleState) { handleARToggle() } // If PerspectiveCamera is in the RealityView entity heirarchy // the content is anchored to the screen rather than the floor Toggle(Keep PerspectiveCamera in AR, isOn: $perspectiveCameraInAR) .disabled(arToggleState) // can only

Sorry for my slow response. I just created FB22780449 with the source code of my simple test project. Please see my comments in that post about the content sometimes not appearing where expected when returning from AR, and sometimes not finding an anchor when going in&out&in&out&in&out&in&out of AR like a squeezebox. (c;

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. I'm not aware of any issue like this, and the general behavior you’re describing sounds like a bug. Have you filed a bug on this and, if so, what's the bug number? Also, what system versions are you seeing this on and have you seen it on watchOS 26.5? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? In theory, what you're doing should just work. More specifically, by design, your extension doesn't control the time data of the notification you're returning, so what actually happens is that the UNNotificationContent your extension returned is immediately embedded into a newly created UNNotification object, which is then processed normally. How that would end up creating the situation you're describing is something I can't explain. However, this i

Thank you for the reply, Travis. To clarify, I have beta updates off, so this is occurring on the public release, macOS tahoe 26.5. The core issue is the system bypassing the 80% limit without any user notification. This is exactly why I’m suggesting the hardware-level 'Pulsing' indicators for MagSafe 4—to bridge the gap when the software fails to communicate these discrepancies. Please consider MagSafe 4, to make communicating any issues unmistakable. i am in the right place for this, as i am trying to develop the magsafe wire, and is a 2-in-1, feedback and development, so please consider this as a development for over 100 million macbook users. Thanks Alyaman

This isn't inexperience on your part — you've already done the hard work of getting each piece running individually. There isn't a public Apple sample covering your exact stack (MTKView + custom Metal renderer + SKRenderer + TCTouchController). The Touch Controller framework shipped at WWDC 2025, its public video coverage is limited to a brief mention in session 209 (Level up your games), and the framework documentation doesn't list any sample code project. That said, the pattern you're describing — individual pieces working, but the controls not drawing reliably when composed with a custom Metal + SpriteKit pipeline — is typically one of two things: a pipeline-state mismatch between TCTouchControllerDescriptor and the MTLRenderCommandEncoder you pass to render(using:), or an unset drawableSize on the touch controller. Both are worth ruling out first. Looking at the framework source, TCTouchController builds its internal Metal render pipeline state once at initialization, from the descriptor

Running a test comparing the overhead between regular open and what we do in anka: ❯ ./run.sh Creating sparse APFS image with hdiutil (2048 MiB cap, volume BenchAPFS) → /Users/nathanpierce/apfs-open-repro/disk.dmg created: /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage Note: hdiutil wrote /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage (-type SPARSE uses .sparseimage beside the requested name). Done. Image stats: -rw-r--r-- 1 nathanpierce staff 10M May 14 13:55 /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage clonefile(2): /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage → /Users/nathanpierce/apfs-open-repro/disk_clone.dmg Clone stats: -rw-r--r-- 1 nathanpierce staff 10M May 14 13:55 /Users/nathanpierce/apfs-open-repro/disk_clone.dmg ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Original sparse image ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ === Phase 1: bare open(2) / close (baseline) ==