Post

Replies

Boosts

Views

Activity

SwiftUI interactive Liquid Glass highlight boundary for a custom L shape
Full code following thread 826485. Feedback: FB25055820. Earlier calibrated Lab recordings on an iPhone 17 Pro Simulator (iOS 27.2 Beta 1, 24B5084k; Xcode 27.2, 27B5019j) showed a round press highlight inside the L, including on its empty cutout where the Button action did not fire. Interactive off removed it; a wider host widened it without stretching the L. These are Simulator observations. This extracted English project compiled, but has not been newly run or optically recorded. The baseline already uses the SAME L contentShape after glassEffect. Other matching-L placements are not established failures. Which public API controls the highlight boundary, and where should contentShape go? Are nonconvex shapes supported? Hold each arm, then the cutout; compare the highlight and action counter. Default uses the recorded baseline order. import SwiftUI @main struct CustomGlassHighlightApp: App { var body: some Scene { WindowGroup { GlassHighlightStudy() } } } private enum Experiment: String, CaseIterable, Identifiable { case baseline = "Baseline — L after glass" case interactiveOff = "Interactive off" case wideHost = "Wide host (180 pt)" case labelAndAfter = "L on label + after glass" case rectangleBefore = "Rectangle before glass" case rectangleAfter = "Rectangle after glass" var id: String { rawValue } var hostWidth: CGFloat { self == .wideHost ? 180 : 120 } var isInteractive: Bool { self != .interactiveOff } var explanation: String { switch self { case .baseline: return "120 × 120 pt host. The same L Shape is used by glassEffect and by contentShape after glassEffect." case .interactiveOff: return "Same L, frame, and modifier order as baseline; only interactive is false." case .wideHost: return "180 × 120 pt host. The L remains 120 × 120 pt, centered in the wider host." case .labelAndAfter: return "Baseline plus the same L contentShape on the Button label, before the Button is constructed." case .rectangleBefore: return "Diagnostic mismatch: Rectangle contentShape before glassEffect; the glass remains an L." case .rectangleAfter: return "Diagnostic mismatch: Rectangle contentShape after glassEffect; the glass remains an L." } } } // A fixed-size nonconvex path. Widening its host does not stretch the L. private struct Fixed120GlassL: Shape { func path(in rect: CGRect) -> Path { let origin = CGPoint(x: rect.midX - 60, y: rect.midY - 60) let points: [CGPoint] = [ .zero, CGPoint(x: 120, y: 0), CGPoint(x: 120, y: 42), CGPoint(x: 42, y: 42), CGPoint(x: 42, y: 120), CGPoint(x: 0, y: 120) ] var path = Path() for (index, point) in points.enumerated() { let target = CGPoint(x: origin.x + point.x, y: origin.y + point.y) if index == 0 { path.move(to: target) } else { path.addLine(to: target) } } path.closeSubpath() return path } } private enum HintPosition { case label, before, after } private struct HitShapeHint: ViewModifier { let experiment: Experiment let position: HintPosition @ViewBuilder func body(content: Content) -> some View { switch (experiment, position) { case (.labelAndAfter, .label): content.contentShape(.interaction, Fixed120GlassL()) case (.rectangleBefore, .before), (.rectangleAfter, .after): content.contentShape(.interaction, Rectangle()) case (.baseline, .after), (.interactiveOff, .after), (.wideHost, .after), (.labelAndAfter, .after): content.contentShape(.interaction, Fixed120GlassL()) default: content } } } private struct GlassHighlightStudy: View { @State private var experiment: Experiment = .baseline @State private var actionCount = 0 var body: some View { ZStack { LinearGradient( colors: [Color(red: 0.06, green: 0.14, blue: 0.26), Color(red: 0.38, green: 0.00, blue: 0.25), .black], startPoint: .topLeading, endPoint: .bottomTrailing ).ignoresSafeArea() VStack(spacing: 24) { Text("Custom Glass Highlight") .font(.title2.bold()) Picker("Experiment", selection: $experiment) { ForEach(Experiment.allCases) { item in Text(item.rawValue).tag(item) } } .pickerStyle(.menu) Text(experiment.explanation) .font(.callout) .frame(minHeight: 76, alignment: .topLeading) .frame(maxWidth: .infinity, alignment: .leading) // This modifier order is extracted from the earlier causal probe. Button { actionCount += 1 } label: { Fixed120GlassL().fill(Color.white.opacity(0.001)) .frame(width: experiment.hostWidth, height: 120) .modifier(HitShapeHint(experiment: experiment, position: .label)) } .buttonStyle(.plain) .modifier(HitShapeHint(experiment: experiment, position: .before)) .glassEffect(.regular.interactive(experiment.isInteractive), in: Fixed120GlassL()) .modifier(HitShapeHint(experiment: experiment, position: .after)) .overlay { Fixed120GlassL() .stroke(Color.white.opacity(0.35), lineWidth: 0.5) .allowsHitTesting(false) .accessibilityHidden(true) } .frame(width: experiment.hostWidth, height: 120) .frame(width: 220, height: 220) .id(experiment) .accessibilityLabel("L-shaped glass button") Text("Button actions: \(actionCount)") .monospacedDigit() Text("Press and hold the top arm, then the lower arm. Try the empty lower-right cutout. Compare the highlight with the L contour and the action counter.") .font(.callout) .frame(maxWidth: .infinity, alignment: .leading) Spacer(minLength: 0) } .foregroundStyle(.white) .padding(24) } .preferredColorScheme(.dark) .onChange(of: experiment) { _, _ in actionCount = 0 } } }
0
0
178
Oct ’26
Siri AI PCC planner: rate limiter reports count=320 over 86400 seconds while another PCC request still completes
I am investigating an intermittent Siri AI failure on an eligible iPhone running iOS 27.2 beta (24B5089g). I captured three sysdiagnoses covering a previously blocked state, a working state, and the transition from working requests into a repeatable failure. I also exported the corresponding Apple Intelligence Report. The user-visible symptom is generic: Siri AI returns a variation of “Something’s gone wrong” for requests that require the agentic planner. Basic Siri functionality may remain available. The transition capture contains the following sequence. Identifiers, request content, account information, and retry dates have been removed: 16:48:55.069 privatecloudcomputed Ropes request finished successfully 16:49:08.770 privatecloudcomputed Ropes request finished successfully 16:49:13.742 privatecloudcomputed rate limit applied for rate with count=320, duration=86400.000000 16:49:13.790 privatecloudcomputed PrivateCloudComputeError Code=32073 16:49:13.837 privatecloudcomputed rate limit applied from cached denials 16:49:13.894 intelligenceflowd deniedDueToUserDeviceRateLimit 16:49:15.439 privatecloudcomputed Ropes request finished successfully The Apple Intelligence Report aligns the planner failure with 16:49:13 and identifies the execution environment as PrivateCloudCompute. Another PCC request completed at 16:49:15, after the planner denial. This is consistent with the restriction being scoped more narrowly than complete PCC unavailability, although the successful request’s metadata is redacted in the unified log. The log wording closely matches the rate limiter in Apple’s published PCC client source. In the 2026-05-15 source release, the client counts matching request records within a moving time window and denies a request when the count reaches a configured threshold. The same implementation stores cached denials and exposes an internal loggedCountSoFar field in TrustedCloudComputeRateLimit. Relevant source locations: RateLimiter.swift RequestLog.swift DeniedRequestLog.swift TrustedCloudComputeRateLimit.swift My current interpretation is limited to the following: 320 appears to be the configured maximum for a matching request class, rather than a reading of the current count. 86400 is consistent with a rolling 24-hour window. It does not necessarily mean that recovery occurs exactly 24 hours after the first visible denial. One Siri interaction cannot be assumed to equal one rate-limit record. The published implementation records a request when it may be sent to ROPES, before the final inference result is known. The evidence establishes rate limiting as the immediate cause of this planner failure. It does not establish how the rule is divided among device, iCloud account, feature identifier, workload type, or workload parameters. Because Apple’s public source predates this beta build and does not include error 32073, source-level behavior should not be assumed to match this build in every detail. I would appreciate clarification on these points: What is the intended scope of deniedDueToUserDeviceRateLimit in this Siri planner path: device, person/account, feature, workload, or a combination? Does count=320, duration=86400 describe a rolling window in current builds? Are attempts rejected from a cached denial excluded from the rolling request count? The published implementation appears to return the existing denial before the request-send accounting path, but I have not established that the current build behaves identically. Is there a supported diagnostic that reports the applicable rate-limit rule, loggedCountSoFar, and a non-redacted retry time to the device owner or through Feedback Assistant? Is it expected that another PCC workload can complete immediately after the Siri planner is denied? Should a user-visible generic Siri error distinguish this condition from network or service failures and offer a meaningful retry interval? For comparison, another developer has reported a cumulative PCC wall that surfaced as either rateLimited or quotaLimitReached while the public quota state remained healthy: Developer Forums thread 843046. My capture differs by providing the client rule parameters and a Siri-specific deniedDueToUserDeviceRateLimit result. I am retaining the original, unmodified sysdiagnoses and report export and can submit them through Feedback Assistant with precise timestamps. I am also running a low-frequency recovery observation and a same-account cross-device comparison. I will update this thread with recovery bounds and will correct the interpretation if later evidence does not support it.
1
1
699
Sep ’26
iPhone 18 Pro Lock Screen controls change appearance after saving an unchanged wallpaper
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.
0
0
1.1k
Sep ’26
SwiftUI interactive Liquid Glass highlight boundary for a custom L shape
Full code following thread 826485. Feedback: FB25055820. Earlier calibrated Lab recordings on an iPhone 17 Pro Simulator (iOS 27.2 Beta 1, 24B5084k; Xcode 27.2, 27B5019j) showed a round press highlight inside the L, including on its empty cutout where the Button action did not fire. Interactive off removed it; a wider host widened it without stretching the L. These are Simulator observations. This extracted English project compiled, but has not been newly run or optically recorded. The baseline already uses the SAME L contentShape after glassEffect. Other matching-L placements are not established failures. Which public API controls the highlight boundary, and where should contentShape go? Are nonconvex shapes supported? Hold each arm, then the cutout; compare the highlight and action counter. Default uses the recorded baseline order. import SwiftUI @main struct CustomGlassHighlightApp: App { var body: some Scene { WindowGroup { GlassHighlightStudy() } } } private enum Experiment: String, CaseIterable, Identifiable { case baseline = "Baseline — L after glass" case interactiveOff = "Interactive off" case wideHost = "Wide host (180 pt)" case labelAndAfter = "L on label + after glass" case rectangleBefore = "Rectangle before glass" case rectangleAfter = "Rectangle after glass" var id: String { rawValue } var hostWidth: CGFloat { self == .wideHost ? 180 : 120 } var isInteractive: Bool { self != .interactiveOff } var explanation: String { switch self { case .baseline: return "120 × 120 pt host. The same L Shape is used by glassEffect and by contentShape after glassEffect." case .interactiveOff: return "Same L, frame, and modifier order as baseline; only interactive is false." case .wideHost: return "180 × 120 pt host. The L remains 120 × 120 pt, centered in the wider host." case .labelAndAfter: return "Baseline plus the same L contentShape on the Button label, before the Button is constructed." case .rectangleBefore: return "Diagnostic mismatch: Rectangle contentShape before glassEffect; the glass remains an L." case .rectangleAfter: return "Diagnostic mismatch: Rectangle contentShape after glassEffect; the glass remains an L." } } } // A fixed-size nonconvex path. Widening its host does not stretch the L. private struct Fixed120GlassL: Shape { func path(in rect: CGRect) -> Path { let origin = CGPoint(x: rect.midX - 60, y: rect.midY - 60) let points: [CGPoint] = [ .zero, CGPoint(x: 120, y: 0), CGPoint(x: 120, y: 42), CGPoint(x: 42, y: 42), CGPoint(x: 42, y: 120), CGPoint(x: 0, y: 120) ] var path = Path() for (index, point) in points.enumerated() { let target = CGPoint(x: origin.x + point.x, y: origin.y + point.y) if index == 0 { path.move(to: target) } else { path.addLine(to: target) } } path.closeSubpath() return path } } private enum HintPosition { case label, before, after } private struct HitShapeHint: ViewModifier { let experiment: Experiment let position: HintPosition @ViewBuilder func body(content: Content) -> some View { switch (experiment, position) { case (.labelAndAfter, .label): content.contentShape(.interaction, Fixed120GlassL()) case (.rectangleBefore, .before), (.rectangleAfter, .after): content.contentShape(.interaction, Rectangle()) case (.baseline, .after), (.interactiveOff, .after), (.wideHost, .after), (.labelAndAfter, .after): content.contentShape(.interaction, Fixed120GlassL()) default: content } } } private struct GlassHighlightStudy: View { @State private var experiment: Experiment = .baseline @State private var actionCount = 0 var body: some View { ZStack { LinearGradient( colors: [Color(red: 0.06, green: 0.14, blue: 0.26), Color(red: 0.38, green: 0.00, blue: 0.25), .black], startPoint: .topLeading, endPoint: .bottomTrailing ).ignoresSafeArea() VStack(spacing: 24) { Text("Custom Glass Highlight") .font(.title2.bold()) Picker("Experiment", selection: $experiment) { ForEach(Experiment.allCases) { item in Text(item.rawValue).tag(item) } } .pickerStyle(.menu) Text(experiment.explanation) .font(.callout) .frame(minHeight: 76, alignment: .topLeading) .frame(maxWidth: .infinity, alignment: .leading) // This modifier order is extracted from the earlier causal probe. Button { actionCount += 1 } label: { Fixed120GlassL().fill(Color.white.opacity(0.001)) .frame(width: experiment.hostWidth, height: 120) .modifier(HitShapeHint(experiment: experiment, position: .label)) } .buttonStyle(.plain) .modifier(HitShapeHint(experiment: experiment, position: .before)) .glassEffect(.regular.interactive(experiment.isInteractive), in: Fixed120GlassL()) .modifier(HitShapeHint(experiment: experiment, position: .after)) .overlay { Fixed120GlassL() .stroke(Color.white.opacity(0.35), lineWidth: 0.5) .allowsHitTesting(false) .accessibilityHidden(true) } .frame(width: experiment.hostWidth, height: 120) .frame(width: 220, height: 220) .id(experiment) .accessibilityLabel("L-shaped glass button") Text("Button actions: \(actionCount)") .monospacedDigit() Text("Press and hold the top arm, then the lower arm. Try the empty lower-right cutout. Compare the highlight with the L contour and the action counter.") .font(.callout) .frame(maxWidth: .infinity, alignment: .leading) Spacer(minLength: 0) } .foregroundStyle(.white) .padding(24) } .preferredColorScheme(.dark) .onChange(of: experiment) { _, _ in actionCount = 0 } } }
Replies
0
Boosts
0
Views
178
Activity
Oct ’26
Siri AI PCC planner: rate limiter reports count=320 over 86400 seconds while another PCC request still completes
I am investigating an intermittent Siri AI failure on an eligible iPhone running iOS 27.2 beta (24B5089g). I captured three sysdiagnoses covering a previously blocked state, a working state, and the transition from working requests into a repeatable failure. I also exported the corresponding Apple Intelligence Report. The user-visible symptom is generic: Siri AI returns a variation of “Something’s gone wrong” for requests that require the agentic planner. Basic Siri functionality may remain available. The transition capture contains the following sequence. Identifiers, request content, account information, and retry dates have been removed: 16:48:55.069 privatecloudcomputed Ropes request finished successfully 16:49:08.770 privatecloudcomputed Ropes request finished successfully 16:49:13.742 privatecloudcomputed rate limit applied for rate with count=320, duration=86400.000000 16:49:13.790 privatecloudcomputed PrivateCloudComputeError Code=32073 16:49:13.837 privatecloudcomputed rate limit applied from cached denials 16:49:13.894 intelligenceflowd deniedDueToUserDeviceRateLimit 16:49:15.439 privatecloudcomputed Ropes request finished successfully The Apple Intelligence Report aligns the planner failure with 16:49:13 and identifies the execution environment as PrivateCloudCompute. Another PCC request completed at 16:49:15, after the planner denial. This is consistent with the restriction being scoped more narrowly than complete PCC unavailability, although the successful request’s metadata is redacted in the unified log. The log wording closely matches the rate limiter in Apple’s published PCC client source. In the 2026-05-15 source release, the client counts matching request records within a moving time window and denies a request when the count reaches a configured threshold. The same implementation stores cached denials and exposes an internal loggedCountSoFar field in TrustedCloudComputeRateLimit. Relevant source locations: RateLimiter.swift RequestLog.swift DeniedRequestLog.swift TrustedCloudComputeRateLimit.swift My current interpretation is limited to the following: 320 appears to be the configured maximum for a matching request class, rather than a reading of the current count. 86400 is consistent with a rolling 24-hour window. It does not necessarily mean that recovery occurs exactly 24 hours after the first visible denial. One Siri interaction cannot be assumed to equal one rate-limit record. The published implementation records a request when it may be sent to ROPES, before the final inference result is known. The evidence establishes rate limiting as the immediate cause of this planner failure. It does not establish how the rule is divided among device, iCloud account, feature identifier, workload type, or workload parameters. Because Apple’s public source predates this beta build and does not include error 32073, source-level behavior should not be assumed to match this build in every detail. I would appreciate clarification on these points: What is the intended scope of deniedDueToUserDeviceRateLimit in this Siri planner path: device, person/account, feature, workload, or a combination? Does count=320, duration=86400 describe a rolling window in current builds? Are attempts rejected from a cached denial excluded from the rolling request count? The published implementation appears to return the existing denial before the request-send accounting path, but I have not established that the current build behaves identically. Is there a supported diagnostic that reports the applicable rate-limit rule, loggedCountSoFar, and a non-redacted retry time to the device owner or through Feedback Assistant? Is it expected that another PCC workload can complete immediately after the Siri planner is denied? Should a user-visible generic Siri error distinguish this condition from network or service failures and offer a meaningful retry interval? For comparison, another developer has reported a cumulative PCC wall that surfaced as either rateLimited or quotaLimitReached while the public quota state remained healthy: Developer Forums thread 843046. My capture differs by providing the client rule parameters and a Siri-specific deniedDueToUserDeviceRateLimit result. I am retaining the original, unmodified sysdiagnoses and report export and can submit them through Feedback Assistant with precise timestamps. I am also running a low-frequency recovery observation and a same-account cross-device comparison. I will update this thread with recovery bounds and will correct the interpretation if later evidence does not support it.
Replies
1
Boosts
1
Views
699
Activity
Sep ’26
iPhone 18 Pro Lock Screen controls change appearance after saving an unchanged wallpaper
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.
Replies
0
Boosts
0
Views
1.1k
Activity
Sep ’26