Overview

Since Xcode 27 GA, text entry from a UI test on a physical iOS 27 device delivers only the first 3–4 characters and then stops, while the call still returns success. Taps and scrolls are fine. The same tests pass on Xcode 27 beta 1. Filed as FB24932647. Broken: Xcode 27.0 (27A266a), 27.1 beta (27A9269), 27.2 beta 2 (27B5028f) Works: Xcode 27 beta 1 (27A5194q) Device: iPhone, iOS 27.0 (24A437) Repro. We drive it through WebDriverAgent. The failing step is XCTest's own event synthesis in testmanagerd, which is the same path XCUIElement.typeText goes through. Xcode 27.2 beta 2, run sudo xcodebuild -runFirstLaunch, reboot the device. Type subjectline into a plain UITextField. Read the field's value back. Expected subjectline. Actual sub or subj, in every one of 16 attempts. In a recipient-style field the fragment appears and is then erased, so nothing survives. 0 of 32 attempts completed. Device log, all within one second: testmanagerd Failed to load displays from CADisplay testmanagerd Failed to resolve displays. Defaulting to generic keyboard sender. testmanagerd Recap event action playback initiated UIKitCore hardwareKeyboardAttached = YES UIKitCore Moving from placement OnScreen to OffScreenDown UIKitCore Change to input view set: (empty) testmanagerd Recap event action playback completed testmanagerd can't resolve a display, so it falls back to a generic keyboard sender that registers a virtual HID keyboard. iOS then treats that as a hardware keyboard and dismisses the software keyboard while the text is still being typed. What changed. Comparing testmanagerd in the two DeveloperDiskImages: beta 1 derived the display from the app's identity (Computed display ID … from embeddedApplicationIdentifier … bundleID). GA removed that and added CADisplay enumeration with the generic fallback. That code is unchanged through 27.2 beta 2. This is not 181945323, which is marked fixed in 27.2 beta 2. That one needs Device Hub and clears on its own. Is anyone else seeing this on device? Is there a supported way to type on device under Xcode 27 GA, other than staying on beta 1?

Hi everyone, I'm developing a Flutter-based proximity app and would appreciate some technical advice. The goal is to detect when two iPhones are physically near each other, even when both phones are locked and the app is running in the background. For example, two users pass each other on the street for 20–40 seconds. We want to reliably identify that encounter, even if the information is processed later. I'm considering combining Core Bluetooth (BLE scanning/advertising) with Core Location (background GPS) to minimise missed encounters. My main questions are: Can two locked iPhones reliably detect each other through background BLE? Can background GPS provide sufficiently frequent location updates to capture brief encounters? Are there supported ways to combine both technologies to improve reliability? Accuracy isn't necessarily critical. Avoiding missed encounters is the priority. I'd really appreciate any advice or experience with similar implementations. Thanks!

Hi all, is anyone else seeing this since switching to Xcode 27.1? Since Oct 20, none of my new TestFlight builds will install. TestFlight shows the “Update” button, then fails with “Could not install [app]. The requested app is not available or doesn’t exist” (sometimes “Try again later” first). What I’ve checked: Upload from Xcode 27.1 (27A9275) succeeds, no ITMS warnings, build status “Valid”, and I get the “ready to test on iOS and watchOS” email The exact same archive installs and runs fine when installed directly from Xcode on the same device (development signing) Device: iPhone 15, iOS 27.0.1 Agreements are active, export compliance answered (ITSAppUsesNonExemptEncryption = NO) Entitlements and Info.plist are identical to my last build made with Xcode 26.5, which installed fine through TestFlight Tried bumping the build number, closing TestFlight, waiting a few hours: same result The only real difference is the toolchain (Xcode 26.5 / iOS 26.5 SDK → Xcode 27.1 / iOS 27.1 SDK). The app also embeds a watchOS app. Has anyone hit this with Xcode 27.x? Did you find a fix, or did Apple support resolve it on their side? “Membership active until January 2027. The updated agreements were accepted on Sunday Oct 18; the TestFlight failures started on Oct 20.” Thanks!

