Hi! I'm updated to iOS 27 beta and see the navigationView with title is not translucid & grandient anymore, how to make it translucid and gradient back? Example in iOS 26 and iOS 27

I want use SensorKit data for research purposes in my current app. I have applied for and received permission from Apple to access SensorKit Data. I have granting all the necessary permissions. But no data retrieved. I am using didCompleteFetch for retrieving data from Sensorkit. CompleteFetch method calls but find the data. Below is my SensorKitManager Code. import SensorKit import Foundation protocol SensorManagerDelegate: AnyObject { func didFetchPhoneUsageReport(_ reports: [SRPhoneUsageReport]) func didFetchAmbientLightSensorData(_ data: [SRAmbientLightSample]) func didFailFetchingData(error: Error) } class SensorManager: NSObject, SRSensorReaderDelegate { private let phoneUsageReader: SRSensorReader private let ambientLightReader: SRSensorReader weak var delegate: SensorManagerDelegate? override init() { self.phoneUsageReader = SRSensorReader(sensor: .phoneUsageReport) self.ambientLightReader = SRSensorReader(sensor: .ambientLightSensor) super.init() self.phoneUsageReader.delegate = self self.ambientLightReader.delegate = self } func requestAuthorization() { let sensors: Set<SRSensor> = [.phoneUsageReport, .ambientLightSensor] guard phoneUsageReader.authorizationStatus != .authorized || ambientLightReader.authorizationStatus != .authorized else { log("Already authorized. Fetching data directly...") fetchSensorData() return } SRSensorReader.requestAuthorization(sensors: sensors) { [weak self] error in DispatchQueue.main.async { if let error = error { self?.log("Authorization failed: \(error.localizedDescription)", isError: true) self?.delegate?.didFailFetchingData(error: error) } else { self?.log("Authorization granted.") self?.fetchSensorData() } } } } func fetchSensorData() { guard let fromDate = Calendar.current.date(byAdding: .day, value: -1, to: Date()) else { log("Failed to calculate 'from' date.", isError: true) return } let fromTime = SRAbsoluteTime.fromCFAbsoluteTime(_cf: fromDate.timeIntervalSinceReferenceDate) let toTime = SRAbsoluteTime.fromCFAbsoluteTime(_cf: Date().timeIntervalSinceReferenceDate) let phoneUsageRequest = SRFetchRequest() phoneUsageRequest.from = fromTime phoneUsageRequest.to = toTime phoneUsageRequest.device = SRDevice.current let ambientLightRequest = SRFetchRequest() ambientLightRequest.from = fromTime ambientLightRequest.to = toTime ambientLightRequest.device = SRDevice.current phoneUsageReader.fetch(phoneUsageRequest) ambientLightReader.fetch(ambientLightRequest) } // ✅ Delegate Methods func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) { Task.detached { if reader.sensor == .phoneUsageReport { if let samples = reader.fetch(fetchRequest) as? [SRPhoneUsageReport] { DispatchQueue.main.async { [weak self] in self?.delegate?.didFetchPhoneUsageReport(samples) } } } else if reader.sensor == .ambientLightSensor { if let samples = reader.fetch(fetchRequest) as? [SRAmbientLightSample] { DispatchQueue.main.async { [weak self] in self?.delegate?.didFetchAmbientLightSensorData(samples) } } } } } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool { return true } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, failedWithError error: any Error) { DispatchQueue.main.async { [weak self] in self?.delegate?.didFailFetchingData(error: error) } } // MARK: - Logging Helper private func log(_ message: String, isError: Bool = false) { if isError { print("❌ [SensorManager] \(message)") } else { print("✅ [SensorManager] \(message)") } } } And ViewController import UIKit import SensorKit class ViewController: UIViewController { private var sensorManager: SensorManager! override func viewDidLoad() { super.viewDidLoad() setupSensorManager() } private func setupSensorManager() { sensorManager = SensorManager() sensorManager.delegate = self sensorManager.requestAuthorization() } } // MARK: - SensorManagerDelegate extension ViewController: SensorManagerDelegate { func didFetchPhoneUsageReport(_ reports: [SRPhoneUsageReport]) { for report in reports { print("Total Calls: (report.totalOutgoingCalls + report.totalIncomingCalls)") print("Outgoing Calls: (report.totalOutgoingCalls)") print("Incoming Calls: (report.totalIncomingCalls)") print("Total Call Duration: (report.totalPhoneCallDuration) seconds") } } func didFetchAmbientLightSensorData(_ data: [SRAmbientLightSample]) { for sample in data { print(sample) } } func didFailFetchingData(error: Error) { print("Failed to fetch data: \(error.localizedDescription)") } } Could anyone please assist me in resolving this issue? Any guidance or troubleshooting steps would be greatly appreciated.

On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)

Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>

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 }

