How do we get distribution available on Apple HomeView is this iPhone or iPad in Supported Destinations? Thank you.

I recently updated my iPhone SE (2020) to the iOS 27 beta, and initially the experience was excellent. The phone felt noticeably faster and more responsive, and I was genuinely impressed with the update. However, after about a day of usage, I started experiencing a charging-related issue. One night, I left my phone connected to the charger before going to sleep when the battery was at 55%. The next morning, I found that the battery had dropped to 42% instead of charging. I checked all connections and confirmed that the charger, cable, and power source were properly connected. When I disconnected and reconnected the charger, the charging lightning bolt icon would briefly appear, then turn grey after about two seconds, and finally disappear completely a couple of seconds later. The phone would not charge. Assuming it might be a faulty charger or cable, I tested with: A different Apple charger A different Lightning cable The same issue persisted. Next, I connected the phone to my Mac. Surprisingly, it started charging, and Finder recognized the device normally. Over the next few days, the behavior became inconsistent: Sometimes the phone would charge. Sometimes it would not charge at all. Connecting to the Mac worked most of the time, but occasionally even that failed. I also noticed another unusual behavior: If I unplugged the Lightning cable from the iPhone and plugged it back in, the charging symbol would briefly appear. However, if I left the cable connected to the iPhone and unplugged/replugged only the USB end from the power adapter, there would be no response whatsoever—no charging sound, no charging icon, nothing. I cleaned the charging port, cable connectors, and charger contacts, but the issue remained. At that point, I realized the problem started immediately after installing the iOS 27 beta. To verify whether it was software-related, I restored the device back to iOS 26.5. After downgrading, the charging issue completely disappeared, and the phone began charging normally again with the same charger and cable. Based on my testing, this appears to be a software-related issue introduced in the iOS 27 beta rather than a hardware problem. I am posting this in case other iPhone SE (2020) users are experiencing similar charging behavior after updating to the beta. Device: iPhone SE (2020) Issue: Intermittent charging failure after updating to iOS 27 beta Status: Resolved after restoring to iOS 26.5

On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?

