“DTiPhoneSimulatorErrorDomain Code 2”

To the App Review and Developer Support Teams, I am writing this post to bring an ongoing and critical issue to your attention, as standard support channels have failed to provide any resolution or clear communication. Issue Summary: My application’s last two versions have been successfully reviewed and approved. However, three In-App Purchases remain stuck in the review process. Lack of Communication: I have opened several support cases regarding this delay, yet I have received no response or actionable feedback. The lack of synchronization between the App Review and Support teams is causing significant operational disruptions. The current communication gap and the slow response times are directly impacting my business and user experience. Impact: It is unacceptable to have a live application with Pending monetization features for such an extended period. This delay is causing financial loss and preventing my users from accessing the services they need. Request: I request an immediate update on the

Hello App Review Team, My app update has been stuck in Waiting for Review for 8+ days with no progress. Previous submissions for this app were reviewed within 24–48 hours, so this delay is unusual. Apple ID: 1666011539 Bundle ID: art.dreamerai.ios Version: 1.62.0 Submitted: May 20, 2026 Status: Waiting for Review We have already tried every available channel: 2 Expedited Review requests submitted — both ignored, no progress Emailed App Review asking for status — no reply This is a major update with critical bug fixes and major new features that our existing users are actively asking about. Our marketing campaign around the launch has already been delayed because of this hold. The build is fully compliant with the Review Guidelines — no new entitlements, no new SDKs, no changes to data collection. Happy to provide any additional info needed. Any help from the App Review team would be greatly appreciated. Thank you.

Hi all — looking for any escalation path for two production-impacting submissions currently stuck in WAITING_FOR_REVIEW. Both apps' live App Store versions are broken for 100% of users; the submissions contain minimal, scope-limited fixes (no new APIs, entitlements, data collection, or UI). The Android equivalents are already live and verified working. MeetingMind: AI Note Taker (Apple ID 6757317991) — v6.1.2 / build 49, submission ID f88195d3-6c35-4e6d-a7a9-6f34b44bf0e7. Waiting since 2026-05-24 (3+ days). Bug: outbound phone calls fail to relay audio from the called party to the caller. Fix: ~5 lines in VoipService.swift. ReadAloudAI: Voice Reader (Apple ID 6757346255) — v7.9.1 / build 38, submission ID 21f4510f-4690-4d15-b559-437f89e037ca. Waiting since 2026-05-26. Bug: backend Cloud Run URLs retired, text-to-speech (core feature) fails for all users on v7.9 and earlier. Fix: configuration-only URL migration to Fly.io. Already done: expedited review filed via the contact form earlier today (no ack

[Also submitted as FB19313064] The .disabled() modifier doesn't visually disable buttons inside a ToolbarItem container on iOS 26.0 (23A5297i) devices. The button looks enabled, but tapping it doesn't trigger the action. When deployment target is lowered to iOS 18 and deployed to an iOS 18 device, it works correctly. It still fails on an iOS 26 device, even with an iOS 18-targeted build. This occurs in both the Simulator and on a physical device. Screen Recording Code struct ContentView: View { @State private var isButtonDisabled = false private var osTitle: String { let version = ProcessInfo.processInfo.operatingSystemVersion return iOS (version.majorVersion) } var body: some View { NavigationStack { VStack { Button(Body Button) { print(Body button tapped) } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) Toggle(Disable buttons, isOn: $isButtonDisabled) Spacer() } .padding() .navigationTitle(Device: (osTitle)) .navigationBarTitleDisplayMode(.large) .toolbar { ToolbarItem { Button(Toolba

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRend

This is a long post, so let me start with a summary: I am attempting to implement what ought to be a simple SwiftData migration, and am receiving the following fatal error from the ModelContainer initializer: NSCocoaErrorDomain Code=134504 Cannot use staged migration with an unknown model version. The crash occurs both in the Simulator and on a physical device. Both the original schema and the new schema load and run as expected if loaded from scratch — so I conclude the Models are OK; it is the migration from the original schema to the new schema which is the issue. I have reported this as FB22652791 and Technical Incident Case # 19893980. I have two model projects available — one contrived, the other using my actual SwiftData models. Now the Details I am developing a SwiftUI/SwiftData app. I am (currently) using Xcode 26.5-beta-3. I set up an alpha-test build using the following approach: public class DatabaseSchema { public let dbSchema: Schema = Schema([ Model1.self, ... , Model16.self ]

Hello Apple App Review Team, I am writing to urgently request your assistance regarding our application 'Kavra'. We are facing a critical situation that is heavily impacting our entire launch roadmap and user base. To give you the timeline: we initially submitted the app for review on April 30th. After waiting for two full weeks without any updates or status changes, we assumed there might be a technical stall in the review pipeline. Consequently, we canceled the submission and resubmitted the app on May 14th. Today is May 27th, and the application has been stuck in the Waiting for Review status for another 13 days. In total, we have been locked in the review queue for nearly a month. This prolonged delay has completely frozen our development cycle and disrupted our time-sensitive marketing plans. We have thoroughly audited our app against all App Store Review Guidelines and confirm 100% compliance. There should be no blockers from our end. If you require any additional information, test accounts, or

I'm trying to use a sandbox account, and am stuck on the verification stage. My primary number (my personal iPhone phone number) has been used too many time, as I've used it to set up many devices. My personal mobile number is tied to a physical SIM in my iPhone 12 Pro. Now I'm trying to use a Freedom Mobile eSIM, and can successfully send and received texts to/from myself, other people, to/from Freedom Mobile as well. Setting up the sandbox account (my email address with a +3 at the end of it) I choose USE A DIFFERENT NUMBER and my eSIM number is shown along with my Freedom description of the eSIM right below it. The Verification Code page appears, but I never get a verification code. I click on DID NOT GET A VERIFICATION CODE? and try trigger a phone call and do not get that either. I've reset my eSIM, I've reset my iPhone's networking, I've rebooted my phone many times, I've un/re-installed the app and TestFlight. I'm willing to try anything here, but is it possible because my pe

[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button(Button 1, systemImage: 1.square.fill) { print(Button 1 tapped) } // ✅ Hit target is entire button Button { print(Button 2 tapped) } label: { Label(Button 2, systemImage: 2.square.fill) } // ❌ Hit target is smaller than

Hi, We operate several iOS apps that use APNs through the HTTP/2 provider API. Since around May 12, we have observed a significant drop in APNs HTTP/410 “Unregistered” responses across multiple apps / bundle IDs. There have been no relevant changes on our side around that time. Our APNs integration, request flow, credentials, and push token handling have remained unchanged. What makes this more confusing is that App Store Connect does not show a corresponding drop in app deletion events for the same apps and time period. In other words, the app deletion trend appears stable in App Store Connect, but APNs 410 “Unregistered” responses dropped sharply. We understand that APNs does not guarantee an immediate 410 response after an app uninstall, and that the exact token invalidation timing is not documented. However, the aggregate change in 410 response volume is large enough that it looks like a behavior change. Questions: Has there been any recent APNs behavior change around when device tokens are marke