[marinofaggiana]

Replace the legacy TOPasscodeViewController implementation with shared SwiftUI passcode components for the main app, Share Extension and E2EE authentication, while preserving existing Keychain credentials and preferences.

Behavior

• Present the mandatory app lock in a dedicated window per scene, above existing sheets, alerts and app popups.
• After three failed attempts, including attempts to change or disable the passcode, lock the app instead of allowing users to close the authentication sheet and continue accessing files. Expiring the delay only enables another authentication attempt; it does not unlock the app. The requirement persists across backgrounding and relaunch, even when passcode-at-startup is disabled.
• Preserve the cumulative failure count across temporary lockouts. The default policy remains a 60-second pause after every three errors, with an optional app reset at ten errors. Reset threshold and delay use the branding parameters; successful authentication clears both counters.
• Request biometric authentication when enabling Touch ID / Face ID in Settings, including the initial Face ID permission request when applicable. Enable the preference only after successful authentication; cancellation or failure leaves it disabled.
• Add error haptics and a synchronized shake of the error message and six passcode dots for incorrect codes and mismatched confirmation codes. Respect Reduce Motion.
• Use “Turn passcode on” / “Turn passcode off” action labels and larger keypad buttons.
• Keep Share Extension authentication inside its panel, with scrolling for smaller layouts and a close button that cancels the entire extension without exposing protected content.
• Remove obsolete passcode wrappers and update third-party acknowledgements.

UI tests and CI

Add seven XCUITests in PasscodeUITests:

Scenario	Verification
Create, change and disable	Reject the old code after changing it; disable protection using the new code.
Disable-flow lockout	Accumulate failures across separate sheet openings, enforce the mandatory app lock, and preserve the original deadline across backgrounding and process relaunch.
Change-flow lockout	Preserve failures across reopening, make Settings inaccessible at the threshold, and require successful authentication even after the delay expires.
Mandatory app lock	Prevent dismissal and interaction with the underlying Settings screen after returning from background.
Existing sheet	Cover Acknowledgements and preserve the sheet after unlocking.
Existing alert	Cover the Clear cache confirmation and preserve the alert after unlocking.
Reset threshold	Enter ten incorrect codes across three lockouts, verify cleanup completes, then relaunch without setup flags and verify login is required and the old passcode is gone.

The main xcode.yml workflow conditionally includes these tests when the PR changes passcode code, Settings integration, preferences, scene/app lifecycle, Share integration, branding, UI-test infrastructure, project configuration or the workflow itself. Otherwise it skips PasscodeUITests and continues running the other enabled tests. There is no separate passcode workflow.

The test environment uses an English simulator and server. The login helper reuses an existing account or performs the real web login, including handling the password-saving prompt. Removing the asynchronous account deletion at launch avoids opening an interface whose account is being deleted underneath it.

Debug-only test setup resets passcode state before each test. The reset-threshold test uses 10-second lockouts while keeping all ten failures and three lockouts; persistence tests retain the normal 60-second delay. With UI_TESTING_NO_EXIT, real reset cleanup completes and exposes a completion marker before XCTest terminates the app itself, avoiding the exit(0) / Thread Sanitizer finalization issue. Normal app execution retains exit(0).

CI uploads TestResult.xcresult even after test failure when available. The bundle includes test results and retained diagnostic screenshots/UI hierarchies for the instrumented failure paths. Console output is available in the Run Xcode Test step.

Running locally

1. Use Xcode 27.1 or newer and a dedicated simulator with its system language set to English. The reset test deliberately removes the app’s local data and credentials.
2. Start a Nextcloud stable30 test server at http://localhost:8080, with admin / admin. Tests/Server.sh provides the Docker setup. Keep Docker and the server running throughout the suite.
3. Verify the server responds and uses English:

   docker exec --user www-data xcode-test-server php /var/www/html/occ config:system:set force_language --value=en
   curl --fail --show-error http://localhost:8080/status.php

4. In Xcode, select the Nextcloud scheme and the dedicated simulator. In the Test navigator (⌘6), run NextcloudUITests → PasscodeUITests. Individual tests can also be run independently.

Additional device verification

• Face ID / Touch ID authorization, successful authentication, rejection and cancellation.
• Share Extension layout and cancellation on iPhone, iPad and changing window sizes, including access to the full keypad after cancelling biometrics.
• E2EE authentication and independent app locking across multiple iPad scenes.
• Error haptics, shake animation and Reduce Motion.

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[mpivchev]

1. Add vibration and shake the "Incorrect password" text and "Passcodes don't match" text.
2. Enabling Touch/Face Id does not ask for permission. Only after reopening the app. Permission should be asked when enabling it.
3. Rename "Lock: On" to "Turn passcode on" and "Turn passcode off"
4. Pressing Change passcode and typing wrong passcode would lock you of more attempts, but you can close the window and continue using the app. The lock should make the app unusable. Please also test this with UI tests.

[mpivchev]

Actually now that I think about it, to me the "too many attempts" 60 seconds cooldown is a bit useless. What is the point of it? We are not really doing anything security wise.

We can remove it and instead turn on the "reset data after 10 attempts" on always?
@marinofaggiana @tobiasKaminsky what do you think?

[mpivchev]

@marinofaggiana the UI tests should be included in the CI. Also keep in mind UI tests must be maintained with time so they are always green.

[marinofaggiana]

1. Add vibration and shake the "Incorrect password" text and "Passcodes don't match" text.
2. Enabling Touch/Face Id does not ask for permission. Only after reopening the app. Permission should be asked when enabling it.
3. Rename "Lock: On" to "Turn passcode on" and "Turn passcode off"
4. Pressing Change passcode and typing wrong passcode would lock you of more attempts, but you can close the window and continue using the app. The lock should make the app unusable. Please also test this with UI tests.

done.

[mpivchev]

@marinofaggiana the UI tests should be included in the CI. Also keep in mind UI tests must be maintained with time so they are always green.

There are two reasons why I did not include the tests in the CI. The first is that they take a long time to run (due to timeouts, retries, etc.), which would result in an excessively long wait each time. The second is that after the final attempt, the tenth one, the app automatically resets, which causes the test to exit as "failed" (exit(0)).

Right, but in this case the UI tests will be not super useful as no one will run them (let's be honest). You can add the UI tests as a separate CI workflow and either:

1. Add a check to only run the workflow if the passcode UI was changed. This is possible via defining the Passcode files folder. This way if no modifications are done on the passcode UI the UI tests will be skipped. IMO this is the best way.
2. You can make the workflow manual, so it is not run automatically.

Claude can do this.

[marinofaggiana]

@marinofaggiana the UI tests should be included in the CI. Also keep in mind UI tests must be maintained with time so they are always green.

They require so much time, far too much time!

[marinofaggiana]

@marinofaggiana the UI tests should be included in the CI. Also keep in mind UI tests must be maintained with time so they are always green.

There are two reasons why I did not include the tests in the CI. The first is that they take a long time to run (due to timeouts, retries, etc.), which would result in an excessively long wait each time. The second is that after the final attempt, the tenth one, the app automatically resets, which causes the test to exit as "failed" (exit(0)).

Right, but in this case the UI tests will be not super useful as no one will run them (let's be honest). You can add the UI tests as a separate CI workflow and either:

1. Add a check to only run the workflow if the passcode UI was changed. This is possible via defining the Passcode files folder. This way if no modifications are done on the passcode UI the UI tests will be skipped. IMO this is the best way.
2. You can make the workflow manual, so it is not run automatically.

Claude can do this.

good idea. I do