Overview

Summary On iPadOS 27.0 (build 24A435), MobileSafari crashes with SIGABRT the first time the software keyboard is brought up by focusing a form field inside a web page. It happens on any website that has a text input: we reproduced it on our own web app, amazon.co.jp, Yahoo! Mail, Gmail, Rakuten, X, and two Japanese public-sector sites. No login is required to reproduce. Environment Devices: iPad mini (A17 Pro / iPad16,2) x2, plus a third iPad (reproduced on 3 devices) OS: iPadOS 27.0 build 24A435 — both the public beta and the RC build (releaseType "User"). Also reproduces after a full erase + clean install, so it is not device-state related. NOT reproducible on: iPhone (iOS 27, same build 24A435), Chrome on the same iPads, or the Xcode 27 Simulator. Steps to reproduce (no login required) Launch Safari and open any page with a login form (e.g. the amazon.co.jp sign-in page). Without logging in, kill Safari from the app switcher (or background it and go to the Home Screen). Launch Safari again; the same page is shown. Tap any text field (ID / email / password) to focus it. Safari crashes immediately. The essential condition appears to be: the FIRST keyboard activation in a freshly launched MobileSafari process is driven by focusing a form field inside WKWebView. If the keyboard has already been built once in that process (see Workaround below), the crash never happens. Crash details We collected five .ips crash reports from three devices and two unrelated websites (our web app and amazon.co.jp). lastExceptionBacktrace is identical across all five, down to the instruction offsets, so page content is not a factor. Key frames: The exception is thrown by NSISEngine (CoreAutoLayout) while -[TUIKeyplaneView prepareForSplitTransition] removes layout constraints in an inconsistent state (this split-keyplane path is iPad-only, which explains why iPhone is unaffected). The re-entrancy: Safari's AutoFill metadata round trip (WBSAutoFillJavaScriptInjectionController -> _SFFormAutoFillController beforeStartInputSession: -> TabDocument _beginAutomaticPasswordInteraction:) calls -[UIResponder reloadInputViews] from -[WKContentView _continueElementDidFocus:requiresStrongPasswordAssistance:] while -[UIKeyboard activate] is still on the stack. In all five reports, a com.apple.root.utility-qos thread is blocked in DISPATCH_WAIT_FOR_QUEUE doing dispatch_sync onto the main queue from -[UITextChecker initGlobalsWithAsynchronousLoading:] (a once-per-process initialization). Four of the five crashes occurred 1–6 seconds after process launch. After the crash, Safari itself sometimes fails to launch until you do Settings > Safari > Clear History and Website Data. Already ruled out (all verified on device) Settings > Passwords > AutoFill turned OFF: still crashes Split keyboard setting turned OFF: still crashes Full device reset + clean install of the RC build: still crashes Site-side causes: reproduces on completely unrelated sites; the crash fires before any login/auth JavaScript runs, and no page code appears in the stack Workaround (reliable, verified) Focus Safari's own address bar FIRST, so the keyboard is constructed through a native text field without the asynchronous AutoFill round trip. After that, focusing web form fields works normally for the lifetime of the process. This workaround is unavailable in SFSafariViewController / in-app browsers, where the crash also reproduces. Questions Can anyone else reproduce this on iPadOS 27.0 (24A435)? Confirmations/boosts appreciated — we want to know how widespread this is before the public rollout. Is there any site-side mitigation (markup, autocomplete attributes, JS) that prevents Safari's AutoFill round trip from re-entering keyboard construction? Standard autocomplete attributes did not help in our tests. Is this a known regression being tracked for an iPadOS 27.x update? Is there any mitigation for SFSafariViewController-based in-app browsers, where the address-bar workaround cannot be used? Filed via Feedback Assistant: FBxxxxxxxx (five .ips crash reports attached there).

App: Weight Tracker, BMI calculator App Apple ID: 1418885210 Version: 1.6.2 (4), iOS The previous build was rejected under Guideline 2.1 because the ATT prompt was not shown on a fresh install. We fixed it, replied with the requested screen recording, and resubmitted on September 23. The status changed to "In Review" on September 24 and has not changed since. The message thread is locked, so we cannot contact the reviewer. Could someone from App Review check whether the submission is stuck? Thank you.

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.

