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

When cacluclating directions for .cycling, the returned route has directions.routes.first!.transporttype == .automobile if I follow the example What do I do wrong? Is this a bug? Tested on macOS 26 and iOS simulator 26

I'm really struggling to get a handle on all the different aspects of Control Widgets. I wish the docs led with comprehensive visual examples. I'm trying to make a Control Widget that shows the user a quick status of something (on or off), and lets the user change that status, but when they turn it off, it can be turned off for a period of time. I want to present some options in a manner similar to the Focus widget. When you first display widets on macOS, you get this: On the Focus widget, see how it has a round button with a moon, the word "Focus", and a disclosure chevron? I want to reproduce that. If you click the moon button, it turns that focus mode on. If you click anywhere else, it shows this: And even those controls are quite fancy, expanding when you click on them. How do I get that second level of UI?

I'm looking for a way to prevent my app from displaying in screenshots and screen recordings. There appears to be plenty of options for UIKit/iOS but nothing I can find for macOS. userDidTakeScreenshotNotification @Environment(.sceneCaptureState) private var captureState Obviously it's possible though as I remember back in the day you couldn't take screenshots of the DVD Player etc.

I'm trying to nail down the correct mental model for keeping a push-to-start Live Activity updatable, and want to confirm my understanding rather than design around an assumption. Flow: my server creates the activity via push-to-start, then I capture its per-activity token (Activity.pushTokenUpdates) and send it to the server for update/end pushes. I observe Activity.activityUpdates and also prime from the Activity.activities snapshot at launch and on foreground. What I'd like to understand for each app state: Foreground / backgrounded (in memory): I capture the token reliably — is that the intended guarantee? System-terminated (jettisoned for resources): does the system relaunch the app in the background to deliver the per-activity token, and is that something I can rely on? User force-quit (swiped from the App Switcher, not reopened): what should I expect here for per-activity token delivery, and what's the recommended strategy if the app stays force-quit — e.g. stale-date on the start push for graceful expiry, or any extension-based path? Essentially: across these states, what's the supported strategy to keep a push-started Live Activity correct? Tested on iOS 18 and 26. Related question from the implementation side: https://developer.apple.com/forums/thread/834934

I tried Glass in NSApp.dockTile.contentView. Any Glass there isn't shown like it normally is in windows. Does this limitation exist intentionally?

Bug 1 strange little square↗ Bug 2 Sometimes half of the time would disappear so maybe the time is under the things on the right

It seems like the automatic edge effect defaults to hard in iOS 27 and soft on iOS 26. Designing for both of these is actually quite difficult - especially since hard edge effects don't work with pinned views in LazyVStack. Is there a way to set the global default to soft for an app?

Hi, I am using the CPPointOfinterestTemplate and wanted to change the trailingNavigationBarButtons when the user navigate to detail screen(This is done with the help of didSelectPointOfInterest delegate function). However i could not find any documentation on resetting the trailingNavigationBarButtons when the user click on the "X"/Close button on the details screen. Can you explain if there is any way i can handle my