Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

We are experiencing issues during extended automated test executions on iOS devices. During long-duration test runs that involve a high volume of interactions with the device under test, the socket connection is unexpectedly terminated. When this occurs, the automation session is disrupted and the test run fails. We would like to better understand the root cause of this behavior and determine whether it is related to the automation framework, the underlying iOS platform, or another system-level constraint. We have the following questions: Are there any iOS security mechanisms or system protections that may be triggered after a high number of automated interactions, resulting in the termination of an active socket connection? Does iOS impose any runtime limitations, session timeouts, resource restrictions, or inactivity thresholds that could impact long-running automation sessions? Are there any known conditions under which iOS may terminate or reset socket connections during extended periods of intensive device interaction? Any guidance on troubleshooting steps, relevant system logs, or known platform limitations would be greatly appreciated.

I've found a repeatable difference in input-to-display latency on macOS depending only on how an application is launched. Launching an application normally: open -n /Applications/App.app consistently produces higher latency than directly running the exact same bundled executable: /Applications/App.app/Contents/MacOS/App I've reproduced this with a minimal Qt QPlainTextEdit application as well as Koi, Xcode, BBEdit, Sublime Text, and Zed. It reproduces across: Mac mini M2 Pro, macOS Sequoia 15.7.9 MacBook Air M4, macOS Tahoe 26.6.1 Minimal reproduction The Qt application is essentially just: import sys from PyQt6.QtWidgets import QApplication, QPlainTextEdit app = QApplication(sys.argv) editor = QPlainTextEdit() editor.resize(1200, 800) editor.show() sys.exit(app.exec()) I package this as a normal .app and compare: open -n dist/QtLaunchTest.app with: dist/QtLaunchTest.app/Contents/MacOS/QtLaunchTest Input-to-display latency is measured externally from generated keyboard input through to the corresponding visible pixel change on the display, with 200 measurements per run. Results (Launch method, avg, p95, p99) At 60 Hz: Open normally, 29.676 ms, 37.742 ms, 43.080 ms Direct Mach-O, 16.404 ms, 20.500 ms, 24.882 ms The p95 difference is 17.242 ms, compared with a 60 Hz frame interval of 16.667 ms. At 100 Hz: Open normally, 24.687 ms, 31.182 ms, 33.797 ms Direct Mach-O, 16.295 ms, 20.623 ms, 23.286 ms The p95 difference is 10.559 ms, compared with a 100 Hz frame interval of 10.000 ms. That relationship is what makes me suspect this is related to presentation/frame scheduling rather than application processing. This also happens with Xcode The same effect occurs when comparing normal and direct launches of Xcode. (Launch method avg p95 p99) On macOS Sequoia 15.7.9: Open normally, 23.433 ms, 29.886 ms, 31.877 ms Direct Mach-O, 15.787 ms, 19.494 ms, 20.480 ms On macOS Tahoe 26.6.1 on an M4 MacBook Air: Open normally, 35.830 ms, 40.122 ms, 53.996 ms Direct Mach-O, 23.639 ms, 27.233 ms, 37.855 ms Koi, BBEdit, Sublime Text, and Zed show the same direction of effect. Things I’ve ruled out so far The difference does not appear to be caused by Terminal. Direct execution remains fast after detaching the process, and using open on the Mach-O itself is also fast. Different LaunchServices forms (open -n, open -na, open -nb, open -b) all produce the slower behavior. I've also compared process QoS and final AppKit activation state, which are the same. Most importantly, application-side instrumentation does not show the additional latency. Input processing and painting complete quickly in both cases. The difference appears only when measuring through to the actual pixel change on the display. Question Is there some presentation, WindowServer, Core Animation, RunningBoard, or application-lifecycle state established when an application is launched through LaunchServices that could affect when completed rendering reaches the display? The refresh-rate result makes it look as though the normally launched application is reaching the display approximately one presentation opportunity later: Direct: input → update → paint → presentation N Normal: input → update → paint → presentation N+1 That's only a model based on the measurements. I haven’t directly observed the presentation sequence. I'm particularly interested in what APIs or Instruments traces could expose the difference between these two processes after they’ve reached the same active AppKit state. I've documented the full investigation, including additional measurements and tests, here: https://hackerman.ai/research/investigating-macos-input-to-display-latency/ Any pointers on what to instrument next would be appreciated.