Hello, I found a visual bug in iOS 27 when using YouTube in the background. Steps: Play a video on YouTube. Lock the iPhone while the video continues playing. Long-press the Lock Screen. Before the customization menu opens, observe the YouTube media player. Issue: The YouTube media player rapidly flickers/flashes approximately 10 times before the customization menu appears. Expected: The transition should be smooth without flickering. Device: iPhone 15 iOS: 27.0.1 I can provide a screen recording if needed. Thank you.

I submitted an app on 09.22.2026, and it is still waiting to be reviewed by the Apple team. Is it normal to have to wait this long for someone to review your app. I have submitted apps in the past and it has never taken this long.

Hi, I’m training an Object Tracking reference object in Create ML using Extended training mode + All Angles for use with visionOS high-frame-rate object tracking. The training ran successfully for approximately 48 hours and reached 97.4%. At that point, Create ML automatically paused. The issue is now completely reproducible: whenever I click Resume, training runs for approximately 3 seconds and then automatically returns to Paused at exactly 97.4%. I captured the system logs while reproducing the issue. MLRecipeExecutionService crashes with: LayerVariable.swift:116: Fatal error: The new value must have the same shape as the current value ([40, 1, 3, 3]), but it has [96, 1, 3, 3]. Immediately afterwards, Create ML reports an interrupted XPC connection to MLRecipeExecutionService. Shortly before the crash, the service also logs: Detector training already finished but its loss file was removed from the cache; reporting loss as 0. and: Error cleaning up detector images: NSCocoaErrorDomain Code=4 NSPOSIXErrorDomain Code=2 "No such file or directory" I would really like to avoid discarding ~48 hours of training if the existing tracker/detector checkpoints can still be recovered. Thanks!

Hello, My app has been waiting in the App Review queue for longer than expected, and I was hoping someone from the Apple Developer team could look into its status. The app is an important part of my submission for an upcoming competition, and the submission deadline is approaching. Having the current version reviewed before that deadline would be extremely helpful, as I need the approved App Store version as part of the project. I completely understand that review times can vary and that the App Review team handles a large number of submissions. I would greatly appreciate it if someone could check whether there are any issues holding up the review or if there is anything I need to provide on my end. Thank you for your time and help.

We ship a Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call. How we measured For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs. The extension cache was reset before each call, so every call triggered a real network lookup. All times are in ms and measured from addNewIncomingCall. Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay): In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms. In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response. Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay). Before the first byte was sent, the system spent another 54–225 ms after the call arrived. In the failing cases the syslog shows: CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing. What works: repeat calls After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about. The problem with the 1-second budget Each blocking lookup has to: Send a PIR query Receive a response of ~22–25 KB. Often open a new TLS/QUIC connection through the OHTTP relay. All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.

(lldb) p [@"ΗΙzzz" caseInsensitiveCompare:@"ᾚabc"] (long long) -1 (lldb) p [@"ᾚabc" caseInsensitiveCompare:@"ΗΙzzz"] (long long) -1 Note the unicode char in the second string. The results can't be both -1, afaik, if one is -1 the other one should be +1. This causes inconsistent indexing in a sorted array resulting in obscure crashes of my app. Am I doing something wrong? Tested on iOS 27 and macOS 26.6.

Hi Apple Developer Support, The ARM64 build of our macOS app, has remained In Progress for over five days. The x64 build of the same release, submitted shortly afterward, has been accepted. Pending ARM64 submission: Submission ID: f2aa218e-680c-4497-a977-17b7f3d85ae1 Submitted: September 23, 2026, at 12:57:14 UTC Archive: signed-arm64.zip Status: In Progress Accepted x64 submission: Submission ID: bbae43b0-3846-46d0-a160-3b3af3aede9b Submitted: September 23, 2026, at 12:59:28 UTC Archive: signed-x64.zip Status: Accepted I checked both submissions again on today using xcrun notarytool info. For the ARM64 submission, notarytool log returns: Submission log is not yet available or submissionId does not exist However, notarytool info successfully finds that submission and still reports In Progress. Could someone please check whether this submission is still undergoing additional analysis, or whether there is an issue requiring action on our side? If another support channel is more appropriate after this length of time, please let us know. This is blocking our Apple Silicon release. We would appreciate any guidance.