On the folded iPhone Duo display, a navigation bar item briefly moves into the vertical bar during dismissal of a full-screen modal, then jumps back to the top. Both navigation controllers consistently return .disabled from preferredVerticalBarBehavior, with childForPreferredVerticalBarBehavior returning nil. Environment Xcode 27.1 RC (27A9275), iOS 27.1 SDK, iPhone Duo simulator, folded outer display in portrait. Steps to reproduce Run the single-file UIKit example below in a scene-based app with a generated launch screen and no main storyboard. Tap the gear button on the Home screen to present Settings using .fullScreen. Tap the close button on Settings. Watch the Home screen's gear button during the dismissal animation. Expected The gear button stays in the top horizontal navigation bar throughout the transition, because the vertical bar preference is .disabled on both navigation controllers. Actual For part of the dismissal, the gear button appears below the status icons in the right-hand vertical bar region. It then jumps back to the top horizontal bar. The underlying tab bar also temporarily moves from the bottom to the right before returning. This reproduces with an otherwise empty view, standard UIKit containers, and the default bar appearance. No app code changes safeAreaInsets, bar frames, or animation timing. During the presentation/dismissal cycle, the Home view's logged right safe-area inset changes from 0 to 88 points and back to 0. In our app, content constrained to the safe area visibly narrows during the same transient change. In separate comparisons, returning .disabled from the root tab controller and content controllers, or requesting setNeedsUpdateOfVerticalBarConfiguration in appearance callbacks, did not eliminate the issue. Changing the modal to .overFullScreen avoided it in the tested simulator, but changes the underlying view controller lifecycle. The example below intentionally keeps .fullScreen to reproduce the problem. Is this expected behavior, or a known UIKit issue? Is there a supported way to keep .disabled effective throughout a fullScreen presentation/dismissal? Has this been addressed in a newer SDK/runtime? I have not tested iOS 27.2 or a physical Duo device. Minimal reproduction (one Swift file): import UIKit @main final class DemoAppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, configurationForConnecting session: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration { let configuration = UISceneConfiguration(name: "Demo", sessionRole: session.role) configuration.delegateClass = DemoSceneDelegate.self return configuration } } final class DemoSceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) { guard let scene = scene as? UIWindowScene else { return } let home = DemoController() home.title = "首页" let navigation = DemoNavigationController(rootViewController: home) navigation.tabBarItem = UITabBarItem(title: "首页", image: UIImage(systemName: "house"), selectedImage: nil) let tabs = UITabBarController() if #available(iOS 18.0, *) { tabs.mode = .tabBar } tabs.viewControllers = [navigation] let window = UIWindow(windowScene: scene) window.rootViewController = tabs self.window = window window.makeKeyAndVisible() } } final class DemoNavigationController: UINavigationController { // 与音剪一致：导航容器固定横向栏，不转发给子页面。 @available(iOS 27.1, *) override var preferredVerticalBarBehavior: UIVerticalBarBehavior { .disabled } @available(iOS 27.1, *) override var childForPreferredVerticalBarBehavior: UIViewController? { nil } } final class DemoController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground if title == "设置" { navigationItem.leftBarButtonItem = UIBarButtonItem(systemItem: .close, primaryAction: UIAction { [weak self] _ in self?.dismiss(animated: true) }) } else { navigationItem.rightBarButtonItem = UIBarButtonItem( image: UIImage(systemName: "gearshape"), primaryAction: UIAction { [weak self] _ in let settings = DemoController() settings.title = "设置" let navigation = DemoNavigationController(rootViewController: settings) navigation.modalPresentationStyle = .fullScreen self?.present(navigation, animated: true) }) } } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() print("[DuoDemo] \(title ?? "") safe=\(view.safeAreaInsets) nav=\(navigationController?.navigationBar.frame ?? .zero) tab=\(tabBarController?.tabBar.frame ?? .zero)") } }

I’m adapting a UIKit app for iPhone Duo and noticed that UITableViewController separators extend underneath the navigation and tab bar controls when those controls move to the side. The cell content appears to respect the safe area, but the separators continue to the screen edge. When using a UITableView inside a regular UIViewController, constraining its horizontal edges to the parent’s safeAreaLayoutGuide prevents this. With UITableViewController, however, the table view is the controller’s root view. The attached screenshots show the difference: Screenshot 1: Separators extend underneath the side controls. Screenshot 2: Separators stop at the safe area boundary. Should UITableViewController respect these safe area boundaries out of the box, including for separators, when system controls move to the side? Or is drawing separators underneath those controls the intended behavior? If automatic adaptation is expected, could this be a UIKit issue?

We are aware that we can opt out of the vertical bar to make it horizontal for folded and unfolded landscape: https://developer.apple.com/documentation/uikit/uiviewcontroller/preferredverticalbarbehavior As per the title, we would like to know if if the reverse is possible (i.e. can we have the unfolded portrait display a vertical bar instead of a horizontal one)

I want to release an app under my company's name. From what I understand you need a DUNS number to verify your business. Because that takes about 30 days to be granted, I was thinking of releasing the app under my personal name and then moving it to the business account. Is that something I could do? Thanks

When a text field on Apple Watch is filled through the iPhone's remote keyboard, text that I PASTE into the iPhone field is displayed correctly on the iPhone but arrives EMPTY on the watch. Typing the same text character by character works fine. This happens in both secure (password) fields and regular text fields, so it doesn't look like a password-field restriction. Steps to reproduce On the watch, open a text field (I tested a password field and a regular one). Open the keyboard on the iPhone when prompted. Copy a short test string (e.g. "test12345") from another app. Paste it into the iPhone field. The iPhone shows the text. Confirm on the watch. Expected: the watch receives the pasted text. Actual: the watch field receives empty input. What I tried Typing the string by hand: arrives correctly. Pasting in a secure field: arrives empty. Pasting in a regular field: arrives empty. Environment iPhone 15 Pro Max, iOS 27.0 [confirm current version] Apple Watch Ultra 2, watchOS 27.2 (24S5091f) MacBook Pro (M1), macOS 27.2 Has anyone else seen this? Any workaround other than typing the text manually would be appreciated.

On iPhone Duo, if a tab bar item's title is set to an empty string while the device is in landscape, setting a non-empty title again after rotating back to portrait doesn't display it. The title stays missing. Filled in FB25015689 Repro: import UIKit @main final class AppDelegate: UIResponder, UIApplicationDelegate { func application( _ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions ) -> UISceneConfiguration { let config = UISceneConfiguration(name: nil, sessionRole: connectingSceneSession.role) config.delegateClass = SceneDelegate.self return config } } final class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene( _ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions ) { guard let windowScene = scene as? UIWindowScene else { return } let tab = TitleViewController() tab.tabBarItem = UITabBarItem(tabBarSystemItem: .favorites, tag: 0) let tabBarController = UITabBarController() tabBarController.viewControllers = [tab] let window = UIWindow(windowScene: windowScene) window.rootViewController = tabBarController self.window = window window.makeKeyAndVisible() } } final class TitleViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let hide = UIButton(configuration: .bordered(), primaryAction: UIAction(title: "hidden") { [weak self] _ in self?.setTabTitle("") }) let show = UIButton(configuration: .bordered(), primaryAction: UIAction(title: "visible") { [weak self] _ in self?.setTabTitle("Favorites") }) let stack = UIStackView(arrangedSubviews: [hide, show]) stack.axis = .vertical stack.spacing = 16 stack.translatesAutoresizingMaskIntoConstraints = false view.addSubview(stack) NSLayoutConstraint.activate([ stack.centerXAnchor.constraint(equalTo: view.centerXAnchor), stack.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } private func setTabTitle(_ newTitle: String) { title = newTitle tabBarItem.title = newTitle } }