I can't seem to find information on this but this is causing a critical bug where the Strong Password suggestion sheet presents on any secure field (UIKit) and clears the others when closing it. This means the user cannot enter a password when there is a secure confirm password field because switching fields clears the other. This looks to be a recent issue but I can't tell when this was introduced or if this is SDK / OS version related. I am finding it in both Xcode 26.2 and 16.4 when running on device (iOS 26.2.1 and XC 26 simulators). Code to reproduce: class ViewController: UIViewController { override func loadView() { let v = UIStackView() v.axis = .vertical v.layoutMargins = .init(top: 16, left: 16, bottom: 16, right: 16) v.isLayoutMarginsRelativeArrangement = true view = v let t1 = UITextField() t1.textContentType = .username t1.placeholder = "Username" v.addArrangedSubview(t1) let t2 = UITextField() t2.isSecureTextEntry = true t2.textContentType = .newPassword t2.placeholder = "Password" t2.clearsOnInsertion = false t2.clearsOnBeginEditing = false t2.passwordRules = nil t2.clearButtonMode = .always v.addArrangedSubview(t2) let t3 = UITextField() t3.isSecureTextEntry = true t3.textContentType = .newPassword t3.placeholder = "Confirm Password" t3.clearsOnInsertion = false t3.clearsOnBeginEditing = false t3.passwordRules = nil t3.clearButtonMode = .always v.addArrangedSubview(t3) v.addArrangedSubview(UIView()) } } No matter what textContentType is used the strong password still forcefully breaks the flow and blocks the user.

I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?

Hi. macOS 26.5 introduced a bug involving menu item keyboard shortcuts without modifier keys. For example, it affects a menu item with the keyboard shortcut J, but not the keyboard shortcut ⌘J. This bug is also present in the first beta of macOS 27. When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected. But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items. I filed this with a sample project as FB22762541. I also wrote about it in more detail at: https://virtualsanity.com/202605/bug-involving-keyboard-shortcuts-for-menu-items-that-have-no-modifier-keys-on-macos-265/ I would love to see this issue addressed. Thank you for your work.

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?

Feedback ID: FB23618084 Hello, I'm reporting an issue that has been reproducible since iOS 26 and is still present on iOS 27 Developer Beta 3. Environment Device: iPhone 16 Pro Max OS: iOS 27 Developer Beta 3 Issue When sharing an image directly from the Photos app using Share → Messages, the message sometimes fails to send and displays "Message Failed to Send". The same image can usually be sent successfully if it is selected from within the Messages app instead of using the Photos share sheet. Steps to Reproduce Open Photos. Select a photo or screenshot. Tap Share. Choose Messages. Select an existing iMessage conversation. Tap Send. Expected Result The selected image should be attached and sent successfully. Actual Result The message fails to send and a "Message Failed to Send" banner appears. Diagnostics I captured Console logs during reproduction. Relevant log entries include: sharingd: No payload to send? IMDPersistenceAgent: Since we failed to get LPLinkMetadata... The Messages compose view opens normally, but based on the logs it appears that the image attachment is not successfully handed off during the Photos → Messages share flow. I have already submitted Feedback Assistant report FB23618084. Has anyone else observed similar behavior or similar Console logs?

Overview I have a navigation split view. The detail view contains a model now this model depends on id from the parent view. Questions How can I pass data from the parent view and yet create the view in the detail view? Or should I be pass the model from the parent view, but the problem is the parent view needs to persist model. Or is there a better approach?

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.

