NextGrowingTextView wraps UITextView in a scroll view so iOS layout changes stop breaking it

A scroll view on the outside, a text view on the inside

The architecture is two lines of nesting and everything else follows from it:

- public NextGrowingTextView: UIScrollView
    - internal NextGrowingInternalTextView: UITextView

The public type is a UIScrollView, not a UITextView, and the text view inside is internal. The internal view is aligned to the scroll view's contentSize, which is what makes the control grow: content pushes the content size, the scroll view's own height follows, and no layout constraint has to be recomputed by hand.

The stated reason for not subclassing UITextView is version history rather than principle. The README says most autoresizing text views are UITextView subclasses, and that each iOS release changed UITextView's layout behaviour, so those implementations accumulated version-specific workarounds to fix bugs and errant behaviour. With the wrapper approach, the README claims, the battle with the framework is over.

The result is a component you drop in where you would have put a text view, with the growth behaviour already handled. The lineage is explicit too: it is described as the successor to HPGrowingTextView, redesigned from scratch rather than patched.

Height changes arrive through delegates, not through constraints

Because the control computes its own height, the host view has to hear about it. That is what the Delegates type is for:

public class Delegates {
  public var willChangeHeight: (CGFloat) -> Void
  public var didChangeHeight: (CGFloat) -> Void
}

public var delegates: Delegates
public override init(frame: CGRect)

Two callbacks, one before and one after, both taking the new height as a CGFloat. The split lets you animate or adjust surrounding layout on the way in and run assertions or side effects on the way out.

The usage pattern in the README captures the rest and uses a weak self capture:

growingTextView.delegates.didChangeHeight = { [weak self] height in
  guard let `self` = self else { return }
  // Do something
}

The delegates property exposes a Delegates class containing the two closures rather than a protocol conformance. The trade is discoverability: nothing in the type system tells a reader that a height change happened, and nothing forces you to implement it.

There is one presentation knob documented, isFlashScrollIndicatorsEnabled, which controls the flash of the scroll indicators while the text view height is below the maximum height. Once the text exceeds the cap, the scroll view's scrolling behaviour becomes visible, and that flag controls whether the movement draws attention.

Installing it: three routes, one of which has moved

The package is distributed three ways and the repository layout supports all of them. There is NextGrowingTextView.podspec at the root for CocoaPods, a Package.swift for SwiftPM, and a badge declaring Carthage compatibility.

CocoaPods is the most fully documented route. The README gives the Podfile:

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!

pod 'NextGrowingTextView'

It also notes that CocoaPods 0.39.0 or later is required to build the component, and that the tool itself is installed with gem install cocoapods. After editing the Podfile you run pod install. To try the demo, clone the repository and run pod install from the Example directory, as the README instructs at the top of the usage section.

Carthage is the route to check carefully. The README's Cartfile sample is:

github "muukii/NextGrowingTextView"

The repository you are reading is FluidGroup/NextGrowingTextView, so that line refers to a different path than the one hosting this README. The FOSSA badge in the same README still references the muukii repository too. Treat the Carthage instructions as stale documentation rather than as something to copy, and confirm the source path before running carthage update.

SwiftPM is present as Package.swift with no documentation at all in the README, which means the package name, platforms and products are whatever that manifest declares and nothing more.

The version claims in this repository disagree with each other

This is worth stating plainly before you pin anything.

The repository description says the component is optimized for iOS 8 and above, and the README repeats it twice, including in the Podfile sample with platform :ios, '8.0'. The Requirements section then says iOS 9.0+ Swift 4.2+. The badge at the top of the README says Swift 5.1. Three different answers about the floor, none of them reconciled.

The release history adds context without resolving it. Tags 2.2.0 and 2.2.1 landed in 2022, then 3.0.0 landed on 2026-07-08, with the last push on 2026-08-21. A major bump after a four year gap usually means something changed in the deployment target or the Swift version, but the README does not document what.

The rule of thumb: treat the podspec and Package.swift as the authority for what 3.0.0 actually requires, and the README prose as describing an earlier generation. If you are on a current toolchain, the Swift 4.2 line in Requirements is certainly obsolete.

Where this is the wrong component

Three boundaries.

If you need a multi-line rich text editor with attributed text, images, or text styling beyond plain entry, this is not it. The README describes no text formatting attributes, no input accessory, and no attributed string handling; it is a growing plain text field.

If you want to show a custom view above the keyboard, the README points elsewhere, to muukii/Bureau, for that behaviour. That is a separate component and not something this one provides.

If you need modern SwiftUI text editing, this is a UIKit component with an initialiser taking a CGRect frame, and there is no SwiftUI wrapper documented.

Also note what is not documented: there is no mention of a maximum height property, a placeholder, a delegate for text changes, or a character limit in the visible README, even though the scroll indicator behaviour implies some cap exists. If you need those, read the source in NextGrowingTextView/ before committing, and note that the demo in Demo/ with ViewController.swift and ScrollViewViewController.swift is the closest thing to usage documentation here.

On licensing and maintenance: the component is MIT licensed with a LICENSE file at the root, which is permissive with notice obligations and no copyleft on your app. The topic list still includes hacktoberfest, and there is a .travis.yml at the root, which suggests continuous integration configuration from an era when that was the default; the .github/ directory is also present, so the build configuration is worth a look before you assume it still runs.

How it compares with HPGrowingTextView and a plain UITextView

The predecessor is the obvious comparison. NextGrowingTextView is described as the successor to HPGrowingTextView and was redesigned from scratch. The difference in approach is exactly the composition versus inheritance split described above, which means the migration is not a drop-in: if your code typed a variable as HPGrowingTextView, the new type is a UIScrollView and you touch the accessors.

Against a plain UITextView with a height constraint you write yourself, the trade is control. Doing it by hand means owning the layout maths, the maximum height clamp, and the behaviour when content exceeds it, and it means maintaining that against iOS releases, which is the problem the README describes. Using this component means accepting the internal text view's accessibility, which is internal and therefore not directly addressable, and the closure-based delegates rather than a protocol you can inherit from.

For a composer in a messaging or note-taking app, that trade is usually worth it. For a one-off form field in an application with a minimum deployment target above iOS 12, the framework may no longer be the problem the component was written to solve.

Editorial conclusion

Adopt NextGrowingTextView if you need a composer that grows to a maximum height and want to avoid UITextView subclassing, because the height is derived from contentSize and reported through delegates rather than recomputed per iOS release. Do not adopt it expecting current documentation, since the repository contradicts itself: the description and Podfile sample say iOS 8 and Swift 4.2+, the README badge says Swift 5.1, the Carthage entry still points at the old muukii path rather than FluidGroup, and Package.swift exists at the root without instructions. Verify first which deployment target version 3.0.0 from 2026-07-08 actually requires by reading the podspec, and treat the Carthage line as suspect until you confirm the module resolves under your project name.

Frequently asked questions

Official sources

1. FluidGroup/NextGrowingTextView on GitHub
2. Issues
3. License: MIT
4. README
5. Releases