Fatal Exception: NSInternalInconsistencyException 0 CoreFoundation 0x2d5ec __exceptionPreprocess 1 libobjc.A.dylib 0x31244 objc_exception_throw 2 Foundation 0x8b58b8 -[NSUndoManager endUndoGrouping] 3 Foundation 0x279154 __NSFirePerformWithOrder 4 CoreFoundation 0x21894 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION 5 CoreFoundation 0x213e8 __CFRunLoopDoObservers 6 CoreFoundation 0x75cf8 __CFRunLoopRun 7 CoreFoundation 0xc8274 CFRunLoopRunSpecific 8 GraphicsServices 0x14c0 GSEventRunModal 9 UIKitCore 0x3ee77c -[UIApplication _run] 10 UIKitCore 0x14e64 UIApplicationMain 11 Glip 0x70398 main + 13 (main.swift:13) 12 ??? 0x1c060cde8 (Missing)

In iOS 18, using TextKit to calculate the height of attributed strings is inaccurate. The same method produces correct results in systems below iOS 18. - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view. UITextView *textView = [[UITextView alloc] initWithFrame:CGRectMake(20, 40, 100, 0)]; textView.editable = NO; textView.scrollEnabled = NO; textView.textContainerInset = UIEdgeInsetsMake(0, 0, 0, 0); textView.textContainer.lineFragmentPadding = 0; textView.backgroundColor = [UIColor lightGrayColor]; [self.view addSubview:textView]; NSMutableAttributedString *attributedString = [[NSMutableAttributedString alloc] initWithString:@"陈家坝好吃的撒海程邦达不差大撒把传达是吧才打卡吃吧金卡多措并举哈不好吃大杯茶十八次是吧"]; NSMutableParagraphStyle *paragraphStyle = [[NSMutableParagraphStyle alloc] init]; paragraphStyle.lineSpacing = 4; [attributedString addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, attributedString.length)]; [attributedString addAttribute:NSFontAttributeName value:[UIFont systemFontOfSize:16] range:NSMakeRange(0, attributedString.length)]; [attributedString addAttribute:NSForegroundColorAttributeName value:[UIColor redColor] range:NSMakeRange(0, attributedString.length)]; textView.attributedText = attributedString; CGFloat height = [self test:attributedString]; textView.frame = CGRectMake(20, 40, 100, height); } - (CGFloat)test:(NSAttributedString *)attString { NSTextStorage *textStorage = [[NSTextStorage alloc] initWithAttributedString:attString]; NSLayoutManager *layoutManager = [[NSLayoutManager alloc] init]; [textStorage addLayoutManager:layoutManager]; NSTextContainer *textContainer = [[NSTextContainer alloc] initWithSize:CGSizeMake(100, CGFLOAT_MAX)]; textContainer.lineFragmentPadding = 0; [layoutManager addTextContainer:textContainer]; [layoutManager ensureLayoutForTextContainer:textContainer]; CGFloat height = [layoutManager usedRectForTextContainer:textContainer].size.height; return ceil(height); }

