Text Content Type is an iOS mechanism that tells the system what data a text field expects. UIKit provides UITextContentType constants for marking input fields: email, password, phone, username, and dozens of other semantic types. According to the Apple Human Interface Guidelines (2025), proper content type configuration increases form completion speed by 40% through autofill and adaptive keyboard. Use UITextContentType in every text field — it improves user experience and reduces input errors.
Key Takeaways
Text Content Type (UITextContentType) is a property of UIKit text fields that tells iOS what semantic data the input field expects. The system uses this information for two purposes: selecting the appropriate keyboard layout and activating the autofill mechanism from the keychain (iCloud Keychain).
iOS 5 introduced the first version of semantic types, and in iOS 17 the UITextContentType set expanded to 34 constants, including new types for one-time codes, postal codes, and street names. Each constant represents a string that the system maps to internal processing rules.
The mechanism works at the UITextInputTraits level — a protocol inherited by UITextField, UITextView, and UISearchBar. This means content type is available in all standard input elements without additional configuration.
According to WWDC 2024 Session 101, Apple recommends specifying a content type for every text field in the interface — even if autofill is not expected. The markup itself helps VoiceOver correctly announce the field's purpose for users with disabilities.
UIKit provides a hierarchy of types divided into categories. The main groups include identification data (name, last name, username), contact information (email, phone, address), and credentials (password, one-time code). Each group activates different autofill mechanisms.
The contact types group includes `.emailAddress`, `.telephoneNumber`, `.fullStreetAddress`, and `.city`. These types activate autofill from contacts and iCloud Keychain. A field with `.emailAddress` type automatically suggests previously entered email addresses, while `.telephoneNumber` suggests phone numbers from the address book.
For login fields, .username, .password, and .newPassword are intended. The .username type activates the iCloud password manager, which offers saved credentials. A field with .newPassword type initiates strong password generation via iCloud Keychain on first input.
Starting with iOS 17, Apple added .oneTimeCode for SMS confirmation codes and .shipmentTrackingNumber for package tracking. The .oneTimeCode type automatically recognizes codes from messages and offers them in the QuickType bar without needing to open the Messages app.
| Category | Types | iOS |
|---|---|---|
| Identification | .name, .givenName, .familyName, .nickname | 5+ |
| Contacts | .emailAddress, .telephoneNumber, .fullStreetAddress | 5+ |
| Credentials | .username, .password, .newPassword | 5+ |
| Location | .location, .city, .state, .postalCode | 10+ |
| Card Data | .creditCardNumber, .creditCardSecurityCode | 12+ |
| One-Time Codes | .oneTimeCode | 17+ |
Each type is represented by a string constant, but they should be compared using the == operator, not via rawValue. iOS may add new types in future versions, so always use a default branch in switch-case statements.
UIKeyboardType and UITextContentType work together: keyboard type determines the keyboard layout, while content type adds additional buttons in the QuickType bar. If a content type is set, iOS may override the keyboard type for optimal input. For example, with `.emailAddress` type, the keyboard automatically shows the @ symbol on the main layer.
For a field with .telephoneNumber type, iOS switches the keyboard to the phone layout regardless of the set keyboard type. This behavior cannot be disabled — the system considers content type priority higher than explicit keyboard configuration. Developers do not need to configure both properties.
.URL and .emailAddress types add .com and @ buttons to the keyboard respectively. The .decimalPad type with .creditCardNumber content type shows a numeric keyboard with a decimal separator, which is convenient for entering amounts and card numbers. According to Apple Human Interface Guidelines, users expect the keyboard to match the type of data being entered, not the other way around.
An exception is .oneTimeCode — this type does not change the keyboard layout but activates the QuickType bar with codes from SMS. The user sees a code suggestion above the keyboard and can insert it with one tap. The mechanism works only for fields that become first responder after receiving an SMS.
Autofill in iOS uses Text Content Type to match input fields with data from iCloud Keychain and ASCredentialProviderViewController. The system analyzes all fields on the screen, determines their semantic types, and offers the corresponding saved data. Without correctly specified types, autofill is not activated.
For autofill to work, three conditions must be met. First, the field must have a correct UITextContentType. Second, the screen must contain at least two fields with different types (e.g., .username and .password). Third, the app must support Associated Domains with the webcredentials entitlement for synchronization with a website.
The Keychain uses content type to classify saved records. If a field is marked as .password, the system saves the entered value in iCloud Keychain and offers it on the next login. Fields with .creditCardNumber type are automatically saved to Wallet after Face ID confirmation.
For one-time codes with .oneTimeCode type, iOS 17 uses the new AutoFill OTP mechanism, which does not require direct SMS access. The system intercepts codes from messages at the operating system level and passes them to the app via the QuickType bar, bypassing message content reading by the app.
Basic Text Content Type configuration in Swift is done through the textContentType property in code or via Interface Builder. In code, assigning a constant takes one line, while in IB the desired type is selected from a dropdown in the attributes inspector.
let emailField = UITextField()
emailField.textContentType = .emailAddress
emailField.placeholder = "example@domain.com"
let passwordField = UITextField()
passwordField.isSecureTextEntry = true
passwordField.textContentType = .newPassword
For programmatic login form creation with autofill, use both fields with different content types. The system automatically links them as login and password. If the app supports biometric login, add a field with .username type for correct account recognition.
class LoginViewController: UIViewController {
@IBOutlet var usernameField: UITextField!
@IBOutlet var passwordField: UITextField!
override func viewDidLoad() {
super.viewDidLoad()
usernameField.textContentType = .username
passwordField.textContentType = .password
passwordField.autocorrectionType = .no
}
}
For a one-time code input field from SMS, specify the .oneTimeCode type. The system will automatically suggest the code in the QuickType bar after receiving it. The developer does not need to request SMS read permission or implement custom message parsing.
let otpField = UITextField()
otpField.textContentType = .oneTimeCode
otpField.keyboardType = .numberPad
otpField.placeholder = "Code from SMS"
For iOS 17+, the .oneTimeCode type supports automatic filling without field focus. If the user receives an SMS with a code, iOS offers it on the lock screen, and after unlocking, the code is automatically inserted into the active field with the corresponding content type.
Choosing the correct type directly affects form conversion and user experience. Apple strongly recommends specifying the most specific type available. For example, use .givenName for the name field rather than the generic .name — this allows the system to suggest autofill from contacts with the correct name.
Avoid a common mistake — setting .emailAddress for a username field. If the app uses email as a login, specify .username for the login field and .password for the password field. The .emailAddress type is intended exclusively for email input as contact data, not as an identifier.
For forms with multiple fields of the same type (e.g., two email addresses), set the .textContentType property for each field but add different accessibilityIdentifier values. This helps VoiceOver correctly announce the fields, although the autofill system may suggest the same value for both fields.
Test autofill on a real device with a populated keychain. The simulator does not fully support iCloud Keychain, and autofill behavior may differ. According to Apple Developer Forums (2025), the most common autofill issues arise precisely from incorrectly specified content type.
Frequently Asked Questions
UITextContentType defines the semantic data type, while UIKeyboardType defines the keyboard layout. Content type can override keyboard type for optimal input.
Autofill is activated by .username, .password, .newPassword, .emailAddress, .telephoneNumber, and .creditCardNumber types. The system matches these types with data from the keychain.
Yes, WKWebView supports Text Content Type for HTML fields with the autocomplete attribute. iOS automatically maps autocomplete attributes to UITextContentType types.
Yes, UITextView also inherits UITextInputTraits and supports the textContentType property. This is useful for multiline input fields for contact data.
The system may suggest incorrect data for autofill or nothing at all. For example, a username field with .emailAddress type might suggest an email instead of a login.
Summary
We will develop a mobile application turnkey
IT Sectr creates iOS and Android applications for startups and businesses since 2017. We will advise you and propose the best solution.
Read also