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 :-)

Xcode 14.3 UI Test fails to start on iPad device.

seems it gets stuck in this state and 3 retries did not help

An API to set this, albeit in an unwieldy way on an individual Text, is not an available symbol currently in Xcode 14 and remains flagged as "beta" for iOS 15.

https://developer.apple.com/documentation/swiftui/text/speechphoneticrepresentation(_:)

The issue is not reproducing on iOS 16>

Engineering has provided the following information regarding this issue:

The problem is with the GraalVM object file helloworld.o, __TEXT,__text section should be marked with PURE_INSTRUCTIONS attribute, but it’s not:

$ otool -lv helloworld.o

attributes SOME_INSTRUCTIONS EXT_RELOC

You can workaround the problem by compiling an empty source file with clang, e.g., like this:

$ echo "" > dummy.c

$ clang dummy.c -o dummy.o -c -target arm64-apple-macosx12.0

And listing it as the first object file in linker invocation, so this works:

hello_with_objc_selector_stubs: helloworld.o Makefile

$(LD) -o $@ $(LDFLAGS) dummy.o libdarwin_withstubs.a helloworld.o $(LIBS)

The linker assertion is only a side effect of the missing attribute, so on our side we can improve the diagnostics, but you can already proceed with the workaround.

Fixed sometime between iOS 15.7 (on a 6S) and iOS 16.02 (13 Pro). W00t, and thanks cricket 🐜. On the downside (spoiler) I will have to come up with a new QA interview question.

Solved in the latest beta.

It turns out iOS 16 is at fault: iOS 16.1 fixes the problem. Closing feedback.

"Unfortunately, the fix here is nontrivial, and other tasks have taken precedence. This is something we'd still like to resolve, and we’ll be tagging this for a more prioritized fix."

also the issue can be solved by reseting the device; but this is obviously not a good option...