“iPhone 16 pro”

Hello everyone, I am an iOS developer based in South Korea, and I’m currently experiencing an unusual App Store review delay that I have not been able to resolve through the normal support channels. My app has been stuck in “Waiting for Review” for more than two weeks, and there has been no progress at all during this time. It has not moved to “In Review”, and I have not received any rejection message or request for additional information from the App Review team. App Information Platform: iOS App Name: WOOTA Apple ID: 6759412826 Status: Waiting for Review Submission Date: February 20, 2026 Developer Account Region: South Korea What I Have Already Tried: I have already attempted the following steps: Submitted an inquiry via App Store Connect → Contact Us → App Review Received a response from Developer Support saying they understand my concern and that they contacted the review team However, since then there have been no updates at all. The app status remains “Waiting for Review”, and there are no messages in

We are an App Developer for past 16 years so have seen a lot happen with App Review over the years (even back when 2 month review times were the norm). However, we have all come to expect app review to take only 48 hours typically. We submitted several macOS Tahoe updates in Feb all approved within 24 to 48 hours, but 2 updates submitted on 25th Feb are stuck in 'waiting for review'. Very strange indeed and checking this forum, it seems many other devs are having the same issue, but from way earlier than us. Is this a known issue currently? I suspect their are different app review queues by region and maybe even app category and popularity of the app, but even accounting for all that, this is unusual. There seems to be no logic to which apps are approved same day vs those kept stuck in 'waiting for review'.

Hello, I've been searching online for ways to remedy this issue for the past 3 days and this is my last resort. The Issue Build on device fails to connect to the device. The prompt will permanently be stuck loading in that screen. Finder is able to connect to the device, just that Xcode is unable to. Xcode does prompt for passcode on the device, and I have entered it accordingly. I note that i AM on VPN, but even disabling VPN and turning off Wifi does not fix the issue. This was working until several days ago. Not sure what the issue is. Fixes Attempted Tried with a different cable, and USB ports Tried with different devices (multiple devices both iPad and iPhone has the same issue) Turn Off and On developer mode on devices. Clear Trusted Computers on devices. Updating both devices to the latest iOS version. Quitting Xcode Clearing derived cache Restarting Macbook Updating to the latest iOS version on Macbook Reinstalling Xcode toggling signing certificates I was trying other fixes like pkill usbmux

As stated in the title, my device is M4 macmini, running macOS 26, with Xcode version 26.1. The error message is : retrying debugserver without secure proxy due to error: Error Domain=com.apple.dtdevicekit Code=811 UserInfo={NSUnderlyingError=0xc42b07930 {Error Domain=com.apple.dt.MobileDeviceErrorDomain Code=-402653150 UserInfo={MobileDeviceErrorCode=, com.apple.dtdevicekit.stacktrace=, DVTRadarComponentKey=261622, NSLocalizedDescription=}}, NSLocalizedRecoverySuggestion=Please check your connection to your device., DVTRadarComponentKey=261622, NSLocalizedDescription=}, the official documentation does state that debugging is supported for devices running at least iOS 15. However, my 2019 MacBook Pro, with macOS 15.7.2 and Xcode 26.1 installed, can debug iOS 12 devices normally. The product manager has asked me to identify the issue, but I am at a loss. If anyone can provide a solution or confirm that support for iOS 12 is no longer available, we would be very grateful. Additionally, iOS 13 devices c

Hello, We're seeing a high rate of providerDidReset callbacks in production across a large user base (iOS 16, 17, 18, and 26). I'd like to understand both the correct way to handle this delegate method and strategies to reduce its frequency. Background The callback occurs across all iOS versions we support and is not isolated to a specific device or region. The callback can occur in any app state (foreground, background, inactive), however it is most dominant in the background state — particularly during VoIP push notification handling. The callback is more prevalent during long app sessions — for example, when the app has been running continuously for a day or overnight. We do not call CXProvider.invalidate() anywhere in our codebase explicitly. After providerDidReset fires, subsequent transactions fail with CXErrorCodeRequestTransactionErrorUnknownCallUUID (error code 4). Re-initializing the provider via initializeProvider() resolves this error. Our Implementation We use a singleton proxy class (Ca

I'm working on UI automation tests using XCUITest for an iOS application (iPhone). My goal is to programmatically scroll a view by a very precise number of pixels (e.g., exactly 500 points down). I understand the scroll(byDeltaX:deltaY:) method is not supported on iPhone, so I'm using the coordinate-based drag method as an alternative. Specifically, I am using XCUICoordinate.press(forDuration:thenDragTo:withVelocity:thenHoldForDuration:) to simulate a drag gesture. I calculate a start and end coordinate with a specific vertical offset in points, expecting the view to scroll by that exact amount. However, I'm observing that the resulting scroll offset is not perfectly accurate. There's a consistent error of several pixels, making the scroll amount unpredictable for precise test assertions. Is there a known limitation to the accuracy of coordinate-based dragging for simulating programmatic scrolling? Are there any alternative methods or best practices within XCUITest to achieve a more reliable

Hello, I have noticed a performance drop on SpriteKit-based projects running on iOS 26.0 (23A341). Below is a SpriteKit scene used to test framerate on different devices: import SpriteKit import SwiftUI class BareboneScene: SKScene { override func didMove(to view: SKView) { size = view.bounds.size anchorPoint = CGPoint(x: 0.5, y: 0.5) backgroundColor = .darkGray let roundedSquare = SKShapeNode(rectOf: CGSize(width: 150, height: 75), cornerRadius: 12) roundedSquare.fillColor = .systemRed roundedSquare.strokeColor = .black roundedSquare.lineWidth = 3 addChild(roundedSquare) let action = SKAction.rotate(byAngle: .pi, duration: 1) roundedSquare.run(.repeatForever(action)) } } struct BareboneSceneView: View { var body: some View { SpriteView( scene: BareboneScene(), debugOptions: [.showsFPS] ) .ignoresSafeArea() } } #Preview { BareboneSceneView() } The scene is very simple, yet framerate drops to ~40 fps as shown by the Metal HUD. Tested on: iPhone 13, iOS 26.0: framerate drops to 40 fps. Sometimes it run

Unexpected behavior encountered when scanning NFC tags. Imagine a link shortener web service where users can create lots of different URLs that are hosted on the same domain eg, https://short.com/unique-path The service has optional App Clip capability -- users can select any of their links and have the service create an App Clip for the selected link(s). Users can encode their URLs into NFC tags and have their customers scan NFC tags. Let's take just two URLs for example: https://short.com/foo https://short.com/bar The /foo link does have an App Clip associated with it while /bar does not have it. Each link has been encoded into appropriate NFC tag. Expected behavior when scanning from an iPhone: /foo -- shows an App Clip popup. /bar -- shows a Open in Safari default notification. What's actually happening /foo -- opens App Clip poput with correct metadata (title, subtitle, image) which is totally expected behavior. /bar (the one that doesn't have app clip associated with it) -- opens an App-Clip-li