Two mobile patch releases landed within three days of each other at the end of August: Android 4.8.4 on August 31, and iOS 12.7.1 on September 2. Neither is a big release on its own. Android fixes one thing. iOS fixes four things and adds one configuration option. But they’re both patches worth installing promptly, for different reasons, so we’re covering them together.
Android 4.8.4: closes an app-lock bypass
Repository: owncloud/android · Tag: v4.8.4 · Released: August 31, 2026 by Jorge Aguado Recio (@joragua) · Release page
This release contains exactly one change: a fix for an app-lock bypass reported in issue #4958, ten days after 4.8.3 shipped. If you use the passcode, pattern, or biometric lock on the ownCloud Android app, this is the release to install.
What was wrong
A user running 4.8.3 found that pressing the device’s back button, or using the back gesture, while the app-lock prompt was on screen would dismiss the prompt and hand over access to the app without any PIN, pattern, or biometric check. They reported it on a Redmi Note 15 Pro+ running Android 16 with Xiaomi’s HyperOS 3.0.304, and noted the same steps didn’t reproduce the issue on a Redmi Note 11 Pro. That’s a useful data point, actually: it suggests the bug came down to how a particular device or Android build handled the back action while the lock screen was on top, rather than one bypass path guaranteed to work everywhere. The issue was filed against app version 4.8.3 with server version 10.16.4, labeled Security and Type:bug.
What changed
The release notes are a single line: “Prevent bypassing passcode, pattern and biometric lock.” There’s no code-level changelog beyond that, so we can’t tell you the exact mechanism of the fix, only that the reported path (dismissing the lock prompt via the system back action) no longer grants access. The tag carries a verified signature from Jorge Aguado Recio, who’s also the assignee on the underlying issue.
One honest gap here: the release doesn’t say which Android versions, manufacturers, or app-lock configurations were affected beyond the single device combination in the original report, and it doesn’t say whether the fix touches any other in-app navigation gesture. If your app lock is the only thing standing between someone and your files on a shared or lost device, treat this as a fix for a known, now-closed bypass, not a guarantee that no other one exists.
Who this affects, and upgrade notes
If you don’t have an app lock configured, this update has no functional effect on you beyond the version bump. If you do, especially on a device that could end up in someone else’s hands, install 4.8.4. There are no breaking changes, no migration steps, and no server-side component to this fix, it’s entirely client-side. The update path is whatever you already use: Play Store, F-Droid, or a manual APK install from the release assets.
iOS 12.7.1: File Provider fixes and Drive ID compatibility
Repository: owncloud/ios-app · Tag: v12.7.1 · Released: September 2, 2026 by Felix Schwarz (@felix-schwarz) · Release page
This one’s a genuine patch release: four bugfixes and one configuration enhancement across five merged pull requests since 12.7.0, no new headline feature. Three of the fixes are in File Provider, the extension that lets the iOS Files app (and anything else that talks to it) browse and manipulate ownCloud content like it’s local storage.
Recursive folder copy (#1557) is the fix worth knowing about if you move a lot of files around. Copying or pasting a full folder hierarchy through File Provider could silently drop files or subfolders along the way, so what you ended up with wasn’t the whole tree you asked for. 12.7.1 fixes the recursive copy path so a folder and everything under it moves as one unit.
Markup UI pinch conflict (#1560) fixes a gesture-recognition mix-up in the markup and annotation view, where a pinch-to-zoom gesture could get misread as a dismiss gesture and close the editor mid-edit. The two are now correctly told apart.
Web app icon retry loop (#1573) stops the app from endlessly retrying when a web app’s icon doesn’t exist on the server. It used to keep re-requesting a resource that was never going to resolve; now the retry loop terminates.
OCVault Drive ID compatibility (#1577) is the biggest change in this release. OCVault, the app’s local metadata and file store, assumed Drive IDs (the identifiers oCIS uses for spaces) followed a standard format. Some deployments don’t: Drive IDs can show up in non-standard formats, or exceed the 255-character filename limit APFS enforces. Either case could break local storage for that Drive, since OCVault uses the Drive ID as part of the on-disk path.
The fix handles this in two steps. Drive IDs that don’t match the expected character pattern get base64-encoded before use. Separately, any Drive ID that’s still too long after that (whether it started too long or became too long once encoded) gets replaced on disk with its SHA-256 checksum, while the original ID is preserved in a new metadata file at that Drive’s folder root, so it can still be mapped back correctly. Two related safety checks came along with it: items with no name are now rejected outright instead of being persisted in a broken state, and the app double-checks a parent folder’s location before removing it, so it doesn’t delete the wrong directory if paths shifted since it last looked.
Configurable web-app link handling (#1572) is the one enhancement, adding a new option, action.in-app-web-app-link-open-mode, that controls what happens when an in-app web app tries to open a link:
- with-default-browser (default) — asks whether to open the link in the device’s default browser
- navigate — asks whether the in-app browser hosting the web app should navigate to the link
- choice — asks the user to pick between the default browser and in-app navigation
- deny — blocks the link and tells the user
- silent-deny — blocks the link silently, effectively a no-op, and logs a debug message without the URL
Worth noting since it’s easy to assume otherwise: none of these modes silently redirect without asking, except silent-deny, which silently blocks. This is configuration-only. Nothing changes unless you set the option explicitly.
Upgrade notes
No breaking changes, no migration steps, a straightforward update over 12.7.0. If you run oCIS spaces with non-standard Drive ID formats or long space names, the Drive ID fix is the one to watch: existing local metadata for those Drives should carry over correctly after updating, since the fix preserves the original ID rather than discarding it.
Bottom line
Different urgency, same advice: update. Android 4.8.4 closes a real app-lock bypass with no downside to installing it. iOS 12.7.1 is lower-stakes but fixes annoying, occasionally data-affecting bugs (the recursive copy issue in particular), plus the Drive ID fix that matters if you’re running oCIS with anything but standard-format space identifiers.
You can find the links to download on the Mobile Apps page.
