:thread: Autofill support on iOS

# compose-ios

[faogustavo]

🧵 Autofill support on iOS

[faogustavo]

Are there any plans to start adding support for autofill with ContentType on iOS?

[faogustavo]

I'm also noticing that password autofill works, but it does not fill the username/email field (I've tested using both the old and new APIs for autofill)

[Andrei Salavei]

Are there any plans to start adding support for autofill with ContentType on iOS?

Already done. Check it out Compose 1.9

I'm also noticing that password autofill works, but it does not fill the username/email field (I've tested using both the old and new APIs for autofill)

This one a bit more tricky because iOS uses internal heuristic to fill email/password fields, but we're aware about it.

[faogustavo]

Check it out Compose 1.9

Does beta03 already have this? I'm using this one. But if it's in some dev build I can add the repository to test

[Andrei Salavei]

Yes, it should. https://youtrack.jetbrains.com/issue/CMP-7882/Provide-API-to-configure-TextField-IME-natively
Check the IosImeOptionsExample in the PR for more info how to use it.

[Nicolas Patin]

Hey @Andrei Salavei, do you have any update for autofill on the username/email field ? I'm on cmp 1.10.1 and I reproduce @faogustavo behaviour.
Thanks!

[Andrei Salavei]

Hi! Semantic autofill for individual fields is already working. Autofill that fills both - email and password is in our plans. And AutoFill button for text field support is on the way.

[Thomas S.]

Hi @Andrei Salavei Salavei,
I can confirm that field-by-field autofill currently works fine for us if the user has manually saved their credentials in the iOS Passwords app beforehand.
However, I have a specific question regarding the other side of the process: the auto-save prompt (CMP-5802). We are trying to trigger the iOS "Save Password" keychain popup when a user successfully logs in or registers for the first time. Since iOS relies on its internal heuristic tracking native `UITextField`s to trigger this prompt, and considering the UIKitTextInputService refactoring is still pending, is there any known workaround we could implement in the meantime? For instance, is it a viable temporary solution to use UIKitView interop to wrap native iOS text fields just for our Login screen, or is it better to just wait for the official Compose implementation?
Thanks

[Andrei Salavei]

Hi @Thomas S.,

is there any known workaround we could implement in the meantime

No idea TBH. I didn't try any solutions yet.

For instance, is it a viable temporary solution to use UIKitView interop to wrap native iOS

From the first look, that worth trying - create two hidden UITestField's with email/password types and make password "secured", also add code to copy text from login and password compose text fields to the native ones. Please tell me if it will work in your project.

[Thomas S.]

@Andrei Salavei,
Yes, wrapping native iOS fields via UIKitView works perfectly!
Instead of using hidden `UITextField`s (which can be flaky with iOS focus and autosave heuristics), I replaced the Compose BasicTextField with a transparent native UITextField only for auth fields on iOS.
The architecture:
• Common Wrapper: Handles all UI decoration (labels, borders, icons).
• Input Area (expect/actual):
Android & Non-Auth iOS: Uses the standard Compose BasicTextField.
iOS Auth Fields (Email/Password): Renders a UIKitView with a UITextField.
The user interacts directly with a real native field (perfect for focus/return key handling), iOS reads the correct semantics (UITextContentTypeUsername/Password), and the Keychain prompt is triggered 100% of the time.
Hope this helps anyone waiting for an official fix!

[Andrei Salavei]

Happy to hear! Thank you!
I would very appreciate if you can write your solution with code samples in the ticket - https://youtrack.jetbrains.com/issue/CMP-5802/Support-Auto-save-and-auto-update-password-prompts-on-iOS.
Most likely there will be other folks who want to re-use this solution as well and be very grateful to you.