563

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
sniurkst
  • 7,212
  • 5
  • 30
  • 30
  • 11
    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. – Fattie Mar 27 '17 at 17:32
  • 1
    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. – Michael May 18 '17 at 17:41
  • 1
    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! – Fattie Feb 26 '21 at 13:23

24 Answers24

839

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user1687195
  • 9,058
  • 2
  • 15
  • 15
  • 2
    This is working for me for two lines, but by the time I get to 5 lines, the text is getting cut off. – livings124 Oct 02 '13 at 22:02
  • This worked great for me, with multiple lines (10+), and using an embedded font. Thanks user1687195. – Custom Bonbons Oct 14 '13 at 14:19
  • 7
    Note that the second line can also be written as: `self.descriptionTextView.textContainerInset = UIEdgeInsetsZero;` – jessepinho Nov 22 '13 at 23:29
  • Didn't manage to remove the top/bottom padding with this solution – Sergey Grischyov Dec 11 '13 at 10:37
  • For vertical align the content of text view with text label, the first line only works for me in iOS 7. – Mingming Apr 03 '14 at 03:17
  • 21
    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. – phatmann Oct 09 '14 at 17:38
  • 3
    This is the correct answer. Scrolling horizontally doesn't happen with this solution. – Michael Jun 18 '15 at 16:50
  • Works nice in iOS7 and above. :-] – tounaobun Aug 03 '15 at 07: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. – Brian Sachetta Mar 22 '16 at 15:16
  • 2
    `lineFragmentPadding` is not intended to modify margins. From the [docs](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSTextContainer_Class/#//apple_ref/occ/instp/NSTextContainer/lineFragmentPadding) _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._ – Martin Berger Apr 04 '16 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. – ldoogy Apr 24 '16 at 06:43
  • @SergeyGrischyov - regarding the insane **"bottom space problem"**, I give the only solution in my answer below. Apple madness. – Fattie Apr 04 '17 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. – Fattie Apr 04 '17 at 13:15
  • You probably also want to disable scrolling – Senseful Dec 07 '17 at 20:34
482

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!

  1. The solution works properly in storyboard

  2. 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".

Enter image description here

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
}

Enter image description here

