I found this explanation very useful in the context of debugging an off-by-one-day bug in my crossword app. It's a classic scenario where crosswords are referenced by date but without a specific time, except that the date is usually reckoned by the time zone of the host publication. I thought I would share an example of how I'm addressing the issue using the defaultDate technique, but generalizing it to choose a "middle of the day" time that should work with whatever time zone (Quinn's example uses a fixed relative time interval that is specific to Sao Paolo). Given a date formatter that already has the desired time zone set on it: var midDayComponents = DateComponents(hour: 12) midDayComponents.calendar = Calendar(identifier: .gregorian) midDayComponents.timeZone = dateFormatter.timeZone dateFormatter.defaultDate = midDayComponents.date It seems that all you need is an hour, a calendar, and a time zone to come up with a suitably mid-day date. I hope this helps somebody!

I continue to see this issue as well, including with the new 5.1 beta today. I think the root of the problem is the way Xcode evidently collects inferred library linkage for dependent Swift Packages. At least, that's one easy scenario to reproduce the bug with. @eskimo : I filed FB13229994 with a simple example project demonstrating (I hope) the issue.

It appears that adding -Wl,-no_warn_duplicate_libraries to "Other Linker Flags" will quiet the warnings.

I wrote extensively about the issue with the warnings, how to suppress them, and how to conditionalize the suppression to only apply to Xcode 15: https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/ https://indiestack.com/2023/10/conditional-xcode-build-settings/ Hope that helps somebody!

From the Xcode 15 Release Notes: Fixed: Resolved an issue where the “Manage version and build number” distribution option in Xcode and Xcode Cloud overwrote the version and build number of framework dependencies in apps. When distributing an app, framework dependencies retain their original version and build numbers. (106869375) So it seems the change was intentional, presumably because other people found it problematic that Xcode was overwriting their framework's Info.plist values. If you have a framework dependency that doesn't include version information it's probably a good idea to file a bug with them to ask them to add the pertinent values.

I was able to get this working just now with a simple programmatic demo: struct ContentView: View { var body: some View { VStack { RealityView { content in let sphereResource = MeshResource.generateSphere(radius: 0.05) let myMaterial = SimpleMaterial(color: .blue, roughness: 0, isMetallic: true) let myEntity = ModelEntity(mesh: sphereResource, materials: [myMaterial]) var collision = CollisionComponent(shapes: [.generateSphere(radius: 0.05)]) collision.filter = CollisionFilter(group: [], mask: []) myEntity.components.set(collision) let input = InputTargetComponent(allowedInputTypes: .all) myEntity.components.set(input) let hoverComponent = HoverEffectComponent() myEntity.components.set(hoverComponent) content.add(myEntity) } } .frame(width: 800, height: 800) .padding(30) .background(.black) } } Maybe if you can get this simple example working it will help you see how yours differs. Daniel

I have discovered a system database at: /var/db/SystemPolicyConfiguration/ExecPolicy Which seems to contain the pertinent provenance information. I am hoping there is a command line tool that will reset values in this database so that I don't have to go wild and try hacking the file myself. But this gives me a lead at least! I'll try it in a VM first...