In iOS 18, using TextKit to calculate the height of attributed strings is inaccurate. The same method produces correct results in systems below iOS 18. - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view. UITextView *textView = [[UITextView alloc] initWithFrame:CGRectMake(20, 40, 100, 0)]; textView.editable = NO; textView.scrollEnabled = NO; textView.textContainerInset = UIEdgeInsetsMake(0, 0, 0, 0); textView.textContainer.lineFragmentPadding = 0; textView.backgroundColor = [UIColor lightGrayColor]; [self.view addSubview:textView]; NSMutableAttributedString *attributedString = [[NSMutableAttributedString alloc] initWithString:@"陈家坝好吃的撒海程邦达不差大撒把传达是吧才打卡吃吧金卡多措并举哈不好吃大杯茶十八次是吧"]; NSMutableParagraphStyle *paragraphStyle = [[NSMutableParagraphStyle alloc] init]; paragraphStyle.lineSpacing = 4; [attributedString addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, attributedString.length)]; [attributedString addAttribute:NSFontAttributeName value:[UIFont systemFontOfSize:16] range:NSMakeRange(0, attributedString.length)]; [attributedString addAttribute:NSForegroundColorAttributeName value:[UIColor redColor] range:NSMakeRange(0, attributedString.length)]; textView.attributedText = attributedString; CGFloat height = [self test:attributedString]; textView.frame = CGRectMake(20, 40, 100, height); } - (CGFloat)test:(NSAttributedString *)attString { // 创建 NSTextStorage 并设定文本内容 NSTextStorage *textStorage = [[NSTextStorage alloc] initWithAttributedString:attString]; // 创建 NSLayoutManager 并关联 NSTextStorage NSLayoutManager *layoutManager = [[NSLayoutManager alloc] init]; [textStorage addLayoutManager:layoutManager]; // 创建 NSTextContainer 并设定其属性 NSTextContainer *textContainer = [[NSTextContainer alloc] initWithSize:CGSizeMake(100, CGFLOAT_MAX)]; textContainer.lineFragmentPadding = 0; [layoutManager addTextContainer:textContainer]; // 强制布局管理器计算布局 [layoutManager ensureLayoutForTextContainer:textContainer]; // 获取文本内容所占的高度 CGFloat height = [layoutManager usedRectForTextContainer:textContainer].size.height; // 返回四舍五入高度 return ceil(height); }

I have added an custom attribute for a paragraph using the below method textStorage.addAttribute(.customCase, value: "checkList", range: paragraphRange) When I insert some text in between the text which contains the custom attribute, that text is not inheriting/propagating the custom attribute of existing paragraph text Old Text : - This is a test New Text : - This is "some new" a test The inserted part is not getting the custom attribute of the old text, Can I know why it's happening, Is it some textKit2's behaviour.

I am developing a library for RichTextEditor for SwiftUI, and I am facing issues with implementing NSParagraphStyle related features like nested bullet lists and text alignment. I have searched a lot and personally feel that the documentation is not enough on this topic, so here I want to discuss how we can achieve the nested list with UI/NSTextView and natively available NSTextList in NSParagraphStyle.textLists. The problem is I am not able to understand how I can use this text list and how to manage adding list and removing list with my editor I have seen code that work adding attributes to each string and then merge them, but I don't want that, I want to add/update/remove attributes from selected text and if text is not selected then want to manage typing attributes to keep applied attributes to current position

I have NsTextList and it has [NsTextListElement], I want to replace an NsTextListElement with other element like NsTextParagraph or NstextListElement or an AttributedString. For some reason the below method is not working at all. And I couldn't find any alternate way of replacing the elements textLayoutManager.replaceContents(in: element.elementRange, with: NSAttributedString(string: "happy"))

When user enters in a textfield, is the input of textfield gets stored in a String ? If yes, then String in swift being immutable, as user keeps on typing does new memory for storing that text gets allocated with each key stroke ? And when we read users input by using delegate method textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) from textfield.text, we get users input in a String. Is it same storage as used by textfield for storing the user input on key stroke or is it some other storage with copy of the user's input in it? Or is UItextfield using a diffrent data structure (buffer) for storing the user input and when we do textfield.text, it gives a copy of data stored in original buffer?

I'm seeing a discrepancy in the metrics of the "New York" system font returned from various Macs. Here's a sample (works well in Playgrounds): import Cocoa let font = NSFont(descriptor: .preferredFontDescriptor(forTextStyle: .body).withDesign(.serif)!, size: NSFont.systemFontSize)! print("\(font.fontName) \(font.pointSize)") print("ascender: \(font.ascender)") let layoutManager = NSLayoutManager() print("lineHeight: \(layoutManager.defaultLineHeight(for: font))") When I run this on multiple Macs, I get two types of different results. Some – most Macs – report this: .NewYork-Regular 13.0 ascender: 12.3779296875 lineHeight: 16.0 However, when I run on my own Mac (and also on the one of a colleague), I get this instead: .NewYork-Regular 13.0 ascender: 14.034145955454255 lineHeight: 19.0 It's clearly the same font in the same point size. Yet the font has different metrics, causing a layout manager to also compute a significantly different line height. So far I've found out that neither CPU generation/architecture nor macOS version seem to play a role. This issue has been reproducible since at least macOS 14. Having just migrated to a new Mac, the issue is still present. This does not affect any other system or commonly installed font. It's only New York (aka the serif design). So I assume this must be something with my setup. Yet I have been unable to find anything that may cause this. Anybody have some ideas? Happy to file a bug report but wanted to check here first.

I'm working on integrating the new format panel shown in the WWDC24 session "What's New in UIKit" under the Text Improvements section. So far, I've implemented long-press functionality on a text passage, allowing the editing options to appear. From there, you can go to Format > More..., which successfully opens the new format panel. However, I would also like to add a button to programmatically display this format panel—similar to how the Apple Notes app has a button in the keyboard toolbar to open it. Does anyone know how to achieve this? Here's my current code for the text editor (I've enabled text formatting by setting allowsEditingTextAttributes to true): struct TextEditorView: UIViewRepresentable { @Binding var text: String func makeCoordinator() -> Coordinator { Coordinator(self) } func makeUIView(context: Context) -> UITextView { let textEditorView = UITextView() textEditorView.delegate = context.coordinator textEditorView.allowsEditingTextAttributes = true return textEditorView } func updateUIView(_ uiView: UITextView, context: Context) { uiView.text = text } class Coordinator: NSObject, UITextViewDelegate { var parent: TextEditorView init(_ uiTextView: TextEditorView) { self.parent = uiTextView } func textViewDidChange(_ textView: UITextView) { self.parent.text = textView.text } } } Thanks in advance for any guidance!

