When a collection of source files is contained in an Xcode group, re-ordering of the files is possible. When they are contained in an Xcode folder, re-ordering of files is impossible. The technical explanation of why a folder is favoured over a group is somewhat at odds with the user experience for all developers. (I've also worked with high school developers who complain that they can't change the order of files in Swift Playgrounds). Co-existing with source control and collaboration could be viewed as a "model" issue. Being able to change the sort order of files is a "view" issue. Surely through the Xcode user file the ordering could be kept separate (and local) from what is shared collaboratively. Being able to change the order a files in a project is a super common use case. The project repository would not want the file ordering changes from multiple users being part of the check in - hence why this could be store in the user defaults for the project in Xcode.

https://www.massicotte.org/swiftui-coordinator-parent provided very useful insight. Every example that I could find makes the same mistake. They all make a property of the Coordinator directly to the NSViewRepesentable which they call parent. Apple too does this in a tutorial. However, it's easy to forget that NSViewRepresentable is a value type, not a reference type. When SwiftUI updates changes it can totally destroy your NSViewRepresentable. If you make your Coordinator refer to a NSViewRepresentable, that reference will become invalid. Things will not update if you think you can access via context.coordinator.parent Massicotte's insight is to not use a View (which can change) but have the Coordinator store the data. My first literal read of that was to store a String but once you think (and code) a bit more you realise that you have to store a Binding<String> in the Coordinator. You are binding to an entry in your model from the Coordinator. This is absolutely necessary if you are going to use your NSViewRepresentable inside a NavigationSplitView. You won't see the issue if you use it in isolation.

This issue was related to being a member of defunct organisations in the developer program. They no longer paid their developer account annual fee and were no longer supporting their app. Simply being a member broke notarisation. I had to be removed from those organisations for things to work again. There is a feature that allows you to remove yourself from organisations. Previously, there was only a way to contact that organiser of that account to have yourself removed. Now you can do this yourself, without trying to contact people who are no longer with an organisation.

but then I will have to add it to each individual column If you need to repeat the same functionality for the context menu, put that in function and make the Button action call that same function. Probably obvious to many. But seems to be the only work around if you want the context menu for the row to be consistent. I too want a single context menu definition for a Table row. In UIKit you have to select the defined cell to reveal the context menu, clicking on places which are effectively empty space doesn't open the context menu. The trick here is to expand your cell to fit the column width. Out of the box Table { }.contextMenu{ } doesn't seem to work at all. I've attached the modifier to the Table and see no context menus at all. So it seems we are stuck with attaching the context menu to the contents of the TableColumn and each column if you want it appear across the row. It forces you to define the content closure, you can't use the TableColumn defaults. Still feels like being an early adopter....

Just ran into this issue too when working through a simple struct with Strings. A table of mostly strings with some columns sensibly optional Strings. The compiler message displayed in Xcode 13.3 is: The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions So not helpful. Removing the path does seem to work, but the docs would suggest that the column will no longer participate in sorting state of the table. I too can think of use cases where I have optional data but want the rest of the non-optional Strings to be sorted (either at the bottom or the top).

Also just started happening for me with the 12.3 update. No other hardware connected at the time it first started. No issues like this prior. 16" Intel. So this isn't just an M1 issue.

I'm now at 1 month and still can't notarise apps.

FB9206318 I'm now up to 14 days of this notarisation error. Whilst others have reported fixing the contracts is a solution, I'm a member of several defunct organisations in Apple Developer, so unclear whether an association with entities that have not signed the contract is part of the issue. The specific organisation trying to submit an app for notarisation has been confirmed to have signed all outstanding contracts.

So waited ... 9 hours, tried again. Same error message. On Xcode 12.5. Moved to Catalina, Xcode 12.4. The error message is different. You must first sign the relevant contacts online (1048). My company contracts are signed. I have no banners asking me to sign anything. However, I'm still a member of defunct organisations that don't exist any more that are no longer in the program. So from this retrograde approach, it seems that the error message might be (in my case) related to other organisations not signing off on their contracts. I just happen to be a member. Can't remove myself or contact the people who don't have an email there any more since they've left.

Apple System Status says there has been an outage. Developer ID Notary Service - Resolved Outage Says yesterday 3:25 - 4:10 am I'm assuming this is a US Pacific time reference. It is reported to have been resolved but I'm still seeing the notarisation UUID error @ 6:40 pm California time. Point for improvement. Localise the date/time references on system status.

It was written 5 years ago so it's possible that things were more confused back then 😃 Worked through cleaning up the code. Thanks for the response. Yes, NSStrings are converted back to String so internal to the ValueTransformer you can simply pass a String value back where the ValueTransformer is defined to return NSString.self. So there is no need to wrap a conversion from String to NSString. override class func transformedValueClass() - AnyClass {   return NSString.self } override func transformedValue(_ value: Any?) - Any? {         let str = convert(value) // returns a String         return str } This needs to be within the Objective-C side since the string is being handed back to a Cocoa Binding. So have to return NSObjects. So using NSNumbers for bool conversion works too. What was also less obvious what that there was a work around that generated a string for the Entity directly, bypassing the ValueTransformer. So buried in the IB Bindings inspector you could see that but not obvious just from reading the code. Alas, the importance of documenting code work arounds and explaining which code isn't actually working.

Writing a wrapper class around the range seems to be one work around. However, there is a bizarre issue where the code compiles and runs in the app, but unit testing reports the same error. Clean and option Clean tried, with no success.

That's it - thanks! Option + command + click is the correct set of keyboard modifiers. Control + command sends me to the code definition. Wow, 3 context menus. Is there a reason for differentiating Embed In for Storyboards and for Swift UI? Those who are used to Storyboards will search for Embed In in the Editor menu as well, but Swift UI doesn't have an Editor menu presence. The option+command+click concept doesn't work in Storyboards. Just thinking of having consistency between the two approaches and helping those learn or work across both techniques.