My app uses the SwiftUI Map control to display annotations. When annotations contain buttons AND the map has an .onTapGesture modifier, annotation button taps aren’t always recognized. Given the following ContentView, run it on an iOS device or simulator. Tap the buttons. Since iOS 18.0, some of the buttons won't respond to tap. I've also tried using the onTapGesture instead of a button, and that shows the same issue. This was not a problem under iOS 17.x: it has only shown up for my users since updating to iOS 18. Additionally, this issue does not occur when running on either macOS 15.0 or visionOS 2.0 when running in "designed for iPad" mode. Note that there was previously a tap issue on VisionOS 1.x (designed for iPad), where no tap gestures were received by annotations. I'm curious if this issue could be related. I have filed a report in Feedback Assistant (FB15273909). struct ContentView: View { private let center = CLLocationCoordinate2D(latitude: 37.77925, longitude: -122.41924) @State private var label: String = "tap a button" @State private var locations: [Location] = [] var body: some View { Map { ForEach(locations) { location in Annotation(location.name, coordinate: location.coordinate) { Button(location.name) { print("\(location.name) tapped") label = "\(location.name) tapped" } .buttonStyle(.borderedProminent) } .annotationTitles(.hidden) } } .onTapGesture { point in print("Map tapped") label = "map tapped" } .safeAreaInset(edge: .top) { Text(label) .padding() .background(.thinMaterial) .clipShape(.rect(cornerRadius: 10)) } .navigationTitle("Test Page") .navigationBarTitleDisplayMode(.inline) .task { for index in 1...16 { locations.append(Location(name: "location \(index)", coordinate: CLLocationCoordinate2D(latitude: center.latitude + Double.random(in: -0.02...0.02), longitude: center.longitude + Double.random(in: -0.02...0.02)))) } } } private struct Location: Identifiable { let id: UUID = UUID() let name: String let coordinate: CLLocationCoordinate2D } } #Preview { ContentView() }

Hi I am on ios 18 and xcode 16 I have a view that changes with a timer and I want to be able to long press that view and show a context menu. However the scroll on the context menu seems to be broken? import SwiftUI struct ContentView: View { @State var number = 0 @State var timer = Timer.publish(every: 0.25, on: .main, in: .common).autoconnect() var body: some View { VStack { Text(number.formatted()) .font(.largeTitle) Text("Long press me") Text("Notice context menu cannot scroll down") } .padding() .background { RoundedRectangle(cornerRadius: 10.0) .fill(Color(uiColor: .secondarySystemBackground)) } .contextMenu { ForEach(0 ..< 100) { index in Button { print("option \(index)") } label: { Label("Option \(index)", systemImage: "globe") } } } .onReceive(timer) { t in number += 1 } } } Is this a bug in swiftUI? In my real application I want the context menu to be able to switch the kind of data the user is viewing.

Is it possible to integrate CKShare with SwiftData? I wanted to provide a quick and good experience to my users.

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered AppleArchive crashes instead of failing gracefully when decrypting a corrupt archive. As described in forum post 765101, UIDocumentPickerViewController can handoff a corrupt copy of an archive to UIDocumentPickerDelegate under specific circumstances. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with the bleeding edge iPadOS 18. Our app is primarily Objective-C, but it utilizes the Swift-based AppleArchive 'EncryptingAndDecryptingDirectories' sample code associated with WWDC21 session: 10233: Bring Encrypted Archives and Performance Improvements to Your App with Accelerate. The WWDC21 'EncryptingAndDecryptingDirectories' Swift sample project crashes in a similar manner when a corrupt archive file created by UIDocumentPickerViewController is dropped into the sample app's window for decryption (see attached crash log). Does anyone know if there's a workaround for the 'EncryptingAndDecryptingDirectories' sample project to prevent AppleArchive from crashing when decrypting a corrupt archive? crash log.txt

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18. Here's our Objective-C code which presents the picker: NSArray* contentTypeArray = @[UTTypeAppleArchive]; UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES]; docPickerVC.delegate = self; docPickerVC.allowsMultipleSelection = NO; docPickerVC.shouldShowFileExtensions = YES; docPickerVC.modalPresentationStyle = UIModalPresentationPopover; docPickerVC.popoverPresentationController.sourceView = self.view; [self presentViewController:docPickerVC animated:YES completion:nil]; The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file. When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data. Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details). Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?

Can anyone help me to resolve this issue? I have two collectionviews in a tableview and each time you try to scroll the collecctionview after clicking a cell, it crashes with the following error: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Expected dequeued view to be returned to the collection view in preparation for display. When the collection view's data source is asked to provide a view for a given index path, ensure that a single view is dequeued and returned to the collection view. Avoid dequeuing views without a request from the collection view. For retrieving an existing view in the collection view, use -[UICollectionView cellForItemAtIndexPath:] or -[UICollectionView supplementaryViewForElementKind:atIndexPath:]

