Feedback: FB24659815. I have submitted a screen recording and screenshot through Feedback Assistant. In GGame, quickly swiping back after opening a game home page with the system SwiftUI zoom transition leaves the destination navigation title, back button, settings button and history button over the visible lobby for about one second. During that interval, lobby content does not respond to taps or scrolling, while the tab bar still works. Steps to reproduce: Open the game lobby. Tap a game icon to enter its home page using zoom. Immediately swipe right to return, attempting to interrupt the incoming animation. When the lobby reappears, immediately try to tap or scroll its content and observe the navigation controls. Expected: once the return transition finishes, the destination controls disappear and the visible lobby accepts taps and scrolling. Interrupted entry and cancelled interactive return should remain supported. Current investigation environment: iPhone 16 Pro, iOS 27.0 Seed 7 (24A5430a), Xcode 27 beta 4. The supplied owner recording shows the visual symptom across Connect Four, Chinese Chess and Chess; the exact build used in those original attachments has not been independently verified. The app uses NavigationStack, matchedTransitionSource and navigationTransition(.zoom(...)). It also has application-side navigation-bar visibility, transition-state and gesture coordination. We have not isolated the exact symptoms in a minimal project without that logic, so the root cause remains unconfirmed. Potentially related discussions: https://developer.apple.com/forums/thread/796805 https://developer.apple.com/forums/thread/802908 Those reports primarily describe disappearing source views that remain tappable. Our issue involves lingering destination controls and temporarily unresponsive root content. I am opening a separate thread to track these differences. Has anyone observed this specific combination? Could the SwiftUI/navigation team check FB24659815 and advise whether this is a framework issue or an application-side lifecycle/gesture interaction? We would appreciate a fix or supported workaround that preserves the system zoom animation and interactive cancellation. The temporary loss of lobby interaction makes this especially disruptive.

My apps are legacy codebases still using AppDelegate instead of SceneDelegate. According to TN3187: Migrating to the UIKit scene-based life cycle, apps should migrate to the scene-based lifecycle. I have the following questions: Is there a specific timeline or deadline for when this migration will be enforced? Will there be deprecation warnings before the assert is triggered? I've tested my app with Xcode 27 beta, and it's not showing any errors or warnings related to this requirement. Based on this, I'm assuming this scene delegate migration may not be relevant for Apple's yearly requirement to submit new apps with the latest iOS SDK, and won't be enforced in April when "apps uploaded to App Store Connect must be built with Xcode 27 or later using an SDK for iOS 27." Can someone confirm if this understanding is correct?

I'm developing a tvOS application using SwiftUI, and I have a custom video player presented using fullScreenCover. .fullScreenCover(isPresented: $isPlayerPresented) { PlayerView() } I would like to implement the same kind of behavior commonly seen in video players: The player is presented full screen. When the playback controls are visible, pressing the Siri Remote Back button should hide the controls. The player should remain presented. Only when the controls are already hidden should pressing Back dismiss the player. However, I am unable to intercept the Back button before the fullScreenCover is dismissed. I have tried several approaches, including: .onExitCommand { // Handle Back } and handling UIPress / .menu events through UIKit. The problem is that when the Siri Remote Back button is pressed while the view is presented using fullScreenCover, the fullScreenCover is dismissed directly. My custom view does not appear to be able to prevent the dismissal. I also tried placing a custom UIView / UITapGestureRecognizer inside the fullScreenCover to intercept the remote button event, but the presentation is still dismissed. According to the SwiftUI documentation, onExitCommand responds to the tvOS exit command generated by the Menu button, but it does not appear to provide a way to prevent the system from dismissing a fullScreenCover in response to the Siri Remote Back button. I also noticed that interactiveDismissDisabled(_:) does not appear to provide a solution for this particular tvOS behavior. My questions Is the Siri Remote Back button expected to automatically dismiss a SwiftUI fullScreenCover on tvOS? Is there a supported API to intercept the Back button before the fullScreenCover is dismissed? Is there a way to tell SwiftUI that a fullScreenCover should not be dismissed by the Siri Remote Back button? If fullScreenCover is not intended for this use case, what is the recommended way to implement a custom full-screen video player that needs to control Back-button behavior? The desired behavior is essentially: Back button ↓ Are playback controls visible? ├── Yes → hide controls, keep player presented └── No → dismiss player I would appreciate any guidance on the intended tvOS API or recommended architecture for implementing this behavior. Thanks!

In all iOS 27 Beta 1-8 UIViewControllerAnimatedTransitioning is broken, it shows black screen when a new screen is opened. This Transitioning works correctly on previous iOS (<27) versions. Check out the attached file with example of source code. Example.txt This bug needs to be fixed ASAP, as it will affect a large number of users upon the public release of iOS 27. Visual demonstration: iOS 27 with broken transition iOS 26 works correctly

