“column”

This is a tricky aspect of NSTextField in table views. usesAutomaticRowHeights relies on the text field's intrinsicContentSize to determine row height. When isEditable is true, NSTextField internally changes its sizing behavior and stops reporting a multi-line intrinsic height, so the row collapses to a single line. Your observation that the text still wraps internally but the cell height doesn't update is exactly right. The fix is to stop using usesAutomaticRowHeights for editable text fields and calculate row heights manually using tableView(_:heightOfRow:). Use a separate non-editable text field as a measurement prototype — since non-editable text fields calculate wrapping height correctly — and call noteHeightOfRows(withIndexesChanged:) when the text changes so the row resizes as someone types. Here is a working example: // Prototype field for height measurement (non-editable, so wrapping height is correct) let measureField: NSTextField = { let tf = NSTextField(wrappingLabelWithString: ) tf.isEditable = f

Thanks for the post, I would recommend to put the output of the console errors on the body of the message as well will easier to see and warning and errors to that point The error I see at the last screen may happen when Xcode attempts to install your app onto a physical device, but the app or probably one of its embedded 3rd party frameworks lacks a valid code signature? If you haven't set up code signing yet, the easiest way to fix this is to let Xcode handle it. Look first at the app team dropdown and make sure everything is valid. Go to the Signing & Capabilities tab and check the box for Automatically manage signing. In the team dropdown, select your Apple Developer account/team. If your main app is signed but a third-party library or framework is not, Xcode will throw this exact error. In General, scroll down to Frameworks, Libraries, and Embedded Content. Look at the Embed column for your frameworks. If you have dynamic frameworks like .framework or .xcframework files that are not Apple, m

[quote='825136021, KirkBeamedUp, /thread/825136, /profile/KirkBeamedUp'] Can this be done … ? [/quote] Probably, but whether it’s worth it depends on how much you value your time. First, some background. Most NE entitlements are available to all developers who are members of a paid team. And you’re right that there’s a bunch of backstory to this, but the info in my Network Extension Framework Entitlements post is up to date. Also, Developer Account Help > Reference > Supported capabilities (macOS) is a good page to bookmark, because it lists a bunch of common capabilities and their team requirements. The Apple Developer column in that table is what you get with free provisioning, also known as Personal Team in Xcode. Now, for iOS and its child platforms that’s the end of the story. For macOS you have options. You can disable SIP and then disable bits of the trusted execution system and thereby claim any entitlements you want. For an example of this, see this post. IMPORTANT This is not a suppor

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