I have raised a bug report for this: FB7849024

Thanks @mtsrodrigues and other contributors. I am developing an app that uses UIManagedDocument in conjunction with UIDocumentBrowserViewController and would like to migrate this to SwiftUI. It sees to me as though the new DocumentGroup stuff might be coaxed into using the same approach. Any ideas?

When the edit button tapped it switches to 'Done', but the table doesn't change to display the delete buttons.

What version of IOS are you using?

The problem is in IOS 14. It works fine in iOS 13.6.

Doh! Thanks. They must have changed something because it was working fine for about a year!

I was wrong. Moving NavigationViewStyle is a red herring. If you remove it altogether it works. It has no effect in the new position (try changing it to .navigationViewStyle(DoubleColumnNavigationViewStyle()) and you'll see that on iPad). I have managed to get it working in the main view of my App (not this test app), but don't understand why. There seems to be some interaction with .sheet going on. I think it's actually some sort of threading/timing error in SwiftUI. Like I said before, it was working fine in iOS 13.6, so they have clearly screwed something up. Apple, as is often the case, seem totally uninterested.

Argh!! I'd unwittingly managed to changed the debugger output option to target output. OK now.

Thanks for the reply. I was mistaking something - there is no need to declare 'stop' outside the closure! That said it doesn't explain the error. The following produces the same error, which I reckon is a compiler bug: import Foundation class Test {     func test() {         let stop:UnsafeMutablePointerObjCBool         stop.initialize(to: false)     } }

If you look at the documentation for UnsafeMutablePointer you will see that the memory pointed to has to be initialised, not the pointer itself and that the initialize method does this. This is confirmed by declaring stop as a var as in:     func test() {         var stop:UnsafeMutablePointerObjCBool         stop.initialize(to: false)     } This still fails the same way. I will report it as a compiler bug. I think that enumerateAttribute initialises it to false anyway, which is why this code isn't needed in the first place.

Ok, so how do you think the code should be written?

Thank you for this. No, I’m not used to using pointers in Swift. I try and steer clear of them. As I mentioned earlier these lines aren’t necessary anyway because emumerateAttribute deals with setting it up. Definitely a case of RTM (polite version).

I think the issue might be because I am using custom attributes. It is ok if none are present.

Thanks for your response. I had indeed set an incorrect attribute. One of those stupid mistakes you can stare at for hours and not see!!

Just found that the following code does the trick, it just needs amending to include traits:     class func preferredCustomFont(for fontFamily: String, andTextStyle textStyle: UIFont.TextStyle) - UIFont {         let systemFontDescriptor = UIFontDescriptor.preferredFontDescriptor(withTextStyle: textStyle)         let customFontDescriptor = UIFontDescriptor.init(fontAttributes: [             UIFontDescriptor.AttributeName.family: fontFamily,             UIFontDescriptor.AttributeName.size: systemFontDescriptor.pointSize // use the font size of the default dynamic font         ])         // return font of new family with same size as the preferred system font         return UIFont(descriptor: customFontDescriptor, size: 0)     }