“column”

While we can't share exactly how this was done in the Mail app, I was able to achieve a similar layout with the following code: NavigationSplitView { // ... } content: { VStack { HStack{ sampleButton sampleButton } .cornerRadius(12) .padding(.top) List() { ForEach(0..<10) { index in Text(Email (index)) } } } } detail: { ContentUnavailableView(Select an email, systemImage: envelope) .toolbar { sampleButton } } To make certain columns collapsable, see NavigationSplitViewVisibility. This would require adding a @State to manage column visibility. Feel free to change it to your liking.  Travis

It means apps don't need to actively track the current location of their files, but can instead determine its current location whenever the user actually asks for it. What should happen if you expand a directory with four subfolders in a NSBrowser (so four columns). And the third folder moves? If an app just follows the file reference URL the UI is broken. I mean if there are/were APIs that handled this in file reference world I'm with you! The concept of file location matters to users and to a lot of apps. I hope Apple doesn't want to put apps in single file jail. Here you get that one txt document and if it moves don't worry we got you. There are other types of apps that do other things. Please don't turn macOS into iOS :)

So, after spending quite some time testing how the staged migration works, I think I figured out most of the nuances with NSLightweightMigrationStage. I want to share my finding in as many places as possible so that other troubled developers would be able to find this info and avoid the struggle 😇 The experimental project: The model V1 initial V2 added Required String name V3 added Required UUID id V4 added Optional String bs V5 added Optional Int attr5. Default: 0 V6 added Optional Int attr6. Changed attr5 default to 2 V7 added Optional String attr7. Chanded attr5 default to 4. V8 added Required Int count. Default: 0. V9 deleted attr7. V10 deleted attr6 Custom Mappings I've also included Model Mapping files with some custom policies: V1 => V2: Fills name field from the custom policy's function. V2 => V3: Fills id with new generated UUIDs from custom policy's function. V4 => V5: Fills attr5 with a random number from 1 to 10 through the custom policy. V7 => V8: Fills count with a random number fro

The issue you're encountering with CSS grid columns misaligning at certain zoom levels, despite using fractional widths, is likely due to subpixel rounding behavior inherent in rendering engines. Here's a deeper dive into why this happens and some potential strategies to mitigate it: Understanding the Issue Fractional Widths and Subpixel Precision: CSS fractional widths (e.g., 518.7875px) aim to distribute space precisely across columns. However, rendering engines often round these values to the nearest whole pixel to fit display resolutions, which can lead to misalignment, especially noticeable at non-100% zoom levels. Subpixel Rounding: At zoom levels like 85% or 115%, the pixel grid becomes more pronounced, and small rounding discrepancies can become visually apparent, causing columns to appear misaligned with background patterns or other elements. Device Display Scaling: MacBook models with Retina displays use higher pixel densities, which can exacerbate subpixel rounding issues

The first image with time 9:35 shows a list of transactions sorted by date using List{}. The column headers are displaying in DARK mode with a black stripe, and header items have switched from black to white. The second image (9:39) changed to a ScrollView {}. The column headers did not change color, but scrolled out of the view. The header is showing that the text has changed from black to white while scrolling. The final image is a ScrollView with LazyVStack pinnedViews. Google suggested using .toolbarColorScheme(.light, for: .navigationBar) at the bottom of the ScrollView to prevent the header stuff from changing color. So my question is: Is this change in color for these views a bug or is this normal behavior with Liquid Glass?

I'd just double-check what that column represents — I presume the first column is the compressed app size and the second column is the uncompressed app size, but the labels at the top that are likely scrolled out of view should tell you. If the label says installed size, then that is the uncompressed size and what the app takes up on disk after installation. If that's correct where your arrows are highlighting the uncompressed app size, then yes, your watchOS app is meeting the size limit noted by Maximum build file sizes. — Ed Ford,  DTS Engineer

The rows in the English column all contain black text, which is the text passed as the value argument to NSLocalizedString(_:value:comment:). The app also runs in English if I select it in the Xcode scheme editor.