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.

All subtopics
Posts under UI Frameworks topic

Post

Replies

Boosts

Views

Activity

UINavigationController, Nav Bar does not extend to top on iPhone Duo
When using a background color for a UINavigation controller it seems the header does not extend to the top of the device for iPhone Duo when its closed in portrait mode. See screenshot. It should fill the entire 'status' bar up to top of device, Landscape correctly works, its just Portrait. Any thoughts on if this is 'expected' behavior? Seems odd to not just extend the navbar alll the way to the top.
Topic: UI Frameworks SubTopic: UIKit Tags:
6
2
936
6d
iOS 26: FloatingBarContainerView overlapping the whole custom ViewController
Hi everyone: I'm experiencing an issue in iOS 26. I've implemented a custom ViewController. It's super simple to edit images with flip, crop, zoom in, and zoom out. My question is that it seems very strange to me. It works without problems in iOS 17.5 and iOS 18. However, when I try to run it with iOS 26, the entire ViewController seems disabled; it doesn't recognize touches or anything. When I checked the UI hierarchy, I saw a strange FloatingBarContainerView overlaying the entire ViewController. I searched the documentation for information about this view, but I couldn't find anything. Any help on how to hide or remove this view in iOS 26? This hasn't been implemented anywhere.
3
0
1.1k
1w
Finger input interrupted while drawing with Apple Pencil + palm resting on display
I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.
3
0
1.1k
1w
Keyboard Toolbar Padding iOS26
When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?
Topic: UI Frameworks SubTopic: SwiftUI
15
9
2.4k
1w
iPhone Duo - Buggy margin shift while dragging down a modal view controller
Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.
2
0
743
1w
Standard toolbar hidden below tab bar in iOS 27.x when running on iPhones
There have been report several issues with this configuration in very old iOS versions. From iOS 27 it seems to be a problem again, or? Assume you have a tab bar controller that contains one ore move navigation controllers. These navigation controllers have one view controller that adds buttons to the navigaton controller's toolbar. Running the app on an iPad, everything works well. Running it on an iPhone, the toolbar is hidden below the tab bar. Is there any workaround to fix this? PS: A simple scene file is attached that shows the issue.
Topic: UI Frameworks SubTopic: UIKit
0
0
43
1w
iOS 27: SwiftUI TextField text invisible while typing when the app runs in Arabic (FB25410049)
Since iOS 27, if an app runs in Arabic (or, presumably, any right-to-left language), typing digits or Latin letters into a SwiftUI TextField makes the field look empty. The binding updates and the caret shows, but the text isn't drawn until editing ends. What I measured: The text's layout fragment is placed at about x = −39,655 pt in a 370 pt wide field, so it's drawn far outside the field. A plain TextField and one with .environment(\.layoutDirection, .leftToRight) (phone and card numbers) are both affected. A UIKit UITextField on the same screen isn't affected. The same build on iOS 18.0 works, and iOS 27 in English works. Minimal repro: one SwiftUI file with four fields. Run it with App Language set to Arabic, tap the first field and type 523. Launch with -autoProbe to have it type into each field and print where the text was laid out. PROBE iOS 27.0, language ar, layout RTL PROBE field 1 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI TextField PROBE field 2 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI, LTR pinned PROBE field 3 text="523" fieldWidth=370 fragmentX=[314] visible=true // UIKit UITextFieldWorkaround that works for us, installed once at launch: import UIKit enum TextFieldDirection { static func install() { for name in [UITextField.textDidBeginEditingNotification, UITextField.textDidChangeNotification] { NotificationCenter.default.addObserver(forName: name, object: nil, queue: .main) { note in guard let field = note.object as? UITextField else { return } MainActor.assumeIsolated { settle(field) } // SwiftUI rebuilds the paragraph style right after; settle again. DispatchQueue.main.async { MainActor.assumeIsolated { settle(field) } } } } } @MainActor static func settle(_ field: UITextField) { let direction: NSWritingDirection = field.effectiveUserInterfaceLayoutDirection == .rightToLeft ? .rightToLeft : .leftToRight if let whole = field.textRange(from: field.beginningOfDocument, to: field.endOfDocument) { field.setBaseWritingDirection(direction, for: whole) } func directed(_ attributes: [NSAttributedString.Key: Any]) -> [NSAttributedString.Key: Any] { var attributes = attributes let style = (attributes[.paragraphStyle] as? NSParagraphStyle)?.mutableCopy() as? NSMutableParagraphStyle ?? NSMutableParagraphStyle() style.baseWritingDirection = direction attributes[.paragraphStyle] = style return attributes } if let typing = field.typingAttributes { field.typingAttributes = directed(typing) } field.defaultTextAttributes = directed(field.defaultTextAttributes) field.setNeedsLayout() field.layoutIfNeeded() } }Don't pin textAlignment instead. SwiftUI puts .natural back on every keystroke and the caret jumps from side to side. If you see this too, please file a duplicate referencing FB25410049. Duplicates help Apple prioritise it.
1
0
88
1w
How do deal with NavigationSplitView not saving selection on iPhone
I have a detail view that has a @Binding var Thing, which is passed to it from the parent. It has TextFields that need to use that bound object's fields. // Using this to pass the selection around @Observable class AppSelection { var selectedThings:Set<Thing> = Set(); } struct ContentView: View { @State private var selectionStore = AppSelection(); var body: some View { NavigationSplitView { ... } content: { ...list that sets the selectionStore.selectedThings... } detail: { if !selectionStore.selectedThings.isEmpty { DetailView(thing:Binding( get: { selectionStore.selectedThings.first! }, // Crashes here set: { selectionStore.selectedThings = [$0] } )) .frame(maxHeight:.infinity, alignment:.top) } else { Text("Select a thing."); } } } } struct DetailView:View { @Binding var thing:Thing; var body:some View { TextField("Blah", $thing.name); TextField("Blerg", $thing.stuff); } }A crash happens when I navigate back from the DetailView in the line commented as such. I assume the NavigationSplitView is resetting the selection back to an empty state. Why the Binding given to the DetailView is even trying to get its value at that point is beyond me (so much weirdness in SwiftUI). I've taken so many different stabs at trying to make things work differently, but I just don't understand enough about SwiftUI. Like can I make the DetailView take an optional binding? If the Thing is nil, then all the TextFields complain that they require a non-optional binding. I don't even want to show the Detail view if nothing is selected (hence the "Select a thing.").
1
0
871
1w
iPhone Duo: Sidebar toolbar item becomes unreachable after rotating to portrait
On the unfolded iPhone Duo simulator, I can reach Settings through the toolbar overflow in landscape. After I rotate to portrait and open the floating sidebar, Settings disappears from both the toolbar and the available menus. I’ve seen this on iOS 27.1 and 27.2. I also reproduced it in a standalone UIKit app on iOS 27.2 and attached the Xcode project to Feedback Assistant report FB25402191. The standalone sample uses a two-column UISplitViewController with a UINavigationController in each column. The primary view controller assigns five actions to toolbarItems once in viewDidLoad, with Settings last. All five use the default visibility priority. The app makes no changes to its toolbar items during rotation. Steps to reproduce Fully unfold the simulated device and rotate to landscape with the detail pane’s vertical toolbar on the right. Widen the sidebar until all five buttons, including the Settings gear, appear in its bottom toolbar. Narrow the sidebar to about 280 points. Four buttons remain along the bottom. Open the ellipsis menu in the detail pane and tap Settings to confirm the action works. Keeping the device unfolded, rotate 90 degrees left into portrait. Tap the sidebar button to reveal the floating sidebar. I expected Settings to remain reachable through an overflow menu if the gear couldn’t fit. Instead, the floating sidebar shows four buttons, and neither pane offers an overflow menu containing Settings. The Settings item is still present in the primary view controller’s toolbarItems array. Rotating back to landscape makes it reachable again. Has anyone reproduced this on a physical iPhone Duo? Is there a supported way to keep an overflowed primary toolbar action accessible when the sidebar changes from a side-by-side column to a floating panel?
Topic: UI Frameworks SubTopic: UIKit
1
0
74
1w
iPhone Duo black bars in landscape on iOS 27.1
I am implementing support for iPhone Duo, and have seen this in many places: Apps built with the iOS 27.1 SDK or later are optimized for iPhone Duo. Apps will extend to use the full display, with toolbars and tab bars appearing vertically below the status bar. (from https://developer.apple.com/iphone-duo/prepare/) But when I build my application in Xcode 27.1, in both the simulator, and on the Duo hardware, my application is not extending to the full-width of the screen when built for iOS 27.1. There are black bars on both the left and right. When I debug the view hierarchy, I do not see the black bars, which indicates to me this is happening at the OS level, not as a result of my constraints. Note that there are no black bars in portrait mode, or on the front screen. In my project settings, only the iPhone Orientation "Portrait" is checked, but I don't want to check Landscape orientations there, because the application does not look good in landscape on a standard iPhone aspect ratio. Are those checkboxes required to remove the black bars? (Checking them does appear to do so, but again, this is quite problematic for the current design of the application.) Thanks in advance for any insights or help you can provide!
Topic: UI Frameworks SubTopic: UIKit
3
0
88
1w
iPadOS 27.0.1: iPhone-only apps crash when displaying the Japanese Kana keyboard on iPad
We are seeing a crash when attempting to display the Japanese Kana keyboard (日本語-かな) in our iPhone-only app running on an iPad with iPadOS 27.0.1. The keyboard displays successfully in our app on iPadOS 26 and iPadOS 27.0. We also reproduced a similar crash in other iPhone-only apps downloaded from the App Store on the affected iPad. We have not yet confirmed whether those apps crash with the same exception. Our app logs the following exception: *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM insertObject:atIndex:]: index 15 beyond bounds [0 .. 2]' *** First throw call stack: ( 0x19fab7190 0x19f834380 0x19fa45734 0x1aee9f5bc 0x1aee3dc14 0x1aee3cb30 0x1aee3c4d4 0x1aee3ab0c 0x1a433798c 0x1a44a4120 0x1a449bd5c 0x1a42148c8 0x1a42143fc 0x1a4239d7c 0x1a421203c 0x1a3fc1338 0x1a3d12e0c 0x1a3d11ed0 0x1a52784ec 0x1a3d11abc 0x1a4115238 0x1a3d436d4 0x1a3d43a80 0x1a44eea14 0x1aabb8ef8 0x1a517161c 0x1a5152450 0x1a5153388 0x1a41f20c4 0x1a49e3fec 0x1a426598c 0x1a42657fc 0x1a4265580 0x1a3d62b30 0x1a3d62984 0x1a95c4dac 0x1a994fb68 0x1a95c5514 0x1a95c287c 0x1a95d2608 0x1a3d6841c 0x1a3d6a298 0x1a4263874 0x1a3d60bdc 0x1a3ce8d78 0x1a3ce7b88 0x1a3ce7928 0x2d1482bc0 0x19fa78c20 0x19fa78b94 0x19fa5a268 0x19fa59384 0x19fa5a7f4 0x249e6ff24 0x1a3d381cc 0x1a9d27404 0x1a9d20b50 0x1a9d20a10 0x109042dc4 0x109042e04 0x19f8ab5b8 ) libc++abi: terminating due to uncaught exception of type NSException Steps to reproduce: Enable the Japanese – Kana keyboard in the iPad’s keyboard settings. Open an affected iPhone-only app on an iPad running iPadOS 27.0.1. Tap a text input field and attempt to display the Japanese Kana keyboard. The app crashes. We suspect this may be a regression involving iPhone compatibility mode on iPad and the Japanese Kana keyboard, but we have not yet identified the failing component in a symbolicated stack trace. We have submitted a report through Feedback Assistant: FB24985530. Has anyone else encountered this behavior? Are there any known workarounds we can apply in the app while this is being investigated?
Topic: UI Frameworks SubTopic: UIKit Tags:
7
7
1.9k
1w
No access to dictation from third-party keyboards on iPhone Duo
On a physical iPhone Duo running iOS 27.1 and later, the system dictation button is placed inside the system keyboard, next to the space bar. Because the button belongs to the system keyboard layout, it isn't available while a third-party keyboard is active. On other iPhone models, the dictation button appears separately from the keyboard, so it stays available with third-party keyboards. On iPhone Duo, our users have no way to start dictation without switching back to the system keyboard. The iPhone Duo Simulator shows the button at the far right, which doesn't match the physical device, so this can't be evaluated accurately in the Simulator. As far as I can tell, there is no public API that lets a keyboard extension start system dictation, so we can't work around this from the extension. My questions: Is this placement intended on iPhone Duo? Is there a supported way for a keyboard extension to offer dictation on this device? If not, are there plans for a separate system dictation button, as on other iPhone models, or a public API for keyboard extensions? I've filed this as FB[number]. If you develop a keyboard extension and see the same issue, please file your own report and reference this number.
1
0
99
1w
PDFView context menu: "Actual Size"
In a PDFView, the OS provides a context menu which contains (among other things) "Actual Size" zoom. This command wrongly displays the page at 1 point = 1 pixel. Traditionally on MacOS, "Actual Size" displays the page at 1 inch on page = 1 inch on screen, e.g. for a Letter page, 8.5 x 11 inches on the screen. (So the API needs to determine the display's pixel density to calculate the zoom size.) In Preview 11.0 on Os 27.2, "Actual Size" in the PDFView context menu and in the View menu both zoom to 1 point = 1 pixel. In Preview on Sequoia, Actual Size in the View menu displays at 1 inch = 1 inch, but the context menu gives 1 pt = 1px. (The latter presumably relying on the built-in context menu from PDFView.) Note that in Pages.app, Actual View gives the expected 1 inch = 1 inch on screen.
1
0
97
1w
NavigationSplitView, endless loop detail<->content
Hi, I already had a problem with the NavigationSplitView before, and I'm still working on it. The NavigationSplitView issue on the phone occurs when trying to navigate back from the detail view to the content view; the app automatically navigates straight back to the detail view. I reproduced the issue in a small program and identified the critical section. However, I do not know why the problem is occurring. I did the same thing again, but this time with @Query, and there was no problem. The categories, recipes and single recipe, all loaded by @Query and no side effects. Requirements for the content: A state variable used in the view, e.g., isLoading A task that loads the data from a ModelActor in a ViewModel, setting isLoading to true beforehand and back to false upon completion Subsequently, it is only possible to exit the detail view after many attempts, because the app immediately navigates back to the detail view automatically upon trying to leave it. One issue is changing the isLoading status variable from within the task. That in itself isn't the problem; the issue only arises when reading data via a ModelActor. If the status variable is changed and, for example, the list is modified manually, there is no problem. It only occurs when a ModelActor is used. I based it on the NavigationCookbook: This is the view I use for the content section (list): @State private var vm: RecipeListViewModel = .init() @State var isLoading: Bool = false if isLoading { ProgressView("Loading...") } else { List(selection: $selectedRecipe) { ForEach(vm.recipes) { recipe in NavigationLink(recipe.name, value: recipe) } } } .task { // bug, when used in UI, because of ModelActor isLoading = true await vm.list(context, categoryName: selectedCategory.name) isLoading = false } .task { // works, because manually modifying the list isLoading = true await vm.addRecipe(context, categoryName: selectedCategory.name) isLoading = false } inside ViewModel // bug func list(_ modelContext: ModelContext, categoryName: String) async { recipes.removeAll() let dh: RecipeDataHandler = .init(modelContainer: modelContext.container) let values = await dh.listByName(categoryName: categoryName) for v in values { recipes.append(.init(recipeId: v.recipeId, name: v.name)) } } // works func addRecipe(_ modelContext: ModelContext, categoryName: String) async { isLoading = true defer { isLoading = false } recipes.removeAll() recipes.append(.init(recipeId: "a", name: "Pambazo")) } ModelActor @ModelActor actor RecipeDataHandler { func listByName(categoryName: String) async -> [RecipeData] { var list: [RecipeData] = [] do { let fd = FetchDescriptor<Recipe>(predicate: #Predicate { $0.category.name == categoryName }, sortBy: [SortDescriptor(\Recipe.name)]) let data = try modelContext.fetch(fd) for item in data { let rec: RecipeData = await .init(recipeId: item.recipeId, name: item.name) list.append(rec) } } catch { print("error: \(error.localizedDescription)") } return list } } Recipe is a @Model and RecipeData just a struct. In principle, everything should run on the MainActor, but the inclusion of the ModelActor still leads to this strange behavior. Any idea what the problem might be? Christian
3
0
361
1w
Fundamental error in PDFOutline created syntax
PDFKit's PDFOutline creates fundamentally flawed PDF syntax when it creates outlines ("Bookmarks") in a PDF document. A PDF document is created with three outlines: "Page 1", "Page 2" and "Page 3". Each is a child of the former, so "Page 3" is a child of "Page 2", and "Page 2" is a child of "Page 1". PDFKit produces flawed PDF syntax, with duplicate entries for each bookmark, missing sibling links, and a convoluted Parent > Child relationship. 3 0 obj << /Type /Pages /Parent 45 0 R /Count 8 /Kids [ 2 0 R 6 0 R 9 0 R 12 0 R 15 0 R 18 0 R 21 0 R 24 0 R ] >> endobj 28 0 obj << /Type /Pages /Parent 45 0 R /Count 3 /Kids [ 27 0 R 31 0 R 34 0 R ] >> endobj 45 0 obj << /Type /Pages /MediaBox [0 0 612 792] /Count 11 /Kids [ 3 0 R 28 0 R ] >> endobj 46 0 obj << /Type /Catalog /Outlines 1 0 R /Pages 45 0 R >> endobj 1 0 obj << /First 47 0 R /Last 48 0 R >> endobj 48 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 51 0 obj << >> endobj 50 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 53 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 52 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 49 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 47 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj(The Parent of all the outline objects is given as object 51, which is blank. The First/Last objects don't link correctly to the expected hierarchy, etc, etc.) Acrobat preflight will flag this as a syntax error, though the bookmarks do largely function in most viewers. Preview doesn't show the top-level outline, though that might relate to FB4013726, filed in 2018. I have shown the created syntax to ChatGPT, which also confirmed that the syntax does not conform to the expected PDF spec: This isn’t simply a matter of PDFKit choosing an unnecessarily elaborate but valid representation. There are genuine structural problems: The top-level Page 1 object’s /Parent does not point to the /Outlines dictionary. The child objects’ /Parent does not point to their actual containing outline. There are duplicate outline objects for Page 1, Page 2 and Page 3. The required sibling Prev/Next chains are absent. The /First//Last relationships don’t correspond cleanly to the claimed hierarchy. The errors are entirely reproducible in any PDFOutlines created by PDFKit. I have filed this as FB25328043. ... and in 2021 as FB8960602. ... and in 2019 as FB5313583.
Topic: UI Frameworks SubTopic: AppKit Tags:
3
1
607
1w
Clipped render of dragged NSTableView row on macOS 27.
On macOS 27, dragged rows on my app's table views are excessively clipped (see image). I don't override methods like `tableView:draggingSession:willBeginAtPoint:forRowIndexes:` so I don’t supply my own drag images, and I don’t use NSTableView suclasses. I tried on a toy project containg with a single table view in a window, and it did not reproduce this behavior. I wonder if my issue if it’s due to my app’s table views being embedded in split views or something. Anyway, how can I fix that?
Topic: UI Frameworks SubTopic: AppKit
1
0
199
1w
UINavigationController, Nav Bar does not extend to top on iPhone Duo
When using a background color for a UINavigation controller it seems the header does not extend to the top of the device for iPhone Duo when its closed in portrait mode. See screenshot. It should fill the entire 'status' bar up to top of device, Landscape correctly works, its just Portrait. Any thoughts on if this is 'expected' behavior? Seems odd to not just extend the navbar alll the way to the top.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
6
Boosts
2
Views
936
Activity
6d
iOS 26: FloatingBarContainerView overlapping the whole custom ViewController
Hi everyone: I'm experiencing an issue in iOS 26. I've implemented a custom ViewController. It's super simple to edit images with flip, crop, zoom in, and zoom out. My question is that it seems very strange to me. It works without problems in iOS 17.5 and iOS 18. However, when I try to run it with iOS 26, the entire ViewController seems disabled; it doesn't recognize touches or anything. When I checked the UI hierarchy, I saw a strange FloatingBarContainerView overlaying the entire ViewController. I searched the documentation for information about this view, but I couldn't find anything. Any help on how to hide or remove this view in iOS 26? This hasn't been implemented anywhere.
Replies
3
Boosts
0
Views
1.1k
Activity
1w
Finger input interrupted while drawing with Apple Pencil + palm resting on display
I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.
Replies
3
Boosts
0
Views
1.1k
Activity
1w
Keyboard Toolbar Padding iOS26
When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
15
Boosts
9
Views
2.4k
Activity
1w
iPhone Duo - Buggy margin shift while dragging down a modal view controller
Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.
Replies
2
Boosts
0
Views
743
Activity
1w
Standard toolbar hidden below tab bar in iOS 27.x when running on iPhones
There have been report several issues with this configuration in very old iOS versions. From iOS 27 it seems to be a problem again, or? Assume you have a tab bar controller that contains one ore move navigation controllers. These navigation controllers have one view controller that adds buttons to the navigaton controller's toolbar. Running the app on an iPad, everything works well. Running it on an iPhone, the toolbar is hidden below the tab bar. Is there any workaround to fix this? PS: A simple scene file is attached that shows the issue.
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
0
Views
43
Activity
1w
iOS 27: SwiftUI TextField text invisible while typing when the app runs in Arabic (FB25410049)
Since iOS 27, if an app runs in Arabic (or, presumably, any right-to-left language), typing digits or Latin letters into a SwiftUI TextField makes the field look empty. The binding updates and the caret shows, but the text isn't drawn until editing ends. What I measured: The text's layout fragment is placed at about x = −39,655 pt in a 370 pt wide field, so it's drawn far outside the field. A plain TextField and one with .environment(\.layoutDirection, .leftToRight) (phone and card numbers) are both affected. A UIKit UITextField on the same screen isn't affected. The same build on iOS 18.0 works, and iOS 27 in English works. Minimal repro: one SwiftUI file with four fields. Run it with App Language set to Arabic, tap the first field and type 523. Launch with -autoProbe to have it type into each field and print where the text was laid out. PROBE iOS 27.0, language ar, layout RTL PROBE field 1 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI TextField PROBE field 2 text="523" fieldWidth=370 fragmentX=[-39655] visible=false // SwiftUI, LTR pinned PROBE field 3 text="523" fieldWidth=370 fragmentX=[314] visible=true // UIKit UITextFieldWorkaround that works for us, installed once at launch: import UIKit enum TextFieldDirection { static func install() { for name in [UITextField.textDidBeginEditingNotification, UITextField.textDidChangeNotification] { NotificationCenter.default.addObserver(forName: name, object: nil, queue: .main) { note in guard let field = note.object as? UITextField else { return } MainActor.assumeIsolated { settle(field) } // SwiftUI rebuilds the paragraph style right after; settle again. DispatchQueue.main.async { MainActor.assumeIsolated { settle(field) } } } } } @MainActor static func settle(_ field: UITextField) { let direction: NSWritingDirection = field.effectiveUserInterfaceLayoutDirection == .rightToLeft ? .rightToLeft : .leftToRight if let whole = field.textRange(from: field.beginningOfDocument, to: field.endOfDocument) { field.setBaseWritingDirection(direction, for: whole) } func directed(_ attributes: [NSAttributedString.Key: Any]) -> [NSAttributedString.Key: Any] { var attributes = attributes let style = (attributes[.paragraphStyle] as? NSParagraphStyle)?.mutableCopy() as? NSMutableParagraphStyle ?? NSMutableParagraphStyle() style.baseWritingDirection = direction attributes[.paragraphStyle] = style return attributes } if let typing = field.typingAttributes { field.typingAttributes = directed(typing) } field.defaultTextAttributes = directed(field.defaultTextAttributes) field.setNeedsLayout() field.layoutIfNeeded() } }Don't pin textAlignment instead. SwiftUI puts .natural back on every keystroke and the caret jumps from side to side. If you see this too, please file a duplicate referencing FB25410049. Duplicates help Apple prioritise it.
Replies
1
Boosts
0
Views
88
Activity
1w
How do deal with NavigationSplitView not saving selection on iPhone
I have a detail view that has a @Binding var Thing, which is passed to it from the parent. It has TextFields that need to use that bound object's fields. // Using this to pass the selection around @Observable class AppSelection { var selectedThings:Set<Thing> = Set(); } struct ContentView: View { @State private var selectionStore = AppSelection(); var body: some View { NavigationSplitView { ... } content: { ...list that sets the selectionStore.selectedThings... } detail: { if !selectionStore.selectedThings.isEmpty { DetailView(thing:Binding( get: { selectionStore.selectedThings.first! }, // Crashes here set: { selectionStore.selectedThings = [$0] } )) .frame(maxHeight:.infinity, alignment:.top) } else { Text("Select a thing."); } } } } struct DetailView:View { @Binding var thing:Thing; var body:some View { TextField("Blah", $thing.name); TextField("Blerg", $thing.stuff); } }A crash happens when I navigate back from the DetailView in the line commented as such. I assume the NavigationSplitView is resetting the selection back to an empty state. Why the Binding given to the DetailView is even trying to get its value at that point is beyond me (so much weirdness in SwiftUI). I've taken so many different stabs at trying to make things work differently, but I just don't understand enough about SwiftUI. Like can I make the DetailView take an optional binding? If the Thing is nil, then all the TextFields complain that they require a non-optional binding. I don't even want to show the Detail view if nothing is selected (hence the "Select a thing.").
Replies
1
Boosts
0
Views
871
Activity
1w
iPhone Duo: Sidebar toolbar item becomes unreachable after rotating to portrait
On the unfolded iPhone Duo simulator, I can reach Settings through the toolbar overflow in landscape. After I rotate to portrait and open the floating sidebar, Settings disappears from both the toolbar and the available menus. I’ve seen this on iOS 27.1 and 27.2. I also reproduced it in a standalone UIKit app on iOS 27.2 and attached the Xcode project to Feedback Assistant report FB25402191. The standalone sample uses a two-column UISplitViewController with a UINavigationController in each column. The primary view controller assigns five actions to toolbarItems once in viewDidLoad, with Settings last. All five use the default visibility priority. The app makes no changes to its toolbar items during rotation. Steps to reproduce Fully unfold the simulated device and rotate to landscape with the detail pane’s vertical toolbar on the right. Widen the sidebar until all five buttons, including the Settings gear, appear in its bottom toolbar. Narrow the sidebar to about 280 points. Four buttons remain along the bottom. Open the ellipsis menu in the detail pane and tap Settings to confirm the action works. Keeping the device unfolded, rotate 90 degrees left into portrait. Tap the sidebar button to reveal the floating sidebar. I expected Settings to remain reachable through an overflow menu if the gear couldn’t fit. Instead, the floating sidebar shows four buttons, and neither pane offers an overflow menu containing Settings. The Settings item is still present in the primary view controller’s toolbarItems array. Rotating back to landscape makes it reachable again. Has anyone reproduced this on a physical iPhone Duo? Is there a supported way to keep an overflowed primary toolbar action accessible when the sidebar changes from a side-by-side column to a floating panel?
Topic: UI Frameworks SubTopic: UIKit
Replies
1
Boosts
0
Views
74
Activity
1w
iPhone Duo black bars in landscape on iOS 27.1
I am implementing support for iPhone Duo, and have seen this in many places: Apps built with the iOS 27.1 SDK or later are optimized for iPhone Duo. Apps will extend to use the full display, with toolbars and tab bars appearing vertically below the status bar. (from https://developer.apple.com/iphone-duo/prepare/) But when I build my application in Xcode 27.1, in both the simulator, and on the Duo hardware, my application is not extending to the full-width of the screen when built for iOS 27.1. There are black bars on both the left and right. When I debug the view hierarchy, I do not see the black bars, which indicates to me this is happening at the OS level, not as a result of my constraints. Note that there are no black bars in portrait mode, or on the front screen. In my project settings, only the iPhone Orientation "Portrait" is checked, but I don't want to check Landscape orientations there, because the application does not look good in landscape on a standard iPhone aspect ratio. Are those checkboxes required to remove the black bars? (Checking them does appear to do so, but again, this is quite problematic for the current design of the application.) Thanks in advance for any insights or help you can provide!
Topic: UI Frameworks SubTopic: UIKit
Replies
3
Boosts
0
Views
88
Activity
1w
iPadOS 27.0.1: iPhone-only apps crash when displaying the Japanese Kana keyboard on iPad
We are seeing a crash when attempting to display the Japanese Kana keyboard (日本語-かな) in our iPhone-only app running on an iPad with iPadOS 27.0.1. The keyboard displays successfully in our app on iPadOS 26 and iPadOS 27.0. We also reproduced a similar crash in other iPhone-only apps downloaded from the App Store on the affected iPad. We have not yet confirmed whether those apps crash with the same exception. Our app logs the following exception: *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM insertObject:atIndex:]: index 15 beyond bounds [0 .. 2]' *** First throw call stack: ( 0x19fab7190 0x19f834380 0x19fa45734 0x1aee9f5bc 0x1aee3dc14 0x1aee3cb30 0x1aee3c4d4 0x1aee3ab0c 0x1a433798c 0x1a44a4120 0x1a449bd5c 0x1a42148c8 0x1a42143fc 0x1a4239d7c 0x1a421203c 0x1a3fc1338 0x1a3d12e0c 0x1a3d11ed0 0x1a52784ec 0x1a3d11abc 0x1a4115238 0x1a3d436d4 0x1a3d43a80 0x1a44eea14 0x1aabb8ef8 0x1a517161c 0x1a5152450 0x1a5153388 0x1a41f20c4 0x1a49e3fec 0x1a426598c 0x1a42657fc 0x1a4265580 0x1a3d62b30 0x1a3d62984 0x1a95c4dac 0x1a994fb68 0x1a95c5514 0x1a95c287c 0x1a95d2608 0x1a3d6841c 0x1a3d6a298 0x1a4263874 0x1a3d60bdc 0x1a3ce8d78 0x1a3ce7b88 0x1a3ce7928 0x2d1482bc0 0x19fa78c20 0x19fa78b94 0x19fa5a268 0x19fa59384 0x19fa5a7f4 0x249e6ff24 0x1a3d381cc 0x1a9d27404 0x1a9d20b50 0x1a9d20a10 0x109042dc4 0x109042e04 0x19f8ab5b8 ) libc++abi: terminating due to uncaught exception of type NSException Steps to reproduce: Enable the Japanese – Kana keyboard in the iPad’s keyboard settings. Open an affected iPhone-only app on an iPad running iPadOS 27.0.1. Tap a text input field and attempt to display the Japanese Kana keyboard. The app crashes. We suspect this may be a regression involving iPhone compatibility mode on iPad and the Japanese Kana keyboard, but we have not yet identified the failing component in a symbolicated stack trace. We have submitted a report through Feedback Assistant: FB24985530. Has anyone else encountered this behavior? Are there any known workarounds we can apply in the app while this is being investigated?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
7
Boosts
7
Views
1.9k
Activity
1w
No access to dictation from third-party keyboards on iPhone Duo
On a physical iPhone Duo running iOS 27.1 and later, the system dictation button is placed inside the system keyboard, next to the space bar. Because the button belongs to the system keyboard layout, it isn't available while a third-party keyboard is active. On other iPhone models, the dictation button appears separately from the keyboard, so it stays available with third-party keyboards. On iPhone Duo, our users have no way to start dictation without switching back to the system keyboard. The iPhone Duo Simulator shows the button at the far right, which doesn't match the physical device, so this can't be evaluated accurately in the Simulator. As far as I can tell, there is no public API that lets a keyboard extension start system dictation, so we can't work around this from the extension. My questions: Is this placement intended on iPhone Duo? Is there a supported way for a keyboard extension to offer dictation on this device? If not, are there plans for a separate system dictation button, as on other iPhone models, or a public API for keyboard extensions? I've filed this as FB[number]. If you develop a keyboard extension and see the same issue, please file your own report and reference this number.
Replies
1
Boosts
0
Views
99
Activity
1w
PDFView context menu: "Actual Size"
In a PDFView, the OS provides a context menu which contains (among other things) "Actual Size" zoom. This command wrongly displays the page at 1 point = 1 pixel. Traditionally on MacOS, "Actual Size" displays the page at 1 inch on page = 1 inch on screen, e.g. for a Letter page, 8.5 x 11 inches on the screen. (So the API needs to determine the display's pixel density to calculate the zoom size.) In Preview 11.0 on Os 27.2, "Actual Size" in the PDFView context menu and in the View menu both zoom to 1 point = 1 pixel. In Preview on Sequoia, Actual Size in the View menu displays at 1 inch = 1 inch, but the context menu gives 1 pt = 1px. (The latter presumably relying on the built-in context menu from PDFView.) Note that in Pages.app, Actual View gives the expected 1 inch = 1 inch on screen.
Replies
1
Boosts
0
Views
97
Activity
1w
NavigationSplitView, endless loop detail<->content
Hi, I already had a problem with the NavigationSplitView before, and I'm still working on it. The NavigationSplitView issue on the phone occurs when trying to navigate back from the detail view to the content view; the app automatically navigates straight back to the detail view. I reproduced the issue in a small program and identified the critical section. However, I do not know why the problem is occurring. I did the same thing again, but this time with @Query, and there was no problem. The categories, recipes and single recipe, all loaded by @Query and no side effects. Requirements for the content: A state variable used in the view, e.g., isLoading A task that loads the data from a ModelActor in a ViewModel, setting isLoading to true beforehand and back to false upon completion Subsequently, it is only possible to exit the detail view after many attempts, because the app immediately navigates back to the detail view automatically upon trying to leave it. One issue is changing the isLoading status variable from within the task. That in itself isn't the problem; the issue only arises when reading data via a ModelActor. If the status variable is changed and, for example, the list is modified manually, there is no problem. It only occurs when a ModelActor is used. I based it on the NavigationCookbook: This is the view I use for the content section (list): @State private var vm: RecipeListViewModel = .init() @State var isLoading: Bool = false if isLoading { ProgressView("Loading...") } else { List(selection: $selectedRecipe) { ForEach(vm.recipes) { recipe in NavigationLink(recipe.name, value: recipe) } } } .task { // bug, when used in UI, because of ModelActor isLoading = true await vm.list(context, categoryName: selectedCategory.name) isLoading = false } .task { // works, because manually modifying the list isLoading = true await vm.addRecipe(context, categoryName: selectedCategory.name) isLoading = false } inside ViewModel // bug func list(_ modelContext: ModelContext, categoryName: String) async { recipes.removeAll() let dh: RecipeDataHandler = .init(modelContainer: modelContext.container) let values = await dh.listByName(categoryName: categoryName) for v in values { recipes.append(.init(recipeId: v.recipeId, name: v.name)) } } // works func addRecipe(_ modelContext: ModelContext, categoryName: String) async { isLoading = true defer { isLoading = false } recipes.removeAll() recipes.append(.init(recipeId: "a", name: "Pambazo")) } ModelActor @ModelActor actor RecipeDataHandler { func listByName(categoryName: String) async -> [RecipeData] { var list: [RecipeData] = [] do { let fd = FetchDescriptor<Recipe>(predicate: #Predicate { $0.category.name == categoryName }, sortBy: [SortDescriptor(\Recipe.name)]) let data = try modelContext.fetch(fd) for item in data { let rec: RecipeData = await .init(recipeId: item.recipeId, name: item.name) list.append(rec) } } catch { print("error: \(error.localizedDescription)") } return list } } Recipe is a @Model and RecipeData just a struct. In principle, everything should run on the MainActor, but the inclusion of the ModelActor still leads to this strange behavior. Any idea what the problem might be? Christian
Replies
3
Boosts
0
Views
361
Activity
1w
Fundamental error in PDFOutline created syntax
PDFKit's PDFOutline creates fundamentally flawed PDF syntax when it creates outlines ("Bookmarks") in a PDF document. A PDF document is created with three outlines: "Page 1", "Page 2" and "Page 3". Each is a child of the former, so "Page 3" is a child of "Page 2", and "Page 2" is a child of "Page 1". PDFKit produces flawed PDF syntax, with duplicate entries for each bookmark, missing sibling links, and a convoluted Parent > Child relationship. 3 0 obj << /Type /Pages /Parent 45 0 R /Count 8 /Kids [ 2 0 R 6 0 R 9 0 R 12 0 R 15 0 R 18 0 R 21 0 R 24 0 R ] >> endobj 28 0 obj << /Type /Pages /Parent 45 0 R /Count 3 /Kids [ 27 0 R 31 0 R 34 0 R ] >> endobj 45 0 obj << /Type /Pages /MediaBox [0 0 612 792] /Count 11 /Kids [ 3 0 R 28 0 R ] >> endobj 46 0 obj << /Type /Catalog /Outlines 1 0 R /Pages 45 0 R >> endobj 1 0 obj << /First 47 0 R /Last 48 0 R >> endobj 48 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 51 0 obj << >> endobj 50 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 53 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 52 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 49 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 47 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj(The Parent of all the outline objects is given as object 51, which is blank. The First/Last objects don't link correctly to the expected hierarchy, etc, etc.) Acrobat preflight will flag this as a syntax error, though the bookmarks do largely function in most viewers. Preview doesn't show the top-level outline, though that might relate to FB4013726, filed in 2018. I have shown the created syntax to ChatGPT, which also confirmed that the syntax does not conform to the expected PDF spec: This isn’t simply a matter of PDFKit choosing an unnecessarily elaborate but valid representation. There are genuine structural problems: The top-level Page 1 object’s /Parent does not point to the /Outlines dictionary. The child objects’ /Parent does not point to their actual containing outline. There are duplicate outline objects for Page 1, Page 2 and Page 3. The required sibling Prev/Next chains are absent. The /First//Last relationships don’t correspond cleanly to the claimed hierarchy. The errors are entirely reproducible in any PDFOutlines created by PDFKit. I have filed this as FB25328043. ... and in 2021 as FB8960602. ... and in 2019 as FB5313583.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
3
Boosts
1
Views
607
Activity
1w
Non-collapsing title
In the Photos app, the Collections title doesn't collapse into a small inline title when scrolling, unlike a standard inline large title display mode. How is this implemented?
Replies
2
Boosts
0
Views
200
Activity
1w
Clipped render of dragged NSTableView row on macOS 27.
On macOS 27, dragged rows on my app's table views are excessively clipped (see image). I don't override methods like `tableView:draggingSession:willBeginAtPoint:forRowIndexes:` so I don’t supply my own drag images, and I don’t use NSTableView suclasses. I tried on a toy project containg with a single table view in a window, and it did not reproduce this behavior. I wonder if my issue if it’s due to my app’s table views being embedded in split views or something. Anyway, how can I fix that?
Topic: UI Frameworks SubTopic: AppKit
Replies
1
Boosts
0
Views
199
Activity
1w