This started after the app had previously worked normally for months. The issue has occurred across multiple Nextcloud iOS versions (34.1.x and now 35.0.0).
I initially suspected a server-side authentication/token issue, but extensive testing indicates that the permanent authentication token remains present and apparently valid on the Nextcloud server after the iOS app has lost the account.
Environment
Nextcloud Server: 34.0.2
Nextcloud iOS: 35.0.0
iOS: 26.6
Web server: Nginx
PHP: 8.3
Database: MariaDB
Redis enabled
Clean reproduction test
To exclude old app data/tokens, I performed the following:
Completely deleted the Nextcloud iOS app.
Rebooted the iPhone.
Deleted all old Nextcloud-iOS authentication tokens for the account from the server.
Reinstalled Nextcloud from the App Store.
Did NOT import/use the existing account offered by other Nextcloud apps.
Manually entered the server URL and performed a completely new login.
A single new permanent authentication token was created (ID 279).
Automatic photo/video upload was enabled again.
After approximately one day, opening the Nextcloud app again showed the login/setup screen. I did NOT log in again so that the server state could be examined.
Server-side token after the logout
Token 279 still existed:
type: 1 (permanent)
remember: 0
expires: NULL
version: 2
password_invalid: 0
password: present
private_key: present
public_key: present
password_hash: present
Therefore, the token had not been deleted, had no expiration timestamp and was not marked as invalid.
Last requests from the iOS app
Immediately before the app stopped communicating with the server, authenticated requests were still successful:
PROPFIND /remote.php/dav/files/ 207
GET /status.php 200
POST /index.php/core/wipe/check 400
DELETE /ocs/v2.php/apps/notifications/api/v2/push 202
GET /ocs/v2.php/cloud/users/ 200
GET /ocs/v1.php/cloud/capabilities 200
GET /ocs/v2.php/apps/files/api/v1/directEditing 200
GET /ocs/v2.php/apps/user_status/api/v1/user_status 200
Immediately afterwards:
GET /ocs/v2.php/apps/notifications/api/v2/notifications 499
GET /ocs/v2.php/apps/notifications/api/v2/notifications 499
GET /ocs/v2.php/apps/dashboard/api/v1/widgets 499
After these three HTTP 499 responses, there were no further requests from Nextcloud-iOS/35.0.0.
There were no HTTP 401 or 403 responses before the account disappeared from the app.
The Nextcloud server log also contained no corresponding error at this time.
The HTTP 499 responses indicate that the client closed the requests before Nginx could return a response.
Additional observations
Similar behavior occurred with previous Nextcloud iOS versions, including 34.1.0, 34.1.2 and 34.1.4.
The app also performs:
DELETE /ocs/v2.php/apps/notifications/api/v2/push
around these events. However, this request also occurs during normal sessions and is followed by successful requests, so it does not appear to be the cause by itself.
/index.php/core/wipe/check returns HTTP 400 both during normal operation and around the affected event.
The issue therefore appears to be client-side: the iOS app seems to lose/remove its local account or credential state even though the corresponding permanent authentication token remains available and valid on the Nextcloud server.
Expected behavior
The account should remain configured in the iOS app and the permanent app token should continue to be used until the user explicitly logs out, removes the account, or the server invalidates the token.
Actual behavior
After approximately 1–2 days, the app unexpectedly returns to the login/setup screen and requires the account to be configured/authenticated again.
This is reproducible even after completely deleting/reinstalling the iOS app and removing all previous Nextcloud-iOS authentication tokens from the server.
Please let me know if additional iOS logs, server logs or database information would be useful. I can reproduce the issue and collect diagnostics before logging in again.
This started after the app had previously worked normally for months. The issue has occurred across multiple Nextcloud iOS versions (34.1.x and now 35.0.0).
I initially suspected a server-side authentication/token issue, but extensive testing indicates that the permanent authentication token remains present and apparently valid on the Nextcloud server after the iOS app has lost the account.
Environment
Nextcloud Server: 34.0.2
Nextcloud iOS: 35.0.0
iOS: 26.6
Web server: Nginx
PHP: 8.3
Database: MariaDB
Redis enabled
Clean reproduction test
To exclude old app data/tokens, I performed the following:
Completely deleted the Nextcloud iOS app.
Rebooted the iPhone.
Deleted all old Nextcloud-iOS authentication tokens for the account from the server.
Reinstalled Nextcloud from the App Store.
Did NOT import/use the existing account offered by other Nextcloud apps.
Manually entered the server URL and performed a completely new login.
A single new permanent authentication token was created (ID 279).
Automatic photo/video upload was enabled again.
After approximately one day, opening the Nextcloud app again showed the login/setup screen. I did NOT log in again so that the server state could be examined.
Server-side token after the logout
Token 279 still existed:
type: 1 (permanent)
remember: 0
expires: NULL
version: 2
password_invalid: 0
password: present
private_key: present
public_key: present
password_hash: present
Therefore, the token had not been deleted, had no expiration timestamp and was not marked as invalid.
Last requests from the iOS app
Immediately before the app stopped communicating with the server, authenticated requests were still successful:
PROPFIND /remote.php/dav/files/ 207
GET /status.php 200
POST /index.php/core/wipe/check 400
DELETE /ocs/v2.php/apps/notifications/api/v2/push 202
GET /ocs/v2.php/cloud/users/ 200
GET /ocs/v1.php/cloud/capabilities 200
GET /ocs/v2.php/apps/files/api/v1/directEditing 200
GET /ocs/v2.php/apps/user_status/api/v1/user_status 200
Immediately afterwards:
GET /ocs/v2.php/apps/notifications/api/v2/notifications 499
GET /ocs/v2.php/apps/notifications/api/v2/notifications 499
GET /ocs/v2.php/apps/dashboard/api/v1/widgets 499
After these three HTTP 499 responses, there were no further requests from Nextcloud-iOS/35.0.0.
There were no HTTP 401 or 403 responses before the account disappeared from the app.
The Nextcloud server log also contained no corresponding error at this time.
The HTTP 499 responses indicate that the client closed the requests before Nginx could return a response.
Additional observations
Similar behavior occurred with previous Nextcloud iOS versions, including 34.1.0, 34.1.2 and 34.1.4.
The app also performs:
DELETE /ocs/v2.php/apps/notifications/api/v2/push
around these events. However, this request also occurs during normal sessions and is followed by successful requests, so it does not appear to be the cause by itself.
/index.php/core/wipe/check returns HTTP 400 both during normal operation and around the affected event.
The issue therefore appears to be client-side: the iOS app seems to lose/remove its local account or credential state even though the corresponding permanent authentication token remains available and valid on the Nextcloud server.
Expected behavior
The account should remain configured in the iOS app and the permanent app token should continue to be used until the user explicitly logs out, removes the account, or the server invalidates the token.
Actual behavior
After approximately 1–2 days, the app unexpectedly returns to the login/setup screen and requires the account to be configured/authenticated again.
This is reproducible even after completely deleting/reinstalling the iOS app and removing all previous Nextcloud-iOS authentication tokens from the server.
Please let me know if additional iOS logs, server logs or database information would be useful. I can reproduce the issue and collect diagnostics before logging in again.