Hello. Some users of my app experience crashes that mention PDFKit. I managed to find out what specific PDF file caused the crash and created a sample that demonstrates the issue and created a bug report in Feedback Assistant (FB22409977). Unfortunately I didn't get any answer for over a month, hence I'm writing it here so others can see that this is a known issue. The crash repro sample is very simple, it's just a PDFView that opens a bundled PDF file upon application lanunch. To cause the crash it is only needed to zoom-in and move around the page that has a table. The crash happens when the system tries to do some sort of OCR. The original crash report came from iPhone 11 user running iOS 26.3.1. Recently another user with iPhone 16 Pro Max running 26.5 experienced the same crash. Thread 12 Queue : PDFKWit.PDFDocument.formFillingQueue (serial) #0 0x000000018d320bd8 in PageLayout::GetBoundsForRangeWithinLine () #1 0x000000018d320c88 in PageLayout::GetBoundsForTextRange () #2 0x000000018d393028 in CGPDFTaggedNodeCreateCopyWithStringRange () #3 0x000000018d316630 in invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) () #4 0x000000018d104f00 in CGPDFPageEnumerateAnnotations () #5 0x000000018d106968 in CGPDFPageCopyRootTaggedNode () #6 0x000000018d106710 in CGPDFPageInsertTableDescriptions () #7 0x00000001957a65b8 in +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] () #8 0x00000001957a3030 in +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] () #9 0x000000019584c018 in __31-[PDFView visiblePagesChanged:]_block_invoke () When CG_PDF_VERBOSE env variable is set, "New text range needs to be within the original node's text range." warning is printed to console several times before the crash happens.

Dear Apple, I am sending feedback regarding the desktop management of macOS to improve the user experience. Mission Control currently only has a “+” button to the right, meaning that all new desktops are forced to the right side of the line. Adding an identical “+” button to the left will increase ease of using the OS, as I don’t necessarily need every new desktop to be on the right side. This will increase usability and make using desktops significantly easier than manually dragging them into the needed positions every time I add a desktop. Another thing is that when I maximize apps, all desktops go to the left by one spot. There should be a setting where you can control where desktops go when maximizing screens, either you want every desktop to go to the right or the left. This makes things easier as sometimes I have my main app on the right, with all the multi-tasking on the left. If desktops move to the right instead of the left, no open apps will be interfered with. (Please put this setting in the “Desktop and Dock” section). I have been using macOS for a year now, and those details were quite clear. Please consider this as a software update for over 100 million Macbook users, increasing usability without changing the OS so much people barely know how to use it. I have been concentrating significantly on macOS lately, noticing an upgrade followed by another, and is how I noticed this. Please consider this a fresh start for my feedback. I apologize for my previous un-trained replies. I am not a trained professional, but I genuinely care about improving the user experience and wanted to share these layout ideas. I promise to keep my interactions respectful of the forum guidelines from now on. May these desktop management ideas be considered? Thanks, Alyaman

Heya, Been struggling with getting a 3 column NavigationSplitView hide both the Sidebar and Content column to only show the Detail view and back to 3 columns in the same window. Basically applying the hide sidebar when pressing the toggle to both the sidebar and the content view. On iOS I could use .displaydetail but on macOs it seems impossible to do as one or the other shows up. I was able to force it to a width of 0 but that gives other issues such as the need to disable the animates otherwise things start flying. Any ideas on how to solve this? ideally we would have something as a double sidebar or a split view that does not extend that nav to all columns as thats a pain to deal with.

Is there currently an option to make generated asset symbols public? If not, would it be possible to set the generated asset symbol so they are public. It's quite common to have an apps design system implemented in a separate framework. Currently the generate assets symbols is useless for this as they can't be access in the framework consumer. It would be great to add it to this new dropdown in Xcode 16 or along side it. (113704993 in the release notes) So the options would be Internal, Public and Off. This should affect the symbols, the extensions and the framework support. (There's a post on the swift forums about this as well here: https://forums.swift.org/t/generate-images-and-colors-inside-a-swift-package/65674)

We're preparing our SDK and host applications for iOS 27 and would like to understand the mandatory requirements for supporting the new Liquid Glass design. Beyond building with the iOS 27 SDK, are there any required implementation or migration steps (UIKit or SwiftUI) that developers must adopt to ensure full compatibility? Are there any behaviors or APIs that require explicit changes, or does the system automatically handle Liquid Glass for standard controls? We're specifically interested in the minimum required changes for compliance and compatibility, rather than optional design enhancements. Thanks in advance for any guidance.

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!

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)

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.

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!

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?

