Manage text storage and perform custom layout of text-based content in your app's views using TextKit.

Posts under TextKit tag

26 Posts

Post

Replies

Boosts

Views

Activity

The NSTextViewDelegate method textViewDidChangeSelection(:) will not fire, while all other text view delegate methods do.
I am trying to implement the NSTextViewDelegate function textViewDidChangeSelection(_ notification: Notification). My text view's delegate is the Coordinator of my NSViewRepresentable. I've found that this delegate function never fires, but any other delegate function that I implement, as long as it doesn't take a Notification as an argument, does fire (e.g., textView(:willChangeSelectionFromCharacterRange:toCharacterRange:), fires and is called on the delegate exactly when it should be). For context, I've verified all of the below: textView.isSelectable = true textView.isEditable = true textView.delegate === my coordinator I can call textViewDidChangeSelection(:) directly on the delegate without issue. I can select and edit text without issues. I.e., the selections are being set correctly. But the delegate method is never called when they are. I am able to add the intended delegate as an observer for the selector textViewDidChangeSelection via NotificationCenter. If I do this, the function executes when it should, but fires for every text view in my view hierarchy, which can number in the hundreds. I'm using an NSLayoutManager, so I figure this should only fire once. I've added a check within my code: func textViewDidChangeSelection(_ notification: Notification) { guard let textView = notification.object as? NSTextView, textView === layoutManager.firstTextView else { return } // Any code I want to execute... } But the above guard check lets through every notification, so, no matter what, my closure executes hundreds of times if I have hundreds of text views, all of them being sent by textView === layoutManager.firstTextView, but once for each and every text view managed by that layoutManager. Does anyone know why this method isn't ever called on the delegate, while seemingly all other delegate methods are? I could go the NotificationCenter route, but I'd love to know why this won't execute as a delegate method when documentation says that it should, and I don't want to have to implement a counter to make sure my code only executes once per selection update. And for more reasons than that, implementing via delegate method is preferable to using notifications for my use case. Thanks for any help!
3
0
257
May ’25
Custom, Markdown autocapitalizationType.
Hi, I've got an app that displays markdown in UITextView / NSTextView. I would like it to behave like Notes app does, that is if user types the line start modifier, e.g: "# " or "> " I would like the keyboard to show a capitalized letters. I've tried looking into overriding insertText - and it breaks the predictive text (can not insert white space). I've tried implementing UITextInputTokenizer but no luck either. Like I said, I see the Notes app does it perfectly, so maybe I'm missing something obvious or there is a way to do it without interrupting the auto-correction and predictive text. Ideally same thing can be applied to the NSTextView as the app support both platforms.
Topic: UI Frameworks SubTopic: UIKit Tags:
0
0
263
May ’25
NSLayoutManager Bug -- layout manager re-laying out overlapping text into the same container.
I've posted a couple times now about major issues I'm having with NSLayoutManager and have written to Apple for code-level support, but no one at Apple has responded to me in more than two weeks. So I'm turning to the community again for any help whatsoever. I'm fairly certain it's a real bug in TextKit. If I'm right about that, I'd love for anyone at Apple to take an interest. And better yet, if I'm wrong (and I hope I am), I'd be incredibly grateful to anyone who can point out where my mistake lies! I've been stuck with this bug for weeks on end. The crux of the issue is that I'm getting what seemed to be totally incompatible results from back to back calls to textContainer(forGlyphAt:effectiveRange:) and lineFragmentRect(forGlyphAt:effectiveRange:withoutAdditionalLayout:)... I'd lay out my text into a fairly tall container of standard page width and then query the layout manager for the text container and line fragment rect for a particular glyph (a glyph that happens to fall after many newlines). Impossibly, the layout manager would report that that glyph was in said very tall container, but that the maxY of its lineFragmentRect was only at 14 points (my NSTextView's isFlipped is true, so that's 14 points measuring from the top down). After investigating, it appears that what is happening under the hood is NSLayoutManager is for some reason laying out text back into the first container in my series of containers, rather than overflowing it into the next container(s) and/or giving me a nil result for textContainer(forGlyphAt:...) I've created a totally stripped down version of my project that recreates this issue reliably and I'm hoping literally anyone at Apple will respond to me. In order to recreate the bug, I've had to build a very specific set of preview data - namely some NSTextStorage content and a unique set of NSTextViews / NSTextContainers. Because of the unique and particular setup required to recreate this bug, the code is too much to paste here (my preview data definition is a little unwieldy but the code that actually processes/parses it is not). I can share the project if anyone is able and willing to look into this with me. It seems I'm not able to share a .zip of the project folder here but am happy to email or share a dropbox link.
7
0
334
May ’25
UITextView's pressesBegan isn't triggered by the software keyboard
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.
3
0
760
May ’25
NSLayoutManager laying out overlapping text into the same NSTextContainer even when there are more containers available.
In summation: I have a nasty bug where my layout manager is laying out text visually overlapping on top of other text, i.e., into a container that it should have left in the rear view as it continues to lay out into ensuing containers. Details below... I'm coding a word processing app with some custom pagination that involves multiple pages, within which there can be multiple NSTextView/NSTextContainer pairs that represent single column or dual column runs of text. I generate pagination data by using a measuring NSLayoutManager. This process ensures that no containers overlap, and that they are sized correctly for their associated ranges of text (i.e., non-overlapping, continuous ranges from a single NSTextStorage). I determine frame sizes by a series of checks, most importantly, by finding the last glyph in a column. Prior to the code below, remainingColumnRange represents the remaining range of my textStorage that is of a consistent column type (i.e., single, left column, or right column). My measuring passes consist of my measuringLayoutManager laying out text into its textContainers, the final of which is an extra overflowContainer (i.e., == measuringLayoutManager.textContainers.last!) which I only use to find the last glyph in the second to last container (measuringContainer, which is thus == measuringLayoutManager.textContainers[count - 2]) let glyphRangeOfLastColumnChar = measuringLayoutManager.glyphRange(forCharacterRange: remainingColumnRange, actualCharacterRange: nil) let lastGlyphIndex = NSMaxRange(glyphRangeOfLastColumnChar) - 1 measuringLayoutManager.ensureLayout(for: measuringContainer) // Not sure if this is necessary, but I've added it to insure I'm getting accurate measurements. if measuringLayoutManager.textContainer(forGlyphAt: lastGlyphOfColumnIndex, effectiveRange: &actualGlyphRangeInContainer) == overflowContainer { actualCharRangeInContainer = measuringLayoutManager.characterRange(forGlyphRange: actualGlyphRangeInContainer, actualGlyphRange: nil) let overflowLoc = actualCharRangeInContainer.location remainingColumnRange = NSRange(location: overflowLoc, length: remainingColumnRange.length - overflowLoc) currentPage += 1 } else { lineFragmentRectForLastChar = measuringLayoutManager.lineFragmentRect(forGlyphAt: lastGlyphIndex, effectiveRange: nil) // Resize measuring container if needed. let usedHeight = lineFragmentRectForLastChar.maxY if usedHeight < measuringContainer.size.height { measuringContainer.size = CGSize(width: measuringContainer.size.width, height: usedHeight) } else if usedHeight == measuringContainer.size.height { currentPage += 1 // we perfectly filled the page } else { // This would be an error case, because all cases should have been handled prior to arriving here. I throw an error. I have never fallen through here. throw MyClass.anError } } // I use the above data to create a PageLayoutItem, which is a struct that has frame data (CGRect/x,y,w,h), a containerIndex (Int), pageNumber (Int), textRange (NSRange), columnType (custom enum). // After this I remove the overflowContainer, and continue to iterate through. This is inefficient but I'm simplifying my code to identify the root issue. I don't explicitly use these containers when done with my pagination process. Rather, I use the PageLayoutItems I have created to generate/resize/remove textContainers/textViews for the UI as needed. My UI-interfacing/generating NSLayoutManager, which is of course assigned to the same NSTextStorage as the measuring layout manager, then iterates through my paginator model class' pageLayoutItems array to generate/resize/remove. I have verified my pagination data. None of my frames overlap. They are sized exactly the same as they should be per my measurement passes. The number of containers/views needed is correct. But here's the issue: My views render the text that SHOULD appear in my final textContainer/textView as visually overlapping the text in my second to last textContainer/textView. I see a garble of text. When I iterate through my UI textContainers, I get this debug print: TextContainer 0 glyphRange: {0, 172} TextContainer 1 glyphRange: {172, 55} TextContainer 2 glyphRange: {227, 100} // this is wrong, final 31 chars should be in container 3 TextContainer 3 glyphRange: {327, 0} // empty range here, odd I have tried setting textContainers for glyph ranges explicitly, via: // Variable names just for clarity here layoutManager.setTextContainer(correctTextView.textContainer!, forGlyphRange: correctGlyphRangeForThisContainer) Debug prints show that I'm setting the right ranges there. But they don't retain. I have tried resizing my final text container to be much larger in case that was the issue. No dice. My final range of text/glyphs still lays out in the wrong container and overlaps the other content laid out there. Any help here?? I've scoured the forums and have been dealing with this bug for two weeks straight with no hope in sight.
4
0
1.1k
May ’25
How do I size a UITextView with scroll disabled?
tl;dr: UITextView does not auto layout when isScrollEnabled = false I have a screen with multiple UITextViews on it, contained within a ScrollView. For each textview, I calculate the height needed to display the entire content in SwiftUI and set it using the .frame(width:height:) modifier. The UITextView will respect the size passed in and layout within the container, but since UITextView is embedded within a UIScrollView, when a user attempts to scroll on the page, often they will scroll within a UITextView block rather than the page. They currently need to scroll along the margins outside of the textview to get the proper behavior. Since I am already calculating the height to display the text, I don't want the UITextView to scroll. However, when I set isScrollEnabled = false, the text view displays in a single long line that gets truncated. I have tried Setting various frame/size attributes but that seems to have zero affect on the layout. Embedding the textView within a UIView, and then sizing the container, but then the textView does not display at all. Setting a fixed size textContainer in the layoutManager but did not work. There's a lot of code so I can't copy/paste it all, but generally, it looks like struct SwiftUITextEditor: View { @State var text: AttributedString = "" var body: some View { ZStack { MyTextViewRepresentable(text: $text) } .dynamicallySized(from: $text) } } struct MyTextViewRepresentable: UIViewRepresentable { @Binding var text: AttributedString let textView = UITextView(usingTextLayoutManager: true) func makeUIView(context: Context) -> UITextView { textView.attributedText = text textView.isScrollEnabled = false } ... }
1
0
255
May ’25
The NSTextViewDelegate method textViewDidChangeSelection(:) will not fire, while all other text view delegate methods do.
I am trying to implement the NSTextViewDelegate function textViewDidChangeSelection(_ notification: Notification). My text view's delegate is the Coordinator of my NSViewRepresentable. I've found that this delegate function never fires, but any other delegate function that I implement, as long as it doesn't take a Notification as an argument, does fire (e.g., textView(:willChangeSelectionFromCharacterRange:toCharacterRange:), fires and is called on the delegate exactly when it should be). For context, I've verified all of the below: textView.isSelectable = true textView.isEditable = true textView.delegate === my coordinator I can call textViewDidChangeSelection(:) directly on the delegate without issue. I can select and edit text without issues. I.e., the selections are being set correctly. But the delegate method is never called when they are. I am able to add the intended delegate as an observer for the selector textViewDidChangeSelection via NotificationCenter. If I do this, the function executes when it should, but fires for every text view in my view hierarchy, which can number in the hundreds. I'm using an NSLayoutManager, so I figure this should only fire once. I've added a check within my code: func textViewDidChangeSelection(_ notification: Notification) { guard let textView = notification.object as? NSTextView, textView === layoutManager.firstTextView else { return } // Any code I want to execute... } But the above guard check lets through every notification, so, no matter what, my closure executes hundreds of times if I have hundreds of text views, all of them being sent by textView === layoutManager.firstTextView, but once for each and every text view managed by that layoutManager. Does anyone know why this method isn't ever called on the delegate, while seemingly all other delegate methods are? I could go the NotificationCenter route, but I'd love to know why this won't execute as a delegate method when documentation says that it should, and I don't want to have to implement a counter to make sure my code only executes once per selection update. And for more reasons than that, implementing via delegate method is preferable to using notifications for my use case. Thanks for any help!
Replies
3
Boosts
0
Views
257
Activity
May ’25
Custom, Markdown autocapitalizationType.
Hi, I've got an app that displays markdown in UITextView / NSTextView. I would like it to behave like Notes app does, that is if user types the line start modifier, e.g: "# " or "> " I would like the keyboard to show a capitalized letters. I've tried looking into overriding insertText - and it breaks the predictive text (can not insert white space). I've tried implementing UITextInputTokenizer but no luck either. Like I said, I see the Notes app does it perfectly, so maybe I'm missing something obvious or there is a way to do it without interrupting the auto-correction and predictive text. Ideally same thing can be applied to the NSTextView as the app support both platforms.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
0
Boosts
0
Views
263
Activity
May ’25
NSLayoutManager Bug -- layout manager re-laying out overlapping text into the same container.
I've posted a couple times now about major issues I'm having with NSLayoutManager and have written to Apple for code-level support, but no one at Apple has responded to me in more than two weeks. So I'm turning to the community again for any help whatsoever. I'm fairly certain it's a real bug in TextKit. If I'm right about that, I'd love for anyone at Apple to take an interest. And better yet, if I'm wrong (and I hope I am), I'd be incredibly grateful to anyone who can point out where my mistake lies! I've been stuck with this bug for weeks on end. The crux of the issue is that I'm getting what seemed to be totally incompatible results from back to back calls to textContainer(forGlyphAt:effectiveRange:) and lineFragmentRect(forGlyphAt:effectiveRange:withoutAdditionalLayout:)... I'd lay out my text into a fairly tall container of standard page width and then query the layout manager for the text container and line fragment rect for a particular glyph (a glyph that happens to fall after many newlines). Impossibly, the layout manager would report that that glyph was in said very tall container, but that the maxY of its lineFragmentRect was only at 14 points (my NSTextView's isFlipped is true, so that's 14 points measuring from the top down). After investigating, it appears that what is happening under the hood is NSLayoutManager is for some reason laying out text back into the first container in my series of containers, rather than overflowing it into the next container(s) and/or giving me a nil result for textContainer(forGlyphAt:...) I've created a totally stripped down version of my project that recreates this issue reliably and I'm hoping literally anyone at Apple will respond to me. In order to recreate the bug, I've had to build a very specific set of preview data - namely some NSTextStorage content and a unique set of NSTextViews / NSTextContainers. Because of the unique and particular setup required to recreate this bug, the code is too much to paste here (my preview data definition is a little unwieldy but the code that actually processes/parses it is not). I can share the project if anyone is able and willing to look into this with me. It seems I'm not able to share a .zip of the project folder here but am happy to email or share a dropbox link.
Replies
7
Boosts
0
Views
334
Activity
May ’25
UITextView's pressesBegan isn't triggered by the software keyboard
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.
Replies
3
Boosts
0
Views
760
Activity
May ’25
NSLayoutManager laying out overlapping text into the same NSTextContainer even when there are more containers available.
In summation: I have a nasty bug where my layout manager is laying out text visually overlapping on top of other text, i.e., into a container that it should have left in the rear view as it continues to lay out into ensuing containers. Details below... I'm coding a word processing app with some custom pagination that involves multiple pages, within which there can be multiple NSTextView/NSTextContainer pairs that represent single column or dual column runs of text. I generate pagination data by using a measuring NSLayoutManager. This process ensures that no containers overlap, and that they are sized correctly for their associated ranges of text (i.e., non-overlapping, continuous ranges from a single NSTextStorage). I determine frame sizes by a series of checks, most importantly, by finding the last glyph in a column. Prior to the code below, remainingColumnRange represents the remaining range of my textStorage that is of a consistent column type (i.e., single, left column, or right column). My measuring passes consist of my measuringLayoutManager laying out text into its textContainers, the final of which is an extra overflowContainer (i.e., == measuringLayoutManager.textContainers.last!) which I only use to find the last glyph in the second to last container (measuringContainer, which is thus == measuringLayoutManager.textContainers[count - 2]) let glyphRangeOfLastColumnChar = measuringLayoutManager.glyphRange(forCharacterRange: remainingColumnRange, actualCharacterRange: nil) let lastGlyphIndex = NSMaxRange(glyphRangeOfLastColumnChar) - 1 measuringLayoutManager.ensureLayout(for: measuringContainer) // Not sure if this is necessary, but I've added it to insure I'm getting accurate measurements. if measuringLayoutManager.textContainer(forGlyphAt: lastGlyphOfColumnIndex, effectiveRange: &actualGlyphRangeInContainer) == overflowContainer { actualCharRangeInContainer = measuringLayoutManager.characterRange(forGlyphRange: actualGlyphRangeInContainer, actualGlyphRange: nil) let overflowLoc = actualCharRangeInContainer.location remainingColumnRange = NSRange(location: overflowLoc, length: remainingColumnRange.length - overflowLoc) currentPage += 1 } else { lineFragmentRectForLastChar = measuringLayoutManager.lineFragmentRect(forGlyphAt: lastGlyphIndex, effectiveRange: nil) // Resize measuring container if needed. let usedHeight = lineFragmentRectForLastChar.maxY if usedHeight < measuringContainer.size.height { measuringContainer.size = CGSize(width: measuringContainer.size.width, height: usedHeight) } else if usedHeight == measuringContainer.size.height { currentPage += 1 // we perfectly filled the page } else { // This would be an error case, because all cases should have been handled prior to arriving here. I throw an error. I have never fallen through here. throw MyClass.anError } } // I use the above data to create a PageLayoutItem, which is a struct that has frame data (CGRect/x,y,w,h), a containerIndex (Int), pageNumber (Int), textRange (NSRange), columnType (custom enum). // After this I remove the overflowContainer, and continue to iterate through. This is inefficient but I'm simplifying my code to identify the root issue. I don't explicitly use these containers when done with my pagination process. Rather, I use the PageLayoutItems I have created to generate/resize/remove textContainers/textViews for the UI as needed. My UI-interfacing/generating NSLayoutManager, which is of course assigned to the same NSTextStorage as the measuring layout manager, then iterates through my paginator model class' pageLayoutItems array to generate/resize/remove. I have verified my pagination data. None of my frames overlap. They are sized exactly the same as they should be per my measurement passes. The number of containers/views needed is correct. But here's the issue: My views render the text that SHOULD appear in my final textContainer/textView as visually overlapping the text in my second to last textContainer/textView. I see a garble of text. When I iterate through my UI textContainers, I get this debug print: TextContainer 0 glyphRange: {0, 172} TextContainer 1 glyphRange: {172, 55} TextContainer 2 glyphRange: {227, 100} // this is wrong, final 31 chars should be in container 3 TextContainer 3 glyphRange: {327, 0} // empty range here, odd I have tried setting textContainers for glyph ranges explicitly, via: // Variable names just for clarity here layoutManager.setTextContainer(correctTextView.textContainer!, forGlyphRange: correctGlyphRangeForThisContainer) Debug prints show that I'm setting the right ranges there. But they don't retain. I have tried resizing my final text container to be much larger in case that was the issue. No dice. My final range of text/glyphs still lays out in the wrong container and overlaps the other content laid out there. Any help here?? I've scoured the forums and have been dealing with this bug for two weeks straight with no hope in sight.
Replies
4
Boosts
0
Views
1.1k
Activity
May ’25
How do I size a UITextView with scroll disabled?
tl;dr: UITextView does not auto layout when isScrollEnabled = false I have a screen with multiple UITextViews on it, contained within a ScrollView. For each textview, I calculate the height needed to display the entire content in SwiftUI and set it using the .frame(width:height:) modifier. The UITextView will respect the size passed in and layout within the container, but since UITextView is embedded within a UIScrollView, when a user attempts to scroll on the page, often they will scroll within a UITextView block rather than the page. They currently need to scroll along the margins outside of the textview to get the proper behavior. Since I am already calculating the height to display the text, I don't want the UITextView to scroll. However, when I set isScrollEnabled = false, the text view displays in a single long line that gets truncated. I have tried Setting various frame/size attributes but that seems to have zero affect on the layout. Embedding the textView within a UIView, and then sizing the container, but then the textView does not display at all. Setting a fixed size textContainer in the layoutManager but did not work. There's a lot of code so I can't copy/paste it all, but generally, it looks like struct SwiftUITextEditor: View { @State var text: AttributedString = "" var body: some View { ZStack { MyTextViewRepresentable(text: $text) } .dynamicallySized(from: $text) } } struct MyTextViewRepresentable: UIViewRepresentable { @Binding var text: AttributedString let textView = UITextView(usingTextLayoutManager: true) func makeUIView(context: Context) -> UITextView { textView.attributedText = text textView.isScrollEnabled = false } ... }
Replies
1
Boosts
0
Views
255
Activity
May ’25