[BK0STAR]

Problem

Complements nab138/isideload#9 on the app side. iloader's 2FA bridge only handled SubmitCode, while isideload also requires SendSms, SendToDevices, ResendCode and Abort. The frontend ignored the methods/numbers sent by the backend and only showed a code field (see #319).

Fix

• Tauri backend (account.rs): a typed async request_two_factor_response exchanging TwoFactorCallbackParams/TwoFactorCallbackResponse over the 2fa-required/2fa-response events, with a timeout (300 s) and a clean Abort path.
• UI (AppleID.tsx / .css): trusted-method and trusted-number pickers, resend code, send to devices, last_error display, and associated styles.
• Locales: EN/FR strings for the new screens.
• Tests: parsing of all TwoFactorCallbackResponse variants.

Verification

• bun run build (tsc + vite): OK.
• Tested end-to-end with the patched isideload: at -22979 throttling, the UI shows the code-entry field with the selected number kept; login completes via a trusted-device code. ✅

⚠️ Dependency — merge AFTER nab138/isideload#9

This PR is a draft: Cargo.toml must point to the fixed isideload commit once nab138/isideload#9 is merged. I will update the dependency (branch = "apple-codesign-quick" → new commit) before marking it ready for review.

Fixes #319

[nab138]

Hello,
I don't have time to fully review a PR of this size right now, but just a few things to note:

• I have already implemented the full set of 2fa options for iloader-next, but I didn't backport the UI to this version of iloader. I am open to merging this pr to implement it, but I'm not really looking to push updates to this version of iloader atm.
• While tests are probably something isideload/iloader could greatly benefit from, I'm not sure it makes sense to start implementing them in this PR. Maybe we can re-visit this in a new pr, but for now I would appreciate if they were removed.
• How much AI was used for this PR? The combination of this PR and the one in isideload were put together very quickly as the updated 2FA callback was added to isideload very recently, and the PR descriptions do seem like AI to me. To be clear, I am not against AI use in general, but I will not be merging a completely vibecoded PR.

Thank you for your time and contribution!

[BK0STAR]

Hello, and thanks for the feedback.

To answer your question directly: I used AI to help me move faster, as many developers do today. It helped with exploring the codebase, planning, and drafting parts of the implementation.

I still made the technical decisions, reviewed and adjusted the changes, ran the builds and tests, and tested the 2FA flow end to end. The result was also independently tested on Linux.

I understand your concern about a “vibecoded” PR. This was not code generated and submitted blindly, and I’m happy to remove the tests and keep the PR focused on the 2FA backport.

Thanks again for taking the time to look at it.

[tripflow-nemt]

I’m hitting this in iLoader 2.3.10 on macOS, and it’s blocking SideStore setup. iLoader displays the verification-code prompt, but no code arrives. Submitting a code produces “Cannot submit code without knowing which method to use.”

The available anisette servers have also been returning 502 or “No space left on device” errors, leaving me without a working login path.

Could this 2FA fix be prioritized for the current release? A local patch passes build and regression checks, but successful end-to-end login is still unverified.