I am using Storyboard to present a UIImagePickerController on a view controller (a simple initial view without any navigation or tab bar). Due to a requirement, we need to exclude the arm64 architecture. However, when I try to present the screen, it gets stuck. I am unable to select an image, and the screen becomes inaccessible. It's happening only on simulator. Does anyone have any solution.

I want to get which button in AccessoryWidgetGroup was pressed in the Watch App, but I can't. When I use Button(_:intent:), it works in Smart Stack, but it doesn't work in Complication Widget. Using widgetURL(_:) always gets the URL of the first button. Below is a snippet of the code I tried. All codes can be found here. struct MyWatchWidgetEntryView : View { var entry: Provider.Entry var body: some View { AccessoryWidgetGroup("Widget Group") { MyWatchWidgetEntryButton(intent: .init(id: "001", imageName: "star.fill")) MyWatchWidgetEntryButton(intent: .init(id: "002", imageName: "heart.fill")) MyWatchWidgetEntryButton(intent: .init(id: "003", imageName: "leaf.fill")) } } } //Button View private struct MyWatchWidgetEntryButton: View { @Environment(\.showsWidgetContainerBackground) var showsWidgetContainerBackground let intent: MyAppIntent var body: some View { Button(intent: intent) { ZStack { if showsWidgetContainerBackground { Color.black } else { AccessoryWidgetBackground() } VStack { Image(systemName: intent.imageName) .font(.headline) Text(intent.id) .font(.system(size: 10, weight: .bold)) } } } .buttonStyle(.plain) .widgetURL(URL(string: "widget://" + intent.id)) } } Does anyone know how to do this? Thank you.

No matter what I do, tabBar is not hidden if I navigate into nested view hierarchy through NavigationLink. Please help.

Hey, i have an app that uses some calculations to replicate a transparent background in widgets, however given that in ios 18 we can now change the icons size to large, I wonder if there is a way to know what the user has currently selected and react to it? The workaround I have is that user needs to select a new config to switch the widget to large so re-calculations are done, but it would be nice if we there was a way for us to catch the new size.

Yet another bug, I suppose, on iOS 18. This time it relates to the SwiftUI framework, and to be precise, it's about the theme change functionality. It no longer works properly on iOS 18, while it’s not an issue on iOS 17. Demo app available at: https://github.com/m4rqs/iOS18ThemeIssue Steps to reproduce: Assume the system is set to use the light theme. Go to the Settings tab. Switch the colour scheme to Dark. Switch the colour scheme to System (this no longer works). Switch the colour scheme to Light (the tab bar is not updated if the content page is long enough and go beyond current view). Switch between tabs (tab bar icons are greyed) enum Theme: Int { case system case light case dark } struct SettingsView: View { @State private var theme: Theme = .system @State private var colorScheme: ColorScheme? = nil var body: some View { Form { Section(header: Text("General")) { Picker("Colour Scheme", selection: $theme) { Text("System").tag(Theme.system) Text("Light").tag(Theme.light) Text("Dark").tag(Theme.dark) } .preferredColorScheme(colorScheme) .onChange(of: theme) { switch theme { case .light: colorScheme = .light case .dark: colorScheme = .dark default: colorScheme = nil } } } } } }

I just finished updating my app to support the new screen sizes for the iPhone 16 series devices (iPhone16 Pro and iPhone 16 Pro Max). In testing the changes, I've come across what I hope is simply a bug in the Xcode 16 simulators. I don't have any actual devices (yet) that I can use to test. In landscape mode, my app presents a "tab" on the right side of the screen that can be tapped to bring out another view. Activating the tab is based on capturing the screen coordinates from a "tap". In Xcode 16, using the iPhone16 simulators on IOS 18, the area of the tab does not recognize that a tap has occurred. After hours of banging my head against my laptop, it dawned on me that the area of the screen that hosts the "tab" is in exactly the same location as "unavailable area" that represents the camera on the simulator. I have arrived at the assumption that the issue is that the simulator is treating the same space at the bottom of the device as it treats that reserved area at the top of the screen. Has anyone else experienced this? Is this a bug in the simulator or is this expected behavior on the iPhone 16 series devices?