Hi, When I run a build and select my iPhone, I get this error: "The capability “Fetch Extended Device Info” is not supported by this device." Although it works correctly when I run the build on the Simulator on my Mac. I recently updated my iPhone to iOS 27.2. Could this be the problem? Is there any way to fix it, or should I wait for an Xcode update? I tried running it in version Xcode 26.5 and 27Beta Thanks!

We have received several cases that our app can not display uitableview cell in iOS26, but users said that they can select cells with single tab and the uitableview didselectcell delegate can response！ I have reported a feedback but no response. Does anyone have the same bugs with me？ You guys can see that the page is blank, I have a video a user sent to me can proved that he can select cell with gesture. We cannot reproduce the bug and don't konw how to fixed, we think this is the bug with iOS26, so here for some help. This bug block our distribution of new version(support iOS26) This is the feedback https://feedbackassistant.apple.com/feedback/20677046

On the iPhone Duo's narrow display, the navigation bar's back button sits in the trailing column below the status bar. During an interactive swipe-back from a screen whose navigation bar is hidden to a screen whose navigation bar is visible, the back button briefly renders in the leading (top-left) position of the bar for one or more frames. In those same frames the trailing-column button is blank. It then jumps back to the trailing column. The result is a visible flicker. Steps to reproduce: Open the attached code in Xcode 27.1 and run it on the iPhone Duo simulator (iOS 27.1), using the narrow display in portrait. Tap "Push". This pushes a screen with a visible navigation bar. Tap "Push without header". This pushes a screen that hides the navigation bar. Slowly swipe back from the leading edge to return to the previous screen. Expected: the back button of the revealed navigation bar stays in the trailing column for the whole transition, the same as with a programmatic pop. Actual: for one or more frames during the gesture, the back button renders at the leading edge of the navigation bar (top-left), and the trailing column is blank. Then it returns to the trailing column. Repro: import UIKit @main final class AppDelegate: UIResponder, UIApplicationDelegate {} final class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) let nav = SwipeableNavigationController(rootViewController: ScreenVC(title: "header 0", showsHeader: true)) window.rootViewController = nav window.makeKeyAndVisible() self.window = window // Auto sequence when launched with `-auto YES`: push header, push no header, pop. guard UserDefaults.standard.bool(forKey: "auto") else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.5) { nav.pushViewController(ScreenVC(title: "header 0", showsHeader: true), animated: true) } DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { nav.pushViewController(ScreenVC(title: "no header", showsHeader: false), animated: true) } DispatchQueue.main.asyncAfter(deadline: .now() + 4.5) { nav.popViewController(animated: true) } } } final class ScreenVC: UIViewController { private let showsHeader: Bool init(title: String, showsHeader: Bool) { self.showsHeader = showsHeader super.init(nibName: nil, bundle: nil) self.title = title } required init?(coder: NSCoder) { fatalError() } override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) navigationController?.setNavigationBarHidden(!showsHeader, animated: animated) } override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemGroupedBackground let push = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Push") { [weak self] _ in self?.navigationController?.pushViewController(ScreenVC(title: "header 0", showsHeader: true), animated: true) }) let pushNoHeader = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Push without header") { [weak self] _ in self?.navigationController?.pushViewController(ScreenVC(title: "no header", showsHeader: false), animated: true) }) let back = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Go back") { [weak self] _ in self?.navigationController?.popViewController(animated: true) }) let stack = UIStackView(arrangedSubviews: [push, pushNoHeader, back]) stack.axis = .vertical stack.translatesAutoresizingMaskIntoConstraints = false view.addSubview(stack) NSLayoutConstraint.activate([ stack.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 10), stack.centerXAnchor.constraint(equalTo: view.centerXAnchor), ]) } } final class SwipeableNavigationController: UINavigationController, UIGestureRecognizerDelegate { override func viewDidLoad() { super.viewDidLoad() interactivePopGestureRecognizer?.delegate = self if #available(iOS 26.0, *) { interactiveContentPopGestureRecognizer?.delegate = self } } func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) -> Bool { viewControllers.count > 1 } } Thank you in advance!

