Post

Replies

Boosts

Views

Activity

SwiftUI confirmationDialog in List inside .sheet is no longer anchored to the originating row on iOS 27 beta
Area SwiftUI → Presentation / ConfirmationDialog Summary After building with Xcode 27 beta, confirmationDialog presented from a row inside a List that is embedded in a .sheet is no longer anchored to the row that triggered it. Instead, the dialog is displayed near the top of the sheet when the sheet is partially expanded, or in the center of the screen when the sheet occupies the full height. This behavior is reproducible across all tested Xcode 27 beta releases and iOS 27 beta releases (Beta 1, Beta 2, and Beta 3). Steps to Reproduce Present a SwiftUI .sheet. Place a List inside the sheet. Add a confirmationDialog to each list row. Trigger the dialog from a swipe action on any row. Observe the position where the confirmation dialog appears. A minimal reproducible sample project is attached. Expected Result The confirmationDialog should be visually associated with the row that triggered it, as it behaved in previous Xcode and iOS releases. The dialog should appear anchored to the selected list row (or as close as the platform allows), providing clear contextual feedback to the user about which item is being acted upon. Actual Result The dialog is no longer associated with the selected row. When the sheet is not fully expanded, the dialog appears near the top area of the sheet, seemingly positioned relative to the sheet itself rather than the triggering row. When the sheet is expanded to full height, the dialog appears in the center of the screen. As a result, the relationship between the selected item and the confirmation dialog is lost, creating a confusing user experience. Regression Yes. The same implementation behaved correctly in previous Xcode and iOS versions. The issue first appeared after upgrading to Xcode 27 beta and remains present in all tested iOS 27 beta releases (Beta 1–3). Impact This is a significant UX regression for existing applications that rely on contextual confirmation dialogs within lists presented inside sheets. Applications that already have production users cannot easily redesign their interaction model to compensate for this behavior change. The previous behavior provided clear context about which list item was being acted upon, while the current behavior makes that association unclear. Configuration Xcode 27 Beta (all tested beta versions) iOS 27 Beta 1 iOS 27 Beta 2 iOS 27 Beta 3 Reproduced on physical devices Reproduced using the attached minimal sample project Attachments Minimal reproducible sample project. Screenshot showing expected behavior (prior implementation). Screenshot showing current behavior on iOS 27 Beta 3. Screen recording demonstrating the regression. struct ContentView: View { @State private var sheetIsPresented = false @State private var itemPendingDeletion: Int? = nil var array = Array(0...100) var body: some View { VStack { Text("Hello, world!") Button("Show List") { sheetIsPresented = true } } .sheet(isPresented: $sheetIsPresented) { List { ForEach(array, id: \.self) { value in ListRow(for: value) .confirmationDialog("Delete?", isPresented: Binding( get: { itemPendingDeletion == value }, set: { isPresented in if !isPresented { itemPendingDeletion = nil } } ) ) { Button { } label: { Text("Delete") } } .swipeActions(edge: .trailing) { Button { itemPendingDeletion = value } label: { Image(systemName: "trash") .foregroundStyle(.red) } } } .listRowInsets(EdgeInsets()) .listRowBackground(Color.clear) } .listStyle(.inset) .contentMargins(16, for: .scrollContent) .presentationDetents([.fraction(1), .fraction(0.9)]) } } @ViewBuilder private func ListRow(for value: Int) -> some View { Text("\(value)") .foregroundStyle(.primary) .padding(.vertical) .frame(maxWidth: .infinity) .background( RoundedRectangle(cornerRadius: 26, style: .continuous) ) .padding(.vertical, 2) } } #Preview { ContentView() } Xcode 27(Beta 1,2,3) Xcode 26.5
1
0
234
3w
SwiftUI confirmationDialog in List inside .sheet is no longer anchored to the originating row on iOS 27 beta
Area SwiftUI → Presentation / ConfirmationDialog Summary After building with Xcode 27 beta, confirmationDialog presented from a row inside a List that is embedded in a .sheet is no longer anchored to the row that triggered it. Instead, the dialog is displayed near the top of the sheet when the sheet is partially expanded, or in the center of the screen when the sheet occupies the full height. This behavior is reproducible across all tested Xcode 27 beta releases and iOS 27 beta releases (Beta 1, Beta 2, and Beta 3). Steps to Reproduce Present a SwiftUI .sheet. Place a List inside the sheet. Add a confirmationDialog to each list row. Trigger the dialog from a swipe action on any row. Observe the position where the confirmation dialog appears. A minimal reproducible sample project is attached. Expected Result The confirmationDialog should be visually associated with the row that triggered it, as it behaved in previous Xcode and iOS releases. The dialog should appear anchored to the selected list row (or as close as the platform allows), providing clear contextual feedback to the user about which item is being acted upon. Actual Result The dialog is no longer associated with the selected row. When the sheet is not fully expanded, the dialog appears near the top area of the sheet, seemingly positioned relative to the sheet itself rather than the triggering row. When the sheet is expanded to full height, the dialog appears in the center of the screen. As a result, the relationship between the selected item and the confirmation dialog is lost, creating a confusing user experience. Regression Yes. The same implementation behaved correctly in previous Xcode and iOS versions. The issue first appeared after upgrading to Xcode 27 beta and remains present in all tested iOS 27 beta releases (Beta 1–3). Impact This is a significant UX regression for existing applications that rely on contextual confirmation dialogs within lists presented inside sheets. Applications that already have production users cannot easily redesign their interaction model to compensate for this behavior change. The previous behavior provided clear context about which list item was being acted upon, while the current behavior makes that association unclear. Configuration Xcode 27 Beta (all tested beta versions) iOS 27 Beta 1 iOS 27 Beta 2 iOS 27 Beta 3 Reproduced on physical devices Reproduced using the attached minimal sample project Attachments Minimal reproducible sample project. Screenshot showing expected behavior (prior implementation). Screenshot showing current behavior on iOS 27 Beta 3. Screen recording demonstrating the regression. struct ContentView: View { @State private var sheetIsPresented = false @State private var itemPendingDeletion: Int? = nil var array = Array(0...100) var body: some View { VStack { Text("Hello, world!") Button("Show List") { sheetIsPresented = true } } .sheet(isPresented: $sheetIsPresented) { List { ForEach(array, id: \.self) { value in ListRow(for: value) .confirmationDialog("Delete?", isPresented: Binding( get: { itemPendingDeletion == value }, set: { isPresented in if !isPresented { itemPendingDeletion = nil } } ) ) { Button { } label: { Text("Delete") } } .swipeActions(edge: .trailing) { Button { itemPendingDeletion = value } label: { Image(systemName: "trash") .foregroundStyle(.red) } } } .listRowInsets(EdgeInsets()) .listRowBackground(Color.clear) } .listStyle(.inset) .contentMargins(16, for: .scrollContent) .presentationDetents([.fraction(1), .fraction(0.9)]) } } @ViewBuilder private func ListRow(for value: Int) -> some View { Text("\(value)") .foregroundStyle(.primary) .padding(.vertical) .frame(maxWidth: .infinity) .background( RoundedRectangle(cornerRadius: 26, style: .continuous) ) .padding(.vertical, 2) } } #Preview { ContentView() } Xcode 27(Beta 1,2,3) Xcode 26.5
0
0
111
3w
Hourly repeating notification.
Somebody help me please. I try to set specific time for notification, it works nice, but if you need a little beat more functional this is where difficulties appear. I'd like to give opportunities for repeat, example every hour. I know that UNCalendarNotificationTriger has a repeat value, but when you set repeat on true it remember date component, exp - .minute, and then just repeating notification every time when that minute comes! I'm looking for solution for set notification at special time(exp: 5:00 pm), and then repeating this notification every hour(6, 7, 8, 9 pm) Maybe it's so easy but looks like I feel stuck 😕
2
0
664
Oct ’24
SwiftUI confirmationDialog in List inside .sheet is no longer anchored to the originating row on iOS 27 beta
Area SwiftUI → Presentation / ConfirmationDialog Summary After building with Xcode 27 beta, confirmationDialog presented from a row inside a List that is embedded in a .sheet is no longer anchored to the row that triggered it. Instead, the dialog is displayed near the top of the sheet when the sheet is partially expanded, or in the center of the screen when the sheet occupies the full height. This behavior is reproducible across all tested Xcode 27 beta releases and iOS 27 beta releases (Beta 1, Beta 2, and Beta 3). Steps to Reproduce Present a SwiftUI .sheet. Place a List inside the sheet. Add a confirmationDialog to each list row. Trigger the dialog from a swipe action on any row. Observe the position where the confirmation dialog appears. A minimal reproducible sample project is attached. Expected Result The confirmationDialog should be visually associated with the row that triggered it, as it behaved in previous Xcode and iOS releases. The dialog should appear anchored to the selected list row (or as close as the platform allows), providing clear contextual feedback to the user about which item is being acted upon. Actual Result The dialog is no longer associated with the selected row. When the sheet is not fully expanded, the dialog appears near the top area of the sheet, seemingly positioned relative to the sheet itself rather than the triggering row. When the sheet is expanded to full height, the dialog appears in the center of the screen. As a result, the relationship between the selected item and the confirmation dialog is lost, creating a confusing user experience. Regression Yes. The same implementation behaved correctly in previous Xcode and iOS versions. The issue first appeared after upgrading to Xcode 27 beta and remains present in all tested iOS 27 beta releases (Beta 1–3). Impact This is a significant UX regression for existing applications that rely on contextual confirmation dialogs within lists presented inside sheets. Applications that already have production users cannot easily redesign their interaction model to compensate for this behavior change. The previous behavior provided clear context about which list item was being acted upon, while the current behavior makes that association unclear. Configuration Xcode 27 Beta (all tested beta versions) iOS 27 Beta 1 iOS 27 Beta 2 iOS 27 Beta 3 Reproduced on physical devices Reproduced using the attached minimal sample project Attachments Minimal reproducible sample project. Screenshot showing expected behavior (prior implementation). Screenshot showing current behavior on iOS 27 Beta 3. Screen recording demonstrating the regression. struct ContentView: View { @State private var sheetIsPresented = false @State private var itemPendingDeletion: Int? = nil var array = Array(0...100) var body: some View { VStack { Text("Hello, world!") Button("Show List") { sheetIsPresented = true } } .sheet(isPresented: $sheetIsPresented) { List { ForEach(array, id: \.self) { value in ListRow(for: value) .confirmationDialog("Delete?", isPresented: Binding( get: { itemPendingDeletion == value }, set: { isPresented in if !isPresented { itemPendingDeletion = nil } } ) ) { Button { } label: { Text("Delete") } } .swipeActions(edge: .trailing) { Button { itemPendingDeletion = value } label: { Image(systemName: "trash") .foregroundStyle(.red) } } } .listRowInsets(EdgeInsets()) .listRowBackground(Color.clear) } .listStyle(.inset) .contentMargins(16, for: .scrollContent) .presentationDetents([.fraction(1), .fraction(0.9)]) } } @ViewBuilder private func ListRow(for value: Int) -> some View { Text("\(value)") .foregroundStyle(.primary) .padding(.vertical) .frame(maxWidth: .infinity) .background( RoundedRectangle(cornerRadius: 26, style: .continuous) ) .padding(.vertical, 2) } } #Preview { ContentView() } Xcode 27(Beta 1,2,3) Xcode 26.5
Replies
1
Boosts
0
Views
234
Activity
3w
SwiftUI confirmationDialog in List inside .sheet is no longer anchored to the originating row on iOS 27 beta
Area SwiftUI → Presentation / ConfirmationDialog Summary After building with Xcode 27 beta, confirmationDialog presented from a row inside a List that is embedded in a .sheet is no longer anchored to the row that triggered it. Instead, the dialog is displayed near the top of the sheet when the sheet is partially expanded, or in the center of the screen when the sheet occupies the full height. This behavior is reproducible across all tested Xcode 27 beta releases and iOS 27 beta releases (Beta 1, Beta 2, and Beta 3). Steps to Reproduce Present a SwiftUI .sheet. Place a List inside the sheet. Add a confirmationDialog to each list row. Trigger the dialog from a swipe action on any row. Observe the position where the confirmation dialog appears. A minimal reproducible sample project is attached. Expected Result The confirmationDialog should be visually associated with the row that triggered it, as it behaved in previous Xcode and iOS releases. The dialog should appear anchored to the selected list row (or as close as the platform allows), providing clear contextual feedback to the user about which item is being acted upon. Actual Result The dialog is no longer associated with the selected row. When the sheet is not fully expanded, the dialog appears near the top area of the sheet, seemingly positioned relative to the sheet itself rather than the triggering row. When the sheet is expanded to full height, the dialog appears in the center of the screen. As a result, the relationship between the selected item and the confirmation dialog is lost, creating a confusing user experience. Regression Yes. The same implementation behaved correctly in previous Xcode and iOS versions. The issue first appeared after upgrading to Xcode 27 beta and remains present in all tested iOS 27 beta releases (Beta 1–3). Impact This is a significant UX regression for existing applications that rely on contextual confirmation dialogs within lists presented inside sheets. Applications that already have production users cannot easily redesign their interaction model to compensate for this behavior change. The previous behavior provided clear context about which list item was being acted upon, while the current behavior makes that association unclear. Configuration Xcode 27 Beta (all tested beta versions) iOS 27 Beta 1 iOS 27 Beta 2 iOS 27 Beta 3 Reproduced on physical devices Reproduced using the attached minimal sample project Attachments Minimal reproducible sample project. Screenshot showing expected behavior (prior implementation). Screenshot showing current behavior on iOS 27 Beta 3. Screen recording demonstrating the regression. struct ContentView: View { @State private var sheetIsPresented = false @State private var itemPendingDeletion: Int? = nil var array = Array(0...100) var body: some View { VStack { Text("Hello, world!") Button("Show List") { sheetIsPresented = true } } .sheet(isPresented: $sheetIsPresented) { List { ForEach(array, id: \.self) { value in ListRow(for: value) .confirmationDialog("Delete?", isPresented: Binding( get: { itemPendingDeletion == value }, set: { isPresented in if !isPresented { itemPendingDeletion = nil } } ) ) { Button { } label: { Text("Delete") } } .swipeActions(edge: .trailing) { Button { itemPendingDeletion = value } label: { Image(systemName: "trash") .foregroundStyle(.red) } } } .listRowInsets(EdgeInsets()) .listRowBackground(Color.clear) } .listStyle(.inset) .contentMargins(16, for: .scrollContent) .presentationDetents([.fraction(1), .fraction(0.9)]) } } @ViewBuilder private func ListRow(for value: Int) -> some View { Text("\(value)") .foregroundStyle(.primary) .padding(.vertical) .frame(maxWidth: .infinity) .background( RoundedRectangle(cornerRadius: 26, style: .continuous) ) .padding(.vertical, 2) } } #Preview { ContentView() } Xcode 27(Beta 1,2,3) Xcode 26.5
Replies
0
Boosts
0
Views
111
Activity
3w
Hourly repeating notification.
Somebody help me please. I try to set specific time for notification, it works nice, but if you need a little beat more functional this is where difficulties appear. I'd like to give opportunities for repeat, example every hour. I know that UNCalendarNotificationTriger has a repeat value, but when you set repeat on true it remember date component, exp - .minute, and then just repeating notification every time when that minute comes! I'm looking for solution for set notification at special time(exp: 5:00 pm), and then repeating this notification every hour(6, 7, 8, 9 pm) Maybe it's so easy but looks like I feel stuck 😕
Replies
2
Boosts
0
Views
664
Activity
Oct ’24