Poorly Written
If you don’t complete the application in one step you get locked out for 24 hours. There’s no excuse these days to not be able to write an app that can pick up where you left off. Have to re-enter mailing address instead of just clicking same as billing? And can’t you pull that from DMV records? Blocks Apple auto-fill. Seriously, was this written by high schoolers as a side project?
Show more
Military User
Texas makes renewing everything required so easy and simple, I had to get my license I sent the DMV all my paperwork and I got everything back in about a week.
Terrible UX - This app should be burned to ground and rebuilt
I renewed vehicle registration through the official TxT app. The address was already on file from the account. The app still forced full manual re-entry of every field. There was no iOS autofill trigger—no address suggestion bar, no Contacts-backed completion, no saved-payment integration. Credit-card entry was equally manual and friction-heavy. The interface looks clean. The interaction design is absent.
This is not a minor inconvenience. iOS has offered address and payment autofill for years via UITextContentType (.addressCity, .postalCode, .creditCardNumber, .name, etc.), Password AutoFill, and the system contact/payment store. Nearly every competent app surfaces the keyboard’s autofill bar or the system sheet when a properly configured field is focused. TxT does not. Users who already authenticated, linked a vehicle, and supplied contact details are treated as if the account is empty. The “personalized account” and “securely store payment and contact information” claims in the app description are marketing language, not implemented behavior.
The renewal flow compounds the problem. Address fields that should pre-populate or offer one-tap reuse instead present blank or “new address” states. Users retype street, city, state, and ZIP multiple times across confirmation and billing screens. Credit-card fields frequently fail to accept input cleanly, reject valid numbers, or refuse to surface saved methods. Other users report the same pattern: the app asks to save payment details then discards them, forces re-entry on every subsequent vehicle, and erases form progress. A 24-hour lockout after incomplete sessions adds further friction for a process that should finish in minutes.
These are not exotic edge cases. They are the default path for a high-volume government transaction that millions of Texans must complete. The app’s visual design—clean dashboard, to-do list, sticker tracking—creates the appearance of modernity. Underneath is a form engine that does not reuse known state, does not expose system autofill, and does not respect the user’s existing data. The result is repeated typing of information the system already holds, on a platform whose OS has solved this problem.
The people who shipped and maintain this should be removed from the project. A competent iOS team would have set the correct content types, wired the address and payment keyboards, tested the renewal path with an existing account, and verified that stored data actually appears. An LLM given the current screen flow and a one-paragraph requirement (“pre-fill from account, enable system autofill, never re-ask for known address”) produces a more usable form in minutes. The gap is not technological complexity; it is basic competence and testing.
TxT demonstrates that a government digital service can look contemporary while delivering an experience that is slower and more error-prone than the paper process it replaced. The visual layer is present. The user-experience layer is not.
This is not a minor inconvenience. iOS has offered address and payment autofill for years via UITextContentType (.addressCity, .postalCode, .creditCardNumber, .name, etc.), Password AutoFill, and the system contact/payment store. Nearly every competent app surfaces the keyboard’s autofill bar or the system sheet when a properly configured field is focused. TxT does not. Users who already authenticated, linked a vehicle, and supplied contact details are treated as if the account is empty. The “personalized account” and “securely store payment and contact information” claims in the app description are marketing language, not implemented behavior.
The renewal flow compounds the problem. Address fields that should pre-populate or offer one-tap reuse instead present blank or “new address” states. Users retype street, city, state, and ZIP multiple times across confirmation and billing screens. Credit-card fields frequently fail to accept input cleanly, reject valid numbers, or refuse to surface saved methods. Other users report the same pattern: the app asks to save payment details then discards them, forces re-entry on every subsequent vehicle, and erases form progress. A 24-hour lockout after incomplete sessions adds further friction for a process that should finish in minutes.
These are not exotic edge cases. They are the default path for a high-volume government transaction that millions of Texans must complete. The app’s visual design—clean dashboard, to-do list, sticker tracking—creates the appearance of modernity. Underneath is a form engine that does not reuse known state, does not expose system autofill, and does not respect the user’s existing data. The result is repeated typing of information the system already holds, on a platform whose OS has solved this problem.
The people who shipped and maintain this should be removed from the project. A competent iOS team would have set the correct content types, wired the address and payment keyboards, tested the renewal path with an existing account, and verified that stored data actually appears. An LLM given the current screen flow and a one-paragraph requirement (“pre-fill from account, enable system autofill, never re-ask for known address”) produces a more usable form in minutes. The gap is not technological complexity; it is basic competence and testing.
TxT demonstrates that a government digital service can look contemporary while delivering an experience that is slower and more error-prone than the paper process it replaced. The visual layer is present. The user-experience layer is not.
Show more
Payment method
Should accept Apple Pay
Great service
Time saver