I think the title says it all.

What's the guidance on submitting new builds for App Review that include support for iPhone Duo/iPhone resizability? Will they work when building with Xcode 27 + if available for 27.1 or do we have to wait for new Xcode release? Any guidance from Apple and timeframe on build submission if our updates are ready and undergoing testing in simulator? Thank you.

"Build a great camera experience for iPhone Duo" covers the device open and the device closed, including reconfiguring the session from AVCaptureDeviceDirectionCoordinator's change handler when the forward-facing camera changes. It does not cover the partially open pose, which "Leverage multiple displays and scenes on iPhone Duo" treats as a first-class hinge state with a continuous angle. Consider a camera app that keeps a live preview on screen and adopts AVCaptureDevice.RotationCoordinator — the documented remedy for cases like the square front sensor on iPhone 17, where a hard-coded 90° leaves the preview tilted — applying videoRotationAngleForHorizonLevelPreview to both the preview and the capture connection. In the partially open pose the two halves are at different physical attitudes: one stands up, the other lies flat. Which camera does AVCaptureDeviceDirectionCoordinator report as forward-facing while the hinge status is partially open? Does the hinge angle affect that decision? RotationCoordinator derives its angle from device attitude. With the two halves at different attitudes, which one does videoRotationAngleForHorizonLevelPreview reflect — the half carrying the active camera, the half hosting the preview layer, or a single device-level reference? If an app deliberately keeps the rear camera on the scene while its preview is drawn on the half facing the user, is that a supported configuration, or is the coordinator expected to override that choice? Is any of this modelled in the iPhone Duo simulator, or does the partially open pose require real hardware to test? Question 4 matters for planning: building against a rotation value that only appears on device would be worth knowing about before the hardware ships.

According to Apple's press release (https://www.apple.com/pt/newsroom/2026/09/apple-debuts-iphone-18-pro-and-iphone-18-pro-max/): Variable aperture also provides more control for creative pros by giving them the ability to manually adjust any of the four aperture settings in the Camera app, and an API is available to developers for even more control across the aperture range in their apps. Can a DTS engineer specify the quoted API please? I can't see it anywhere in the documentation yet. What does it mean "even more control across the aperture range"? Will it be possible to set the aperture in a 0.0-1.0 range?

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

Hi, I was testing my app on iPhone Duo simulator and couldn't understand why even though I am using native navigation stack and toolbars, the toolbar items are not placed on the vertical space. With some debugging I found that it's due to the Group {} I am using Group - because I have a switch inside it where I switch between different types of views, and I insert an environment object only once in the Group {}.environment... I recreated the issue in a clean project, here is full source code: SourceCode.swift And the result when nesting the NavigationStack inside a Group {}. If I remove the Group, toolbar items are pushed to the vertical space as needed

