column

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

Can we bundle our app with our own version of SQLite with extensions that we want. Yes, and you should do that. The version that Apple includes depends on the iOS version (see https://github.com/yapstudios/YapDatabase/wiki/SQLite-version-(bundled-with-OS) for a table). If you use the Apple version, there's a danger that your app will break after an iOS update, or will not function on an older iOS version that you are still trying to support but don't test on as well as you should. I was caught out by the latter issue because the sqlite in iOS 14 doesn't support on conflict without a column list.

While I can't predict the future or comment on anything future looking, I'd like to color in some details of the complier so you have a more complete understanding of how things work, in hopes that you can use this information to inform your own decisions around adopting Swift 6. If you take a look at the Xcode support page and look at the table of Xcode versions, you'll notice the Swift column has two sets of data — the complier version, and language modes. As you stated, Swift 6 was released with Xcode 16, and you can see that in the version number of the complier in the chart. Every Xcode release has one version of the Swift complier, and so that means every app that has compiled with Xcode 16 or newer has already compiled with the Swift 6 complier. Your question here is better stated as what is the longevity of the Swift 5 language mode? The language mode (which you'll find in your project as the SWIFT_VERSION build setting) is the version of the language the compiler is using for its compilation