I have issue with unwanted changing offset in collection view to top or to near top. It is happening in collection view with vertical scroll when estimatedItemSize is not set to zero (main factor). If estimatedItemSize is zero it is always fine. It is SDK that provides items that should be loaded in few cells, items have dynamic height which is received from server and can be updated several times. Scenario when it happens (when was noticed) is 2 sections, in section 0 item is at index 4 of 14, section 1 is with only one cell with dynamic height item. If specific item is at index 0 in section 0 or have 1 cell per section (tried 15 sections and set items in sections 5 and 15) all is good regardless of estimatedItemSize. When new height is received if I call invalidateLayout or reloadItemAtIndexPaths it will “jump”. That same height is set in sizeForItemAtIndexPath. In some combinations it happens and in some not and that is the most annoying part. I tried setting estimated height to received height and it didn’t help (other cell may be smaller or larger). Also if I put items in one section at indexes 4 and 14 it “jumps”. I managed to make it work by setting at specific moment estimatedItemSize to zero then put back to one that SDK user set and didn’t see any issues but I was wondering if there is any other solution for this and did anyone had issue like this. It would be nice to have solution to keep one estimatedItemSize if it is not the default one (zero).

iPadOS18 Tab Bar has been moved to top of screen. Everything looks ok when translucent=true. But there is an unwanted white space at bottom of screen when setting translucent=false. Is it iPadOS bug? See white area at bottom of attached screenshot.

