“column”

Thanks for the post, you can quickly turn off Liquid Glass on the info.plist file to see your assets without Liquid Glass using the UIDesignRequiresCompatibility key on your info.plist: https://developer.apple.com/documentation/BundleResources/Information-Property-List/UIDesignRequiresCompatibility Note: Check the note on that documentation as should be only used for testing not for deployment . I would also recommend for you to take a look at this great documentation. https://developer.apple.com/documentation/TechnologyOverviews/adopting-liquid-glass Also, by default, older versions of iOS automatically applied a gloss overlay to make all app icons look uniform. I do not know if that’s your case based on your description. To turn this off and have your raw PNGs display exactly as you designed them, you need to tell the system that your icon is. If you are using an Asset Catalog to manage your app icons, which is the standard for modern iOS development. Open your Xcode project and select your Asset Catalog. S

OK, you’re definitely on the right path here. [quote='883659022, RobJones, /thread/821896?answerId=883659022#883659022, /profile/RobJones'] it works ONLY WITH my enterprise provisioning profile. [/quote] Interesting. I didn’t expect to see a difference between team types here, because Developer Account Help > Reference > Supported capabilities (iOS) says that Keychain Sharing is available for all three team. However, I tested this and discovered a discrepancy. Specifically, I created a test project with two app targets: Individual, signed by the Individual team I use for testing (SKMME9E2Y8) PersonalTeam, signed by the Personal Team I use for testing (SKMME9E2Y8) Note Personal Team is the term that Xcode uses for Apple’s free provisioning feature. It corresponds to the Apple Developer column in the table I referenced earlier. In contrast, an Individual team is covered by the ADP column. I then added the Keychain Sharing capability to both, built them for the device, and then dumped the

Here is more concrete context. Platform / tools Target: macOS app Language / frameworks: Swift, SwiftUI, SwiftData Cloud sync: SwiftData with CloudKit mirroring in the production configuration Xcode: 26.4 (17E192) Test OS: macOS 26.4 (25E246) What I’m seeing In the macOS app, issue board scrolling can become inconsistent or very slow. Changing an issue status from detail view can be very slow. Scrolling the status menu itself can be slow. Typing in issue description/notes fields can become sluggish. The problem is much more noticeable with my full production-sized dataset than with a small dev dataset. What I’ve tested so far I compared a small dev dataset vs a much larger production-sized dataset. With a small dataset, the same UI feels fast and smooth. With the large dataset, the same UI becomes noticeably slower. I also tested a local-only copy of the production dataset with CloudKit disabled. That improved some behavior, but it did not remove the lag entirely. When I reduced the local test dataset from ~1

actually i would like to delete this post. turns out xcode always generates the file with the column before the : but a script of mine that pulls translations regenerates the file without the spaces before the : and then when i make a change in xcode, this dif happens. Im sorry for the confusion.

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