I’m developing a macOS application that contains an embedded User Service Login Item: Outer app bundle ID: com.xxx.app Embedded User Service bundle ID: com.xxx.app.service Team ID: DE8Y96K9QP The User Service is embedded at: OuterApp.app/Contents/Library/LoginItems/UserService.app I deployed a com.apple.configuration.app.managed declaration through an MDM server, with an asset declaration of type: com.apple.asset.credential.identity, the declaration uses: "AppComposedIdentifier": "com.xxx.app (DE8Y96K9QP)" When the ManagedApp APIs are called from the outer ZTA app, the app successfully receives the identity. However, when the same ManagedApp APIs are called from the embedded User Service, the identity list is empty. When I instead use the embedded service’s identifier: "AppComposedIdentifier": "com.xxx.app.service (DE8Y96K9QP)", macOS reports either Error.InvalidCodeSignature or Error.NotPresent. My questions are: Can an embedded Login Item or embedded subsystem be the target of an app.managed declaration and access managed identities through ManagedAppIdentitiesProvider? Or must AppComposedIdentifier always identify the top-level application that contains the embedded Login Item? If the declaration targets the outer application, is there a supported way for the embedded User Service to access the same managed identity—for example, through XPC communication with the outer application? The outer application and embedded User Service are signed by the same Team ID, and both signatures validate successfully when checked with codesign. Thanks, Ying

I have an app that I am implementing background assets, using self hosted unmanaged. Everything compiles fine, and I get no errors. But I can't figure out how to trigger the 'install' phase into the extension. I have tried copying the app into /Applications without luck. I have deleted the entire DerivedData and all copies of the application. Nothing seems to work. I tried using the Apple provided sample app from here and got the same results. I don't understand why the CLI tool backgroundassets-debug only works with iOS based connected devices? Please let me know how can I test my BADownloaderExtension on Mac via XCode. Thank you.

Hello, We are investigating an auto-renewable monthly subscription in the Production environment. Timeline and observed behavior: On June 29, 2026, the user initiated the first subscription purchase. The Apple Account used WeChat Pay as its payment method. The WeChat charge failed because the balance was insufficient, and no funds were deducted from any available payment source. Nevertheless, StoreKit returned a verified transaction, the subscription purchase succeeded in the app, and App Store Connect Sales Analytics reports proceeds for the purchase. We grant entitlement based only on Apple's signed transaction and subscription status, so the user currently has access. As of July 20, 2026, Get All Subscription Statuses from App Store Server API returns: environment: Production status: 1 (Active) expiresDate: 2026-07-29T03:37:11Z autoRenewStatus: 1 no gracePeriodExpiresDate no revocationDate no expirationIntent no billing retry indication Our App Store Server Notifications endpoint has received only: SUBSCRIBED / INITIAL_BUY We have not received DID_FAIL_TO_RENEW, EXPIRED, REFUND, or REVOKE. Questions: Is it expected for Apple to issue a valid production initial-purchase transaction and report proceeds even when the underlying WeChat Pay charge failed and no money was deducted? Could this be an unpaid Apple Account balance or delayed settlement that is invisible to the developer? While the Server API returns status 1, should the developer continue granting entitlement until expiresDate? Is there another authoritative App Store Server API or signed field that indicates the payment has not actually been collected? If renewal or collection later fails, when should we expect DID_FAIL_TO_RENEW or a change to billing retry or expired status? We have intentionally omitted transaction IDs and account identifiers from this public post. I can provide them privately to Apple Support if needed. Thanks

I submitted my app for a big national event on September 22nd, got a rejection for metadata in two days, and fixed it in the same day. Now the event is in two days, and I'm still in Waiting for Review. I tried to contact support and also submitted an expedited review request yesterday, but still stuck. Is there anything I can do to help speed this up? Or anyone from support who can escalate? We desperately need it live, otherwise it will be too late. Thanks!

