Thank you for your research. Your reply prompted me to try things differently, and turns out, the particular way we had text fields set up in our app was the reason their undo was flaky. Embarrassing, but at least all is clear now!

Sorry for not replying earlier. No, I'm afraid that info isn't what I'm looking for. The thing that I'd like to understand really is, specifically: how to use the built-in undo support of SwiftUI TextField views, if any. Hopefully you're able to get details on this somehow!

Thank you for your reply! I understand now, and was able to fix our code. I’d read the documentation page too quickly and misunderstood what it was saying exactly. It's pretty interesting that you need to read the environment not from within the row view, but from a descendant of it. For anyone else reading this, here’s some additional tests that helped me understand exactly the required setup. The third row especially (ListItemThinWrapper) seems to suggest you should be thinking in terms of resolved views, or something like that. struct ProminentBackgroundInList: View { var body: some View { List(selection: .constant(Set([0, 1, 2, 3]))) { ListItem().tag(0) // doesn't work ZStack { ListItem() // works }.tag(1) ListItemThinWrapper().tag(2) // doesn't work ListItemStackWrapper().tag(3) // works } } struct ListItem: View { @Environment(\.backgroundProminence) var backgroundProminence var body: some View { HStack { Image(systemName: "person.fill") .foregroundStyle(backgroundProminence == .standard ? .orange : .primary) Text("Person") } } } struct ListItemThinWrapper: View { var body: some View { ListItem() } } struct ListItemStackWrapper: View { var body: some View { ZStack { ListItem() } } } } #Preview { ProminentBackgroundInList() }

To more clearly state my question, what I’m really asking is: how does SwiftUI’s TextField work with Undo? What are the conditions to making that work?

Thanks for the tip! I am using SwiftUI, however, so its's the SwiftUI TextEditor and TextField views that I'm trying to understand.

Thank you very much for looking into this; this makes perfect sense now. When I first looked into fixing the file structure to fit the rules, my first instinct was to experiment by submitting slightly modified versions for notarization (i.e. add/delete/move a file, then resign, zip and notarize) until notarization broke again. This was foiled, however, since CLI notarization always succeeded! Now that I know that I can reproduce this stricter behavior found in Xcode (by dropping extended attributes while zipping), it'll be easy to experiment and check my work. Thank you!

Yes, that's exactly it! I just reproduced the issue, strictly running through your list, to make extra sure. Here's the Xcode submission UUID: 417D4144-65D6-4C05-A219-4B2B5039AF7E And the notarytool submission UUID: 035482f3-855c-455f-bd60-6be63ceefd61 And for good measure, a screenshot of the submission failure in Xcode:

(interesting reads, thank you—just learned a bunch of things) My previous message was misleading though, sorry: when notarizing through the command line, I was submitting the .app that Xcode re-signed with my Developer ID identity, not the original .app from the archive. Or said differently, I was submitting the .app found in *.xcarchive/Submissions, not *.xcarchive/Products. Still, the confusion remains! Because that means I'm submitting the exact same .app for notarization; and so in Xcode notarization fails, and using xcrun notarytool it succeeds. So strange. For now we should be fine notarizing through the command line, but if you do have insight into why there's a difference in the notarization service's behavior, I'm very much interested.

Thank you for your super detailed answer! And, oops, sorry about missing (or probably forgetting about) these warnings in the docs. I've been looking into various solutions, mostly gravitating towards the “symlinks for gnarly edge cases” solution. However, I ran into something perplexing: If I create an archive build within Xcode, then submit it using “Direct Distribution”, the process fails with a “The signature of the binary is invalid.” issue. But! If I then submit this same, archived .app, using notarytool, this submission then succeeds! Is this what you were referring to, when mentioning Xcode being persnickety? I don't understand the implications here—is Xcode performing the notarization submission differently? Is it OK to just rely on the command line for notarization? Here's how I submit via Terminal. I'm using the same AC profile in both cases: xcrun notarytool submit --keychain-profile "AC_PASSWORD" --wait ZippedArchivedApp.zip

Sure! Here's the first dialog: And the second: Of note, the second dialog only appears if you choose “Allow” in the first. If you instead choose “Always Allow”, the second dialog is skipped. (and the keychain read succeeds)

In my tests, the attributedTitle property does have an effect, but if you set it too early in the tab's lifecycle, it gets reset. Setting it a bit later, it seems to properly stick. However, despite what the docs state*, the title's font size and font color are incorrect, even when left unspecified: the font is slightly too large, and the color is the same for both selected and unselected tabs (and isn't correct for either). * “Attributes that are left unspecified, including the font and foreground color, are automatically filled in using default values appropriate for the window tab”

Thanks a lot! I had the same issue, and probably would have never figured out the solution on my own.