Hey, Maybe someone can explain me why NSLayoutManager is giving me "unstable" layout? It's like it decides to include line-height-multiple of 1.2 sometimes: We're doing some custom text rendering and if I change font size by a bit (or other property), then suddenly there is this extra text spacing. What we noticed so far is that there is something special about the first font that was set on NSTextStorage, in that case text has no extra spacing. Once you change it to slightly modified font else - the extra spacing is introduced. It's not NSParagraphStyle.lineHeightMultiple - if I set it to something non default then it acts as extra, but doesn't solve the "layout instability" issue. Any clue what's causing this? or how to make it to be stable?

Short version: Is it possible to do the expensive parts of setting UITextView attributedText on a background queue in advance of the UITextView main thread setup? Long version: Setting attributedText on UITextView is expensive, and UILabel is not an option for us. Is there a way to create a text container and layout manager ourselves in order to perform the expensive work on another queue in advance of setting up the UITextView? Ideally we wouldn’t need to have the layout manager draw a bitmap that we show instead of the UITextView altogether. We’re currently calling the layout manager’s ensureLayout(..) function on a background queue but not seeing an improvement in the main thread performance of setting the attributedText on the UITextView. Does ensureLayout(..) not compute and cache the layout work? Or is the layout work not the expensive part of setting attributed text?

I am trying to add custom attributes on-the-fly. To make it work, I subclassed NSTextLayoutFragment, and overrode .textLineFragments property to return custom made NSTextLineFragment objects. But if I override it, TextKit2 no longer render the text and selection also doesn't work. It's same even if provide NSTextLineFragment with exactly same properties (attributed string and range). In WWDC 22 video, you told me that NSTextLayoutFragment and NSTextLineFragment are all immutable and have value semantics. But it doesn't work with different object, therefore seems still have very strong reference semantics. How to make it work with custom attributes? P.S. I also reported this as a feedback -- https://feedbackassistant.apple.com/feedback/12443016

I've been working with UITextView and TextKit 2, which became the default text engine since iOS 16, and I've encountered performance issues when handling very large text documents. Even on iPhone 14 Pro, I've noticed stuttering and frame drops when scrolling through the text view containing a large amount of text. To reproduce the issue, you can use the following code: // In iOS 16 let textView = UITextView() textView.text = "some really large string (say 1 million characters)" The scrolling performance in this scenario is not smooth. However, if you switch to TextKit 1 by accessing the layoutManager property, the performance significantly improves: // In iOS 16 let textView = UITextView() let _ = textView.layoutManager // this enables the compatibility mode textView.text = "some really large string (say 1 million characters)" With this code, scrolling remains smooth even with large text documents. It's very disappointing to see TextKit 2 performing worse than TextKit 1, even though Apple claims TextKit 2 has significantly improved performance with noncontiguous layout. Furthermore, the sample code for TextKit 2, available here, crashes when handling very large text due to excessive memory usage. Has anyone else experienced similar performance issues with TextKit 2, and are there any potential solutions or workarounds to improve the performance?

The way NSTextView is built it's inevitable to use NSTextStorage with TextKit2, however the NSAttributedString uses NSRange vs the TextKit2 family uses NSTextRange for text location, etc. What I struggle with is the relation between these two. I didn't find a convenient translation between these two. Is NSAttributedStrint NSRange length=1 equal to NSTextRange offset 1? I think it's not (at least it's not necessarily true for every NSTextContentManager. So my question is, given a NSTextRange, what is the corresponding NSRange in NSTextContentStorage.attributedString

I'm trying to implement custom NSTextContentManager and use it with NSTextView, however it seems that NSTextView expect NSTextContentStorage all the time. final class MyTextContentManager: NSTextContentManager { // ... } It's added to layout manager, and NSTextView instance finds it properly: let textContentManager = MyTextContentManager() textContentManager.addTextLayoutManager(textLayoutManager) however, when I use it, I see errors at: [MyTextContentManager textStorage]: unrecognized selector sent to instance 0x600003d84870 the textStorage property is part of NSTextStorageObserving, that is not NSTextContentManager interface. It looks like NSTextView is not ready to work with custom NSTextContentManager. What did I miss?

In the "old" TextKit, page-based layout is accomplished by providing an array of NSTextContainers to NSLayoutManager, each with its own NSTextView. TextKit 2, NSTextLayoutManager allows only a single text container. Additionally, NSTextParagraph seems to be the only concrete NSTextElement class. Paragraphs often need to break across page boundaries. How would one implement page-based layout in TextKit 2?

I've a custom UIView to render a large piece of text using CATiledLayers. My draw(rect:) implementation is quite simple: override func draw(_ rect: CGRect) { 	let range = layoutManager.glyphRange(forBoundingRect: rect, in: textContainer) 	layoutManager.drawBackground(forGlyphRange: range, at: .zero) 	layoutManager.drawGlyphs(forGlyphRange: range, at: .zero) } This code works without any issue on iOS 13, but fails with a crash on iOS 14 simulator: Thread 9: EXC_BAD_ACCESS (code=1, address=0x28) #0 0x00007fff2396a3f5 in _NSLayoutTreeMoveToGlyphIndex () I can see that draw(rect:) is being called from different threads in both iOS 13 and 14. However the EXC_BAD_ACCESS has never happened so far in iOS 13. I wonder whether this is a behaviour change in iOS 14 or an issue. If this is a change in NSLayoutManager, then is it still possible to use CATiledLayer to render large amount of text in coordination with NSLayoutManager?