Hello, After building with the iOS 26 SDK, a table-view swipe action created with UIContextualAction is displayed as a circular Liquid Glass button instead of the rectangular action used on earlier iOS versions. This is how my code look UIContextualAction *action = [UIContextualAction contextualActionWithStyle:UIContextualActionStyleNormal title:@"" handler:^(UIContextualAction *action, UIView *sourceView, void (^completionHandler)(BOOL)) { completionHandler(YES); }]; action.backgroundColor = UIColor.systemPurpleColor; action.image = [UIImage imageNamed:@"my_action_image"]; UISwipeActionsConfiguration *configuration = [UISwipeActionsConfiguration configurationWithActions:@[action]]; configuration.performsFirstActionWithFullSwipe = NO; return configuration; Has anyone found a supported workaround that does not require a completely custom swipe implementation? This occurs only with the new iOS 26 appearance. The same implementation displays correctly on earlier iOS versions. Thank you.

HI, I have an issue displaying SwiftUI previews with Xcode 14. My project has iOS and an watchOS Target. It also includes a lot of SPM, most of them only used by the PhoneApp. The project build successfully for both iOS and watchOS. I can see that when building the watch target, only SPM that are included in this target are build for for watchOS The issue is when I try to build a swiftUI preview of the watch target. In this case I can see on the build for Preview log that Xcode try to build ALL spm defined in the Xcode project, including the one that are not used by the watch Target, As a lot if spm are for iOS only, and doesn't build for watchOS, the build for preview fails, and I'm unable to preview my swiftUI views on the AppeWatch. Note that my project is working fine on Xcode 13. This issue is easy to reproduce in any Xcode projects containing a iOS and watchOS target by adding a SPM that is only for iOS. Any workaround to fix this issue ?

I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does. if let phoneNumber = ussdNumberTextfield.text { let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)! if let url = URL(string: encoded) { if application.canOpenURL(url){ DispatchQueue.main.async { self.application.open(url, options: [:]) { success in } } } } }

Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.

I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?

Central talking to one custom peripheral, CoreBluetooth state restoration enabled. Behavior I understand: iOS kills the app for memory pressure, peripheral does something, restoration relaunches into the background. Documented, and I have watched it work. Behavior I do not: I force-quit from the app switcher. The device had been unplugged and off for about a week. Plugged it back in and within a minute it had fresh data that only my app could have sent. So the app ran, and I never opened it. Everything I have read says force-quit is a hard opt-out until the user launches again. The only theory I have is that this is not the same event class as what I tested before. Earlier tests were all notifications from an already-connected peripheral. This time there was a connect request outstanding from before the force-quit, and it completed when the device came back. Possibly a pending connection completing is handled differently than traffic on a live link. I do not have instrumentation on this yet, so I cannot say whether it relaunched or was still resident, and I cannot rule out that the phone rebooted sometime during the week. Adding logging before I try to reproduce. Has anyone characterized this properly? Specifically whether a connectPeripheral pending from before a force-quit survives, and whether its completion can trigger relaunch. The docs do not draw that distinction.

hello. I was going through the Swift tutorial and am seeing that the code for MomentsViews.swift is showing as .sheet(isPresented: $showCreateMoment) { MomentEntryView() } but this makes the navigation title and toolbar not render. ChatGPT recommended this instead: .sheet(isPresented: $showCreateMoment) { NavigationStack { MomentEntryView() } } will the tutorial need to be updated or am I missing something elsewhere?

