You're right! I didn't even notice this, but it's also happening in our app, and I just made a clean sample project that also has this problem. It's obviously a bug somewhere in SwiftUI, of which there are many. :( You should file a bug report, and I'll do the same.

Predictive code completion still failing to install on a M1 Mac Mini with the Xcode 16 RC and the macOS Sequoia RC. Here's the error I'm getting. The operation couldn’t be completed. (ModelCatalog.CatalogErrors.AssetErrors error 1.) Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 User Info: { DVTErrorCreationDateKey = "2024-09-09 20:45:40 +0000"; } -- Failed to find asset: com.apple.fm.code.generate_small_v1.base - no asset Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 -- System Information macOS Version 15.0 (Build 24A335) Xcode 16.0 (23050) (Build 16A242) Timestamp: 2024-09-09T13:45:40-07:00

The problem you're describing (where something loads the second time you open it but not the first) is almost always a case of something happening asynchronously and the view not updating after the async code has finished. Looking at what you've posted, it looks like the first view controller's table didSelectRow function, configureDocPdf runs asynchronously and the pdf presenting code doesn't wait for it to finish before firing. So the first time you load the PDF, your URLSession is still trying to get the data when LectorPdfViewController is initialized with self.doc (which wouldn't have loaded yet). Another way to test this would be to try and load different PDFs each time, and see if it's always displaying the previous PDF you tried to load. That would be because the URLSession finished the previous self.doc, but not the one you're trying now. If that turns out to be the problem, you'll need to hold off loading the pdf view controller and presenting it until after the pdf data is downloaded. In the future, you might also take a look at the new async/await APIs which would prevent a bug like this from happening. Hope this helps.

It turned out to be an App Store Connect problem. I had to call Apple by phone and talk to support to find out what the actual error was, and it turned out to be something weird like we were trying to use the same name for our app before we got the system to release that name from a previous project we had used. Something like that. You can find the contact info here: https://developer.apple.com/contact/topic/select Good luck. It was a total nightmare.

I'm not sure exactly what's going wrong for you, but you can force a text view to update using any of the following (depending on what actually is going wrong for you): // asks the text view to redraw textView.needsDisplay = true // asks for relayout textView.needsLayout = true // these two need to be called together to force the NSLayoutManager to reprocess this range textView.layoutManager?.invalidateGlyphs(       forCharacterRange: NSRange(location: 0, length: textView.string.utf16.count),       changeInLength: 0,       actualCharacterRange: nil) textView.layoutManager?.invalidateLayout(       forCharacterRange: NSRange(location: 0, length: textView.string.utf16.count),       actualCharacterRange: nil)

You can use NSTextAttachment to insert an image in a UITextView's textStorage. let attachment = NSTextAttachment() attachment.image = scaledImage let imageString = NSAttributedString(attachment: attachment) textView.textStorage.insert(imageString, at: indexWhereYouWantTheImage)

TextKit 2 isn't a complete replacement for TextKit 1, and given how many apps rely on TextKit, it's unlikely Apple will drop support for it for a long time. You should be fine. Also, while I would have liked to see parity between iOS and macOS for TextKit 1, it seems clear that's what TextKit 2 is for, and the legacy APIs won't be unified in the way we might have liked.

As of SwiftUI 2, I don't think so. I believe you need to wrap an NSTextView or UITextView with this functionality. Doing this for UIKit is very straightforward (just use UIViewRepresentable), but on the Mac it's more complicated because NSTextView isn't a scroll view subclass like UITextView is. Here's a gist I found that shows what you need to do on macOS: https://gist.github.com/unnamedd/6e8c3fbc806b8deb60fa65d6b9affab0