macOS 14.6.1, SwiftUI, Xcode 16.0 (developing for macOS) I have a TextField with a custom formatter and a custom binding (one created using Binding(get:set:). My understanding is that the TextField should only call on the formatter and update the binding when I commit the TextField by moving focus away from it, hitting return, etc. Unfortunately, that is not the case. I was able to verify that the formatter is being called (via NSLog added to the formatter code) every time I add a character to the field. Not only is this a waste of CPU resources, but in combination with the custom binding, it is causing a data entry issue for my application. I am writing a simple emulator for a computer system I concocted, and the formatter is formatting a memory location into its assembly language - the formatter's string method disassembles the instruction from the underlying memory value and the getObjectValue method assembles an input string back into the memory location. One example of an instruction would be the "set" instruction. All of these are valid forms for input to the assembler: set set 0 set x The "set" by itself is equivalent to "set 0", so what is happening is that I type "set" and the TextField immediately gets a valid response back from the formatter and updates the binding with the value of the "set 0" instruction. The custom binding updates the value in memory, which triggers the "get" method of the binding and updates the TextField with the disassembled value which helpfully adds the "0" to the field, setting it to "set 0" before I have a chance to type the "x". I need to manually delete the "0" from the line which I never typed there in the first place in order to finish typing the line of input. I either need a way to cause the TextField to behave the way it is supposed to and only update the binding when the value is committed, or a way to prevent the binding's get method from being retriggered by its own set method. Any ideas how to go about fixing this? Note that I set up a temporary TextField which was bound using a simple $binding to a state variable, and while the variable is updated whenever valid input is presented, it does not trigger the TextField to reread and thus I do not have the same input issue with that TextField. There is a reason why I need to use the custom get/set in context, however, so this is still an issue for me.

Is there an API to register .ttf files that have variables fonts (ie one or more axes specified). CTFontManagerRegisterGraphicsFont() makes only the default variation available. The same file when specified in UIAppFonts of Info.plist makes all the variants available (confirmed by querying UIFont.fontName(forFamilyName:)) This is mostly required for registering fonts that are bundled as part of a Swift package.

I'm working on an app that will be used in laboratory conditions. The application must be as dim as possible. For all the text and buttons, I'm thus using Color(red: 0.1, green: 0.0, blue: 0.0). However, a bright Home Bar / Swipe up bar emerges whenever the user interacts with the screen. This characteristic renders the iPhone useless in those conditions. In the Android version, such problems do not exist. And, I have yet to find a solution here in this forum or elsewhere. I must force the Home Bar to be invisible or Color(red: 0.1, green: 0.0, blue: 0.0). How to do that? Can anybody help?

View using NavigationSplitView(sidebar:content:detail:) in SwiftUI on tvOS does not show the View in the content closure and does not allow proper navigation. This occurs when NavigationSplitViewStyle is .automatic or .prominentDetail. It also occurs when not specified. You can avoid using this sidebar style by adding .navigationSplitViewStyle(.balanced). However, I would like to build an app employing this View. I would be glad to know what you have noticed and if you have any advice. Code Here is the code to reproduce it Just replace it with this and somehow the phenomenon occurs. import SwiftUI struct ContentView: View { @State var selected:Int? @State var selected2:Int? var body: some View { NavigationSplitView { List(selection: $selected){ NavigationLink(value: 1){ Label("1", systemImage: "1.circle") } NavigationLink(value: 2){ Label("2", systemImage: "2.circle") } NavigationLink(value: 3){ Label("3", systemImage: "3.circle") } } .navigationTitle("Sidebar") } content: { if let selected = selected { List(selection: $selected2){ NavigationLink(value: 1){ Label("1", systemImage: "1.square") } NavigationLink(value: 2){ Label("2", systemImage: "2.square") } NavigationLink(value: 3){ Label("3", systemImage: "3.square") } } .navigationTitle("Content \(selected)") } else { Text("No Selected") } } detail: { Group { if let selected2 = selected2 { Text(String(selected2)) }else{ Text("No Selected") } } .navigationTitle("Detail") .frame(maxWidth: .infinity, maxHeight: .infinity) } .navigationSplitViewStyle(.prominentDetail) } } Environment tvOS 18 Simulator (22J356) macOS 15.1 beta (24B5055e) Xcode 16.0 (16A242d) How to Reproduce Open the attached project with Xcode. Build the project on Apple TV with Xcode. press any button on the sidebar Confirm that the View in the content closure is not displayed. Actual Behavior The View in the content closure is not displayed, and the View in the detail closure is displayed. (4/4) Correct Behavior The View in the content closure is displayed, and when the button of the View is pressed, the View in the detail closure is displayed.

There is a significant rendering issue in PencilKit when using an iPad set to "More Space" display mode, combined with an Apple Pencil that supports hover functionality (e.g., Apple Pencil 2). This problem affects all applications that use PencilKit, including Apple's own Notes and Quick Note. The issue results in flickering black borders and subtle jittering while drawing, which is especially noticeable during tasks requiring precise handwriting, such as writing mathematical expressions. Due to the short strokes and frequent lifts and drops of the pencil, the jitter is much more pronounced, leading to visual discomfort and even dizziness after extended use. Steps to Reproduce: Open Settings on your iPad. Navigate to Display & Brightness > Display Zoom > More Space. Switch to the More Space display mode. Open the Notes app or trigger Quick Note from any application by swiping from the bottom-right corner. Start drawing or writing using the Apple Pencil (with hover functionality) in the writing area. Observe the display anomalies as you hover and write: Flickering black borders appear intermittently around the writing area. The strokes show subtle jittering whenever you lift and lower the pencil. This is particularly disruptive when writing short, precise strokes, such as those in mathematical expressions, where the frequent up-and-down motion makes the jitter more apparent. Expected Results: Smooth and stable drawing experience with no visual artifacts or jittering during interactions with the Apple Pencil, regardless of the display zoom settings. Actual Results: Flickering black borders intermittently appear during drawing. Jittering of strokes is noticeable, particularly when lifting and lowering the Apple Pencil for short strokes. This disrupts precise writing tasks, especially in cases like mathematical notation, where frequent pen lifts and short strokes make the jitter much more apparent. This can lead to discomfort (e.g., dizziness) after extended use. System-Wide Impact: This issue affects all apps that utilize PencilKit, including third-party apps such as Doodle Draw (link). Since PencilKit is a core framework, the rendering bug significantly degrades the user experience across multiple productivity and note-taking applications. Similar Reports: There are numerous discussions about this issue online, indicating that many users are experiencing the same problem. Reddit Discussion: https://www.reddit.com/r/ipad/comments/1f042ol/comment/ljvilv6/ Apple Support Thread Additionally, a feedback report (ID: FB15166022) related to this issue with Notes has been previously filed, but the bug remains unresolved. This bug severely impacts the usability of PencilKit-enabled apps, especially during tasks that involve frequent, precise pencil strokes, such as writing mathematical expressions. We kindly request the development team investigate this issue promptly to ensure a smooth, stable experience with the iPad's "More Space" display mode and Apple Pencil hover interaction.

I try to create a sheet that shows a textfield and the textfield should gain the focus immediately after the sheet is presented. This use case is explained in Session 10162 at 11:21 and at 13:31 my desired behavior is shown. I could not get this to work in my own code and downloaded the sample code from here: https://developer.apple.com/documentation/swiftui/focus-cookbook-sample Then I opened the sample code and run it in the simulator. It does not focus when the sheet appears in a iOS 18 simulator using Xcode 16 installed via the AppStore. It does gain focus if I use the "add" Button. No changes made on the sample code. Just adjusted the Team setting to get a clean build. The behavior I get locally under iOS 18 is not what is shown in the session and I can't understand why. I tried the following Simulators (and platforms) iPhone 16, iPad Pro (M4, 11inch) and my Mac. On none of those the last item got focus just by presenting the sheet. Is it not possible to test this in a simulator? Could I have a configuration error? Given all the information I found yet, this seems like a Bug. It would be very helpful if someone could replicate my problem. Thank you for your help. Programm Versions: Xcode: Version 16.0 (16A242d) MacOS: 15.0 (24A335)