Sounds like the classic off-by one error to me. PDF Pages are traditionally one-based, while many functions in PDFKit, i.e. page(at:) are zero based. https://developer.apple.com/documentation/pdfkit/pdfdocument/page(at:)

Is that workaround still the only solution in 2.1? I have a scene with one anonymous Window group, and 4 Window groups with ids. When I have main and one other WindowGroup open, and close the anonymous window first, then on reopening 2 of the WindowGroups with id appear, yet not the main WindowGroup.

I have the same issue, and the thing is that it works just fine as expected in visionOS 2.0, but fails to be called in iOS 18.0. I'm loading the content from a bundle, and use literally the same code on both platforms. I consider this a bug in iOS. The alternative for me was to trigger updates by listening to changes in the underlying data model: RealityView { content in // your async loading code here... // you might need to adjust your scene after loading to your data model } .onChange(of: yourDatamodel) { // your refresh code here... } code-block

Actually, I'm using Blender for creating these entities, but there are problems with the output, i.e. Blender exports an environment light (even if lights are disabled in export), which creates issues when compiling the package). Also, I need to assign new materials in Composer Pro, as I need universal inputs to alter textures at runtime in my scenario. I understand references, but the funny thing is that somehow (still haven't figured out a sequence of steps how to do it) I manage to convert these references to original data within the scene. These data are kept even when removing the originally referenced *.usdz. For me that makes stuff so much easier than dealing with the exports from Blender.

I managed to do this again, but I have still no idea why it worked now. Same for materials. Isn't there simple a command to resolve external references?

This is a classic XCode bug, still happening with XCode 15.1. The only way I have found to fix it is to delete derived data

Disabling Live Issues obviously prevents just the display w/o addressing the root cause. There seem to be some kind of error cache, which is not properly reset. This is an Xcode bug.

Xcode won't display README for Swift Packages on PRIVATE repos. It's really as simple and dumb as that. While the package manager finds and loads your package just fine from private repos, the element displaying the repo operates under the assumption that the README can be read without authentication.

Same issue here, and beside the issues mentioned already, this is quite a pain of you have a number of potential devices to run on. While previously devices were automatically switched when connected via cable, now I always have to select them in the menu. Which can be quite bothersome, if you have multiple similar devices. Cable debugging was always way faster than remote debugging, and I really do not understand why Apple is fixing something that was not broken.

I had that issue in a legacy project when macOS was added as a run destination, I think as a side effect of an Xcode update . Removing macOs from the supported destinations in the General tab of my target fixed it for me.

Same problem here. I would really appreciate any efforts of Apple to document what these kind of error messages mean.

Re A: It seems that this is the rather buggy focus system on Catalyst. Basically that log entry means that your app technically has lost the focus – though there should no reason for it. However, certain drag and drop functions or SwiftUI buttons cease to function then, which makes part of your UI unresponsive.

This is a complete mess. It can not be controlled, and documentation of this use case is pretty nonexistent. I'm tying to use an SwiftUI framework on Mac that has many dependencies to UIColor, so Mac Catalayst is the only way to go. Trying to get that running with the Document based App template is a total mess, and the focus issue complete destroys the interactivity of the interface randomly. Drag operations seem to be particularly vulnerable.

This seems to be an issue of the underlying PDF document. I find the same error message in specific documents that also seem to abort the rendering process. Nonetheless, I would be happy to learn more about that error message, and especially how to avoid it in PDF creation.