Summary A TabView with .tabViewStyle(.page) builds its tabs with ForEach; each tab presents a fullScreenCover(item:) from inside. Once the TabView is on screen, either of these breaks every later presentation: a tab is added or removed, or a tab's root view changes identity (Group { switch state } going from .loading to .loaded, with no tab added or removed). From then on each cover is dismissed by SwiftUI itself 15–70 ms after the present. With the standard transition it opens and closes once. With .navigationTransition(.zoom) the dismissal reaches UIKit while the cover is still animating in, and the app crashes: NSInternalInconsistencyException: Cannot morph from a view that is not in the hierarchy. Reproduces on iOS 26.0, 26.5 and 27.1 simulators and on devices on iOS 27.0.x. In our shipping app it is the top crash, ~2,000 events/day. How we got here The crash appeared when we adopted .navigationTransition(.zoom) for this cover. Every report is SheetBridge.dismiss/present → dismissViewControllerAnimated: → -[UIView(UIMorphableInternal) _morphPreviewFromCurrentState:…]. A second tap while the cover was still zooming in reproduced it; we guarded against that. Crashes continued. Disassembling UIKit showed that a dismissal during a zoom presentation preempts it and morphs from the presented view; if that view is not in the hierarchy, UIKit asserts instead of falling back. Any premature dismissal is enough. Our crash breadcrumbs showed every user navigating between tabs of a page-style TabView shortly before the crash, so we went looking for what dismisses a cover that was just presented. A lab with our topology (~1,700 automated presents) found the two triggers above. Both reproduce on iOS 26.0, 26.5 and 27.1, so the SwiftUI side is not new; the zoom transition is what makes it fatal. Steps to reproduce Run the PagedTabViewCoverRepro scheme (https://github.com/matheusmdutra03/PagedTabViewCoverRepro). The bottom tab bar selects the scenario; each screen explains the cause and shows the steps. "Page list changes": tap Add a tab, then tap any photo. "Page content changes": tap Reload tab content, then tap any photo. Expected The photo opens and stays until Close. Actual Zoom on: the app crashes with "Cannot morph from a view that is not in the hierarchy." Zoom off: the photo closes by itself about 1 s later. The on-screen counter shows "Dismissed by system". Why we think it happens The page-style TabView tracks the presentations made from its tabs, keyed by each tab's identity in the ForEach. Scenario 1 changes that identity directly: the tab list is diffed. Scenario 2 changes it indirectly. Group adds no view of its own, so the tab is whichever switch branch is active. When state flips, the branch changes type and SwiftUI sees a different view in that slot. For the TabView that is the same as removing the tab and inserting a new one. Either way the tracking is rebuilt and the tab's fullScreenCover loses the presentation it owns. Every present after that is treated as orphaned: SwiftUI dismisses it, presents a second copy, and dismisses that too (captured with method hooks on present/dismiss in the sample). With .zoom the final dismissal lands while the cover is still animating in and its view is not in the window yet; UIKit's zoom-out has no fallback for that and asserts. The broken state lives in the TabView subtree: recreating only the TabView clears it, and a cover attached outside the TabView is never affected. What fixed it in the sample Scenario 1: .id(tabs.map(\.title)) on the TabView, so a list change recreates the TabView instead of diffing it. 20/20 clean. Does not help scenario 2. Scenario 2: ZStack { switch state { … } } instead of Group { … } as the tab's root. ZStack is a real view, so the tab keeps its identity and the switch only changes its content. 20/20 clean. Does not help scenario 1. Both are app-side workarounds, one per trigger. A standard TabView, a paging ScrollView, or a cover attached outside the TabView never reproduce. Suggested fix Keep each tab's presentation bookkeeping bound to its ForEach identity across list diffs and root-identity changes, so a tab's fullScreenCover/sheet never loses the presentation it owns. If SwiftUI still has to dismiss a presentation it no longer tracks, do it without animation while the presented view is not in the window, so the UIKit zoom transition cannot assert. Results (iOS 27.1, 20 presents each) Scenario 1: 0 clean · 9 dismissed by system · 11 crashes. With .id(tabs): 20 clean. Scenario 2: 0 clean · 0 dismissed · 20 crashes. With ZStack: 20 clean. Attachments Evidence/ has crash logs (iOS 27.1 and 26.5), a screen recording, and the raw trial logs. The ZoomDismissCrashRepro scheme in the same project reproduces the UIKit assertion with five public-API calls and no SwiftUI.

