“iPhone 16 pro”

Same issue for me as well and my ability to test on a real device is totally blocked and has been actually since some time back in Nov.! Xcode 26.3 iOS 26.3.1 watchOS 26.3 Watch was paired to Xcode but would never connect due to the same tunneling errors mentioned by others. After unpairing via Xcode Devices and Simulators the watch cannot be repaired even though I have unpaired and repaired it with iPhone and unpaired and repaired the iPhone to Xcode. NOTHING will cause Xcode to find the watch again. Damn it Apple this crap has been an ongoing issue since Xcode 26.0 How do you have 3 dot releases and not fix something like this?! Might have gotten the watch re-connected via another suggestion in higher up in this thread to connect mack to iPhone via Hotspot. I can see the watch again in Devices and Organizers, but the setup is taking foreeeeeevvverrr so not sure what happen when I switch the mac back to regular wifi.

I always had next console messages after first app hide (even in empty project): 0.5 Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context. 0.5 Metadata: Process: TestError | Library: AXCoreUtilities | Subsystem: com.apple.Accessibility | Category: AXCommon I changed toggle on iPhone: Settings -> Accessibility -> Read & Speak -> Speak Selection (from ON to OFF) and messages disappeared. Hope it will help someone.

Thanks for your post and your question. If it were possible to restrict a user from downgrading an app, how would that impact the user experience at the App Store level? How would this be perceived by users? App Store policies and the iOS system design mandate that users have ultimate control over their subscriptions. If you are selling storage, you will likely be utilizing Auto-Renewable Subscriptions. Even if you hide the downgrade option inside your app's UI, the user can always go to their iPhone's Settings > Apple ID > Subscriptions and select a lower-tier plan. Because you cannot prevent the downgrade, I would recommend you to handle the scenario gracefully within your app's logic. I would recommend you to look at all the technical resources available to you to make sure the downgrade is possible including if you must create a new storage and move the existing data. However, your backend and app logic must still be prepared for the user to bypass your UI and downgrade via their Apple ID s

Having a similar problem, although I'm not sure if it's related to iOS26 or phones with the U2 chip. I am doing peer to peer rather then peer to object, but figured I'd share my findings. iPhone 16 Pro (U2 chip), iOS 26.3.1: NISession created — capabilities: token: true supportsDirection: false supportsCameraAssistance: true supportsExtendedDistanceMeasurement: true supportsPreciseDistanceMeasurement: true iPhone 12 (U1 chip), iOS 18.6.2: NISession created — capabilities: token: true supportsDirection: true supportsCameraAssistance: true supportsExtendedDistanceMeasurement: false supportsPreciseDistanceMeasurement: true What I've found so far: 16 Pro / U2 / iOS 26 (?) 3D direction vector is never available Camera seems to be required for directional convergence Everything seems to be determined by hAngle Seems to start an NI session with dirSrc as 'none' and then resolves to 'hAngle' after camera convergence is complete 12 / U1 / iOS 18 Seems to start an N

Having the same problem, although I'm not sure if it's related to iOS26 or phones with the U2 chip. Worth noting that I am doing peer to peer rather then peer to object, but figured I'd share my findings. iPhone 16 Pro (U2 chip), iOS 26.3.1: NISession created — capabilities: token: true supportsDirection: false supportsCameraAssistance: true supportsExtendedDistanceMeasurement: true supportsPreciseDistanceMeasurement: true iPhone 12 (U1 chip), iOS 18.6.2: NISession created — capabilities: token: true supportsDirection: true supportsCameraAssistance: true supportsExtendedDistanceMeasurement: false supportsPreciseDistanceMeasurement: true What I've found so far, at least the case of the 16 Pro / U2 / iOS 26 (?): 3D direction vector is never available Camera seems to be required for directional convergence Everything seems to be determined by hAngle Placing both a 16 Pro and a 12 face down on a table with rear cameras covered: 12 continues t

Hello - It appears that your app's two IAP subscriptions (the Pro Monthly and the Pro Annual) were approved by App Review on March 13, 2026 and should be live in your app at this time. Please let us know if you need anything else. Thank you.

Thanks for the post, very interesting you went to an approached that will create a duplicate app instead of localization. I would actually focus on the reason you can’t localize in another language as that API has been proven to be great. I think we should focus on that. Apple’s automated systems and human reviewers are trained to flag apps that look and function similarly to existing apps. I believe the primary goal is to keep the App Store clean the preference is that a single app supports multiple languages and features, rather than having separate apps for different regions or languages. I think on the final result having 2 apps on the same region with different languages. If both apps are available in the same region that could be a really bad experience for the users. Let’s focus on the reason you can’t localize. Localization isn't just translating words; it's adapting the software. Developers extract all hard-coded text in the app and put them into a file called. The app then pulls the correct language

Similar issue here when starting an ARSession. iOS 26.3.1 on an iPhone 16 Pro. No issues running the same app on an iPhone 12 on iOS 18.6.2 `(Fig) signalled err=-12710 at <>:601 <<<< FigXPCUtilities >>>> signalled err=-17281 at <>:308 <<<< FigCaptureSourceRemote >>>> Fig assert: err == 0 at bail (FigCaptureSourceRemote.m:569) - (err=-17281)`

[quote='880167022, parker9, /thread/810258?answerId=880167022#880167022, /profile/parker9'] GitHub has the actual source for that version in Releases [/quote] OK. I downloaded the app, the .dSYM, and the source code and took a look. First, the crash report has this: Binary Images: 0x102c6c000 - 0x102c9ffff DIM arm64 <3e247524da7930099f63cd12ace4ab0e> …/DIM I used dwarfdump to confirm that I have the right .dSYM: % dwarfdump --uuid DIM.app/Contents/MacOS/DIM UUID: 7A4DAC69-55A2-3D1B-B9E0-6A14AB2D5EEA (x86_64) DIM.app/Contents/MacOS/DIM UUID: 3E247524-DA79-3009-9F63-CD12ACE4AB0E (arm64) DIM.app/Contents/MacOS/DIM I then symbolicated those frames: % atos -l 0x102c6c000 -o DIM.app.dSYM 0x102c799bc 0x102c8b4d4 closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207) thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28 Plugging that into the backtrace, I get this: Thread 1 Crashed:: Dispatch queue: com.apple.root.utility-qos 0 DIM … 0x102c6c000 + 55740 closure #1 in ViewControl