Apple Pencil Pro 'double tap' stopped working after most recent iPadOS 27 Developer Beta. I use the pencil every day/every other day, so it's probably a bigger issue for me than most that might have the same issue. Squeeze still works, but I use that for changing the tool pallet. I've tried restarting the tablet multiple times, forgetting and re-pairing the pencil, as well as tweaking the settings that were suggested in other posts from years ago. At this point, I'm hoping that it is a Beta issue, but curious if anyone else on iPadOS 27 is having the same issue or if there's anyone that has had the same issue on a non-Beta version of iPadOS 26.

I'm working on adding Live Activities to my app but I'm running into a problem, and I'm wondering if anyone knows what's going on. The live activities are started and updated entirely via push notifications (sent through FCM). On the lock screen, updates come through fine for a while, but then the activity gets stuck while the phone is locked. The moment I unlock the device, it immediately jumps to the latest state. I've tried different update frequencies and sending with both priority 5 and priority 10, but no luck. I've also looked through the liveactivitiesd logs, but I'm not really sure what I should be looking for. And yes, NSSupportsLiveActivitiesFrequentUpdates is enabled.

Since iOS 18.3, icons are no longer generated correctly with QLThumbnailGenerator. No error is returned either. But this error message now appears in the console: Error returned from iconservicesagent image request: <ISTypeIcon: 0x3010f91a0>,Type: com.adobe.pdf - <ISImageDescriptor: 0x302f188c0> - (36.00, 36.00)@3x v:1 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: B19540FD-0449-3E89-AC50-38F92F9760FE error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request} Does anyone know this error? Is there a workaround? Are there new permissions to consider? Here is the code how icons are generated: let request = QLThumbnailGenerator.Request(fileAt: url, size: size, scale: scale, representationTypes: self.thumbnailType) request.iconMode = true let generator = QLThumbnailGenerator.shared generator.generateRepresentations(for: request) { [weak self] thumbnail, _, error in }

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

A CarPlay app with the carplay-fueling entitlement displays a list of stations. Tapping a station hands off to the Maps app for directions and navigation. Sometimes the handoff will return unsuccessful from the open call. The first attempt will succeeed. I immedediately return to my app and select a different station. The second attemp may succeed or it may fail. If the handoff attempt fails I can switch to the Maps app, return to MyApp, tap the same station row that just failed and the handoff will succeed. The issue is across multiple iOS versions (18 and 26) and multiple devices. Looking at the sysdiagnose logs, a successful handoff looks like this: 2026-06-26 15:56:27.762040 lsd: pid 14570 requests to open URL with scheme <private> 2026-06-26 15:56:27.768475 lsd: [FBSSystemService][0xee43] Sending request to open "com.apple.Maps" 2026-06-26 15:56:27.782145 lsd: [FBSSystemService][0xee43] Request successful: <BSProcessHandle ... Maps:17170; valid: YES> A failed handoff looks like this: 2026-06-26 17:05:00.162432 lsd: pid 14570 requests to open URL with scheme <private> 2026-06-26 17:05:00.171618 lsd: [FBSSystemService][0x3d16] Sending request to open "com.apple.Maps" 2026-06-26 17:05:00.173776 SpringBoard: Received request to open "com.apple.Maps" with url "maps:<private>" from lsd:122 on behalf of MyApp:14570. 2026-06-26 17:05:00.174110 SpringBoard: Received untrusted open application request for "com.apple.Maps" from <FBApplicationProcess ... app<au.com.philk.MyApp>:14570> 2026-06-26 17:05:00.175103 SpringBoard: Open "com.apple.Maps" request from lsd:122 failed with error: FBSOpenApplicationServiceErrorDomain; code: 1 ("RequestDenied") Reason: Application au.com.philk.MyApp is neither visible nor entitled, so may not perform un-trusted user actions. Underlying: FBSOpenApplicationErrorDomain; code: 3 ("Security") Looking more closely at the logs, the template UI is brought forward: CarPlay: DBApplicationSceneHostViewController; au.com.philk.MyApp; proxy: com.apple.CarPlayTemplateUIHost RunningBoard briefly grants MyApp foreground / render assertions: Foreground Template App FBWorkspace (ForegroundFocal) Set darwin role to: UserInteractiveFocal visibility is yes However, SpringBoard also records MyApp as background: 2026-06-26 17:04:53.709527 SpringBoard: Application process state changed for au.com.philk.MyApp: taskState: Running; visibility: Background The denied open at 17:05:00 appears to use SpringBoard's application visibility/trust decision, not the fact that the user is actively interacting with MyApp's CarPlay template UI. The following is logged: Application au.com.philk.MyApp is neither visible nor entitled, so may not perform un-trusted user actions. I have tried two different ways to pass/open the URL, and both will fail, usually after the first attempt. A plain maps:// URL Creating a MapItem and using: MKMapItem.openInMaps(launchOptions:from:completionHandler:) I wonder if this is the same or similar bug to the one reported here? https://developer.apple.com/forums/thread/787788?answerId=843556022#843556022 What is the root cause of the random failures? Any help or pointers will be appreciated.

