Introduction

Sometimes a UITextView should display sensitive or controlled text that users can read but not copy, cut, or select. Typical cases include DRM-constrained content, exam apps, or in-app views where text extraction is explicitly disallowed by product policy. On iOS, default text interactions expose the edit menu and selection handles, so you need a custom subclass to disable specific actions.

The important point is scope. You should disable interactions only where truly required, because removing familiar editing behavior impacts accessibility and user trust. A clean implementation overrides action routing and selection capability while keeping layout and rendering intact. This article provides a production-friendly Swift approach with clear limitations.

Core Sections

Subclass UITextView and block menu actions

Override canPerformAction(_:withSender:) to reject actions you do not want.

1import UIKit
2
3final class LockedTextView: UITextView {
4    override func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool {
5        if action == #selector(copy(_:)) ||
6            action == #selector(cut(_:)) ||
7            action == #selector(select(_:)) ||
8            action == #selector(selectAll(_:)) ||
9            action == #selector(paste(_:)) {
10            return false
11        }
12        return super.canPerformAction(action, withSender: sender)
13    }
14}

This removes those items from the UIMenu when user long-presses.

Disable text selection behavior

Blocking menu items alone may still allow selection handles in some cases. Disable selection at the control level.

1final class LockedTextView: UITextView {
2    override var selectedTextRange: UITextRange? {
3        get { nil }
4        set { }
5    }
6
7    override func selectionRects(for range: UITextRange) -> [UITextSelectionRect] {
8        []
9    }
10
11    override func caretRect(for position: UITextPosition) -> CGRect {
12        .zero
13    }
14}

This prevents caret and selection UI from appearing.

Configure interaction and editability correctly

Set text view flags to match your intended UX.

1let tv = LockedTextView()
2tv.isEditable = false
3tv.isSelectable = false
4tv.isScrollEnabled = true
5tv.text = "Read-only content"

If users should still type but not copy/cut/select, keep isEditable = true and adjust overrides carefully for allowed actions.

iOS 16+ edit menu integration

Newer iOS versions route menus through UIEditMenuInteraction. The action override still works, but test on target OS versions because menu presentation behavior evolves.

1override func buildMenu(with builder: UIMenuBuilder) {
2    super.buildMenu(with: builder)
3    builder.remove(menu: .standardEdit)
4}

Use this only if you want to suppress the entire standard edit menu for that view.

Re-enable actions selectively

Sometimes you want to allow copy but block cut/paste. Keep policy explicit.

1enum TextActionPolicy {
2    case fullyLocked
3    case copyOnly
4}
5
6var policy: TextActionPolicy = .fullyLocked

Inside canPerformAction, branch on policy rather than hard-coding one permanent behavior. This makes future product changes safer.

Accessibility and UX fallback

When restricting selection, offer alternatives for users relying on assistive tools.

tv.accessibilityHint = "Content is read-only and text selection is disabled."

If policy allows, provide a controlled export/share button that logs user intent and preserves auditability.

Common Pitfalls

• Disabling text interactions globally across the app instead of only in views with explicit security or policy requirements.
• Overriding menu actions but forgetting selection/caret methods, leaving partial interaction states.
• Using private APIs to suppress editing behavior, which risks App Store rejection.
• Ignoring accessibility implications when removing standard text affordances users expect.
• Failing to test on multiple iOS versions where edit menu behavior differs subtly.

Summary

To disable Copy, Cut, Select, and Select All in UITextView, use a subclass that denies edit actions and suppresses selection UI. Keep the restriction local to sensitive contexts, and configure isEditable/isSelectable according to desired behavior. Validate on target iOS versions, especially around edit menu changes, and provide accessibility cues or controlled alternatives when possible. With a clear policy-driven implementation, you can enforce content restrictions without destabilizing general text rendering.