Using accessibilityRotor(_:entries:) as described in the documentation works fine on Xcode 26 and iOS 26 whereas it fails to compile on Xcode 27 when at least iOS 26 is selected as the minimum deployment target. .accessibilityElement(children: .contain) .accessibilityRotor("VIPs") { // ❗️Conformance of 'Optional<Wrapped>' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer ForEach(messages) { message in // If the Message is from a VIP, make a Rotor entry for it. if message.isVIP { AccessibilityRotorEntry(message.subject, id: message.id) } } } The error states "Conformance of 'Optional' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer" which should not be the case as the code was compiling prior to Xcode and iOS 27. Feedback is FB24587642. It contains a sample project to reproduce the issue. Using Xcode 27 beta 6 with iOS 26 as minimum deployment target and Swift 6 language mode.

I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift

Hi. I've noticed that on iOS 27 the UITabBarItem badge goes behind the tab image during tab selection. Here is a little screen recording of a simple Storyboard project with just a UITabBarController and two child UIViewControllers. On the left is iOS 26.5 and on the right is iOS 27.0 beta 6. While filled icons look more or less ok, the outline icons look the most concerning with this new behaviour. So, the question is whether this is a bug or a feature?

We are seeing an intermittent launch-time crash that increased sharply starting with iOS 18.4. The affected app version is 1.4.8, which uses the UISceneDelegate-based lifecycle. The primary UIWindow is created and managed for the UIWindowScene provided to the scene delegate. The OS-version distribution is very specific: iOS 18.3: no significant occurrence iOS 18.4 through the tested iOS 18.x releases: the crash occurs iOS 26: no occurrence observed This comparison uses the same application binary. Therefore, the issue appears to be specific to the iOS 18.4–18.x UIKit/FrontBoard implementation rather than a general behavior on all newer iOS versions. The crash occurs on the main thread: EXC_BREAKPOINT (SIGTRAP) 0 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 1 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 2 FrontBoardServices -[FBSScene _sendUpdate:] + 1156 3 FrontBoardServices -[FBSScene _updateClientSettings:] + 552 4 FrontBoardServices -[FBSScene updateClientSettingsWithBlock:] + 124 5 UIKitCore -[FBSScene(UIApp) updateUIClientSettingsWithBlock:] + 168 6 UIKitCore __39-[UIWindow _noteOverlayInsetsDidChange]_block_invoke + 248 7 UIKitCore -[_UIAfterCACommitBlock run] + 72 8 UIKitCore -[_UIAfterCACommitQueue flush] + 168 9 libdispatch.dylib _dispatch_call_block_and_release + 32 10 libdispatch.dylib _dispatch_client_callout + 16 11 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 12 libdispatch.dylib _dispatch_main_queue_drain + 180 13 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 14 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 15 CoreFoundation __CFRunLoopRun + 1980 16 CoreFoundation CFRunLoopRunSpecific + 572 17 GraphicsServices GSEventRunModal + 168 18 UIKitCore -[UIApplication _run] + 816 19 UIKitCore UIApplicationMain + 336 Another observed variant contains: -[FBSScene _sendUpdate:].cold.1 + 244 Some reports continue through: _UIApplicationFlushCATransaction _UIUpdateSequenceRun while others continue through the main dispatch queue. These reports appear to belong to the same crash family because they share the following path: UIWindow _noteOverlayInsetsDidChange → FBSScene updateUIClientSettingsWithBlock: → FBSScene _updateClientSettings: → FBSScene _sendUpdate: → SIGTRAP The crash occurs during cold launch, immediately after the root tab bar controller begins its first appearance. In affected launches, the last application-side lifecycle marker we observe is: MSKMainTabBarViewController.viewWillAppear(_:) The process then terminates while UIKit is flushing the first appearance-related Core Animation transaction. No later application-side lifecycle marker is observed before termination. We are treating viewWillAppear(_:) only as the last observable application-side marker. We do not assume that it directly causes the crash, because the failing UIWindow client-settings update is deferred until after the Core Animation commit. There are no application frames in the crashing portion of the stack, and the app does not call any private API. The affected app version has already adopted the UISceneDelegate lifecycle, so this does not appear to be caused by the legacy UIApplicationDelegate-only compatibility lifecycle. We have also observed the same FBSScene update path during a normal, non-crashing launch. The fatal reports differ in that FrontBoardServices triggers SIGTRAP inside _sendUpdate: or its compiler-generated cold path. Because the client-settings update is deferred, the crash report does not identify which UIWindow operation, overlay-insets change, or FBSScene client setting originally produced the rejected update. Has anyone encountered this exact FBSScene / _noteOverlayInsetsDidChange crash specifically on iOS 18.4–18.x? In particular: Is this a known UIKit or FrontBoardServices regression introduced in iOS 18.4? Was this behavior changed or fixed in iOS 26? Which UIWindow or FBSScene client setting can cause this internal assertion? Is there a supported way to identify the UIWindow responsible for the rejected update? Are there known launch-time restrictions involving multiple UIWindows, key-window transitions, overlay insets, status-bar updates, or first-appearance transactions? Is there a recommended diagnostic profile, breakpoint, or logging option for capturing the original producer of the deferred update?

I am seeing a reproducible issue with macOS ControlCenter's per-app menu bar tracking state in a SwiftUI MenuBarExtra app. On launch the app creates its menu bar status item. ControlCenter then reads group.com.apple.controlcenter / trackedApplications, moves the app's status item host to the blocked list, sends NSStatusItemChangeVisibilityAction with visibility=0, and the app terminates because its only status item is removed. Two observations: Changing only the bundle identifier makes the menu bar item appear normally. In trackedApplications, the affected app has its own entry with isAllowed: true; a separate entry for another app has isAllowed: false, and that disallowed foreign entry's menuItemLocations contained an entry referencing the affected app. Removing only the affected app's reference from the other app's disallowed entry fixed the issue: the app launched normally, and ControlCenter no longer sent visibility=0. ControlCenter appears to associate one app's menu item identity with another app's disallowed tracked record, letting the foreign blocked record override the app's own allowed record. Is this expected? And is there a supported way to reset this per-app ControlCenter menu bar state without editing the protected group.com.apple.controlcenter plist directly? Testing Environment: macOS 26.3 (25D125) Xcode 26.3 (17C529) LSUIElement: true Sandboxed app SwiftUI MenuBarExtra Relevant log pattern: Host properties initialized; (bid:[AffectedApp]-Item-0-[pid]) State(applicationItem: true, clientRequestsVisibility: true, neverClip: false) looked up value <private> for key trackedApplications (Domain: group.com.apple.controlcenter) Moving host to blocked list; (bid:[AffectedApp]-Item-0-[pid]) Requesting blocked host to not be visible; (bid:[AffectedApp]-Item-0-[pid]) Sending action(s): <NSStatusItemChangeVisibilityAction: ...> Received action(s): NSStatusItemChangeVisibilityAction 0 agent requesting visibility=0 temporary=0 0 terminating on removal

In my app I get a UIImage for a PHAsset via PHImageManager.requestImage(for:targetSize:contentMode:options:resultHandler:). I directly display that image in a UIImageView that has preferredImageDynamicRange set to .high. The problem is I do not see the high dynamic range. I see the HDRDemo23 sample code uses PhotosPicker to get a UIImage from Data through UIImageReader whose config enables prefersHighDynamicRange. Is there a way to support HDR when using the Photos APIs to request display images? And is there support for PHLivePhoto displayed in PHLivePhotoView retrieved via PHImageManager.requestLivePhoto?

I am seeing a SwiftUI environment object remain alive after the view hierarchy that owns it has been dismissed. The retained object is owned by @StateObject inside a fullScreenCover. A TextField presented deeper in that hierarchy receives focus through @FocusState. After navigating back and dismissing the cover, the @StateObject does not deinitialize. The memory graph shows that system keyboard/input-assistant views retain a UITraitCollection, which retains a SwiftUIEnvironmentWrapper containing the environment object. Environment macOS 26.6.1 (25G76) Xcode 26.6 (17F113) iOS 26.5 Simulator iPhone 11 26.6 Minimal reproduction import Combine import SwiftUI final class DemoCoordinator: ObservableObject { let id = UUID() init() { print("[+] DemoCoordinator INIT \(id)") } deinit { print("[-] DemoCoordinator DEINIT \(id)") } } @main struct FocusStateLeakApp: App { var body: some Scene { WindowGroup { RootView() } } } struct RootView: View { @State private var isFlowPresented = false var body: some View { Button("Present flow") { isFlowPresented = true } .fullScreenCover(isPresented: $isFlowPresented) { FlowContainer() } } } struct FlowContainer: View { @Environment(\.dismiss) private var dismiss @StateObject private var coordinator = DemoCoordinator() var body: some View { NavigationStack { NavigationLink("Push field screen") { FieldScreen() } .navigationTitle("Flow") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close") { dismiss() } } } } .environmentObject(coordinator) } } struct FieldScreen: View { @State private var text = "" @FocusState private var isFocused: Bool var body: some View { TextField("Type something", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding() .navigationTitle("Field") .onAppear { isFocused = true } .onDisappear { isFocused = false } } } Steps to reproduce Launch the application. Tap “Present flow”. Tap “Push field screen”. The TextField automatically becomes focused and the software keyboard appears. Navigate back. Tap “Close” to dismiss the full-screen cover. Observe the console or capture a memory graph. Expected result: After the full-screen cover is dismissed, FlowContainer and its @StateObject storage should be released. The following message should be printed: [-] DemoCoordinator DEINIT ... Actual result: DemoCoordinator remains alive and its deinit is not called. The captured memory graph contains one DemoCoordinator. The same behavior occurs after migrating the reproducer to the Observation framework. Questions Is retaining the SwiftUI environment through keyboard-owned cached trait collections expected? Is there a supported way to prevent dismissed SwiftUI environments from being retained by the input-assistant hierarchy? Is this a known UIKit/SwiftUI issue for which a Feedback ID already exists? Should this be reported as a SwiftUI issue, UIKit issue, or Text Input issue in Feedback Assistant? I can provide the minimal Xcode project and the captured .memgraph file if needed.

The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!