[Bug]: Nextcloud iOS app falls back to native file download instead of Collabora editor (regression after #5838)

[anym001]

Describe the bug
After the fix in PR #5838 (merged Jul 9, 2026), the previous 404 on the directEditing token redemption endpoint is resolved. However, a different, subsequent issue remains: the Nextcloud iOS app does not attempt to use the Collabora editor at all — it falls back to a native iOS share sheet ("Copy to Numbers") instead of opening the document for editing.

Opening the same document via mobile Safari works perfectly. The issue is specific to the Nextcloud iOS app.

To Reproduce

1. Set up Nextcloud Office with a self-hosted Collabora server (connection test passes, occ richdocuments:activate-config passes all checks)
2. Open the Nextcloud iOS app
3. Navigate to a .xlsx or .docx file
4. Tap the file to open it

Expected behavior
The Nextcloud iOS app opens the document in the Collabora editor (as it does in the mobile browser).

Screenshots
N/A

Client details:

• OS: iOS 26.5.2
• Browser: Nextcloud iOS app (not browser-based)
• Version: Nextcloud iOS app 34.1.0
• Device: iPhone

Server details

Operating system: Unraid (Linux), Docker-based

Web server: Apache (mod_php)

Database: MariaDB

PHP version: 8.3

Nextcloud version: 34.0.2

Version of the richdocuments app: 11.1.0 (includes fix from PR #5838)

Version of Collabora Online: CODE 26.04.2.4 (self-hosted, external Docker container, nginx reverse proxy)

Configuration of the richdocuments app

{
    "apps": {
        "richdocuments": {
            "canonical_webroot": "",
            "disable_certificate_verification": "",
            "doc_format": "ooxml",
            "enabled": "yes",
            "external_apps": "",
            "installed_version": "11.1.0",
            "public_wopi_url": "https://office.mydomain.at",
            "types": "filesystem,prevent_group_restriction",
            "wopi_allowlist": "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16",
            "wopi_url": "https://office.mydomain.at"
        }
    }
}

Logs

Access log analysis

When opening via the iOS app, the app calls:

GET /ocs/v2.php/apps/files/api/v1/directEditing → 200 OK

...but never follows up with POST /apps/richdocuments/token. It falls back to a native file download instead.

When opening via Safari (mobile browser), the full WOPI flow executes correctly:

POST /apps/richdocuments/token → 200
GET /index.php/apps/richdocuments/wopi/files/{id} → 200 (COOLWSD Agent)
GET /index.php/apps/richdocuments/wopi/files/{id}/contents → 200 (COOLWSD Agent)
POST /index.php/apps/richdocuments/wopi/files/{id} → 200 (COOLWSD Agent)

occ richdocuments:activate-config output

✓ Reset callback url autodetect
Checking configuration
🛈 Configured WOPI URL: https://office.mydomain.at
🛈 Configured public WOPI URL: https://office.mydomain.at
🛈 Configured callback URL:
✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 26.04.2.4

Nextcloud log (data/nextcloud.log)

No relevant errors during the failed iOS app open attempt. The only logged error occurs during thumbnail generation (fclose(): supplied resource is not a valid stream resource in RemoteService.php), which is a separate, pre-existing issue.

---

Additional context

This is not the same issue as #5758 / PR #5838, which fixed a 404 on the token redemption endpoint (/apps/files/directEditing/{token}). In this case, the iOS app fetches directEditing capabilities successfully but then does not initiate the Collabora flow at all — POST /apps/richdocuments/token is never called.

Server-side configuration is confirmed correct. The issue appears to be on the iOS app side: it receives the directEditing capabilities response but does not act on them to open the document via Collabora.