NSTextLayoutManager.usageBoundsForTextContainer gives me a wildly inacurrate (much too big) height, and enumerating the documentRange.endLocation Y coordinate in reverse gives me a too small height. Any workarounds for these issues yet? I can't get any reasonable/reliable text height estimation from NSTextLayoutManager. And enumerating in a forward direction is not possible, since if you have lets say 10000 lines, this will destroy performance for a non-contiguous text view since we are always forcing layout of the complete text.

Really? I can't believe nobody has this issue. It literally still happens just by returning false for some paragraphs from textContentManager(:shouldEnumerate:options:) -> Bool

Could it have something to do with region availability? I have my app available in Germany and Austria - the subscription was available worldwide. As soon as I changed the subscriptions availalbe regions to the same 2, the subscription loaded. Don't know if it was a coincidence or not.

I have the same problem with Apples default "SubscriptionStoreView". Did anyone resolve this?

+1

Can't say for iOS, but since it shares the same TextKit codebase as macOS, I can say that scrolling performance degrades significantly above ~3000 lines. 10k lines is an absolute nightmare. That being said, it seems to matter if a text view has line wrap or not. If it has no linewrap, the performance is significantly worse - which is ironic since you would imagine the layout can just assume fixed line heights.

Found a better way yet? Having the same problem.

I refuse to use Feedback Assistant anymore, out of the ~50 issues I filed there exactly 0 where fixed or even replied to. Even some 3 or 4 year old reports are still not fixed and the issue persists to this day.

I have the same problem with Sonoma / Xcode 15. It's quite annoying since I don't even need anything Metal related.

+1 M2 Pro Mini, no update

Same issue here. I see "Testing..." in the Xcode statusbar but it does nothing. It seems to work when I turn off "Execute in parallel".

Have you found a solution for this? Might it just be that the sandbox environment is offline?

Apple asleep at the wheel. What else is new.

It worked for a while, now it is back to being broken... can't submit again.

The submit issue asside, seems production builds are extremely unstable. I have never seen so many crashes with nonsensical stack traces since we deployed swift concurrency in our retail build. This thing seems to be alpha at most.