The UITextView.allowedWritingToolsResultOptions has no effect to how "Writing Tools" feature works. When it is set to empty, it still offer all options in the Writing Tools popup dialog. The result is that it is not possible to limit output results to eg. only plain text, or disable tables in output. let textView = UITextView() textView.isEditable = true textView.writingToolsBehavior = .complete textView.allowedWritingToolsResultOptions = [] resulting Writing Tools has all options available. I Tested with TextKit1 and TextKit 2 setup. tested on iPadOS 18.1 beta (22B5069a) Report: FB15429824

With the upcoming launch of Apple Intelligence and Writing Tools, we've been forced to migrate our text editing app to TextKit 2. As soon as we released the update, we immediately got complaints about incorrect selection behaviour, where the user would tap a word to begin editing, but the caret would be shown in an undefined location, often dozens of paragraphs below the selected content. To reproduce: Create a UITextView backed by a standard TextKit 2 stack and a large amount of text (50,000+ words) - see sample project below Scroll quickly through the text view (at least 20% of the way down) Tap once to select a position in the document. Expected: The caret appears at the location the user tapped, and UITextView.selectedRange is the range of the text at the location of the tap. This is the behaviour of TextKit 1 based UITextViews. Actual: The caret is positioned at an undefined location (often completely off screen), and the selectedRange is different to the range at the location of the tap, often by several thousand. There is no pattern to the magnitude of the discrepancy. This incorrect behaviour occurs consistently in the sample project on the simulator, but you may need to hide the keyboard by pulling down, then repeat steps 2-3 a few times. This happens on iPhone and iPad, and on iOS 17, 18, and 18.1. Do you have any insight into why this might be happening or how to work around this issue? Sample code is here: https://github.com/nathantesler/textkit2-issue/tree/master