I have filed a bug report for this (FB17734946), but I'm posting it here verbatim in case others have the same issue and in hopes of getting attention from an Apple engineer sooner. When calling setNeedsDisplayInRect on a CATiledLayer - or a UIView whose backing layer is CATiledLayer - one would expect to re-draw only a region identified by the rect passed to the method. This is even written in the documentation for the class: "Regions of the layer may be invalidated using the setNeedsDisplayInRect: method however the update will be asynchronous. While the next display update will most likely not contain the updated content, a future update will." However, upon calling this method, CATiledLayer redraws whole contents instead of just the tile at the specified rect, and it flashes when doing so. It behaves exactly the same as if one had called setNeedsDisplay without passing any rect; all contents are cleared and re-drawn again. I'm 100% sure I've passed in the correct rect of the exact tile that I need to redraw. I have even tried passing much smaller rects, but still the same. (And yes, the rect I've passed accounts for the current level of detail.) I have found this GitHub repo https://github.com/frankus/NetPhotoScroller, which based on discussion from here https://forums.macrumors.com/threads/catiledlayer-blanks-out-tiles-when-redrawing.1333948/ aims at solving these issues by using two private methods on CATiledLayer class: (void)setNeedsDisplayInRect:(CGRect)r levelOfDetail:(int)level; (BOOL)canDrawRect:(CGRect)rect levelOfDetail:(int)level; I have explored the repo in detail, however I wasn't able to test exactly this code from the GitHub repo. I have tried using those two private methods myself (through an Objective-C class that defines the methods in the header file and then a swift class which inherits it), but I couldn't solve the issue; the flashing and the full re-draw is still there. After doing a lot of research, the conclusion seems to be that one cannot use CATiledLayer with contents that are downloaded remotely, on demand, as tiles are being requested. I have, however, found one interesting thing which seems to work so far: before calling setNeedsDisplayInRect (or just setNeedsDisplay, as they behave the same for CATiledLayer in my testing), cache the current layer's contents, and after calling setNeedsDisplay (or setNeedsDisplayInRect), restore the contents back to the layer. This prevents flashing and preserves any tiles that were drawn at the time of the re-draw. let c = tiledLayer.contents tiledLayer.setNeedsDisplay(tileRect) tiledLayer.contents = c However! Docs clearly state the warning: Do not attempt to directly modify the contents property of a CATiledLayer object. Doing so disables the ability of a tiled layer to asynchronously provide tiled content, effectively turning the layer into a regular CALayer object. I believe this message implies modifying the contents property with some raw content, like image data, and that it may be safe to re-apply the existing contents (which are in my testing of type CAImageProvider) -- but I can't rely on an implementation detail in my production app. I have tested this and confirmed that the bug appears on: iPhone 14 Pro, iOS 18.5 iPhone 13 Pro, iOS 17.5.1 iPhone 5s, iOS 15.8.3 iPad Pro 1st gen, iPadOS 18.4.1 a couple simulator versions I can also confirm that the fix (to re-apply contents property) is also working properly on all these versions. Is this expected behavior, that tiled layer redraws itself entirely instead of redrawing specific tiles? Is it safe to modify contents of a CATiledLayer by re-applying the existing contents? If not, is there an alternative to avoid flashing?

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki