Skip to main content

Text Input and Form Controls

Forms are where mobile UI quality becomes visible quickly. Input latency, keyboard handling, validation timing, and error clarity all affect completion rate and user trust.

TextInput​

TextInput is the primary primitive for typed input. Treat it as a stateful control with UX, validation, and keyboard consequences.

Use it for:

  • short fields like email, phone, OTP, and names
  • multiline notes and descriptions
  • search bars
  • secure entry fields

Best patterns​

  • create a reusable app-level input wrapper instead of styling each field independently
  • standardize label, helper text, error text, and disabled states
  • choose keyboard type, auto-capitalization, auto-correct, and secure entry intentionally
  • separate raw input state from validated domain state when needed

Common mistakes​

  • validating too aggressively on every keystroke
  • not managing focus transitions across multiple fields
  • forgetting keyboard and safe-area interactions on smaller devices

Switch​

Switch is best for binary settings that take effect immediately.

Use it when:

  • the user is toggling a durable preference
  • the change is reversible
  • the on/off meaning is obvious without additional context

Avoid it for high-risk decisions that need explanation or confirmation.

Button​

The built-in Button is acceptable for basic prototypes, but many production teams wrap it quickly because they need:

  • consistent variants
  • loading states
  • disabled states
  • icon support
  • better typography control

The important point is not whether you use the raw Button, but whether action semantics remain clear and accessible.

Form composition​

A production form usually needs more than individual controls:

  • field registration strategy
  • validation timing rules
  • submit locking
  • error summarization
  • success and retry states

Teams should decide whether forms are:

  • controlled end to end
  • managed by a form library
  • split between controlled inputs and server-state submission

Accessibility and autofill​

For form-heavy apps, define conventions for:

  • labels and helper copy
  • secure fields
  • autofill hints
  • keyboard return-key behavior
  • focus order

These details are not polish. They are part of form correctness.

Team rule​

Inputs should be standardized early. If every feature implements form controls differently, validation and accessibility quality will drift almost immediately.

Pair this page with Touchables and Pressable and Images, Safe Areas, and Platform Adaptation for keyboard and layout edge handling.