Hello, Our app was removed from the App Store on September 19. We revised all metadata as requested by App Review and resubmitted on September 25. Since then, the submission has remained in "Waiting for Review" with no movement to "In Review." The app has now been unavailable for 10 days. We have submitted an App Review Status inquiry through Developer Support and have an App Review Appointment scheduled, but the earliest available slot is October 7. Has anyone experienced a similar situation after an app removal, or is there a way to check whether the submission is progressing normally? Thank you.

I’m seeing a repeatable failure to export changes in the background with an NSPersistentCloudKitContainer private database on iPhone. While offline, I create an object and save its managed object context. I then leave the app and lock the phone. After Wi‑Fi reconnects, the change remains absent from the same app on my Mac. Opening the iPhone app causes it to sync and appear on the Mac. The unplugged sequence reproduces this. When I tried the same sequence with the iPhone plugged in, background sync worked. In a sysdiagnose from an unplugged occurrence: 16:44:21: The context saved the new object. 16:44:21: dasd queued the CloudKit export but reported networkPathAvailability = 0. 16:44:27: iOS suspended the app. 16:48:21: Wi‑Fi reported a satisfied path. Through 16:54:42: No subsequent export attempt appeared in the logs. Opening the iPhone app caused the change to appear on the Mac. In the same offline-to-online routine, a reminder created in Apple Reminders appears on my Mac without reopening Reminders on the iPhone; my app’s new object does not appear until I reopen my app on the iPhone. Is a queued NSPersistentCloudKitContainer export expected to run after connectivity returns while the app remains suspended and unplugged? If so, what should I check to learn why it did not run here? Or does Reminders receive background scheduling priority that third-party apps cannot use?

Five apps Waiting for Review — Shipaton 2026 deadline September 30 — Expedited requests submitted Hi Apple Developer Community, I’m participating in Shipaton 2026 and have five iOS app submissions currently Waiting for Review. I have submitted expedited review requests for all five apps. The competition deadline is September 30, 2026 at 11:45 PM PDT (UTC−7). Apps must be publicly available on the App Store for judges to download and review, so pending submissions and TestFlight builds do not qualify. These are my five priority submissions: App Apple ID Version Current submission date Submission ID Knowless 6813508086 1.0 September 24, 2026 f4d5e751-01f0-43de-b7e3-73fe7c2667fe Elsewhere: Hidden Safe Place 6813465116 1.0 September 25, 2026 a09f3b83-89a4-4fa3-ae3a-51ae956c577c lifelong 6788564145 1.0 September 28, 2026 bcecc5d7-e5eb-41d4-b68b-d048f1278d09 baseline - fitness state 6804717722 1.0 September 28, 2026 d61092a8-9204-47ca-bd0e-22b2ba13bb77 Lockeat 6815507097 1.0 September 28, 2026 1361a7a8-9976-4495-9b76-60170d989aec These dates refer to the current submissions; some were submitted more recently than others. Could an Apple representative help route this time-sensitive request to the App Review team, or advise whether any further action is needed after submitting the expedited requests? I understand that expedited review and approval cannot be guaranteed. I’m available to respond promptly to any questions or requests for additional information. Thank you for your time and help.

On Xcode 26 and earlier versions, two-finger touches were possible on Simulator by holding down the option key. On Xcode 27 with Device Hub, this is no longer possible. While the trackpad can be used for pinch and rotate gestures, two-finger taps and two-finger pans are not possible. This is a major regression that renders our app basically unusable in Device Hub. We rely on two-finger tap and pan gestures to navigate our 3D models. Not being able to do this in Device Hub and in Xcode previews would be a huge loss. Is this actually no longer supported or am I missing something?

In previous versions of Simulator.app, you could drag an unsigned iOS .app bundle onto the Simulator screen to install it. This was useful functionality to allow for more easy distribution of simulator-only builds within a team without needing to worry about signing and distribution. This functionality appears to have been completely removed in Device Hub which is a shame.

在使用 xode 27 真机调试项目时 报了 ibrary 'd64' not found 这个错误， 这边有用到-ld64 遇到这个问题需要怎么去解决呢？ xcode 26 没有报这个错