Hi all, I'm hoping someone from Apple can help. I've tried the usual routes and haven't had a reply. The problem In App Store Connect, under Business (Agreements, Tax and Banking), my old bank account has shown as "Processing" for over a year. I've since closed that account, so it will never finish processing. While it's stuck, I can't complete the Paid Apps Agreement. That means my in-app purchases won't load in sandbox testing and can't go on sale. My app is otherwise ready to release, so this is now the only thing holding it up. What I've tried 15 October: emailed Developer Support asking for the old bank account to be removed. No reply. Emailed again since then. Still no reply. Sent a separate request to update my address. No reply yet. What I need The old "Processing" bank account removed or cancelled My address updated, as per my separate request Then I can add my current bank account and complete the Paid Apps Agreement Has anyone else had a stuck "Processing" bank account cleared? If so, how did you get it done? And is there a better way to reach the right team than the contact form? If anyone from Apple can look into this, I'm happy to send account details privately. Thanks very much, Tom

Hi, My app update has been stuck in “Waiting for Review” for quite a while now, and it seems to be taking much longer than my previous submissions. I haven’t received any messages or requests for additional information, so I was wondering if someone from Apple would be able to take a look at the submission and see if there’s anything holding it up or if it can be reviewed soon. I understand review times can vary, but I’d really appreciate any help. Thanks!

Hello, I am a beginner learning to develop iOS apps with SwiftUI. My setup: MacBook running macOS 27.0.1 Xcode 27.1 iPhone 15 Pro running iOS 27.0.1 Developer Mode enabled on the iPhone My iPhone is connected via USB-C and is recognized by Finder and macOS System Information. However, my iPhone does not appear as a run destination in Xcode. Only simulators are available. The command xcrun devicectl list devices detects the physical iPhone, but its connection information shows: pairingState: unsupported tunnelState: unavailable I have already restarted both devices, tried different USB ports, checked my Apple account in Xcode, and confirmed that Developer Mode is enabled. A simple SwiftUI test app runs correctly in the simulator, but I cannot install it on my physical iPhone. What could cause this pairing problem, and how can I resolve it? Thank you for your help.

Hello, I requested "Family Controls (Distribution)" for one of my apps. I received email that the entitlement is granted and I can use it: Hello XXXX The entitlement for Family Controls (Distribution) has been assigned to your account, and you can now configure this capability for eligible apps. If you’re enrolled as an organization, Admins on your team can also use this capability. However, on the identifiers page, the status still shows as "No Requests". Additionally, I see nowhere any other indicator. I opened a case with the ID 102999908799 but didnt receive any response. Anybody knows what to do? Thank you.

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

When using ArrangementView with the overlay style, the Duo simulator does not appear to return a distinct z-index environment value, though it correctly displays z-index 0 and 1 on other iPhone simulators. I would like to use this value to determine whether the overlay is active. Currently, this does not seem possible. Is this behavior intended, or is it a bug? If intended, what is the recommended approach to determine if the Duo is displaying the arranged view over another arranged view? import SwiftUI struct ContentView: View { var body: some View { ArrangementView { Controls() } secondary: { Player() } .arrangementViewStyle(.overlay) } } struct Controls: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Controls Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .leading) } } struct Player: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Player Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .trailing) } } #Preview { ContentView() }

Hello, When I click in the box to write a text (in preview) the virtual keyboard does not appear. On the other hand, when I want to write my script, the keyboard appears well. This one works perfectly in all my applications on the iPad. I could read on the internet that this would come from a problem with the Swift Playground application. I uninstalled and then reinstalled the application but the problem is still present. Thanks

