I encountered an issue with UITextView on iOS 18 where, when typing Pinyin, extra Unicode characters such as U+2004 are inserted unexpectedly. This occurs when using a Chinese input method. Steps to Reproduce: 1. Set up a UITextView with a standard delegate implementation. 2. Use a Pinyin input method to type the character “ㄨ”. 3. Observe that after the character “ㄨ” is typed, extra spaces (U+2004) are inserted automatically between the characters. Code Example: class ViewController: UIViewController { @IBOutlet weak var textView: UITextView! override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. } } extension ViewController: UITextViewDelegate { func textView(_ textView: UITextView, shouldChangeTextIn range: NSRange, replacementText text: String) -> Bool { print("shouldChangeTextIn: range \(range)") print("shouldChangeTextIn: replacementText \(text)") return true } func textViewDidChange(_ textView: UITextView) { let currentText = textView.text ?? "" let unicodeValues = currentText.unicodeScalars.map { String(format: "U+%04X", $0.value) }.joined(separator: " ") print("textViewDidChange: textView.text: \(currentText)") print("textViewDidChange: Unicode Scalars: \(unicodeValues)") } } Output: shouldChangeTextIn: range {0, 0} shouldChangeTextIn: replacementText ㄨ textViewDidChange: textView.text: ㄨ textViewDidChange: Unicode Scalars: U+3128 ------------------------ shouldChangeTextIn: range {1, 0} shouldChangeTextIn: replacementText ㄨ textViewDidChange: textView.text: ㄨ ㄨ textViewDidChange: Unicode Scalars: U+3128 U+2004 U+3128 ------------------------ shouldChangeTextIn: range {3, 0} shouldChangeTextIn: replacementText ㄨ textViewDidChange: textView.text: ㄨ ㄨ ㄨ textViewDidChange: Unicode Scalars: U+3128 U+2004 U+3128 U+2004 U+3128 This issue may affect text processing, especially in cases where precise text manipulation is required, such as calculating ranges in shouldChangeTextIn.

In TextKit 1, I can override drawBackground(forGlyphRange:at:) in NSLayoutManager to do custom background drawing. However, I'm not too sure what the designated way of doing background drawing is in TextKit 2. One thing I've tried is to do custom drawing in my own CALayer that's used in the configureRenderingSurface delegate callback, but I'm unsure if we are suppose to use this API and steal the textViewportLayoutController.delegate away from _UITextLayoutcanvasView?

Is there an easy way to allow users to tap on SwiftUI Text elements to highlight specific words e.g. copy ? The .textSelection API works to select an entire block of text however it'd be great to confirm if there is an existing way with Text for individual words or if Apple plan on adding this ability at some point in the future.

in ios it is not same as it in computer there is text:"ยินดี in computer is but in ios it is the fontsize is 16 I tried every font which is in ios and tried copy simsun in windows to ios and create CTFont I draw it using UIGraphics drawString

We are currently trying to adopt the newly introduced find bar in our app. The app: The app is a text editor with a main text view. However it includes nested views (for text like footnotes) that are presented as modal sheets. So you tap on the footnote within the main text, a form sheet is presented with the contents of the footnote ready to be edited. We have an existing search implementation, but are eager to move to the system-provided UI. Connecting the find bar through a custom UIFindSession with our existing implementation is working without any issues. The Problem: Searching for text does not only work in the main text view, but also nested text (like footnotes). Let's say I have a text containing the word "iPhone" both in the main text and the footnote. In our existing implementation, stepping from the search match to the next one would open the modal and highlight the match in the nested text. The keyboard would stay open. With the new UIFindInteraction this is not working however. As soon as a modal form sheet is presented, the find interaction closes. By looking at the stack trace I can see a private class called UIInputWindowController that cleans up input accessory views after the modal gets presented. I believe it is causing the find panel to give up its first responder state. I noticed that opening popovers appears to be working fine. Is there a way to alter the presentation of the nested text so that the view is either not modal or able to preserve the current find session? Or is this unsupported behavior and we should try and look for a different way? The thing that really confuses me is that this appears to work without issue in Notes.app. There the find bar is implemented as well. There are multiple views that can be presented while the find bar is open. Move Note is one of them. The view appears as a modal sheet. It keeps the find bar open and active, though its tint color matches the deactivated one of the main Notes view. The find bar is still functional with the text field being active and the overlay updating in the background. This behavior appears to be a bug in the Notes app, but is exactly what we want for our use case. I attached some images: Two are from the Notes app, two from a test project demonstrating the problem. Opening a modal view closes the find bar there.

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); }

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); }

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)

I have an app that uses UITextView for some text editing. I have some custom operations I can do on the text that I want to be able to undo, and I'm representing those operations in a way that plugs into NSUndoManager nicely. For example, if I have a button that appends an emoji to the text, it looks something like this: func addEmoji() { let inserting = NSAttributedString(string: "😀") self.textStorage.append(inserting) let len = inserting.length let range = NSRange(location: self.textStorage.length - len, length: len) self.undoManager?.registerUndo(withTarget: self, handler: { view in view.textStorage.deleteCharacters(in: range) } } My goal is something like this: Type some text Press the emoji button to add the emoji Trigger undo (via gesture or keyboard shortcut) and the emoji is removed Trigger undo again and the typing from step 1 is reversed If I just type and then trigger undo, the typing is reversed as you'd expect. And if I just add the emoji and trigger undo, the emoji is removed. But if I do the sequence above, step 3 works but step 4 doesn't. The emoji is removed but the typing isn't reversed. Notably, if step 3 only changes attributes of the text, like applying a strikethrough to a selection, then the full undo chain works. I can type, apply strikethrough, undo strikethrough, and undo typing. It's almost as if changing the text invalidates the undo manager's previous operations? How do I insert my own changes into UITextView's NSUndoManager without invalidating its chain of other operations?

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

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.

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?

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

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!

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

Based on the session content, it seems that setting the TextView property writingToolsBehavior = .complete should bring up the writing tools bottom panel view. However, it does not appear to be working. Is this a feature that will be added in a future update, or is there something additional I need to do? Test on: XCode 16.0 beta (16A5171c), iOS Simulator 18.0 Beta, iPhone 11 Pro iOS 18.0 Beta

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)

I have an NSTextLayoutManager set up with NSTextContentStorage and NSTextContainer. To work out the height of the content, I call the method updateContentSizeIfNeeded() which contains the code textLayoutManager.enumerateTextLayoutFragments(from: textLayoutManager.documentRange.endLocation, options: [.reverse, .ensuresLayout]) { layoutFragment in height = layoutFragment.layoutFragmentFrame.maxY return false } The first time this is called, it returns the correct height. Then I add a new character to the start of the NSTextContentStorage like so textContentStorage.performEditingTransaction { storage.replaceCharacters(in: NSRange(location:0, length: 1), with: "a") } textLayoutManager.ensureLayout(for: textLayoutManager.documentRange) textLayoutManager.textViewportLayoutController.layoutViewport() updateContentSizeIfNeeded() This time, the height returned is ~600px too big. The state of the NSTextLayoutFragment is set to layoutAvailable The next time I add a character to textContentStorage using the same code above, the height returned is correct again. I can work around this by calling enumerateTextLayoutFragments from the start of the document and not in reverse, then ignoring all fragments except the last one, but I don't know if that's the correct way to do it, or if I should be doing something else