“column”

I just had a chance to test this under iPadOS 26.1 beta 2. Great news - if the primaryBackgroundStyle property of the split view is set to .none then we get back the old style tile layout and none of the content of the other columns appear behind the primary column. Thank you. If the primaryBackgroundStyle is set to .sidebar, the primary column is inset a bit as it has been since iPadOS 26.0 (and that's fine for a sidebar). But there is still some unwanted extension of content from the other columns behind the primary column. It's not nearly as bad as iPadOS 26.0. Running the app I used for the screenshot in the first post of this thread now results in just the background color of the selected row appearing on the far left. The section headers do not extend to the far left any more. Here's how it looks now with primaryBackgroundStyle = .none with iPadOS 26.1 beta 2: Here's how it looks now with primaryBackgroundStyle = .sidebar with iPadOS 26.1 beta 2 (note the row

Hi Ptit-Xav, I placed the controls in the same manner as Claude31 recommended. If there is a better placement methods, please specify I don't know what you mean by placement constraint My view above is what I thought was a logical subview Regarding ZStack, I thought this was used to control depth of controls, such as various picture objects on top of each other. Don't know what you mean by global view, or what an overlay is I have spent about one month attempting to find comprehensive documentation on SwiftUI and its controls and how to place them, but have come up short. Even Rust has better documentation when it comes to the types of controls available (think FLTK or Iced), what they look like, and how to use them. 99% of the designs are a single vertical column. I have several SwiftUI books, and they cover a lot of material, but answering specific questions about how to place controls on a Form, epecially when the design is more complex, is seemingly hard to come by. Sorry for all the questions, b

Your layout seems quite unusual in the sense that you put a slider in the middle of nothing. There is seems to have no placement constraint other than obsolete positioning. (may be i am wrong) As show by Claude31 , you should define logical subviews (buttons view, tile view, header view, ...) Then you define how are these subviews arrange in line or column. If you need more complex positionning, you may use a large ZStack and set each subviews to a specific place. Or use en overlay to put the slider in the middle of the global view.

I’ve always wondered about those status values, so I did some experimentation today (-: Remember that to sign code you need a code-signing identity. This is a digital identity, that is, the combination of a certificate and a private key that matches the public key in that certificate. For more background on this, see TN3161 Inside Code Signing: Certificates. So, there are four possibilities for the Manage Certificates UI: No row — If the certificate is not known to the Developer website, there’s simply no row for it in the list. Not In Keychain — This means that the certificate is known to the Developer website but there’s no copy of that certificate in your keychain. Missing Private Key — This means that the certificate is known to the Developer website and is available locally, but the associated private key is not in your keychain. Blank status — If the Status column is blank, everything is copacetic; Xcode will offer that code-signing identity as an option to sign code. Note If both the certifica

Hi, It seems like it expected behavior. From the demo I can assume that it's not for those type of document. Imagine that you have a normal document, where you have a 2 columns of text. You wouldn't want to read it line by line like you want to do with receipts Unfortunately I try to do the same thing, so I have to stay with simple previous iOS OCR solution and trying to connect those in lines by my own (not very good) algorithm.

Nice to know that the original issue goes away in the latest Beta. Regarding the crash triggered by the access to Item.children, if you can provide a runnable code snippet to demo the issue, I'll take another look. You have mentioned a few classes with inheritance, and so I think it is probably worth mentioning that over-using inheritance may impact your app's performance negatively. Concretely, with today's default store (DefaultStore), all the types in an inheritance hierarchy are persisted with one single table in SQLite. If your inheritance hierarchy has many classes, the table (columns and data) can be quite big, which can slow down the performance of fetching and inserting data. That being said, when adopting SwiftData inheritance, you might examine if that is a right use case. This WWDC25 session(starting from around 4:25) covers this topic a bit. You can take a look, if haven't yet. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Hi Ziqiao, the problem is that when you want to use SwiftData for an enterprise app, the user needs proper navigation. In such apps, you usually have more than one screen or form. I did some additional tests with your code and replaced the NavigationStack with a NavigationView. The reason is that I need the automatic two-column split for a sidebar menu and a detail view, not just a single view. The NavigationSplitView doesn’t seem to work as expected. Using it as a root view with an embedded TabView was my first attempt, but that didn’t work either. That’s why I tried embedding the NavigationSplitViews inside the TabView. When I replace your NavigationStack with a NavigationView, I get the automatic two-column view on iPad — but with a second navigation view below the DocumentGroup navigation view. This looks bugged. The NavigationSplitView also has issues with the back button and the document title in sheets. I’ll file a feedback report for now as you suggested and try to find a workaround