Recurring fatal crash inside PDFKit's private tile-rendering pool. Exception is EXC_BREAKPOINT trapped inside CFRelease.cold.2, called from -[PDFTileSurface releaseSurface], reached via -[PDFTilePool releasePDFTileSurface:] <- -[PDFPageLayerTile dealloc]. Symptom matches an over-release / stale-reference bug in PDFTilePool's internal bookkeeping, not app-level misuse. This is a DIFFERENT app/codebase than the one already reported in Developer Forums thread 837282 (https://developer.apple.com/forums/thread/837282?answerId=896871022#896871022), hitting the identical 3-frame private call chain. That report used PDFView + a PKCanvasView overlay and speculated PencilKit/DYDisplayLinkInterposer overlay timing might be a factor. Our app uses a plain PDFView with NO PencilKit/PKCanvasView overlay of any kind, which rules that out as a necessary trigger -- the bug reproduces on stock PDFKit alone. Crash signature (symbolicated, from production Crashlytics): #0 CFRelease.cold.2 #1 CFEqual (also seen as plain CFRelease in the other report -- same release path) #2 -[PDFTileSurface releaseSurface] #3 -[PDFTilePool releasePDFTileSurface:] #4 -[PDFPageLayerTile dealloc] ... (see "Independent trigger paths" below for what appears above frame #4) blameFrame: CFRelease.cold.2, CoreFoundation, owner: PLATFORM (Crashlytics-attributed, no app frames anywhere in the crashing thread across any sample). Independent trigger paths observed (all converge on the same 3-frame chain above): Async tile-render completion (our most common variant, ~57% of our occurrences): -[PDFPageLayerTile recievePDFTileSurface:] -> -[PDFPageLayer tileDrawingComplete:] -> old tiles array dealloc -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 Page-turn animation completion: -[PDFDocumentViewController pageViewController:didFinishAnimating:previousViewControllers:transitionCompleted:] -> -[PDFPageView clearTiles] -> -[PDFPageLayer _releaseTiles] -> -[__NSArrayM removeAllObjects] -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 CATransaction commit / layer teardown: CA::Transaction::commit() -> CA::release_root_if_unused(...) -> CA::release_objects(...) -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 (from forum thread 837282, different app) UIScrollView content-offset smooth scroll: -[UIScrollView setContentOffset:] -> smooth-scroll display link -> autorelease pool drain -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 Four independent call sites funneling into the same release path strongly suggests the bug is inside PDFTilePool/PDFTileSurface's own reference counting, not any one caller's usage pattern. Diagnostic instrumentation (our own investigation, not yet submitted anywhere): We swizzled -[PDFTileSurface releaseSurface] in a debug build and logged every call (thread, surface pointer identity, re-entrancy count via a weak-keyed NSMapTable) during normal PDF navigation (page turns, scroll, zoom) on an affected device model. Across all observed calls: every surface was released exactly once, always on the main thread -- no Objective-C-level double-call or cross-thread race was observed at the releaseSurface entry point itself. This suggests the over-release is not "PDFTilePool calling release twice" but more likely a race between PDFTilePool's single, correctly-ordered release call and a separate system-level reclaim of the tile's backing store (e.g. IOSurface/purgeable memory eviction under memory pressure) that PDFTilePool's bookkeeping doesn't account for -- consistent with the device skew below. Device / OS distribution (production Crashlytics, 90-day window, 51 events, ~37 impacted users): iPad12,1 (iPad 9th gen): 45 events (88%) iPad11,7 (iPad 8th gen): 4 events iPad15,4 (iPad Air 11" M3): 1 event iPad11,4 (iPad Air 3rd gen): 1 event 100% on iPadOS 26.5.0 within this window This matches forum thread 837282's own report of "iPad 8, iPad 9 ... lower-end devices heavily affected" on iOS 26.4.2/26.5, "not affected on iOS 18.x" -- independent corroboration from two unrelated codebases of a regression concentrated on lower-RAM iPads specifically on 26.x. Expected Result: PDFKit's internal tile pool releases each rendered tile surface exactly once and does not trap inside CFRelease regardless of memory pressure, device tier, or which internal code path (render-complete, page-turn, layer-commit, scroll) triggers the release. Actual Result: App crashes with EXC_BREAKPOINT inside CFRelease.cold.2 during ordinary PDF viewing (page turns, scrolling, or async tile-render completion), concentrated on lower-RAM iPads (iPad 8th/9th gen) running iPadOS 26.4.2/26.5. Configuration: Plain PDFView (paged, .singlePage, displayDirection .horizontal), no PKCanvasView/PencilKit Affected iPadOS versions: 26.4.2, 26.5 (not reproduced on iOS 18.x per forum thread) Most affected devices: iPad 8th/9th generation (3GB RAM tier) Related report: https://developer.apple.com/forums/thread/837282?answerId=896871022#896871022 (same 3-frame private call chain, different app, DTS could not reproduce with vanilla PDFKit+PencilKit under stress testing as of that thread; no FB filed there yet)

Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

Our app is using react native and native swift code to build an iOS app. We have some screens in both sides need to be protected if user is trying to capture a screenshots of it. We are trying to workaround to implement this screen protection by using UITextField and set isSecureTextEntry = true But there are some issues that we are facing as below: App is hang after go back from a screen that's is protected When app go back from a protected screen there is a black screen show up when screen is transiting back If we do protect entire screen from React Native side, there are leaking memory in react native screen and it can not be free up Do we have any other solution to prevent screenshot or can we fix above issues and continue using UITextField to implement it?

I have a ScrollView with a LazyVStack with Sections. I initialize the ScrollView with a scroll position but the ScrollView starts with the first row at the top. Am I doing something wrong or is this just a bug in ScrollView? It seems to work fine if I do not use Section. struct ContentView: View { @State var scrollPosition: ScrollPosition init() { var p = ScrollPosition(idType: Int.self) p.scrollTo(id: 500, anchor: .top) scrollPosition = p } var body: some View { ScrollView { LazyVStack { ForEach(0..<sectionCount, id: \.self) { j in Section { ForEach(0..<rowCount, id: \.self) { i in RowView(text: "\(j)/\(i) [\(j*rowCount+i)]") .id(j*rowCount+i) } } header: { HeaderView(title: "\(j)") } } } .scrollTargetLayout() } .scrollPosition($scrollPosition) } }

Hi all, Sharing a reproducible UIKit issue I’m seeing across multiple iPadOS 26 betas, with a tiny sample attached and a short video. Short video https://youtu.be/QekYNnHsfYk Tiny project https://github.com/yoasha/ListSwipeOvershootReproSwift Summary In a UISplitViewController (.doubleColumn), a UICollectionView using list layout shows a large leading-swipe overshoot when the split view is expanded (isCollapsed == false). The cell content translates roughly 3–4× the action width. Repros with appearance = .plain and .grouped Does not repro with .insetGrouped Independent of trailing provider (issue persists when trailing provider is nil) Collapsed split (compact width) behaves correctly Environment Devices: iPad Air (3rd gen), iPadOS 26.0 (23A5326a) → Repro Simulators: iPad Pro 11-inch (M4), iPadOS 26.0 beta 6 → Repro Also tested on device: iPadOS 26 beta 5, 6, 7, 8 Xcode: 26.0 beta 6 (17A5305f) Steps to reproduce Launch the sample; ensure the split is expanded (isCollapsed == false). In the secondary list, set Appearance = Plain (also repros with Grouped). Perform a leading swipe (LTR: swipe right) on any row. Actual: content shifts ~3–4× the action width (overshoot). Expected: content translates exactly the action width. Switch Appearance = InsetGrouped and repeat the leading (swipe right) gesture → correct (no overshoot). Feedback Assistant FB ID: FB19785883 (full report + attachments filed; this forum thread mirrors the repro for wider visibility) Minimal code (core of the sample) If anyone from Apple needs additional traces or a sysdiagnose, I can attach promptly. Thanks! // Secondary column VC (snippet) var cfg = UICollectionLayoutListConfiguration(appearance: .plain) // also .grouped / .insetGrouped cfg.showsSeparators = true cfg.headerMode = .none cfg.leadingSwipeActionsConfigurationProvider = { _ in let read = UIContextualAction(style: .normal, title: "Read") { _,_,done in done(true) } read.backgroundColor = .systemBlue let s = UISwipeActionsConfiguration(actions: [read]) s.performsFirstActionWithFullSwipe = false return s } // Trailing provider can be nil and the bug still repros for leading swipe: cfg.trailingSwipeActionsConfigurationProvider = nil let layout = UICollectionViewCompositionalLayout.list(using: cfg) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) // … standard data source with UICollectionViewListCell + UIListContentConfiguration // Split setup (snippet) let split = UISplitViewController(style: .doubleColumn) split.preferredDisplayMode = .oneBesideSecondary split.viewControllers = [ UINavigationController(rootViewController: PrimaryTableViewController()), UINavigationController(rootViewController: SecondaryListViewController()) ]

Since iPadOS 18, UIDocumentViewController has contained a document browser that shows a white page with rounded corners against a background of your choice, with the app name and "Create Document" buttons on the page. For instance, when you launch Pages, you see a white rounded page rectangle against a background of swirly orange, with “Choose a Template” and “Start Writing” buttons on the white page. In Numbers, there’s a green swirly background. In apps built and run on iPadOS 27, however, the white page with rounded corners is entirely missing, making the browser screen very ugly, with the “New Document” button translucent directly against whatever background is set. This can be reproduced simply by creating a new iOS "Document App" in Xcode 27 and building on iPadOS 27. I assume this is a bug, since if you turn on exception breakpoints, you see the following exception breakpoint triggered during launch: Exception = (NSException *) "[<_UIDocumentLaunchViewController 0x10732b200> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _pageContainerView." I have thus reported it as FB23418746. I am curious, though, whether it is a design decision to remove the page background on iPadOS 27, or whether I am missing some sort of setting in the UIDocumentViewController’s launch options for restoring the page. (I hope it’s not intentional, as I like the page, and without it, the black app name gets lost against darker or busier backgrounds.) (I did try to include screenshots showing the issue when I first went to post this message, but doing so resulted in my IP address being blocked access to the forums for a week because of the forums’ new security measures.)

In the iOS Photos app there is a caption field the user can write to. How can you write to this value from Swift when creating a photo? I see apps that do this, but there doesn't seem to be any official way to do this using the Photo library through PHAssetCreationRequest or PHAssetResourceCreationOptions or setting EXIF values, I tried settings a bunch of values there including IPTC values but nothing appears in the caption field in the iOS photos app. There must be some way to do it since I see other apps setting that value somehow after capturing a photo.

Bug ID: FB23168323 Device: iPad Air 13-inch (M3), fully stock iPadOS 27 Public Beta, no jailbreak or system tweaks. I am the original bug reporter for this issue starting from iPadOS 27 Developer Beta 2. This power icon is a brand-new UI element added to Control Center in iPadOS 27, and its gesture logic is broken from launch. The bug still exists fully in the newly released Public Beta build. Problem details: Single tap on the top-right new power icon has no response at all; cannot lock screen as intended. Only long press works normally to bring up power off / restart slider menu. After my initial feedback submission, over 10 duplicate bug reports have been filed by other iPad users. This daily lock screen shortcut is completely unusable now, we have to rely only on the physical power button every day. Hope this new feature UI gesture bug can get prioritized for hotfix in the next beta update. Thank you.

I want to detect when the user stopped touching the screen. But I want it to be in a vertical ScrollView and a DragGesture isn't recognized when the view is scrolled vertically. I'm guessing this is because there wasn't anything dragged, since the view moved along with the user's finger. import SwiftUI struct TestView: View { var body: some View { ScrollView { VStack(spacing: 0) { Rectangle() .foregroundStyle(.green) .frame(height: 700) } } .gesture(DragGesture().onEnded({ _ in print("Drag gesture ended") })) } } How should I go about detecting when the user lifted their finger off the screen on a scrollview?

Hi everyone, I'm using an iPhone 13 running the iOS 27 Public Beta, and overall the experience has been excellent. Battery life is better than I expected, and the system feels very smooth during everyday use. However, I'm experiencing one persistent issue while playing Call of Duty: Mobile (CODM). Whenever an iOS system UI appears, the game briefly stutters or drops frames. This happens with: Pulling down the Notification Center The volume indicator (Volume HUD) Other iOS overlays or system UI animations The stutter only lasts for a moment while the UI is displayed, and gameplay immediately returns to normal if I open the full control center (swiping down). The frame drops will be also gone when I change the frame rate from MAX to Low then Low to MAX frame rate. Things I've already tried: Restarting the device -Enabling Shader Preload in CODM -Closing background apps -Testing different graphics and frame rate settings (which is a temporary solution) -Updating to the latest iOS 27 Public Beta The issue was also present on my previous iOS version, so it doesn't appear to be new to this beta. During normal gameplay, the game runs smoothly. The frame drops only occur when iOS overlays are rendered. Has anyone else experienced this on iPhone, particularly on iPhone 13 or other models? I'm also curious whether this is an iOS compositor issue, a CODM optimization issue, or simply expected behavior when system UI interrupts a game. Any feedback or suggestions would be greatly appreciated. Thank you!

Area: UIKit / Files / Document Picker (or Safari / WebKit if that category fits better — root UI is Files) Summary On iPhone Air running iOS 26.4 (also reproduced on iPhone Air Simulator with iOS 26.5), presenting the system file picker freezes / becomes unresponsive. The same build and the same iOS major version work correctly on iPhone 17 Pro. This happens for BOTH: WKWebView default file upload panel triggered by Native UIDocumentPickerViewController presented from UIKit So this is not specific to WKWebView’s WKFileUploadPanel alone — it appears to be a Files / File Provider UI issue on iPhone Air. Environments FAILS: Device: iPhone Air (model identifier iPhone18,4) OS: iOS 26.4 (production customer report) Also: iPhone Air Simulator, iOS 26.5 — same freeze WORKS: Device: iPhone 17 Pro (simulator and comparison testing) OS: same iOS 26.x line Also: iOS 18.4 Simulator — file picker works Steps to Reproduce A) Via WKWebView (HTML file input) Open an app that hosts a WKWebView loading a page with Tap the control that triggers file selection System Files UI appears (often on “Recents” / 最近项目) B) Via native UIDocumentPickerViewController Present UIDocumentPickerViewController(forOpeningContentTypes:asCopy: true) for image/pdf types allowsMultipleSelection = true modalPresentationStyle = .fullScreen (also tried default sheet) Actual Results UI opens but hangs / freezes Typical UI state: empty white content area Tabs may still show Recents / Shared / Browse On Browse → “On My iPhone”, content area stays blank and UI is unresponsive Cancel / switching tabs often does not work User cannot select a file; must force-quit the app Expected Results Document picker remains interactive; user can browse and select files (as on iPhone 17 Pro with the same OS). Comparison Environment File picker iPhone Air + iOS 26.4 (device) Freeze iPhone Air Simulator + iOS 26.5 Freeze iPhone 17 Pro + iOS 26.x OK Simulator iOS 18.4 OK Photo library / UIImagePicker OK on Air Photo/camera pickers work on iPhone Air. Only the Files / document picker path fails. Impact Production customers on iPhone Air + iOS 26.4 cannot upload documents (PDF/files) in our hybrid insurance app (WKWebView). Image upload via photo library still works. This blocks claims / document upload flows for Air users. Notes / attempts Not fixed by switching from WKWebView to UIDocumentPickerViewController not fixed by asCopy: true not fixed by fullScreen presentation not fixed by setting / clearing directoryURL App-side workarounds (camera / photo library only) avoid Files UI but do not restore true file picking Please investigate Files / Recents / On My iPhone enumeration hang specific to iPhone Air on iOS 26.4+. Attachments to add Screen recording: freeze on iPhone Air Screen recording: same steps on iPhone 17 Pro (works) Screenshots of frozen Recents / Browse empty state sysdiagnose from iPhone Air if possible (Settings → Privacy & Security → Analytics, or instruct via Feedback Assistant)

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