(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.

Fattie
  • 27,874
  • 70
  • 431
  • 719
  • 1
    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. – shim Jul 13 '17 at 23:15
  • 1
    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. – shim Jul 14 '17 at 01:53
  • 3
    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` – Fab1n Feb 14 '18 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 @Fab1n answer/comment. With scrollEnabled turned off , it still runs and looks okay in the simulator, but it doesn't look right in the storyboard – NNN Jan 15 '19 at 13:27
  • 2
    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. – El Horrible Jul 17 '19 at 13:55
  • @Fattie , 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: https://www.dropbox.com/s/l7ci6j0m1apc3l5/TestApp.zip?dl=0 – El Horrible Jul 21 '19 at 17:14
  • 4
    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 – Tometoyou Oct 03 '19 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. – DanubePM Feb 08 '20 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.) – Fattie Sep 11 '20 at 15:04
  • translatesAutoresizingMaskIntoConstraints is only used when storyboard has to automatically adds constraints, that one forget – Fattie Sep 21 '20 at 14:30
  • 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. – kwiknik Feb 21 '23 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. – kwiknik Feb 21 '23 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 – Dmitry Aug 31 '23 at 14:05
  • #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()`. – Dmitry Aug 31 '23 at 14:18
  • @Dmitry 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? – Fattie Aug 31 '23 at 18:08
259

This workaround was written in 2009 when iOS 3.0 was released. It no longer applies.

I ran into the exact same problem, and in the end I had to wind up using

nameField.contentInset = UIEdgeInsetsMake(-4, -8, 0, 0);

where nameField is a UITextView. The font I happened to be using was Helvetica 16 point. It’s only a custom solution for the particular field size I was drawing. This makes the left offset flush with the left side, and the top offset where I want it for the box it’s drawn in.

In addition, this only seems to apply to UITextViews where you are using the default aligment, i.e.,

nameField.textAlignment = NSTextAlignmentLeft;

Align to the right for example and the UIEdgeInsetsMake seems to have no impact on the right edge at all.

At very least, using the .contentInset property allows you to place your fields with the "correct" positions, and accommodate the deviations without offsetting your UITextViews.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Michael
  • 3,269
  • 2
  • 23
  • 16
  • I'm resorting to making the TextView's frame extend farther to the right. At about 16.0 additional points the wrapping behavior of my textview and my label match up. Not crazy about this approach. – kris Oct 18 '11 at 16:05
  • 16.0f makes sense, so I'm not too worried. I believe the UITextView underestimates its own size by 16.0f as a direct result of insetting by 8.0f on the left and right edges. – Ben Challenor Mar 11 '12 at 18:12
  • 1
    Yes it does work in iOS 7. Make sure the UIEdgeInset is set to the right values. It might be different than UIEdgeInsetsMake(-4,-8,0,0). – app_ Sep 18 '13 at 09:13
  • 15
    In IOS 7 I found UIEdgeInsetsMake(0,-4,0,-4) worked the best. – Racura Oct 11 '13 at 04:51
  • 2
    Yes, those are example numbers. I stated "Its only a custom solution for the particular field size I was drawing". Mainly I was trying to illustrate that you have to play with the numbers for your unique layout situation. – Michael Oct 18 '13 at 21:12
  • 3
    UITextAlignmentLeft is deprecated in iOS 7. Use NSTextAlignmentLeft. – Jordi Kroon Mar 12 '14 at 12:49
  • UIEdgeInsetsMake(-8,-4,0,0) works best for me. *shrug* – Millie Smith Feb 04 '15 at 01:33
  • UIEdgeInsetsMake(-8,-4,-8,-4) gets rid of the padding on all four sides. iOS 8. – Brett Donald Aug 10 '15 at 23:16
  • 7
    I don't get why people upvote an answer that utilizes hard-coded values. It is VERY likely to break in future versions of iOS and is just a plain bad idea. – ldoogy Aug 12 '16 at 21:15
  • As can be seen from the comments the specific values for the `contentInset` depends on font, UIKit and potentially other factors. The correct answer is http://stackoverflow.com/a/18987810/1555903 – klaaspieter Nov 17 '16 at 09:11
  • 1
    This is a hacky solution, set the 'textContainer' lineFragmentPadding to 0 instead. – Saren Inden Apr 06 '17 at 10:07
88

Building off some of the good answers already given, here is a purely Storyboard / Interface Builder-based solution that works in iOS 7.0+

Set the UITextView's User Defined Runtime Attributes for the following keys:

textContainer.lineFragmentPadding
textContainerInset

Interface Builder

pkamb
  • 33,281
  • 23
  • 160
  • 191
dvs
  • 12,324
  • 6
  • 38
  • 45
47

On iOS 5 UIEdgeInsetsMake(-8,-8,-8,-8); seems to work great.

Engin Kurutepe
  • 6,719
  • 3
  • 34
  • 64
44

I would definitely avoid any answers involving hard-coded values, as the actual margins may change with user font-size settings, etc.

Here is user1687195's answer, written without modifying the textContainer.lineFragmentPadding (because the documentation state this is not the intended usage).

This works great for iOS 7 and later.

self.textView.textContainerInset = UIEdgeInsetsMake(
                                      0,
                                      -self.textView.textContainer.lineFragmentPadding,
                                      0,
                                      -self.textView.textContainer.lineFragmentPadding);

This is effectively the same outcome, just a bit cleaner in that it doesn't misuse the lineFragmentPadding property.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
ldoogy
  • 2,819
  • 1
  • 24
  • 38
  • 1
    I tried another solution based on this answer and it works great. The solutions is: `self.textView.textContainer.lineFragmentPadding = 0;` – Bakyt Abdrasulov Jan 23 '17 at 06:52
  • 1
    @BakytAbdrasulov please read my answer. While your solution works, it is not in accordance with the docs (see the link in my answer). `lineFragmentPadding` isn't meant to control the margins. That's why you're supposed to use `textContainerInset`. – ldoogy Jan 23 '17 at 07:06
25

Storyboard or Interface Builder solution using user-defined runtime attributes:

Screenshots are of iOS 7.1 & iOS 6.1 with contentInset = {{-10, -5}, {0, 0}}.

user-defined runtime attributes

Output

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Uladzimir
  • 3,067
  • 36
  • 30
17

You can use the textContainerInset property of UITextView:

textView.textContainerInset = UIEdgeInsetsMake(10, 10, 10, 10);

(top, left, bottom, right)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Himanshu padia
  • 7,428
  • 1
  • 47
  • 45
  • 1
    I wonder why this is not assigned as the best answer here. The textContainerInset really satisfied my needs. – KoreanXcodeWorker Apr 26 '16 at 15:58
  • Updating the bottom value on the `textContainerInset` property isn't working for me when I want to change it to a new value—see http://stackoverflow.com/questions/19422578/uitextview-textcontainerinset-not-respecting-bottom-inset-value. – Evan R Apr 28 '16 at 22:22
  • @MaggiePhillips It's not the best answer because hardcoded values can't possibly be the right way to do this, and are guaranteed to fail in some cases. You need to take lineFragmentPadding into account. – ldoogy May 21 '16 at 00:32
17

All these answers address the title question, but I wanted to propose some solutions for the problems presented in the body of the OP's question.

Size of Text Content

A quick way to calculate the size of the text inside the UITextView is to use the NSLayoutManager:

UITextView *textView;
CGSize textSize = [textView usedRectForTextContainer:textView.textContainer].size;

This gives the total scrollable content, which may be bigger than the UITextView's frame. I found this to be much more accurate than textView.contentSize since it actually calculates how much space the text takes up. For example, given an empty UITextView:

textView.frame.size = (width=246, height=50)
textSize = (width=10, height=16.701999999999998)
textView.contentSize = (width=246, height=33)
textView.textContainerInset = (top=8, left=0, bottom=8, right=0)

Line Height

UIFont has a property that quickly allows you to get the line height for the given font. So you can quickly find the line height of the text in your UITextView with:

UITextView *textView;
CGFloat lineHeight = textView.font.lineHeight;

Calculating Visible Text Size

Determining the amount of text that is actually visible is important for handling a "paging" effect. UITextView has a property called textContainerInset which actually is a margin between the actual UITextView.frame and the text itself. To calculate the real height of the visible frame you can perform the following calculations:

UITextView *textView;
CGFloat textViewHeight = textView.frame.size.height;
UIEdgeInsets textInsets = textView.textContainerInset;
CGFloat textHeight = textViewHeight - textInsets.top - textInsets.bottom;

Determining Paging Size

Lastly, now that you have the visible text size and the content, you can quickly determine what your offsets should be by subtracting the textHeight from the textSize:

// where n is the page number you want
CGFloat pageOffsetY = textSize - textHeight * (n - 1);
textView.contentOffset = CGPointMake(textView.contentOffset.x, pageOffsetY);

// examples
CGFloat page1Offset = 0;
CGFloat page2Offset = textSize - textHeight
CGFloat page3Offset = textSize - textHeight * 2

Using all of these methods, I didn't touch my insets and I was able to go to the caret or wherever in the text that I want.

mikeho
  • 6,790
  • 3
  • 34
  • 46
14

Here is an updated version of Fattie's very helpful answer. It added two important lines that helped me get the layout working on iOS 10 and 11 (and probably on lower ones, too):

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

The important lines are the two translatesAutoresizingMaskIntoConstraints = <true/false> statements!

This surprisingly removes all margins in all my circumstances!

While the textView is not the first responder, it could happen that there is some strange bottom margin that could not be solved using the sizeThatFits method that is mentioned in the accepted answer.

When tapping into the textView, suddenly the strange bottom margin disappeared and everything looked like it should, but only as soon as the textView has got firstResponder.

So I read here on Stack Overflow that enabling and disabling translatesAutoresizingMaskIntoConstraints does help when setting the frame/bounds manually in between the calls.

Fortunately this not only works with frame setting, but with the two lines of setup() sandwiched between the two translatesAutoresizingMaskIntoConstraints calls!

This, for example, is very helpful when calculating the frame of a view using systemLayoutSizeFitting on a UIView. It gives back the correct size (which previously it didn't)!

As in the original answer mentioned:

Don't forget to turn off scrollEnabled in the Inspector! That solution does work properly in storyboard, as well as at runtime.

That's it, and now you're really done!

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Fab1n
  • 2,103
  • 18
  • 32
12

For iOS 10, the following line works for the top and bottom padding removing.

captionTextView.textContainerInset = UIEdgeInsetsMake(0, 0, 0, 0)
Anson Yao
  • 1,544
  • 17
  • 27
  • Xcode 8.2.1. still the same issue as mentioned in this answer. My solution was to edit the values as UIEdgeInsets(top: 0, left: -4.0, bottom: 0, right: -4.0). – Darkwonder Feb 25 '17 at 02:44
  • `UIEdgeInset.zero` works using XCode 8.3 and iOS 10.3 Simulator – Simon Warta Mar 31 '17 at 10:02
12

Latest Swift:

self.textView.textContainerInset = .init(top: -2, left: 0, bottom: 0, right: 0)
self.textView.textContainer.lineFragmentPadding = 0
Pang
  • 9,564
  • 146
  • 81
  • 122
Urvish Modi
  • 1,118
  • 10
  • 11
  • Great answer. This answer removes the additional Top inset. textView.textContainerInset = UIEdgeInsets.zero doesn't remove 2 pixels from top inset. – korgx9 Aug 02 '19 at 13:44
6

For Swift 4, Xcode 9

Use the following function. It can change the margin/padding of the text in UITextView:

public func UIEdgeInsetsMake(_ top: CGFloat, _ left: CGFloat, _ bottom: CGFloat, _ right: CGFloat) -> UIEdgeInsets

So in this case it is:

 self.textView?.textContainerInset = UIEdgeInsetsMake(0, 0, 0, 0)
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Shan Ye
  • 2,622
  • 19
  • 21
5

For SwiftUI

If you are making your own TextView using UIViewRepresentable and want to control the padding, in your makeUIView function, simply do:

uiTextView.textContainerInset = UIEdgeInsets(top: 10, left: 18, bottom: 0, right: 18)

or whatever you want.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
P. Ent
  • 1,654
  • 1
  • 12
  • 22
4

Here's an easy little extension that will remove Apple's default margin from every text view in your app.

Note: Interface Builder will still show the old margin, but your app will work as expected.

extension UITextView {

   open override func awakeFromNib() {
      super.awakeFromNib();
      removeMargins();
   }

   /** Removes the Apple textview margins. */
   public func removeMargins() {
      self.contentInset = UIEdgeInsetsMake(
         0, -textContainer.lineFragmentPadding,
         0, -textContainer.lineFragmentPadding);
   }
}
N S
  • 2,524
  • 6
  • 32
  • 42
4

Doing the inset solution I still had padding on the right side and the bottom. Also text alignment was causing issues. The only sure-fire way I found was to put the text view inside another view that is clipped to bounds.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
rp90
  • 854
  • 1
  • 9
  • 20
  • What is the *"inset solution"*? Can you elaborate and/or add a reference? Please respond by [editing (changing) your answer](https://stackoverflow.com/posts/5507746/edit), not here in comments (***without*** "Edit:", "Update:", or similar - the answer should appear as if it was written today). – Peter Mortensen Sep 25 '21 at 07:52
2

For me (iOS 11 & Xcode 9.4.1) what worked magically was setting up textView.font property to UIFont.preferred(forTextStyle:UIFontTextStyle) style and also the first answer as mentioned by Fattie. But the Fattie answer did not work till I set the textView.font property. Else UITextView keeps behaving erratically.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Nikhil Pandey
  • 262
  • 4
  • 11
2

In case anyone is looking for the latest Swift version then the below code is working fine with Xcode 10.2 and Swift 4.2

yourTextView.textContainerInset = UIEdgeInsets(top: 0, left: 0, bottom: 0, right: 0)
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Bhavin_m
  • 2,746
  • 3
  • 30
  • 49
1

I have found one more approach. Getting the view with text from UITextView's subviews and setting it up in the layoutSubview method of a subclass:

- (void)layoutSubviews {
    [super layoutSubviews];

    const int textViewIndex = 1;
    UIView *textView = [self.subviews objectAtIndex:textViewIndex];
    textView.frame = CGRectMake(
                                 kStatusViewContentOffset,
                                 0.0f,
                                 self.bounds.size.width - (2.0f * kStatusViewContentOffset),
                                 self.bounds.size.height - kStatusViewContentOffset);
}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Nikita
  • 1,811
  • 1
  • 20
  • 41
1

The textView scrolling also affect the position of the text and make it look like not vertically centered. I managed to center the text in the view by disabling the scrolling and setting the top inset to 0:

    textView.scrollEnabled = NO;
    textView.textContainerInset = UIEdgeInsetsMake(0, textView.textContainerInset.left, textView.textContainerInset.bottom, textView.textContainerInset.right);

For some reason I haven't figured it out yet, the cursor is still not centered before the typing begins, but the text centers immediately as I start typing.

Alex
  • 995
  • 12
  • 25
1

In case you want to set an HTML string and avoid the bottom padding, please make sure that you are not using block tags, i.e., div and p.

In my case this was the reason. You can easily test it out by replacing occurrences of block tags with, e.g., the span tag.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
1

You need to set inset and lineFragmentPadding on didMoveToSuperView

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

For anyone coming to this because of parsing HTML into UITextView, just remove the new line introduced by the closing p tag "/n". I assume that you work with NSMutableAttributedString:

if let lastCharacter = attributedString.string.last, lastCharacter == "\n" {
    attributedString.deleteCharacters(in: NSRange(location:(attributedString.length) - 1, length:1))
}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
christostsang
  • 1,701
  • 3
  • 27
  • 46
-4
[firstNameTextField setContentVerticalAlignment:UIControlContentVerticalAlignmentCenter];
Luke
  • 11,426
  • 43
  • 60
  • 69
  • An explanation would be in order. E.g., what is the idea/gist? Please respond by [editing (changing) your answer](https://stackoverflow.com/posts/7033311/edit), not here in comments (***without*** "Edit:", "Update:", or similar - the answer should appear as if it was written today). – Peter Mortensen Sep 25 '21 at 07:55