In the WWDC22 talk "What's new in TextKit and text views" (https://developer.apple.com/videos/play/wwdc2022/10090?time=408), it was announced (at minute 6:45) that TextKit 2 & NSTextList is supposed to be working on both UIKit and AppKit. While NSTextLists are correctly rendering on iOS, they are not working on macOS. The paragraphs aren't inset and the numbers/bullets do not render in front of the list items. Any help? let textView = NSTextView(frame: self.view.bounds) textView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(textView) let safeArea = view.safeAreaLayoutGuide NSLayoutConstraint.activate([ textView.topAnchor.constraint(equalTo: safeArea.topAnchor), textView.bottomAnchor.constraint(equalTo: safeArea.bottomAnchor), textView.leadingAnchor.constraint(equalTo: safeArea.leadingAnchor), textView.trailingAnchor.constraint(equalTo: safeArea.trailingAnchor) ]) let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.textLists = [NSTextList(markerFormat: NSTextList.MarkerFormat("{decimal}."), options: 0)] let attributedText = NSMutableAttributedString("Item 1\nItem 2\nItem 3\nItem 4f") attributedText.addAttribute(.paragraphStyle, value: paragraphStyle, range: NSRange(location: 0, length: attributedText.length)) textView.textStorage?.setAttributedString(attributedText)

Based on this TextKit 2 demo project I thought that I could implement syntax highlighting by parsing syntax block tokens (e.g. comments like <!-- --> or /* */) in processEditing and storing their locations, and then actually applying the rendering with NSTextContentStorageDelegate in textContentStorage(_:textParagraphWith:) by checking the location of each paragraph against the store of syntax tokens. This sort of works except that the rendering is only updated for paragraphs which are changed. Is there a way to trigger NSTextContentStorage to re-fetch paragraphs in a given range? Or is this a totally misguided approach to the problem?

Am I missing something or is there anything anywhere about Writing Tools with SwiftUI Text and other objects: https://developer.apple.com/wwdc24/10168 This entire talk seems to talk about UIKit and AppKit? Just making sure I am not missing something obvious...

UITextView erroneously overrides string attributes when applying spellchecker annotation attributes. It doesn't need any particular setting. Default UITextView instance with attributed text let textView = UITextView(usingTextLayoutManager: true) textView.spellCheckingType = .yes Once spellcheck attributes get applied, other attributes like foreground color get applied to the misspelled words. This behavior happens only on Mac Catalyst, and started to appear on macOS 14 or newer. Please check the Xcode project that demonstrates the issue https://github.com/user-attachments/files/16689336/TextEditor-FB14165227.zip Open TextEditor project Select "My Mac (Mac Catalyst)" build destination Run the project. A window with a text area should appear Select the whole text (either using mouse or keyboard command+a) Observe how foregroundColor changes to text (this is the issue) That eventually led to crash 💥 This bug is reported to Apple FB14165227

Instead of implementing a textview from scratch (UITextInput it a lot of work/boilerplate) It makes sense for me to subclass UITextView. However, when subclassing it seems this is limited to TextKit 1 only, I get an assertion failure: *** Assertion failure in -[_UITextKit1LayoutController initWithTextView:textContainer:], _UITextKit1LayoutController.m:72 I thought I would just need to call the super init: super.init(usingTextLayoutManager: true) But this isn't a designated initialiser: Must call a designated initializer of the superclass 'UITextView' Is there a way to do this and override the layout manager so that it uses TextKit 2 in the subclass? (My aim is to then draw the fragments manually using TextKit2 to get a custom layout while ultimately using all of the UITextView implementation as 99% of it is what I want - other than custom drawing of text fragments). My code is below: class DocumentTextView: UITextView { private let _textLayoutManager = NSTextLayoutManager() private var textContentStorage: NSTextContentStorage { textLayoutManager!.textContentManager as! NSTextContentStorage } override var textLayoutManager: NSTextLayoutManager? { _textLayoutManager } init() { let textContainer = NSTextContainer(size: .zero) super.init(frame: .zero, textContainer: textContainer) _textLayoutManager.textContainer = textContainer textContentStorage.attributedString = NSAttributedString(string: text, attributes: [ .foregroundColor: UIColor.label, ]) textContentStorage.addTextLayoutManager(_textLayoutManager) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } }

I'm building a SwiftUI app with a UITextView subclass, and it seems that the software keyboard doesn't trigger the pressesBegan or pressesEnded functions of UITextView. With a hardware keyboard, pressesBegan works as expected, allowing us to intercept key presses in our subclass. I can't find any documentation about this, or any other forum posts (here or on Stack Overflow) that talk about a discrepancy between software and hardware keyboard behaviors, and I can't believe this is an intended behavior. Our app is a SwiftUI app, in case that's relevant. Does anyone have any guidance? Is this a bug or am I not understanding this API? Any information or work arounds would be greatly appreciated. I've made a sample project that demonstrates this issue, which you can grab from GitHub at https://github.com/nyousefi/KeyPressSample. To see this in action, run the sample project and start pressing keys. The hardware keyboard will print the key press at the top of the screen (above the text view), while the software keyboard won't.

How can we performantly scroll to a target location using TextKit 2? Hi everyone, I'm building a custom text editor using TextKit 2 and would like to scroll to a target location efficiently. For instance, I would like to move to the end of a document seamlessly, similar to how users can do in standard text editors by using CMD + Down. Background: NSTextView and TextEdit on macOS can navigate to the end of large documents in milliseconds. However, after reading the documentation and experimenting with various ideas using TextKit 2's APIs, it's not clear how third-party developers are supposed to achieve this. My Code: Here's the code I use to move the selection to the end of the document and scroll the viewport to reveal the selection. override func moveToEndOfDocument(_ sender: Any?) { textLayoutManager.ensureLayout(for: textLayoutManager.documentRange) let targetLocation = textLayoutManager.documentRange.endLocation let beforeTargetLocation = textLayoutManager.location(targetLocation, offsetBy: -1)! textLayoutManager.textViewportLayoutController.layoutViewport() guard let textLayoutFragment = textLayoutManager.textLayoutFragment(for: beforeTargetLocation) else { return } guard let textLineFragment = textLayoutFragment.textLineFragment(for: targetLocation, isUpstreamAffinity: true) else { return } let lineFrame = textLayoutFragment.layoutFragmentFrame let lineFragmentFrame = textLineFragment.typographicBounds.offsetBy(dx: 0, dy: lineFrame.minY) scrollToVisible(lineFragmentFrame) } While this code works as intended, it is very inefficient because ensureLayout(_:) is incredibly expensive and can take seconds for large documents. Issues Encountered: In my attempts, I have come across the following two issues. Estimated Frames: The frames of NSTextLayoutFragment and NSTextLineFragment are approximate and not precise enough for scrolling unless the text layout fragment has been fully laid out. Laying out all text is expensive: The frames become accurate once NSTextLayoutManager's ensureLayout(for:) method has been called with a range covering the entire document. However, ensureLayout(for:) is resource-intensive and can take seconds for large documents. NSTextView, on the other hand, accomplishes the same scrolling to the end of a document in milliseconds. I've tried using NSTextViewportLayoutController's relocateViewport(to:) without success. It's unclear to me whether this function is intended for a use case like mine. If it is, I would appreciate some guidance on its proper usage. Configuration: I'm testing on macOS Sonoma 14.5 (23F79), Swift (AppKit), Xcode 15.4 (15F31d). I'm working on a multi-platform project written in AppKit and UIKit, so I'm looking for either a single solution that works in both AppKit and UIKit or two solutions, one for each UI framework. Question: How can third-party developers scroll to a target location, specifically the end of a document, performantly using TextKit 2? Steps to Reproduce: The issue can be reproduced using the example project (download from link below) by following these steps: Open the example project. Run the example app on a Mac. The example app shows an uneditable text view in a scroll view. The text view displays a long text. Press the "Move to End of Document" toolbar item. Notice that the text view has scrolled to the bottom, but this took several seconds (~3 seconds on my MacBook Pro 16-inch, 2021). The duration will be shown in Xcode's log. You can open the ExampleTextView.swift file and find the implementation of moveToEndOfDocument(_:). Comment out line 84 where the ensureLayout(_:) is called, rerun the app, and then select "Move to End of Document" again. This time, you will notice that the text view moves fast but does not end up at the bottom of the document. You may also open the large-file.json in the project, the same file that the example app displays, in TextEdit, and press CMD+Down to move to the end of the document. Notice that TextEdit does this in mere milliseconds. Example Project: The example project is located on GitHub: https://github.com/simonbs/apple-developer-forums/tree/main/how-can-we-performantly-scroll-to-a-target-location-using-textkit-2 Any advice or guidance on how to achieve this with TextKit 2 would be greatly appreciated. Thanks in advance! Best regards, Simon

demo code : - (void)drawRect:(CGRect)rect { CGContextRef context = UIGraphicsGetCurrentContext(); // Flip the coordinate system CGContextSetTextMatrix(context, CGAffineTransformIdentity); CGContextTranslateCTM(context, 0, self.bounds.size.height); CGContextScaleCTM(context, 1.0, -1.0); NSDictionary *attrs = @{NSFontAttributeName: [UIFont systemFontOfSize:20], NSForegroundColorAttributeName: [UIColor blueColor], NSUnderlineStyleAttributeName: @(NSUnderlineStyleThick), }; // Make an attributed string NSAttributedString *attributedString = [[NSAttributedString alloc] initWithString:@"Hello CoreText!" attributes:attrs]; CFAttributedStringRef attributedStringRef = (__bridge CFAttributedStringRef)attributedString; // Simple CoreText with CTFrameDraw CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString(attributedStringRef); CGPathRef path = CGPathCreateWithRect(self.bounds,NULL); CTFrameRef frame = CTFramesetterCreateFrame(framesetter,CFRangeMake(0, 0),path,NULL); //CTFrameDraw(frame, context); // You can comment the line 'CTFrameDraw' and use the following lines // draw with CTLineDraw CFArrayRef lines = CTFrameGetLines(frame); CGPoint lineOrigins[CFArrayGetCount(lines)]; CTFrameGetLineOrigins(frame, CFRangeMake(0, 0), lineOrigins); for (int i = 0; i < CFArrayGetCount(lines); i++) { CTLineRef line = CFArrayGetValueAtIndex(lines, i); CGContextSetTextPosition(context, lineOrigins[i].x, lineOrigins[i].y); // CTLineDraw(line, context); // You can comment the line 'CTLineDraw' and use the following lines // draw with CTRunDraw // use CTRunDraw will lost some attributes like NSUnderlineStyleAttributeName, // so you need draw it by yourself CFArrayRef runs = CTLineGetGlyphRuns(line); for (int j = 0; j < CFArrayGetCount(runs); j++) { CTRunRef run = CFArrayGetValueAtIndex(runs, j); CTRunDraw(run, context, CFRangeMake(0, 0)); } } } this code will use CTRunDraw to draw the content , and the underline will draw and show normally in iOS17 & Xcode 15 , But when you build it with XCode16 & iOS18 beta . the underline will be missing .

Hi Apple, I'm implementing a custom text view by conforming to UITextInput and backing it with TextKit2. However, I like the UITextItem feature of the default UITextView. Can I get some guidance on how to reimplement it? Are we looking at overlaying UIMenu buttons? Or some API where I can display a UIMenu at a rect I specify? Hopefully, it is not some kind of private API? Thanks for the help in advance.