I've filed this as FB23714849 too, but I'm running into an issue with the Toggle component when displayed in a toolbar and a more complex label is used. This worked fine in iOS 26. Minimal repro example + screenshot: struct ContentView: View { @State var toggleState1 = false @State var toggleState2 = false var body: some View { NavigationStack { Text("Hello, world!") .toolbar { // THIS ITEM (leading) WORKS AS EXPECTED ToolbarItem(placement: .topBarLeading) { Toggle("Working", systemImage: "heart", isOn: $toggleState2) } // THIS ITEM (trailing) DOES NOT TOGGLE AS EXPECTED // It always appears enabled even when it should not ToolbarItem(placement: .topBarTrailing) { Toggle(isOn: $toggleState1) { Image(systemName: "star") } } } } } } My ultimate goal is to have a menu here where I can make the menu's label appear as a selected toggle (e.g. to display that one of a few filters is enabled). This is the case as of iOS Developer Beta 3 (and I believe the prior iOS 27 betas).

I have an app that uses UIToolbar and UIBarButtonItem, I create the bar button items using init(customView:), but I need them to be larger than the default toolbar item size, so I constrain the custom views to be larger, such as 50x50. Example: let button = UIButton(type: .system) button.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ button.widthAnchor.constraint(equalToConstant: 50), button.heightAnchor.constraint(equalToConstant: 50), ]) let item = UIBarButtonItem(customView: button) toolbar.items = [item] This worked on iOS 26 and would show a circular glass button. But on iOS 27 the button shows as an oval where the height seems capped at 44pt, and can't be made any taller. This has been an issue for all iOS 27 betas so far, and I've already filed this as a feedback (FB23641020). Has anyone else seen this issue or found a workaround?

On iOS 26 (reproduced on both Simulator and iPhone), the system share sheet (UIActivityViewController) displays the row of activity/app icons at a greatly oversized scale. The app's approximate hierarchy is like UIWindow.rootViewController → a plain container UIViewController → UITabBarController → an embedded container child → UINavigationController → the visible screen. When the share sheet is presented from a view controller inside such an hierarchy, the icons are oversized. When the same UIActivityViewController, with the exact same activity items, is presented from a full-screen modal view controller (modalPresentationStyle = .fullScreen / .overFullScreen), the icons render correctly. Is this a bug of iOS 26+? On iOS 27 the behaviour is the same.

Hello dear Apple Engineers and fellow developers. Today I was crafting my new App Icon with Icon Composer and I was wondering how I can support alternative App Icons. I couldn't find any documentation about it yet. Is it already supported? Will it be supported soon?

When I use an inline search bar on a screen and the keyboard is opened, we can see an odd blur in the final place first before the keyboard finishes the move

https://gist.github.com/MorusPatre/4b1e93973c3e4133794512fd7eefee48 This Is a Test App to find out how to actually achieve the exact sidebar styling Apple uses for Finder, Photos etc. The crucial part is how do I make it so the symbol and name of the selected row use the accent colour with active and inactive styling rather than having the accent colour for the row background? It shouldn't be that complicated I feel like but every AI model (even Claude Fable 5) fails at that and I haven't found apps or videos where that is explained so is that just a classic case of "Apple doesn't want you to know"?

recently I found crash issue on my iOS 16 device. If I kill the app process and re-launch it quickly, the app will crash occasionally without any hints nor messages this is only happed when the app's main page is attached a visual effective view on top of it. while I remove the visual effective view, the crash never happened again. could anybody tells me what is going wrong with the effective view, and how to fix it. thank you.

Description: When following Apple's WWDC guidance to hide the default Liquid Glass background on a ToolbarItem using .sharedBackgroundVisibility(.hidden) and draw a custom circular progress ring, a rectangular rendering artifact appears during navigation bar transition animations (e.g., when the navigation bar dims/fades during a push/pop transition). Steps to Reproduce: Create a ToolbarItem with a custom circular view (e.g., a progress ring using Circle().trim().stroke()). Apply .sharedBackgroundVisibility(.hidden) to hide the default Liquid Glass background. Navigate to a detail view (triggering a navigation bar transition animation). Observe the ToolbarItem during the transition. Expected Result: The custom circular view should transition smoothly without any visual artifacts. Actual Result: A rectangular bounding box artifact briefly appears around the custom view during the navigation bar's dimming/transition animation. The artifact disappears after the transition completes. Attempts to Resolve (All Failed): Using .frame(width: 44, height: 44) with .aspectRatio(1, contentMode: .fit) Using .fixedSize() instead of explicit frame Using Circle().fill() as a base view with .overlay for content Using Button with .buttonStyle(.plain) and Color.clear placeholder Various combinations of .clipShape(Circle()), .contentShape(Circle()), .mask(Circle()) Workaround Found (Trade-off): Removing .sharedBackgroundVisibility(.hidden) eliminates the rectangular artifact, but this prevents customizing the Liquid Glass appearance as intended by the API. Code Sample: swift if #available(iOS 26.0, *) { ToolbarItem { Button { // action } label: { Color.clear .frame(width: 32, height: 32) .overlay { ZStack { // Background arc (3/4 circle) Circle() .trim(from: 0, to: 0.75) .stroke(Color.blue.opacity(0.3), style: StrokeStyle(lineWidth: 4, lineCap: .round)) .rotationEffect(.degrees(135)) .frame(width: 28, height: 28) // Progress arc Circle() .trim(from: 0, to: 0.5) // Example: 50% progress .stroke(Color.blue, style: StrokeStyle(lineWidth: 4, lineCap: .round)) .rotationEffect(.degrees(135)) .frame(width: 28, height: 28) Text("50") .font(.system(size: 12, weight: .bold)) .foregroundStyle(Color.blue) Text("100") .font(.system(size: 8, weight: .bold)) .foregroundStyle(.primary) .offset(y: 12) } .background { Circle() .fill(.clear) .glassEffect(.clear.interactive(), in: Circle()) } } } .buttonStyle(.plain) } .sharedBackgroundVisibility(.hidden) // ⚠️ This modifier causes the rectangular artifact during transitions } Environment: iOS 26 Beta