When you touch down on a button in a scroll view, you can cancel the tap by scrolling. In SwiftUI, this works correctly when the scroll view is not inside a dismissible sheet.
However, if the scroll view is inside a sheet that can be dismissed with a drag gesture, scrolling does not cancel the button touch, and after scrolling, the button tap is activated.
This happens whether the modal is presented from SwiftUI using the sheet modifier, or wrapped in a UIHostingController and presented from UIKit.
This is a huge usability issue for modals with scrollable content that have buttons inside of them.
Video of behavior: https://youtube.com/shorts/w6eqsmTrYiU
Easily reproducible with this code:
import SwiftUI
struct ContentView: View {
@State private var isPresentingSheet = false
var body: some View {
ScrollView {
LazyVStack {
ForEach(0..<100, id: \.self) { index in
Button {
isPresentingSheet = true
} label: {
Text("Button \(index)")
.padding(.horizontal)
.padding(.vertical, 5)
.frame(maxWidth: .infinity, alignment: .leading)
}
}
}
.padding()
}
.sheet(isPresented: $isPresentingSheet) {
ContentView()
}
}
}
Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Overview
I have an iOS project where I have a list with sections.
Each cell in the section can be swiped to have some action
What needs to be done
When swipe button is pressed the cell needs to move from one section to the other without a UI glitch.
Problem
When I press the swipe action button, there is a UI glitch and some warnings are thrown.
UICollectionView internal inconsistency: unexpected removal of the current swipe occurrence's mask view. Please file a bug against UICollectionView. Reusable view: <SwiftUI.ListCollectionViewCell: 0x10700c200; baseClass = UICollectionViewListCell; frame = (16 40.3333; 370 52); hidden = YES; layer = <CALayer: 0x600000c12fa0>>; Collection view: <SwiftUI.UpdateCoalescingCollectionView: 0x106820800; baseClass = UICollectionView; frame = (0 0; 402 874); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000c13330>; backgroundColor = <UIDynamicSystemColor: 0x60000173a9c0; name = systemGroupedBackgroundColor>; layer = <CALayer: 0x600000c3a070>; contentOffset: {0, -62}; contentSize: {402, 229}; adjustedContentInset: {62, 0, 34, 0}; layout: <UICollectionViewCompositionalLayout: 0x10590edb0>; dataSource: <_TtGC7SwiftUI31UICollectionViewListCoordinatorGVS_28CollectionViewListDataSourceOs5Never_GOS_19SelectionManagerBoxS2___: 0x106822a00>>; Swipe occurrence: <UISwipeOccurrence: 0x103c161f0; indexPath: <NSIndexPath: 0xab1f048608f3828b> {length = 2, path = 0 - 0}, state: .triggered, direction: left, offset: 0>
Test environment:
Xcode 26.0.1 (17A400)
iOS 26 Simulator (iPhone 17 Pro)
Feedback filed:
FB20890361
Code
I have pasted below the minimum reproducible code
ContentView
import SwiftUI
struct ContentView: View {
@State private var dataStore = DataStore()
var body: some View {
List {
ToDoSection(status: .notStarted, toDos: notStartedToDos)
ToDoSection(status: .inProgress, toDos: inProgressToDos)
ToDoSection(status: .completed, toDos: completedTodos)
}
}
var notStartedToDos: [Binding<ToDoItem>] {
$dataStore.todos.filter { $0.wrappedValue.status == .notStarted }
}
var inProgressToDos: [Binding<ToDoItem>] {
$dataStore.todos.filter { $0.wrappedValue.status == .inProgress }
}
var completedTodos: [Binding<ToDoItem>] {
$dataStore.todos.filter { $0.wrappedValue.status == .completed }
}
}
ToDoSection
import SwiftUI
struct ToDoSection: View {
let status: ToDoItem.Status
let toDos: [Binding<ToDoItem>]
var body: some View {
if !toDos.isEmpty {
Section(status.title) {
ForEach(toDos) { toDo in
Text(toDo.wrappedValue.title)
.swipeActions(edge: .trailing) {
if status == .notStarted {
Button("Start") {
toDo.wrappedValue.status = .inProgress
}
}
if status != .completed {
Button("Complete") {
toDo.wrappedValue.status = .completed
}
Button("Move back") {
toDo.wrappedValue.status = .notStarted
}
}
}
}
}
}
}
}
ToDoItem
import Foundation
struct ToDoItem: Identifiable {
let id: UUID
let title: String
var status: Status
}
extension ToDoItem {
enum Status: Equatable {
case notStarted
case inProgress
case completed
var title: String {
switch self {
case .notStarted:
"Not Started"
case .inProgress:
"In Progress"
case .completed:
"Completed"
}
}
}
}
DataStore
import Foundation
@Observable
class DataStore {
var todos: [ToDoItem]
init() {
todos = [
ToDoItem(id: UUID(), title: "aaa", status: .notStarted),
ToDoItem(id: UUID(), title: "bbb", status: .notStarted),
ToDoItem(id: UUID(), title: "ccc", status: .notStarted)
]
}
}
Topic:
UI Frameworks
SubTopic:
SwiftUI
We have separated much of our UI into different packages to reduce complexity and compile time. When we recently tested using new .xcstrings string catalogs, we hit an unexpected problem.
Strings extracted from SwiftUI components like Text or Button are extracted into the Localizable.xcstrings in the same package, but the default behaviour of Text(_ key:tableName:bundle:comment:) is to use Bundle.main.
When the default behaviour of the string extraction isn't to extract to the main app target, this introduces a very fragile system where it's easy to add code that looks localised, but ends up failing lookup at runtime.
I don't feel comfortable that we will always remember to define the correct module every time we create a Text. Also, other components like Button doesn't have an init that takes a Bundle, so we would also have to remember that Button(_ titleKey:action:) can now only be used in a package if we make sure that the main bundle contains a matching key.
Is there a way for us to make sure that strings are always extracted to the same place as they are resolved against by default? Either by having strings in packages extracted to an xcstrings file in the main app or having Text default to resolving against the module bundle by default?
We have some rather old code that worked for many years, but recently started to crash sporadically here:
The crash looks like this:
or
Our code is called from many threads concurrently, but as said it worked without any issues until recently.
I've found the apparently same crash on iOS at this Reddit post: https://www.reddit.com/r/iOSProgramming/comments/1kle4h4/ios_185_doesnt_fix_cicontext_rendering_crash/
Recap: we believe it started on macOS 18.4 and is still on macOS 18.5. But maybe it was already on macOS 18.3. This matches the observation in the Reddit post well.
Should we create a feedback with sysdiagnose?
Thanks! :)
Is there any way to prevent the keyboard from bouncing when changing the focus state in onSubmit? Or is it not recommended to change focus in onSubmit?
The following view is setup so that pressing return on the keyboard should cause focus to move between the TextFields.
struct TextFieldFocusState: View {
enum Field {
case field1
case field2
}
@FocusState var focusedField: Field?
var body: some View {
Form {
TextField("Field 1", text: .constant(""))
.focused($focusedField, equals: .field1)
.onSubmit { focusedField = .field2 }
TextField("Field 2", text: .constant(""))
.focused($focusedField, equals: .field2)
.onSubmit { focusedField = .field1 }
}
}
}
I would expect that when pressing return, the keyboard would say on screen.
What actually happens is the keyboard appears to bounce when the return key is pressed (first half of gif). I assume this is because onSubmit starts dismissing the keyboard then setting the focus state causes the keyboard to be presented again.
The issue doesn't occur when tapping directly on the text fields to change focus (second half of gif).
Hello, community and Apple engineers. I need your help.
Our app has the following issue: NavigationStack pushes a view twice if the NavigationStack is inside TabView and NavigationStack uses a navigation path of custom Hashable elements.
Our app works with issues in Xcode 18 Beta 13 + iOS 18.0. The same issue happened on previous beta versions of Xcode 18.
The issue isn’t represented in iOS 17.x and everything worked well before iOS 18.0 beta releases.
I was able to represent the same issue in a clear project with two simple views. I will paste the code below.
Several notes:
We use a centralised routing system in our app where all possible routes for navigation path are implemented in a View extension called withAppRouter().
We have a enum RouterDestination that contains all possible routes and is resolved in withAppRouter() extension.
We use Router class that contains @Published var path: [RouterDestination] = [] and this @Published property is bound to NavigationStack. In the real app, we need to have an access to this path property for programmatic navigation purposes.
Our app uses @ObservableObject / @StateObject approach.
import SwiftUI
struct ContentView: View {
@StateObject private var router = Router()
var body: some View {
TabView {
NavigationStack(path: $router.path) {
NavigationLink(value: RouterDestination.next, label: {
Label("Next", systemImage: "plus.circle.fill")
})
.withAppRouter()
}
}
}
}
enum RouterDestination: Hashable {
case next
}
struct SecondView: View {
var body: some View {
Text("Screen 2")
}
}
class Router: ObservableObject {
@Published var path: [RouterDestination] = []
}
extension View {
func withAppRouter() -> some View {
navigationDestination(for: RouterDestination.self) { destination in
switch destination {
case .next:
return SecondView()
}
}
}
}
Below you can see the GIF with the issue:
What I tried to do:
Use iOS 17+ @Observable approach. It didn’t help.
Using @State var path: [RouterDestination] = [] directly inside View seems to help. But it is not what we want as we need this property to be @Published and located inside Router class where we can get an access to it, and use for programmatic navigation if needed.
I ask Apple engineers to help with that, please, and if it is a bug of iOS 18 beta, then please fix it in the next versions of iOS 18.0
With the introduction of the new matchedTransitionSource from iOS 18, we can apply a zoom transition in the navigation view using .navigationTransition(.zoom) This works well for zoom animations.
However, when I try to apply a matched geometry effect to views that are similar in the source and destination views, the zoom transition works, but those views don't transition seamlessly as they do with a matched geometry effect.
Is it possible to still use matched geometry for subviews of the source and destination views along with the new navigationTransition?
Here’s a little demo that reproduces this behaviour:
struct ContentView: View {
let colors: [[Color]] = [
[.red, .blue, .green],
[.yellow, .purple, .brown],
[.cyan, .gray]
]
@Namespace() var namespace
var body: some View {
NavigationStack {
Grid(horizontalSpacing: 50, verticalSpacing: 50) {
ForEach(colors, id: \.hashValue) { rowColors in
GridRow {
ForEach(rowColors, id: \.self) { color in
NavigationLink {
DetailView(color: color, namespace: namespace)
.navigationTransition(
.zoom(
sourceID: color,
in: namespace
)
)
.edgesIgnoringSafeArea(.all)
} label: {
ZStack {
RoundedRectangle(cornerRadius: 5)
.foregroundStyle(color)
.frame(width: 48, height: 48)
Image(systemName: "star.fill")
.foregroundStyle(Material.bar)
.matchedGeometryEffect(id: color,
in: namespace,
properties: .frame, isSource: false)
}
}
.matchedTransitionSource(id: color, in: namespace)
}
}
}
}
}
}
}
struct DetailView: View {
var color: Color
let namespace: Namespace.ID
var body: some View {
ZStack {
color
Image(systemName: "star.fill")
.resizable()
.foregroundStyle(Material.bar)
.matchedGeometryEffect(id: color,
in: namespace,
properties: .frame, isSource: false)
.frame(width: 100, height: 100)
}
.navigationBarHidden(false)
}
}
#Preview {
ContentView()
}
I opened a feedback ticket (FB16508762) but maybe someone in the community already found a workaround while the feedback reaches the maintainers.
When I put a Button inside a ScrollView, the tap animation stops working reliably and works only when the user taps and holds the button for a short time. The reasons, I believe is related to the fact that isPressed of configuration does not change and the default button styles use it to animate the tap.
import SwiftUI
struct DebuggingButtonStyle: ButtonStyle {
func makeBody(configuration: Configuration) -> some View {
configuration.label
.onChange(of: configuration.isPressed, { oldValue, newValue in
print("Is pressed: \(oldValue) -> \(newValue)")
})
}
}
struct ContentView: View {
var body: some View {
VStack {
Text("Buttons inside scroll view respond to taps as expected, however isPessed value of the configuration do not change unless the user press and hold it. Try to press the promiment button quickly or use the debug button and observe the console log.")
ScrollView {
VStack {
Button("Button Inside ScrollView") {
print("Button tapped")
}
.buttonStyle(.borderedProminent)
Button("Button Inside ScrollView (printing isPressed)") {
print("Button tapped")
}
.buttonStyle(DebuggingButtonStyle())
}
}
.border(FillShapeStyle(), width: 2)
Spacer()
Text("For reference, here is a button outside of a ScrollView. Tap the promiment button to observe how the button is expected to animate in respnse to a press.")
VStack {
Button("Button Outside ScrollView") {
print("Button tapped")
}
.buttonStyle(.borderedProminent)
Button("Button Outside ScrollView (printing isPressed)") {
print("Button tapped")
}
.buttonStyle(DebuggingButtonStyle())
}
}
.padding()
}
}
Basically when showing a view using the .fullScreenCover modifier, it has no background anymore, any other UI elements are still shown but the view under it is also still shown.
When I dismiss a view presented with .navigationTransition(.zoom), the source view gets a weird background (black or white depending on the appearance) for a couple of seconds, and then it disappears.
Here’s a simple code example.
import SwiftUI
struct NavigationTransition: View {
@Namespace private var namespace
@State private var isSecondViewPresented = false
var body: some View {
NavigationStack {
ZStack {
DetailView(namespace: namespace)
.onTapGesture {
isSecondViewPresented = true
}
}
.fullScreenCover(isPresented: $isSecondViewPresented) {
SecondView()
.navigationTransition(.zoom(sourceID: "world", in: namespace))
}
}
}
}
struct DetailView: View {
var namespace: Namespace.ID
var body: some View {
ZStack {
Color.blue
Text("Hello World!")
.foregroundStyle(.white)
.matchedTransitionSource(id: "world", in: namespace)
}
.ignoresSafeArea()
}
}
struct SecondView: View {
var body: some View {
ZStack {
Color.green
Image(systemName: "globe")
.foregroundStyle(Color.red)
}
.ignoresSafeArea()
}
}
#Preview {
NavigationTransition()
}
Summary
As presented in the SwiftUI WWDC video, the new tabViewBottomAccessory should allow for unique contents for .inline. This is what was presented as being used for the Apple Music miniplayer. However, the functionality seems to be either missing or unintuitive. As seen in the photos attached, not only does .inline functionality not seem to do anything, but the inline accessory also has misaligned elements that cannot be fixed by conditionally modifying the contents.
Build Target
iOS 26.0
Details
This problem recurs on physical devices, simulators, and Xcode previews.
Here is a view I've constructed for use as a tabViewBottomAccessory:
struct FitnessToolbarAccessory: View {
@Environment(\.tabViewBottomAccessoryPlacement) var placement
var body: some View {
if (placement == .inline) {
Text("hello")
} else {
HStack {
HStack {
Image(systemName: "dumbbell.fill")
VStack(alignment: .leading) {
Text("Active Workout")
Text("Push Day - Chest")
.font(.system(size: 13))
}
Spacer()
Image(systemName: "pause.fill")
}
.padding()
}
}
}
}
Here is the result, working as expected in expanded mode:
And here is the result in inline mode after minimizing the tabViewBottomAccessory:
The content of this inline accessory is clearly incorrect, as it was specified to contain a Text view containing "hello". Additionally, the contents seem to have some incorrect alignment. This occurs regardless of the contents of the accessory, even plain text.
Right now, the traffic light buttons overlapped on my iPad app top corner on windows mode (full screen is fine).
How do I properly design my app to avoid the traffic light buttons? Detect that it is iPadOS 26?
Topic:
UI Frameworks
SubTopic:
SwiftUI
I have some really straight forward code in a sample project. For some reason when the app launches the title is blurred obscured by scrolledgeeffect blur. If I scroll down the title goes small as it should do and all looks fine. If I scroll back to the top, just before it reaches the top the title goes large and it looks correct, but once it actually reaches/snaps to the top, is then incorrectly blurs again.
Is there anything obvious I'm doing wrong? Is this a bug?
struct ContentView: View {
var body: some View {
NavigationStack {
ScrollView {
VStack {
Rectangle().fill(Color.red.opacity(0.2)).frame(height: 200)
Rectangle().frame(height: 200)
Rectangle().frame(height: 200)
Rectangle().frame(height: 200)
Rectangle().frame(height: 200)
}
}
.safeAreaBar(edge: .top) {
Text("Test")
}
.navigationTitle(Title")
}
}
}
When displaying a view with a Button inside a ScrollView using the sheet modifier, if you try to close the sheet by swiping and your finger is touching the Button, the touch is not canceled.
This issue occurs when building with Xcode 16 but does not occur when building with Xcode 15.
Here is screen cast.
https://drive.google.com/file/d/1GaOjggWxvjDY38My4JEl-URyik928iBT/view?usp=sharing
Code
struct ContentView: View {
@State var isModalPresented: Bool = false
var body: some View {
ScrollView {
Button {
debugPrint("Hello")
isModalPresented.toggle()
} label: {
Text("Hello")
.frame(height: 44)
}
Button {
debugPrint("World")
} label: {
Text("World")
.frame(height: 44)
}
Text("Hoge")
.frame(height: 44)
.contentShape(Rectangle())
.onTapGesture {
debugPrint("Hoge")
}
}
.sheet(isPresented: $isModalPresented) {
ContentView()
}
}
}
Using an App Clip link encoded into a QR Code shows an error when scanning the encoded QR Code on an iPhone or iPad.
After being scanned, the App Clip's banner is visible, but a message says: "App Clip Unavailable".
Accessing the same App Clip URL via Safari works as expected.
I've filed a feedback with more details and screenshots of the issue here: FB17891015
Thanks!
Why is the UIKeyboard implementation still holding a reference to this UITextField, thus keeping it from being deallocated?
The memory debugger shows:
UIKeyboardImpl -> UIKBAutofillController -> NSMutableDictionary -> NSMutable...(Storage) -> UITextField
Any idea what's going on there?
We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible:
What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app.
What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it
Here's two similar stack traces:
App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash
App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash
Since these are private trameworks, there is no documentation or information on their behavior that I can find.
There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips!
Here's the long version, in case anyone finds it useful:
In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves.
Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause.
Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition.
There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain.
And here's the stack trace inline, in case the attachments expire or search engines can't read them:
Thread 0 name:
Thread 0 Crashed:
objc_retain_x2 (libobjc.A.dylib)
BSIntegerMapEnumerateWithBlock (BaseBoard)
-[BSSettings initWithSettings:] (BaseBoard)
-[BSKeyedSettings initWithSettings:] (BaseBoard)
-[FBSSettings _settings:] (FrontBoardServices)
-[FBSSettings _settings] (FrontBoardServices)
-[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices)
-[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices)
-[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices)
-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices)
__94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices)
-[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices)
__94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices)
__94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices)
_dispatch_client_callout (libdispatch.dylib)
_dispatch_block_invoke_direct (libdispatch.dylib)
__FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices)
-[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices)
-[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices)
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation)
__CFRunLoopDoSource0 (CoreFoundation)
__CFRunLoopDoSources0 (CoreFoundation)
__CFRunLoopRun (CoreFoundation)
CFRunLoopRunSpecific (CoreFoundation)
GSEventRunModal (GraphicsServices)
-[UIApplication _run] (UIKitCore)
UIApplicationMain (UIKitCore)
(null) (UIKitCore)
main (AppDelegate.swift:0)
0x1ab8cbf08 + 0
Hello there!
I wanted to give a native scrolling mechanism for the Swift Charts Graph a try and experiment a bit if the scenario that we try to achieve might be possible, but it seems that the Swift Charts scrolling performance is very poor.
The graph was created as follows:
X-axis is created based on a date range,
Y-axis is created based on an integer values between moreless 0-320 value.
the graph is scrollable horizontally only (x-axis),
The time range (x-axis) for the scrolling content was set to one year from now date (so the user can scroll one year into the past as a minimum visible date (.chartXScale).
The X-axis shows 3 hours of data per screen width (.chartXVisibleDomain).
The data points for the graph are generated once when screen is about to appear so that the Charts engine can use it (no lazy loading implemented yet).
The line data points (LineMark views) consist of 2880 data points distributed every 5 minutes which simulates - two days of continuous data stream that we want to present. The rest of the graph displays no data at all.
The performance result:
The graph on the initial loading phase is frozen for about 10-15 seconds until the data appears on the graph.
Scrolling is very laggy - the CPU usage is 100% and is unacceptable for the end users.
If we show no data at all on the graph (so no LineMark views are created at all) - the result is similar - the empty graph scrolling is also very laggy.
Below I am sharing a test code:
@main
struct ChartsTestApp: App {
var body: some Scene {
WindowGroup {
ContentView()
Spacer()
}
}
}
struct LineDataPoint: Identifiable, Equatable {
var id: Int
let date: Date
let value: Int
}
actor TestData {
func generate(startDate: Date) async -> [LineDataPoint] {
var values: [LineDataPoint] = []
for i in 0..<(1440 * 2) {
values.append(
LineDataPoint(
id: i,
date: startDate.addingTimeInterval(
TimeInterval(60 * 5 * i) // Every 5 minutes
),
value: Int.random(in: 1...100)
)
)
}
return values
}
}
struct ContentView: View {
var startDate: Date {
return endDate.addingTimeInterval(-3600*24*30*12) // one year into the past from now
}
let endDate = Date()
@State var dataPoints: [LineDataPoint] = []
var body: some View {
Chart {
ForEach(dataPoints) { item in
LineMark(
x: .value("Date", item.date),
y: .value("Value", item.value),
series: .value("Series", "Test")
)
}
}
.frame(height: 200)
.chartScrollableAxes(.horizontal)
.chartYAxis(.hidden)
.chartXScale(domain: startDate...endDate) // one year possibility to scroll back
.chartXVisibleDomain(length: 3600 * 3) // 3 hours visible on screen
.onAppear {
Task {
dataPoints = await TestData().generate(startDate: startDate)
}
}
}
}
I would be grateful for any insights or suggestions on how to improve it or if it's planned to be improved in the future.
Currently, I use UIKit CollectionView where we split the graph into smaller chunks of the graph and we present the SwiftUI Chart content in the cells, so we use the scrolling offered there. I wonder if it's possible to use native SwiftUI for such a scenario so that later on we could also implement some kind of lazy loading of the data as the user scrolls into the past.
When building with iOS 26 SDK beta 5 (23A5308f), onTapGesture is no longer being triggered on Map views. This appears to be a regression in beta 5 specifically, as this issue was not present in beta 4.
How to reproduce
Code
The following code demonstrates the issue, as seen in the videos below.
import MapKit
import SwiftUI
struct ContentView: View {
@State private var location = CGPoint.zero
var body: some View {
Map()
.onTapGesture { location in
self.location = location
}
.safeAreaInset(edge: .bottom) {
VStack(alignment: .center) {
Text("iOS \(UIDevice.current.systemVersion)")
.font(.largeTitle)
Text("Tapped Location")
Text("\(location.x), \(location.y)")
}
.frame(maxWidth: .infinity, alignment: .center)
.background(.background)
}
}
}
Demo
The gifs below show the behavior in iOS 18.5 (in which the tap gestures are recognized and tapped coordinate is displayed in the safe area inset) and iOS 26 beta 5 (in which the tap gestures have no effect):
iOS 18
iOS 26
Next steps?
Is there a recommended workaround for this issue?
I have installed the iOS 26 Beta on my device and conducted a comprehensive functionality test of my iOS application, which I designed and developed. The application includes a feature that allows users to share images directly to X (formerly Twitter) and Facebook.
During testing, I encountered an issue where the icons for X (formerly Twitter) and Facebook do not appear in the share dialog, despite both apps being installed on the device. This issue prevents users from sharing images to these platforms directly from the app.
Steps to Reproduce:
1.Install iOS 26 Beta on a compatible device.
2.Ensure that both the X (formerly Twitter) and Facebook apps are installed and logged in on the device.
3.Open the iOS application and navigate to the image sharing feature.
4.Attempt to share an image using the share dialog.
5.Observe that the icons for X (formerly Twitter) and Facebook are missing from the share options.
Expected Behavior:
The share dialog should display icons for X (formerly Twitter) and Facebook, allowing users to share images directly to these platforms.
Actual Behavior:
The icons for X (formerly Twitter) and Facebook do not appear in the share dialog, preventing direct sharing to these platforms.
Code Implementation:
I have not implemented any code to exclude X (formerly Twitter) and Facebook from the share options. Below is the relevant code for controlling the share screen:
let activityViewController = UIActivityViewController(activityItems: activityItems, applicationActivities: applicationActivities)
let excludedTypes = [
UIActivity.ActivityType.assignToContact,
UIActivity.ActivityType.print,
]
activityViewController.excludedActivityTypes = excludedTypes
activityViewController.completionWithItemsHandler = completion
self.present(activityViewController, animated: true, completion: nil)
As shown in the implementation, there is no exclusion of X (formerly Twitter) and Facebook, yet their icons do not appear in the share dialog.