S

24

570

I have a UITextView in my iOS application, which displays a large amount of text.

I am then paging this text by using the offset margin parameter of the UITextView.

My problem is that the padding of the UITextView is confusing my calculations as it seems to be different depending on the font size and typeface that I use.

Is it possible to remove the padding surrounding the content of the UITextView?

Sirup answered 14/4, 2009 at 7:42 Comment(3)

Note that this QA is almost ten years old! With 100,000+ views, since it's one of the stupidest problems in iOS. Just FTR I put in the current, 2017, reasonably simple / usual / accepted solution below as an answer. – Volteface 27/3, 2017 at 17:32

I still get updates on this, having written a hardcoded workaround in 2009 when IOS 3.0 had just been released. I just edited the answer to clearly state that it is years out of date and to ignore the accepted status. – Burchette 18/5, 2017 at 17:41

Amazingly, well over ten years now (200,000 views of this QA!) and Apple still have not fixed the combination of plain bugs, soft bugs, and bizarre behavior in UITextView. It is really one of the weirdest things in all of mobile computing development! – Volteface 26/2, 2021 at 13:23

V

490

Up-to-date for 2023

It is one of the silliest bugs in iOS.

The class given here, UITextViewFixed is used widely and is usually the most reasonable solution overall.

Here is the class:

@IBDesignable class UITextViewFixed: UITextView {
    override func layoutSubviews() {
        super.layoutSubviews()
        setup()
    }
    func setup() {
        textContainerInset = UIEdgeInsets.zero
        textContainer.lineFragmentPadding = 0
    }
}

Don't forget to turn off scrollEnabled in the Inspector!

The solution works properly in storyboard
The solution works properly at runtime

You're done. In general, that should be all you need in most cases.

Even if you are changing the height of the text view on the fly, UITextViewFixed usually does all you need.

(A common example of changing the height on the fly, is changing it as the user types.)

Here is the broken UITextView from Apple...

Screenshot of Interface Builder with UITextView

Here is UITextViewFixed:

Screenshot of Interface Builder with UITextViewFixed

Note that of course you must...

...turn off scrollEnabled in the Inspector!

(Turning on scrollEnabled means "make this view expand as much as possible vertically by expanding the bottom margin as much as possible.")

Some further issues

(1) In very unusual cases when dynamically changing heights, Apple does a bizarre thing: they add extra space at the bottom.

No, really! This would have to be one of the most infuriating things in iOS.

If you encounter the problem, here is a "quick fix" which usually helps:

...
        textContainerInset = UIEdgeInsets.zero
        textContainer.lineFragmentPadding = 0

        // this is not ideal, but sometimes this "quick fix"
        // will solve the "extra space at the bottom" insanity:
        var b = bounds
        let h = sizeThatFits(CGSize(
           width: bounds.size.width,
           height: CGFloat.greatestFiniteMagnitude)
       ).height
       b.size.height = h
       bounds = b
 ...

(2) In rare cases, to fix yet another subtle mess-up by Apple, you have to add:

override func setContentOffset(_ contentOffset: CGPoint, animated: Bool) {
    super.setContentOffset(contentOffset, animated: false) // sic
}

(3) Arguably, we should be adding:

contentInset = UIEdgeInsets.zero

just after .lineFragmentPadding = 0 in UITextViewFixed.

However believe or not that just doesn't work in current iOS! (Checked 2023.) It may be necessary to add that line in the future.

The fact that UITextView is broken in iOS is one of the weirdest things in all of mobile computing. Ten year anniversary of this question and it's still not fixed!

Finally, here's a somewhat similar tip for TextField: Set the maximum character length of a UITextField in Swift

Completely random tip: how to add the "..." on the end

Often you are using a UITextView "like a UILabel". So you want it to truncate text using an ellipsis, "..."

If so, add:

 textContainer.lineBreakMode = .byTruncatingTail

Handy tip if you want zero height, when, there's no text at all

Often you use a text view to only display text. So, you use lines "0" to mean the text view will automatically change height depending on how many lines of text.

That's great. But if there is no text at all, then unfortunately you get the same height as if there is one line of text!!!! The text view never "goes away".

If you want it to "go away", just add this

