Post

Replies

Boosts

Views

Activity

Reply to List Section with Swipe Action - glitches
Possibly the same issue here. Sections not needed to reproduce issue with SwiftUI List in iOS 26, 26.0.1, and 26.1. Filed back in mid-August FB19602925 Minimal code to repro: struct Item: Identifiable, Hashable { var id: Int var title: String } struct ContentView: View { @State var items: [Item] = [ Item(id: 0, title: "One"), Item(id: 1, title: "Two"), Item(id: 2, title: "Three"), ] var body: some View { List(items) { item in Text(item.title) .swipeActions(edge: .trailing) { Button("Pin", systemImage: "pin") { pinItem(item) } .tint(.green) Button("Copy", systemImage: "document.on.document") { duplicateItem(item) } .tint(.blue) } } .listStyle(.plain) } func pinItem(_ item: Item) { if let idx = items.firstIndex(of: item) { items.move(fromOffsets: IndexSet(integer: idx), toOffset: 0) } } func duplicateItem(_ item: Item) { let newId = (items.map(\.id).max() ?? 0) + 1 items.insert(Item(id: newId, title: "Copy of \(item.title)"), at: 0) } }
Topic: UI Frameworks SubTopic: SwiftUI
Nov ’25
Reply to Menu presentation in UIHostingController issues
Found this thread when researching an issue with the same log message in a pure SwiftUI app. There's a nasty layout/animation associated with what I'm seeing (but I'm not sure it's related to the log). A sample project to repro is attached to FB20272800 (apologies for hijacking OP's thread, but I thought it might perhaps be interesting to them that issue reproduces in iOS 26 without using a UIHostingController in our own code. A simple Menu suffices)
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’25
Reply to Completion handler blocks are not supported in background sessions
Howdy! I found this thread and wanted to let you know that I believe I managed to suss out a way to make the omitted parts of the API usage work. It ain't pretty, but here goes. .backgroundTask(.urlSession(my_id_goes_here)) { await downloadManager.waitForBackgroundEvents() } I think key here is that the async waitForBackgroundEvents() function is not allowed to return until our background url session reports that it's finished. Here's how I did that: func waitForBackgroundEvents() async { let task = Task { await withCheckedContinuation { continuation in self.continuation = continuation } } _ = urlSession // trigger lazy initialization of the background url session with relevant identifier. Crucially, this hooks up the delegate which allows processing of events to happen. _ = await task.value // The task is completed by resuming the continuation in response to urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession). Not sharing those parts }``` Sadly, the backgroundTask APIs and URLSession APIs don't really work well together. I think one could imagine a future where some new async addition to URLSession lets you capture the background events in one simple call. Cheers. -- Jonas Salling
Apr ’25
Reply to BGTaskScheduler crashes on iOS 18.4
@DTS Engineer I ran some tests here that I think maybe highlights what's going on: I set a symbolic breakpoint on -[BGTaskScheduler registerForTaskWithIdentifier:usingQueue:launchHandler:] I edited my app scheme to "Wait for the executable to be launched" I run the app from Xcode. I trigger the app to be launched from a home screen widget (AudioPlaybackIntent) Here, on iOS 18.3 and earlier, at the time the app is launched, the symbolic breakpoint is triggered. On 18.4 beta, the symbolic breakpoint is not triggered. Now, foreground the app. On iOS 18.4 beta the symbolic breakpoint is triggered now, but because the app was already launched (in the background) the assert kicks in. I hope you guys are already on track to fix this issue (but it's worrying that we've now seen 4 betas without a fix). I don't think widgets are the only way to trigger this issue. I've seen it happen on the first launch right after installing a new build from TestFlight. Maybe app pre-warming could be another path to trigger the launch without tasks getting registered, but that's just speculation. __ Jonas Salling
Mar ’25
Reply to Zoom navigation transitions for tabViewBottomAccessory are not working in SwiftUI with ObservableObject or Observable
@Gipfeli Interesting. Issue reproduces for me here on 26.4b1 (device).
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Feb ’26
Reply to List Section with Swipe Action - glitches
Possibly the same issue here. Sections not needed to reproduce issue with SwiftUI List in iOS 26, 26.0.1, and 26.1. Filed back in mid-August FB19602925 Minimal code to repro: struct Item: Identifiable, Hashable { var id: Int var title: String } struct ContentView: View { @State var items: [Item] = [ Item(id: 0, title: "One"), Item(id: 1, title: "Two"), Item(id: 2, title: "Three"), ] var body: some View { List(items) { item in Text(item.title) .swipeActions(edge: .trailing) { Button("Pin", systemImage: "pin") { pinItem(item) } .tint(.green) Button("Copy", systemImage: "document.on.document") { duplicateItem(item) } .tint(.blue) } } .listStyle(.plain) } func pinItem(_ item: Item) { if let idx = items.firstIndex(of: item) { items.move(fromOffsets: IndexSet(integer: idx), toOffset: 0) } } func duplicateItem(_ item: Item) { let newId = (items.map(\.id).max() ?? 0) + 1 items.insert(Item(id: newId, title: "Copy of \(item.title)"), at: 0) } }
Topic: UI Frameworks SubTopic: SwiftUI
Replies
Boosts
Views
Activity
Nov ’25
Reply to Expandable cell in List View shows slowly after swiping to delete it
Would like to pile on with a mention of FB19602925 (filed back in mid-August): SwiftUI List: change to items animate incorrectly when swipeAction is involved. I think it could be the same issue. Contains a minimal project to reproduce. If UIDesignRequiresCompatibility is set to true, the problem goes away. Issue is tied to Liquid Glass.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to SwiftUI's tabViewBottomAccessory API Cannot Control Visibility in iOS 26.1
FB20425139
Topic: UI Frameworks SubTopic: SwiftUI
Replies
Boosts
Views
Activity
Oct ’25
Reply to Menu presentation in UIHostingController issues
Found this thread when researching an issue with the same log message in a pure SwiftUI app. There's a nasty layout/animation associated with what I'm seeing (but I'm not sure it's related to the log). A sample project to repro is attached to FB20272800 (apologies for hijacking OP's thread, but I thought it might perhaps be interesting to them that issue reproduces in iOS 26 without using a UIHostingController in our own code. A simple Menu suffices)
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’25
Reply to Completion handler blocks are not supported in background sessions
Howdy! I found this thread and wanted to let you know that I believe I managed to suss out a way to make the omitted parts of the API usage work. It ain't pretty, but here goes. .backgroundTask(.urlSession(my_id_goes_here)) { await downloadManager.waitForBackgroundEvents() } I think key here is that the async waitForBackgroundEvents() function is not allowed to return until our background url session reports that it's finished. Here's how I did that: func waitForBackgroundEvents() async { let task = Task { await withCheckedContinuation { continuation in self.continuation = continuation } } _ = urlSession // trigger lazy initialization of the background url session with relevant identifier. Crucially, this hooks up the delegate which allows processing of events to happen. _ = await task.value // The task is completed by resuming the continuation in response to urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession). Not sharing those parts }``` Sadly, the backgroundTask APIs and URLSession APIs don't really work well together. I think one could imagine a future where some new async addition to URLSession lets you capture the background events in one simple call. Cheers. -- Jonas Salling
Replies
Boosts
Views
Activity
Apr ’25
Reply to BGTaskScheduler crashes on iOS 18.4
@DTS Engineer I ran some tests here that I think maybe highlights what's going on: I set a symbolic breakpoint on -[BGTaskScheduler registerForTaskWithIdentifier:usingQueue:launchHandler:] I edited my app scheme to "Wait for the executable to be launched" I run the app from Xcode. I trigger the app to be launched from a home screen widget (AudioPlaybackIntent) Here, on iOS 18.3 and earlier, at the time the app is launched, the symbolic breakpoint is triggered. On 18.4 beta, the symbolic breakpoint is not triggered. Now, foreground the app. On iOS 18.4 beta the symbolic breakpoint is triggered now, but because the app was already launched (in the background) the assert kicks in. I hope you guys are already on track to fix this issue (but it's worrying that we've now seen 4 betas without a fix). I don't think widgets are the only way to trigger this issue. I've seen it happen on the first launch right after installing a new build from TestFlight. Maybe app pre-warming could be another path to trigger the launch without tasks getting registered, but that's just speculation. __ Jonas Salling
Replies
Boosts
Views
Activity
Mar ’25
Reply to BGTaskScheduler crashes on iOS 18.4
Same. Submitted logs in FB16610879
Replies
Boosts
Views
Activity
Feb ’25