Hello, We're a game studio. Our app has already been transferred from Team A to Team B, and no build has been released from Team B yet. We're now deciding how to handle guest accounts in the first update from B, and we'd like to confirm several platform behaviours before we commit to a plan. Current state The app is now owned by Team B. The build currently on the App Store was published while the app was still under Team A, and is the only build users have. No build has been uploaded or released from Team B — including TestFlight. The app signs users in either with a bound credential (phone number or third-party sign-in) or as a guest. A guest account has no recoverable credential: no email, no phone number, no third-party identifier. The only handle tying the user to their progress is a token stored locally on the device. That guest token is stored in the keychain under a plain keychain access group declared in the Xcode project: $(AppIdentifierPrefix)com.example.game.shared. It is not an App Group, and not an AGI keychain access group. The problem From "Overview of app transfer" we understand that keychain sharing "continues to work only until the app is updated", and that after the first update from B the token in the A-prefixed group will no longer be readable. For a user with a bound credential that's a single re-login. For a guest user it means the account becomes unreachable — there is nothing to re-login with. Their progress, purchases and inventory would be orphaned, and we have no way to identify them from the new build. So the first update from B is a one-way decision point for us, and we'd like to get it right. What we're evaluating Option 1 — Ship from B and carry the guest identity in the app container. If the app's sandbox container (Documents / Library / UserDefaults) survives an in-place cross-team update, we could read a guest identifier written there by the old build and exchange it server-side for a fresh B-prefixed token. No further transfer needed. This only helps users who update in place — anyone who deletes and reinstalls loses the container. Option 2 — Transfer back to A, ship a migration build, then transfer to B again. Have Team A publish a build that moves the token into an AGI keychain access group for a dedicated App Group ID, wait until most users have run it, then transfer the app back to B and transfer the App Group ID, as described in "App ID Prefix Change and Keychain Access". Option 3 — Dual-write now and accept loss for users who don't update in time. Our questions Q1 — App container across a cross-team update. Does an app's sandbox container (including UserDefaults, Library and Documents) persist when a user updates in place to a build signed by the recipient team? We can't find this stated anywhere, and Option 1 depends entirely on the answer. Q2 — identifierForVendor. Does identifierForVendor stay stable across an app transfer, i.e. when the signing team changes? We'd like to use it as a secondary anchor for guest accounts, but we're unwilling to rely on undocumented behaviour, and we can't find documentation either way. Q3 — Transferring back. Is transferring an app back to its original team supported? Are there restrictions we should know about — a cooldown, a cap on the number of transfers, or a requirement that the app meet the transfer criteria again? Specifically, if Team B has uploaded a build to App Store Connect but never released it (no App Store release, no TestFlight distribution), does that affect the app's eligibility to be transferred back? And when the app returns to A, is the App ID Prefix guaranteed to revert to the value it had originally, or can a team end up with a different prefix than it had before (for example on legacy accounts that hold more than one prefix)? Q4 — Keychain-only state. Given that the original build never declared an App Group, is there any supported way to recover items from an A-prefixed keychain access group once the app is owned by B and the next build is signed by B? We assume not, and that Option 2 is the only supported path — please confirm. Q5 — Recommended practice. Is there a recommended approach for migrating accounts that have no recoverable credential? We'd rather follow an established pattern than invent one. A separate question: certificate and profile expiry on Team A's side Team A's distribution certificate and provisioning profile will expire at some point, while the app stays under B without an update. We'd like to confirm that this has no effect on sign-in and no effect on payments for the version currently installed from the App Store. Reasoning that applies to both. The App Store re-signs the app during distribution, and the delivered build contains no embedded provisioning profile (TN3125), so neither A's certificate nor A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in. Tokens — guest and bound alike — live in the keychain under the A-prefixed access group. Our reading is that certificate expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup. The signing certificate isn't an input to that comparison. Is that correct? Payments. Our reading is that payments are unaffected on both sides: StoreKit transactions (purchase, renewal, refund) are handled by Apple's servers and don't depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret — a 32-character hexadecimal string with no relationship to any certificate — so verifyReceipt and the App Store Server API keep working. Is that correct, or does something break here? One consequence we do care about. For Option 2 we'd need Team A to sign and publish that migration build. We assume A must therefore issue a new, valid certificate and profile before it can ship again — that is, expiry doesn't affect the installed app, but it does affect A's ability to publish anything further. Is that right? We also assume the App Store Server Notifications URLs configured for the app are unchanged by the transfer. Could you confirm that as well? Thanks!

Hi, When I used Rork to sign in Apple Developer Account to test my App, I got this message below "Apple rejected the sign-in request before checking the credentials (Apple app-token request, HTTP 503). The client identity this app sends is probably out of date." Screenshot below Does anyone knows why? What should I do? Thanks!

Hello, After a recent iOS update, I was going through my settings to set restrictions on apps installed on my device, and I noticed this option on each app's page: Learn from this App: "Allow Siri to learn from how you use [App Name] to make suggestions across apps." I turned it off right away, but it left me with several questions. In 2026, Siri has received major updates, including new AI features, and it now communicates with me much more often. Before I decide whether to turn this setting back on, I'd like to understand: What data does Siri collect from each app? For example, does it look at which apps I open and when, what I do inside them, or the content I view? How is that data used to improve suggestions? What does Siri actually do with what it learns? Where is this data processed and stored? Does it stay on my device, or is it sent to Apple's servers or synced through iCloud? How is my personal information protected? Is it linked to my Apple Account, and is it shared with app developers or third parties? How is the content I watch or read used across apps? Could something I view in one app affect suggestions in another app? Can I see or delete what Siri has already learned? If so, how? I know Apple takes privacy and security seriously, so I'm not too worried. But this is one of those features Apple didn't really talk about on stage, so I'd appreciate a clearer explanation of how it works. Thanks!