In iOS 27, willTransition(to:with:), registerForTraitChanges(), and other mechanisms to monitor size classes do not change when an iPhone interface is resized. Only viewWillTransition(to:with:) is invoked with a new size. And this only happens on the iPhone: the iPad continues to work as it has in the past. It appears that this is intended behavior. That is not to say that it's intuitive behavior. Many experienced developers are encountering the "horizontal size is always compact" behavior and immediately thinking "this must be a beta bug": https://fatbobman.com/en/posts/from-size-class-to-available-space/ But it's not. I get that the new size class behavior is expressing static device semantics and is no longer a dynamic size indicator. The problem is that the tools we have been using to build layouts for the past decade use size classes as dynamic sizing indicators. Storyboards can contain variations that specify whether a constraint is used for regular or compact widths/ heights. Developers have used this ability to automatically adjust layouts as the size classes change. In one case, I use this capability to adjust a top-over-bottom layout in a portrait configuration to a side-by-side in a landscape configuration: switching centering, leading/trailing, and aspect ratios to fit the available size. I suspect that many developers who have taken the time to create a unique layout for an iPad are doing something similar. (Ironically, the folks who treated an iPad as a big iPhone are the ones least affected by this change.) When iPadOS got the ability to resize interfaces (as UIScene windows), I made sure that the automatic size class contraints worked correctly and made adjustments as necessary. That work now has to be discarded and switched over to something more universal. If this is truly the intended behavior going forward, time needs to be invested in updating the tooling behind automatic constraint variations: There should be warnings when the storyboard is compiled. I have dozens of automatic contraints embedded in the storyboard: and they're hard to find (each subview has its own contraints, so it's a manual traversal of a huge tree). There should be runtime warnings that your code that inspects size classes won't be executed. This was the biggest "what the hell is going on?" when trying to resize the interface the first time. At a higher level, Apple engineers have described what is happening. They have not explained why the iPhone is behaving differently than an iPad. And that's the root of this whole situation being unintuitive. We've got no clue. And developers without a clue are unlikely to adopt a new technology. It's essential that Apple explains this change in more detail. Yes, you're going to have to obfuscate it and make us read between the lines, but it's got to be done. (Everyone understands the changes regarding mainScreen wink wink, for example.) A reply in this thread would be a good place to start this explanation.

For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure. As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends. I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).

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?

Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

Experiencing an issue with UIContextualAction title text respecting the user's Dynamic Type / preferred content size category when Liquid Glass is active. It's setup using a UITableView with trailing swipe actions via trailingSwipeActionsConfigurationForRowAt. Under Liquid Glass, the contextual action buttons render as floating glass pills, but the title text within them remains at a fixed size regardless of the Dynamic Type setting. Increasing the preferred content size category to accessibility sizes has no visible effect on the action label font size. Any suggestions to make this scalable for dynamic font

The issue can be reproduced as follows : Launch the iOS 26.5 Simulator. Go to the Settings app. Tap Accessibility. Tap Spoken Content. Turn on Speak Selection. Tap Voices. An empty view gets opened, in which no language can be selected. How can voices be downloaded in the iOS 26.5 Simulator ? Note: There is not such issue in the iOS 18.5 Simulator. Note: There is not such issue in a real iOS 26.5 Device.