override var intrinsicContentSize: CGSize {
    var i = super.intrinsicContentSize
    print("for \(text) size will be \(i)")
    if text == "" { i.height = 1.0 }
    print("   but we changed it to \(i)")
    return i
}

(I made it '1' height, so it's clear what's going on in that demo, '0' is fine.)

What about UILabel?

When just displaying text, UILabel has many advantages over UITextView. UILabel does not suffer from the problems described on this Q&A page.

Indeed the reason we all usually "give up" and just use UITextView is that UILabel is difficult to work with. In particular it is ridiculously difficult to just add padding, correctly, to UILabel.

In fact here is a full discussion on how to "finally" correctly add padding to UILabel: Adding space/padding to a UILabel. In some cases if you are doing a difficult layout with dynamic height cells, it is sometimes better to do it the hard way with UILabel.

Volteface answered 19/2, 2017 at 22:45 Comment(14)

Why do you say it's necessary to turn off scrollEnabled in the inspector? When I do that I seem to get even less space in the my text view. – Supraorbital 13/7, 2017 at 23:15

The height of the frame of the scroll view is unrelated to the content size. The question posed by OP makes no mention of height. Simply trying to understand your response. – Supraorbital 14/7, 2017 at 1:53

I've posted an updated answer to @Fattie's answer which helped me to really get rid of all insets using the special trick of enabling/disabling translatesAutoresizingMaskIntoConstraints. With this answer alone I was not able to remove all the margins (some strange bottom margin resisted to go away) in a view hierarchy using auto layout. It also deals with calculation of view sizes using systemLayoutSizeFitting, which previously returned an invalid size due to the buggy UITextView – Voccola 14/2, 2018 at 14:40

I'm on Xcode 10.1 and using Swift 4 and i found Fattie's solution works for me if i kept scrollEnabled turned on and i used the translatesAutoresizingMaskIntoConstraints trick mentioned in @Voccola answer/comment. With scrollEnabled turned off , it still runs and looks okay in the simulator, but it doesn't look right in the storyboard – Crenelation 15/1, 2019 at 13:27

I had textviews in table, the ones that had single line of text didn't calculate its height correctly (autolayout). To fix it I had to override didMoveToSuperview and call setup there also. – Flyspeck 17/7, 2019 at 13:55

@Volteface , Constraints are fine, there is always 1 or 2 extra row at the bottom. It works OK if I use regular UITextView. I just tested it with simple test project and same problem occurs. I've put UITextViewFixed in table cell with top/bottom/leading/trailing constraints. I've put test project on dropbox if you want to test it: dropbox.com/s/l7ci6j0m1apc3l5/TestApp.zip?dl=0 – Flyspeck 21/7, 2019 at 17:14

I used this in my app and it causes a recursive call between layoutSubviews and setup causing a stack overflow error! Something is wrong here – Anglophobe 3/10, 2019 at 17:42

I had the extra spacing at the bottom issue when using a UITableViewCell. I found that doing the sizeThatFits part in layoutSubview froze my app (infinite loop?) if I attempted to edit the text view. Instead, I did what El Horrible suggested and that works fine. – Classless 8/2, 2020 at 22:15

Guys take care using didMoveToSuperview - although it can seemingly work in simple cases, if you don't something in layout, it will, of course, never size properly as the layout changes! Regarding the other comment, in iOS programming it's easy to accidentally have an infinite loop in your custom classes, I certainly often do it!, it is unrelated to anything here.) – Volteface 11/9, 2020 at 15:4

Great collation of info. Unfortunately neither of the two fixes for that extra space at the bottom works for me. When UITextView contains 1 line, there's no extra bottom padding. When it contains 2 or 3 lines, there is. Using UITextViewFixed and applying all fixes you've suggested, testing both with & without the two optional ones. – Temperamental 21/2, 2023 at 12:27

When I try your first fix for extra bottom space, the height remains the same, but text is incorrectly offset in the Y axis, as though top inset padding is unzeroed. The only working solution I've found for a tight-fitting UITextView that has dynamic self-sizing is to override intrinsicContentSize and fudge-adjust the calculated height by subtracting 0.4 * font.lineHeight, in the case where there's more than one visible line. – Temperamental 21/2, 2023 at 12:39

