I think we are supposed to override managedObjectContext to implement this. When NSPersistentDocument needs the coordinator it gets it goes via this property.

Thank you for the quick answer!

Can you elaborate on why a 4k alignment in the section header can cause the linker to insert 4k fill bytes? The symbol (Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a) after the 4k of fill bytes at address 0x100158c40 is certainly not 4k aligned. If anything, I would expect the linker to fill in less than 4k filler bytes, so that the symbol is 4k aligned. What is the linker trying to achieve here?

Also note that this occurrence of 4k filler bytes is placed in the middle of the __text section of one input object file; I would expect the section alignment to be used when multiple sections of the same kind but from different object files are concatenated.

Furthermore, why are earlier versions of ld64 produce a working binary with the same input?

As a side note, if I bump the section alignment to 16k this sequence of filler bytes before the symbol Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a disappears, and the emitted binary works with the latest available ld64 version.

I would really love to understand the behaviour around this.

I’ve noticed that the bug doesn’t happen when I run ALL target unit tests. It only happens when I run class tests or a specific test.

Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

The __text section in helloworld-unaligned-ptrs.o is 4KB aligned. So, when linked with other code, ld will attempt to align it, which means it will use fill bytes, in this case they are NOPs.

This issue when working for a corporation with a proxy is very annoying, and compiling libgit2.dlyb is no longer an option because the library is signed and XCode wont load it anymore.

As of now, it falls to Apple to fix this, and respect the proxy settings set in the OS.

Something that was not mentioned is that DSC works on M1 MBP, but doesn't work on the 2019 MBP. So this is specifically impacting the Intel stack.

Related thread on apple/swift-package-manager: https://github.com/apple/swift-package-manager/issues/4581

This is still an issue with Monterey 12.6.2.

Xcode 14.1 fixed the issues. Other issues are from third party libraries packaging.

Thanks, I modified the sample project to use NavigationStack and that appears fine. However, when I tried to use NavigationSplitView there is a table row deselection bug. I'll submit that as another feedback however I thought I would attach the project and a screen-capture so you can see it.

https://youtube.com/shorts/On_8alWwox8?feature=share

Thanks for your feedback. This looks like an issue that you need to resolve.

And, this can be resolved by using the new Navigation APIs to avoid the view identity issues described.

Please close this report if resolved, or let us know if still an issue for you.

Thank you.

I’ve attached a sample project which reproduces this bug.

The same is also available on Github: https://github.com/dezinezync/FB11739659

Thank you, Nikhil.

Associated Developer Forums Post - https://developer.apple.com/forums/thread/719444

H4sIAD1ZaGMCA1POzEvOKU1JVbApLknJzNfLsOPiKsvPTFFw00jOSCzSUijWVKjmUlAoLijKzCtJ0yjWUVBS0rTmquUCAAIitqQ6AAAA

Associated Developer Forum post - https://developer.apple.com/forums/thread/718738

This was fixed by setting the text attributes on all control states, but the described behavior is still unexpected when only handling the normal control state.

It's been some time on this, Apple replies stating to "Thanks for your patience, and your feedback. We believe this issue is resolved. Please test with the latest watchOS 8 beta 3" I've only just retested now on WatchOS 9 and iOS 16 and revisited this code using Xcode Version 14.1 (14B47b) and this issue has indeed been fixed.

Still buggy in iOS 16

After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue:

We can't reproduce this issue internally. Using an iOS 16 SDK Xcode, we built and run the app on an iOS 15.5 device, and the HUD comes up for the app (showing two key commands) rather than for the system.

If this issue does occur, it’s probably a SpringBoard issue where it doesn’t give the app keyboard focus correctly. However, that would be a bug on iOS 15.5, not on iOS 16, and it's highly unlikely we'll put in keyboard focus bug fixes for iOS 15. Thanks!

Thank you! Adding PURE_INSTRUCTIONS indeed fixed the issue for us.

PS: Please update https://github.com/apple-opensource/ld64 :-)