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.

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?

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?

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

What are the performance implications of building an app that is effectively single-threaded (for example, heavily isolated to @MainActor) versus one that allows work to execute across multiple executors and threads?

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

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.

I want to connect a BluetoothHFP microphone to MFi hearing aids. Whenever I make the microphone the input it steals the output and whenever I make the MFi the output it steals the input. Is it possible to do this using AVAudioSession? Is it possible to redefine the MFi hearing aids as a speaker and use Live Listen?

I was recently charging my macbook, just like any normal time i do. i expected to see the battery at 80%, but the macbook was hiding a surprise for me. the magsafe glowed amber, so i knew it cant be on 80%, so when i opened the lid, the surprise was a shocking 94%. I didn't know what to expect, but my macbook is running macOS tahoe 26.5, so everything seemed normal to me until: someone please help in fixing this bug, as it isn't the first time this happens to me. please link this to my magsafe 4 idea here, as the magsafe could activate pulsing amber (1 second on 1 second off, for both amber and yellow pulsing lights) in case of failure to stop on set limit, making it visually much easier to understand if there is an issue.

I have encountered the following issue on iPadOS. Has anyone experienced this issue or reported it before? Steps to Reproduce Enable Windowed Apps mode in Settings. Launch the Settings app and another app (App X), and display both in windowed mode. Use the Settings app to completely cover App X (App X becomes inactive at this point). From the Settings app, enable Full Screen Apps mode. Bring App X to the foreground. Expected Result App X becomes active when brought to the foreground. Actual Result Even after bringing App X to the foreground, it immediately becomes inactive. The issue persists even if App X is restarted. To resolve the issue, it is necessary to either restart the iPad or switch back to Windowed Apps mode. Verified OS Versions iPadOS 26.5: Reproducible iPadOS 26.4.2: Reproducible iPadOS 26.2: Not reproducible iPadOS 26.0.1: Not reproducible Additional Information According to the console logs, App X appears to remain inactive because the deactivation reason "sceneOverlap" persists.

After macOS update to 26.5 (25F71), I observed the Return key does not work in interaction with Terminal’s “New Remote Connection” window, but only the first interaction with the window. Launch Terminal Open New Remote Connection window Use the keyboard or mouse to select a Service, like Secure Shell Pick a Server, either static or Discovered Pressing Return used to launch the appropriate command (because the Connect button is lit/colored), but now the system error sound occurs. Either the mouse must be used on this first interaction, or I have to use keyboard shortcuts (tab) to highlight the Connect button where I can press either Space or Return. After that first interaction, the Return key functions per normal UI rules.

On iOS 26 (26.0–26.5), a rectangular region in the lower half of the screen sometimes does not render while the content underneath remains laid out and interactive — scrolling works, hit testing succeeds, and rows visibly emerge from behind the floating tab bar as you scroll. This is a render-server / compositor gap, not a layout or safe-area issue. We see it on both UIKit and SwiftUI scroll surfaces inside the same UITabBarController: UIKit: UICollectionView with UICollectionViewFlowLayout (sectionInsetReference = .fromSafeArea) SwiftUI: List(.plain) nested in TabView(.page) inside a UIHostingController Confirmed on iPhone 16 Pro, iPhone 17 Pro, iPhone 13 Pro Max. Community threads (linked below) report the same symptom in Messages, Notes, Safari, Mail, and the App Store. Questions for Apple Is this acknowledged as an OS-level regression, and is a fix targeted for an upcoming iOS 26.x release? Is there a deterministic repro? We've tried background/foreground cycles, push notifications mid-scroll, tab switches during inertia, lock/unlock, orientation flips, simulated memory warnings, layout-invalidation storms, and trait-collection cycles — none reliably trigger it on our test devices. Is there a developer-side mitigation (e.g. avoiding specific UIVisualEffectView / Glass configurations, opting out of a rendering optimization) until a system fix lands? Is there a runtime signal on CALayer or UIScrollView we can inspect to detect this gap state and force a recovery (tile redraw, backing-store discard, etc.)? Notes We cannot reproduce locally. Affected users hit it organically; once it appears it persists across re-layout until the view controller is torn down. Community reports consistently mention Reduce Transparency being enabled on affected devices, and toggling it off clears the issue for many. In our own testing, RT alone is not sufficient to trigger the bug — it appears to be a contributing condition rather than the trigger. References: Apple Discussions: https://discussions.apple.com/thread/256182149 Reddit r/ios (multiple system apps): https://www.reddit.com/r/ios/comments/1nlzn7f/some_apps_cutting_off_half_the_display/ https://www.idownloadblog.com/2026/03/23/webpage-content-cutting-off-safari/

Just posted this feedback regarding macOS 26 "Tahoe" (FB19853155) - please support with additional submissions if you share my view. I will miss the beautiful and individual designed icons of the past! "macOS 26 is enforcing squicles for app icons, falling back to a grey background for 3rd party apps without a compliant AppIcon asset. As a result many original app icons are reduced in size and hard to distinguish because they share the same background color. Although I respect Apple's strive for an iOS-like UI on Macs, a smooth transition path would be more user- and developer-friendly ... e.g. with some info.plist property to opt-out icon migration, potentially ignored by a future macOS version. The current solution causes a bad usability, and makes the system look inconsistent as many - especially free - software will not be updated with new icon designs. Please reconsider this bad design decision!"