Hello, Our app, MAVE, has remained in “Waiting for Review” since October 11. As of October 23, the review has not started. It is a free iOS video editing app with two consumable in-app purchases. The app and both products were submitted together. We checked the required agreements and account setup in App Store Connect and found no outstanding action items or messages from App Review. We contacted Developer Support on October 14 and followed up on October 19, but have received only automated acknowledgments. Has anyone experienced a similar delay, and was there anything that helped resolve it? If an Apple representative can help investigate, we can provide the app and submission details through a private support channel. Thank you.

Hi... our first iOS app, WiVu (Apple ID 6737291340, version 1.0), has been in “Waiting for Review” since Friday, October 16. There are no messages in App Store Connect, and nothing has been flagged that we can see. What we’ve done so far: Requested an expedited review on October 19 Submitted an App Review status request on October 20 (case 103003005645) Called developer support on October 22. They confirmed they can’t access App Review and that it needs to go to the App Review team We’re launching a pilot with a theater partner, and our Android app is already live. Could someone from App Review please take a look or let us know if anything is needed from us? Thank you...

Hello Apple Developer Community, I would like to seek guidance from fellow developers who have faced similar App Store review challenges. Our app, AstroCure, initially included horoscope features and astrology-related entertainment games. Apple rejected the app because the astrology category is considered saturated. Following this feedback, we made significant changes to the app. We removed the entertainment games and other non-essential features, and now focus exclusively on astrology consultations, allowing users to connect with astrologers for personalized guidance. We believe the value of a consultation platform depends on the expertise of its astrologers, the quality of consultations, and the services offered to users. Just as businesses differentiate themselves through the professionals they bring on board, astrology consultation platforms can also provide distinct value within an established category. However, our latest submission has been waiting for review for approximately 15 days. After requesting a call with Apple, I received a call from an App Review representative two days later. During the conversation, I was advised to remove the app from review and update it because we were apparently not offering anything new. This leaves us uncertain about what further changes are expected. We have already removed the entertainment features and narrowed the app's focus to astrology consultations, but we have not received specific guidance on what would make the app eligible for approval. I would appreciate the community's advice on a few questions: Has anyone successfully resolved a similar rejection for an astrology or consultation app? What kind of differentiation does Apple expect from an astrology consultation platform? Shouldn't Apple evaluate an app's actual value to users, the expertise of its service providers, and its functionality rather than reject it simply because the category is saturated? Has anyone received specific, actionable feedback from Apple that helped them overcome a similar situation? We respect Apple's review process and are willing to make meaningful improvements. We simply need clearer guidance on what is expected so we can address the concerns appropriately instead of making changes without knowing whether they will resolve the issue. I would appreciate hearing about your experiences and any suggestions that could help us move forward. Thank you.

I have a shortcut that should repeat on the 1st Saturday of every month at 8 am. However, it doesn't trigger. If I set it to trigger daily, it works; if I set it to repeat weekly, it works. But if I set it to repeat on the first Saturday, it doesn't. The option to select the first Saturday is native in the Shortcuts app. Select time of day -> Repeat -> Frequency Monthly -> Change "each" to "on the"

Hello App Review team, Our app AirSystem HQ (Apple ID: 6821436401, bundle ID: com.airsystemhq.app) has been in Waiting for Review since October 17, 2026. We submitted an expedited review request on October 18 and have had no movement since. An earlier submission received a reviewer question about pricing. We corrected the pricing and resubmitted, and nothing is pending on our side. AirSystem HQ is a service and sales platform for compressed-air service companies, and customers are waiting to onboard. Could someone check whether anything is holding this submission and help move it forward? Case number: 102996856121 Thank you, Michael Moore Moore Managed IT Inc

Hello, Our app Done Spend App ID 6798325949, published by Done Technologies AB has been in “Waiting for Review” since 4th October 2026 with no change in status. The previous submission was rejected under Guideline 4.3(a) on 7 October. We replied in App Review messages explaining that Done Spend is a separate product for a separate regulated market: it is published by Done Technologies AB, its cards are issued by Mynt AB (authorised by Finansinspektionen), and it serves Norway and Sweden. The similar app, Accountabl, is a UK product run by a different legal entity. We also updated the App Review demo credentials at that time. We’ve checked App Store Connect and there are no outstanding agreements, metadata issues or unanswered messages. We have a customer launch planned for November and would be grateful if App Review could look into the status of this submission. Thank you.