As mentioned in other comments, #1 in "Some further issues" may lead to recursive call. Instead of trying to fix that extra space at the bottom in the layoutSubviews(), we should note that this behaviour is not at all unexpected. It happens because the layout engine first calculates the height before layoutSubviews() is fired. Therefore it takes into account the original top and bottom insets and sticks with the hight afterwards. With that in mind the solution should be to make the same adjust – Olivas 31/8, 2023 at 14:5

#1 in "Some further issues" solution may lead to recursive call. That extra space at the bottom is not at all unexpected though. It happens because the layout engine first calculates the height before layoutSubviews() is fired. Therefore it takes into account the original top and bottom insets and sticks with the height afterwards. Based on that, my solution was to make the same text container adjustments in required init?(coder aDecoder: NSCoder) as proposed in layoutSubviews(). WIth that you don't have to manipulate the bounds in layoutSubviews(). – Olivas 31/8, 2023 at 14:18

@Olivas for sure, anytime at all you use layoutSubviews you risk making a mistake and ending up in a loop and crash! It's a good idea to use required init?(coder but that would also take some thought about the layout cycle and, perhaps, you'd have to be careful if code v. storyboard bringup? – Volteface 31/8, 2023 at 18:8

B

846

For iOS 7.0, I've found that the contentInset trick no longer works. This is the code I used to get rid of the margin/padding in iOS 7.

This brings the left edge of the text to the left edge of the container:

textView.textContainer.lineFragmentPadding = 0

This causes the top of the text to align with the top of the container:

textView.textContainerInset = .zero

Both lines are needed to completely remove the margin/padding.

Barrelhouse answered 24/9, 2013 at 17:5 Comment(14)

This is working for me for two lines, but by the time I get to 5 lines, the text is getting cut off. – Summand 2/10, 2013 at 22:2

This worked great for me, with multiple lines (10+), and using an embedded font. Thanks user1687195. – Nuptials 14/10, 2013 at 14:19

Note that the second line can also be written as: self.descriptionTextView.textContainerInset = UIEdgeInsetsZero; – Diversion 22/11, 2013 at 23:29

Didn't manage to remove the top/bottom padding with this solution – Taxidermy 11/12, 2013 at 10:37

For vertical align the content of text view with text label, the first line only works for me in iOS 7. – Geelong 3/4, 2014 at 3:17

Setting lineFragmentPadding to 0 is the magic I was looking for. I have no idea why Apple makes it so hard to line up UITextView content with other controls. – Outlaw 9/10, 2014 at 17:38

This is the correct answer. Scrolling horizontally doesn't happen with this solution. – Burchette 18/6, 2015 at 16:50

Works nice in iOS7 and above. :-] – Peavey 3/8, 2015 at 7:48

I like this solution the best. Setting the insets to hard coded values (for example: UIEdgeInsetsMake(2, 2, 2, 2)) is sketchy at best since the defaults could change with every version of the OS. – Seafaring 22/3, 2016 at 15:16

lineFragmentPadding is not intended to modify margins. From the docs Line fragment padding is not designed to express text margins. Instead, you should use insets on your text view, adjust the paragraph margin attributes, or change the position of the text view within its superview. – Maclay 4/4, 2016 at 18:35

This should be marked as the correct answer. I'm baffled by Apple's statement that this was not designed to express text margins. I suppose you could just set the left inset to -lineFragmentPadding instead of changing this, which makes it a bit cleaner. In any case, this solution is FAR cleaner than a bunch of hardcoded insets. – Sandasandakan 24/4, 2016 at 6:43

@SergeyGrischyov - regarding the insane "bottom space problem", I give the only solution in my answer below. Apple madness. – Volteface 4/4, 2017 at 13:10

While the particular point given in this answer is totally correct, it, very simply, does not "remove the stupid padding from a text view" as asked in the question. Since this QA is very old, I typed in the correct current answer below - look for the yellow screenshots! :) Hope it helps someone. – Volteface 4/4, 2017 at 13:15

You probably also want to disable scrolling – Alienism 7/12, 2017 at 20:34

V

490