Hello everyone, This is my first ever game submission to the App Store, so I’m honestly very excited to finally be at this stage. I’ve spent a lot of time working on the game, and seeing it reach the review process for the first time is a really exciting moment for me. The app has now been in “Waiting for Review” for around 5 days. I completely understand that the review process takes time and that Apple’s review team has many submissions to handle. At the same time, since this is my first game and I’m really looking forward to launching it, I’m starting to get a little concerned about the waiting time. I wanted to kindly ask if there is anything I can do from my side to help move the review forward, or if there is any possibility of requesting an expedited review in this situation. I absolutely understand that the normal review process needs to be followed, and I’m not expecting any special treatment. I would just be very grateful if there is anything I can do, or if someone could let me know whether a faster review might be possible. Thank you very much for taking the time to read this, and thank you to everyone who can share their experience or advice. It’s my first game, so I’m both excited and a little nervous about seeing it finally go live. :)

On iPhone 18 Pro, the Now Playing panel and bottom Lock Screen controls can use different material opacity and foreground colors for the same wallpaper and settings. The final appearance depends on the preceding wallpaper-editing sequence. Environment Device: iPhone 18 Pro iOS: 27.2 beta (24B5084k) Liquid Glass: Clear / most transparent setting Wallpaper: Built-in iPhone 18 Pro wallpaper collection Variants tested: Silver and Black within the same saved wallpaper configuration Feedback Assistant: FB24866793 Two observed appearance states For clarity, I use the following labels: Higher-opacity state (S_s): The Now Playing panel and bottom buttons have a light or gray, relatively solid fill with dark foreground icons. Translucent state (S_t): The same elements are more transparent and use light foreground icons. In Sleep mode, they darken and blend into the background more naturally. No Liquid Glass setting is changed during the following sequence. Shortest reproduction sequence 1. Change Silver to Black Start with the Silver variant displaying the higher-opacity state (Silver S_s). Open the Lock Screen wallpaper carousel, tap Customize, change Silver to Black within the same iPhone 18 Pro wallpaper configuration, tap Done, and exit the carousel. Observed result: Black retains the higher-opacity state (Black S_s). 2. Save Black without changing it Reopen the same Black wallpaper in Customize, make no changes, tap Done, and exit. Observed result: Black changes to the translucent state (Black S_t). 3. Change Black back to Silver Reopen Customize, change Black back to Silver, tap Done, and exit. Observed result: Silver retains the translucent state (Silver S_t). 4. Save Silver without changing it Reopen the same Silver wallpaper in Customize, make no changes, tap Done, and exit. Observed result: Silver changes back to the higher-opacity state (Silver S_s). The complete sequence is therefore: Silver S_s → Black S_s → Black S_t → Silver S_t → Silver S_s The two actual appearance changes occur after reopening Customize and saving without changing the selected wallpaper. Actual result When switching between Silver and Black inside the same saved wallpaper configuration, the existing material state can be preserved even though the new wallpaper has a different brightness. Reopening the configuration and saving it without making a change can then alter: Now Playing panel opacity Notification material appearance Bottom shortcut-button opacity Foreground or icon colors As a result, the exact same Silver or Black wallpaper can appear in either state solely because of the preceding editing history. Expected result The material opacity and foreground colors should be determined consistently from the currently selected wallpaper and the Liquid Glass setting. Switching between Silver and Black should update the appearance immediately if different treatments are intended for them. Saving an unchanged wallpaper should not alter the Lock Screen appearance. Sleep mode impact The issue is especially noticeable in Sleep mode. In the higher-opacity state, the Now Playing panel and bottom buttons remain conspicuous gray elements against the darkened Lock Screen. In the translucent state, the same controls darken and integrate with the background. Supporting evidence The corresponding Feedback Assistant report, FB24866793, includes: A screen recording of the complete sequence in normal mode A screen recording of the same sequence in Sleep mode A detailed PDF report containing screenshots, terminology, additional observations, and reproduction paths Both recordings show the following sequence: Silver S_s → Black S_s → Black S_t → Silver S_t → Silver S_s The recordings and PDF cannot be attached directly to this Developer Forums post, but they are available to Apple through the Feedback Assistant report. Request for confirmation Could anyone else with an iPhone 18 Pro test this sequence on the same iOS build? If you can reproduce it, please consider filing a separate Feedback Assistant report and referencing FB24866793.