I have a SwiftUI detail view with a native toolbar. On iPhone, the bottom toolbar appears correctly in portrait. After rotating the device to landscape, the bottom toolbar disappears. It does not come back unless the detail view is rebuilt. I would like to keep the native toolbar appearance and behavior, especially the iOS toolbar/glass effect. I do not want to replace it with a custom safeAreaInset bar. Environment Platform: iOS Current target/system: iOS 27 UI framework: SwiftUI Device idiom: iPhone The issue happens when rotating from portrait to landscape. Expected behavior The native bottom toolbar remains visible after device rotation. Actual behavior The native bottom toolbar is visible in portrait, but disappears after rotating to landscape. Core code The main view attaches toolbar content like this: private var contentWithToolbarAndSheets: some View { coreLayout .slateNavigationBarTitleDisplayModeInline() .toolbar { #if os(iOS) ToolbarItem(placement: .principal) { VStack(spacing: 0) { Text(String(localized: "第 \(scene.safeNumber) 场")) .font(.headline) .fontWeight(.semibold) .lineLimit(1) Text(scene.safeSetName) .font(.subheadline) .foregroundStyle(.secondary) .lineLimit(1) } } #endif bottomBarContent } #if os(macOS) .navigationTitle(String(localized: "第 \(scene.safeNumber) 场")) .navigationSubtitle(scene.safeSetName) #endif .slateBottomBarBackgroundHidden() } The bottom toolbar content: @ToolbarContentBuilder private var bottomBarContent: some ToolbarContent { #if os(iOS) let bar = scriptBottomBar ToolbarItem(placement: .slateBottomBar) { bar.monitorButton } if #available(iOS 26.0, macOS 26.0, *) { ToolbarSpacer(.fixed, placement: .slateBottomBar) } ToolbarItem(placement: .slateBottomBar) { bar.soundRollButton } if #available(iOS 26.0, macOS 26.0, *) { ToolbarSpacer(.flexible, placement: .slateBottomBar) } ToolbarItem(placement: .status) { bar.principalContent } ToolbarItem(placement: .slateBottomBar) { bar.historyButton } if #available(iOS 26.0, macOS 26.0, *) { ToolbarSpacer(.fixed, placement: .slateBottomBar) } if isRecording { if #available(iOS 26.0, macOS 26.0, *) { ToolbarSpacer(.fixed, placement: .slateBottomBar) } ToolbarItem(placement: .slateBottomBar) { bar.trailingContent } } #endif } The compatibility wrappers are: func slateBottomBarBackgroundHidden() -> some View { #if os(iOS) self.toolbarBackground(.hidden, for: .bottomBar) #else self #endif } extension ToolbarItemPlacement { static var slateBottomBar: ToolbarItemPlacement { #if os(iOS) .bottomBar #else .automatic #endif } } Workaround that made it reappear Previously, I had a workaround that listened to size class and orientation changes, then forced the detail view to rebuild by clearing and restoring the selected scene: #if os(iOS) .onChange(of: horizontalSizeClass) { _, _ in forceRefreshByClearingSidebarSelection() } .onChange(of: verticalSizeClass) { _, _ in forceRefreshByClearingSidebarSelection() } .onReceive(NotificationCenter.default.publisher(for: UIDevice.orientationDidChangeNotification)) { _ in let orientation = UIDevice.current.orientation guard orientation.isPortrait || orientation.isLandscape else { return } forceRefreshByClearingSidebarSelection() } #endif #if os(iOS) private func forceRefreshByClearingSidebarSelection() { guard UIDevice.current.userInterfaceIdiom == .phone else { return } let currentSceneID = session.selectedSceneID session.selectedSceneID = nil DispatchQueue.main.async { if session.selectedSceneID == nil { session.selectedSceneID = currentSceneID } } } #endif This made the toolbar reappear after rotation, but it is too heavy because it rebuilds the selected scene/detail view. Things I tried Moved the center toolbar item from .status to .bottomBar. Result: did not fix the disappearing toolbar. Kept native toolbar, added a local toolbarRefreshToken, updated it on horizontalSizeClass / verticalSizeClass changes, and attached .id(toolbarRefreshToken) to toolbar item contents. Result: did not fix it. Removed .toolbarBackground(.hidden, for: .bottomBar). Result: did not fix it. Replacing the toolbar with safeAreaInset(edge: .bottom) works visually in terms of persistence, but loses the native toolbar/glass behavior, so this is not acceptable for this app. Question Is this expected behavior for SwiftUI bottom toolbars in compact-height landscape on iPhone, or is this a SwiftUI toolbar invalidation bug? Is there a recommended way to keep native .toolbar / .bottomBar behavior stable across portrait-to-landscape rotation without forcing the entire detail view to rebuild?

I attach an ad in front of the main video using AVPlayerInterstitialEvent, and PiP works across the interstitial→content transition. I’ve noticed that some apps, while in Picture in Picture, show additional UI that: displays the remaining time of the interstitial item, and lets the user skip the interstitial item and switch to the main video. As far as I know, the AVPictureInPictureController window is system-drawn and can’t be customized by the developer. So my questions are: Is there an official/supported path to present this kind of UI (a remaining-time indicator and a skip control for the interstitial item) over the PiP window? If so, what is the mechanism — is it a system control that gets forwarded to a delegate, framework-provided interstitial UI, or When the interstitial is skipped this way, does the framework return to the primary item automatically, or does the app drive it? I’d really appreciate any insight intodone. Thanks!