“iPhone 16 pro”

-It is the iPhone not receiving the notification to update. Steps to reproduce Change property on Mac iPhone app is active, no changes received (even after 2 hours) Swipe to home screen on iPhone open iPhone app SwiftData syncs on iPhone and shows changes that were made on the Mac (Again, this worked 48 hours ago, and the only change that was made was updating all devices to iOS26.4)

I've been working with the new Swift Vision API's RecognizeTextRequest on iOS 18 and hit this exact deadlock. After profiling with Instruments, I found that the Vision framework internally uses a limited thread pool for its neural engine requests — on most devices this caps at 2 concurrent ANE inference sessions. The workaround I'm using is a semaphore-based concurrency limiter that queues requests: actor OCRPipeline { private let maxConcurrent = 2 private var running = 0 private var pending: [CheckedContinuation] = [] func recognizeText(in image: CGImage) async throws -> [String] { await acquireSlot() defer { Task { await releaseSlot() } } let request = RecognizeTextRequest() let handler = ImageRequestHandler(image) let observations = try await handler.perform(request) return observations.compactMap { $0.topCandidates(1).first?.string } } } This keeps throughput high while never exceeding the 2-concurrent-request limit. In my testing across iPhone 15 Pro and iPad Air M2, this processes ~

This issue happens in the latest iOS 17, 18, and 26 simulators. I have not tested older simulators like iOS 15 or 16. I am using Xcode 26.4 (17E192), Simulator 16.0 (1063.2) (SimulatorKit 955.7, CoreSimulator 1051.49) and macOS Tahoe 26.4.

Same issue here — DSA In Review since February 13, 2026 (41 days). App blocked in all 27 EU countries. Two support requests submitted, no response. Phone callback not available for this topic. Case ID: 102848525554 Posted a separate thread as well. Has anyone found a resolution?

Thanks for the response, for context it was around 15 submissions over a few months and 30ish messages. I get your example, but I think my situation’s a bit different. The updates weren’t just micro changes trying to slip something through, there was a mix of both small tweaks and broader changes. The issue was the feedback stayed very generic (“overtly sexual”) without pointing to specific elements, so each update was essentially a best guess at what might be triggering it. Especially early on, when only metadata was flagged, I assumed the issue was relatively minor. By the end, I actually went in the opposite direction of evasion & submitted a build with everything unlocked and included screenshots showing all content upfront, so review had full visibility, as requested during a phone call. It’s possible I missed a couple of screenshots in earlier messages, but nothing was intentional. That’s why the 3.2(f) decision caught me off guard, there was no intent to hide or mislead, just trying to int

I’ve also spent some time investigating this. While monitor mode works, setting the channel using CoreWLAN’s [CWInterface setWLANChannel:error:] API does not behave as expected. As a result, capturing isn’t reliable for third-party apps on Macs with the Apple N1 Wi-Fi chip or the MacBook Neo. I've identified and submitted two issues: FB22295165: [CWInterface setWLANChannel:error:] does not work on a disassociated interface, even though the documentation indicates it should, and it behaves correctly on older Macs. FB22295685: Once in monitor mode, [CWInterface setWLANChannel:error:] reports a successful channel change and the interface reflects the requested channel, but capturing continues on a different channel (usually the channel the interface was operating on previously to being placed in monitor mode). There also appears to be a race condition between entering monitor mode and macOS attempting to rejoin a network shortly after calling [CWInterface disassociate]. While I can’t confirm this definitively, t

Thanks Albert. The AASA is publicly accessible with no blocking, no IP filtering, and no user agent restrictions: https://fanarchy.fans/.well-known/apple-app-site-association Apple's own CDN already has the current version synced: https://app-site-association.cdn-apple.com/a/v1/fanarchy.fans So the AASA sync is working — the issue is the experiences stuck in Received and not transitioning to Published. We're also seeing inconsistent behavior across devices. QR code scans for the same URL work on some devices but show App Clip not available on others. For example, it works on an iPhone but fails on an iPad — same URL, same network, both fresh devices that have never had our app installed. Interestingly, when we removed /next-game from the App Clip entry in our AASA, QR codes started falling through to Safari where our Smart App Banner meta tag (apple-itunes-app with app-clip-bundle-id) successfully triggers the App Clip card. This workaround is functional but shouldn't be necessary. We have other App

Hey @THeberlein, This is unexpected behavior. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. I'd greatly appreciate it if you could open a bug report; please include a link to your webpage and a sysdiagnose from your Vision Pro captured after this occurred, and post the FB number here once you do. Instructions on capturing a visionOS Sysdiagnose can be found on the Profiles and Logs webpage. Bug Reporting: How and Why? has tips on creating your bug report. Thanks for your help, Michael