After Xcode 11.2: app crashes due to _UITextLayoutView — solution

Online Python Trainer for Beginners

Learn Python easily without overwhelming theory. Solve practical tasks with automatic checking, get hints in Russian, and write code directly in your browser — no installation required.

Start Course

After updating Xcode 11.2 the app crashes: how to defeat _UITextLayoutView

\n\n

Ever had this happen: you're calmly working on a project, everything is flying, tests pass, users are happy. And then — bam! — you update Xcode to version 11.2, launch the app, and it crashes with a mysterious error _UITextLayoutView. Sound familiar? If yes — you're not alone. This problem literally exploded on Stack Overflow in late 2019 (thousands of views in a week).

\n\n

In this article, I will not only show how to fix this bug but also explain why it occurs, how to diagnose it, and most importantly, how to prevent it in the future. We'll break it all down with live examples in Swift. Let's go!

\n\n

What kind of beast is _UITextLayoutView?

\n\n

Let's start with theory. _UITextLayoutView is an internal (private) UIKit class responsible for rendering text in UITextView. Apple does not document it publicly, so when something went wrong with this class in Xcode 11.2, developers found themselves at a dead end. The error looks something like this:

\n\n
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[_UITextLayoutView setFrame:]: unrecognized selector sent to instance 0x...'
\n\n

The key phrase is "unrecognized selector sent to instance". This means you are trying to call the setFrame: method on an object that doesn't support it. And since _UITextLayoutView is a private class, it behaved differently before Xcode 11.2.

\n\n

Who is at risk?

\n\n

The problem doesn't appear for everyone, only under certain conditions. Here's a typical scenario:

\n
    \n
  • You are using UITextView with auto-sizing enabled.
  • \n
  • You have a custom view hierarchy where UITextView is nested inside UIScrollView or UITableViewCell.
  • \n
  • You actively interact with the text field: scrolling, editing, changing the font.
  • \n
\n\n

If at least one point matches — congratulations, you're in the risk zone. But don't worry: there is a solution, and it's elegant.

\n\n

Step 1: Diagnosis — find the culprit

\n\n

Before treating, let's make sure the problem is indeed _UITextLayoutView. Open the Xcode console (View → Debug Area → Activate Console) and launch the app. If you see an error similar to the one I provided above — you're on the right track.

\n\n

An additional sign: the crash occurs on the very first attempt to display UITextView or when scrolling inside it. If the app crashes immediately after loading — it's most likely this.

\n\n

Step 2: Simple and quick solution (for those in a hurry)

\n\n

The most popular fix on Stack Overflow is to disable auto-sizing for UITextView. Here's how to do it:

\n\n
// In your viewDidLoad or setup method\ntextView.isScrollEnabled = false\ntextView.translatesAutoresizingMaskIntoConstraints = true
\n\n

But attention! This solution works, but it breaks auto-sizing of the text. If it's critical for you that UITextView dynamically changes height based on content — this option won't work. Let's dig deeper.

\n\n

Step 3: Advanced solution — overriding layoutSubviews

\n\n

Apple released a patch in Xcode 11.2.1, but if for some reason you stayed on 11.2, or want a universal solution, here's what you need to do.

\n\n

Create a subclass of UITextView and override the layoutSubviews method:

\n\n
import UIKit\n\nclass FixedTextView: UITextView {\n    override func layoutSubviews() {\n        super.layoutSubviews()\n        // Clear the layer of extra subviews caused by the bug\n        self.subviews.forEach { subview in\n            if subview.isKind(of: NSClassFromString("_UITextLayoutView") ?? UIView.self) {\n                

Blogs

Book Recommendations