Set up WebDAV on iPhone and iPad: connecting Nextcloud, Synology and Hetzner

You run a Nextcloud, a Synology NAS or a Hetzner Storage Box. On your computer it has worked for years — and then you try to open the same files on your iPhone and hit an error message that tells you exactly nothing. “Connection failed”, that’s it. This isn’t bad luck, and usually it isn’t your server either: iOS doesn’t ship with a WebDAV client. The Files app can mount SMB shares via “Connect to Server” — WebDAV simply isn’t on the menu. So you need an app from the App Store, the exact server URL including its path prefix, and, as soon as two-factor authentication is on, an app password instead of your regular one.

Why the iOS Files app isn’t enough

On a Mac you type a WebDAV address into the Finder and you’re in. On an iPhone that path doesn’t exist. Apple’s Files app offers only SMB under “Connect to Server” — the protocol from the Windows world that works well on a local network, but that you never want to expose to the open internet.

That’s exactly why WebDAV is so popular for remote access: it runs over plain HTTPS on port 443, gets through every firewall and needs no VPN tunnel. The catch is that the client side has to be handled by a dedicated app. People who don’t know this spend hours hunting for a server-side bug that was never there.

The right WebDAV URL — where most setups fail

The most common cause of “it doesn’t work” is mundane: someone enters the address of the web interface instead of the WebDAV endpoint. Those are two different things on the same server.

The Nextcloud paths are in the official Nextcloud documentation, the Storage Box address and the CNAME caveat in Hetzner’s WebDAV docs, the Synology ports in the Knowledge Center article on the WebDAV Server package, and the password rule in Koofr’s help center.

One detail people routinely miss: on Nextcloud, USERNAME is the internal username — not necessarily your email address, and not the display name. If you sign in with your email address, the two can diverge, and you’ll get a 404 despite perfectly correct credentials.

Auth variants: why your password suddenly stops working

WebDAV almost always authenticates via HTTP Basic Auth — username and password travel with every request, protected by TLS. It’s unglamorous and works everywhere. The catch: Basic Auth has no concept of a second factor.

So on Nextcloud, the moment you turn on two-factor authentication, the server rejects your normal account password for WebDAV. You need an app password, generated under Settings → Security — a long random string you paste into the app once. That’s not a security downgrade, quite the opposite: you can revoke that one string if a device goes missing, without touching your account password.

Koofr goes a step further and requires an application-specific password for every WebDAV connection, whether or not you use two-factor. On a Hetzner Storage Box it’s worth creating a sub-account limited to one directory for mobile access, rather than storing your main credentials on a phone.

And one more classic: if there’s a reverse proxy in front of your server, it can swallow the Authorization header unless it’s explicitly passed through. Then no password ever reaches the backend — and you keep getting 401s even though everything is correct.

Certificates: the second most common reason nothing works

On a desktop you click a certificate warning away and carry on. On iOS the connection just drops. Three cases show up over and over:

• A self-signed certificate. Every NAS ships with one. iOS doesn’t trust it — rightly so, because without an extra check the connection could be silently redirected while you’re out and about. The clean fix is a real certificate, for example via Let’s Encrypt straight from DSM. The pragmatic fix is an app that remembers the certificate on first connect and alerts you if it ever changes.
• An incomplete certificate chain. The server sends its own certificate but not the intermediate. On a computer this often goes unnoticed, because the browser has the missing piece cached from earlier visits or fetches it on the fly. A freshly set-up iPhone has no such cache — hence the confusing verdict “the site loads in Safari, but the app won’t connect”.
• A certificate issued for the wrong name. You connect via the local IP or nas.local, but the certificate says nas.example.com. Formally a correct rejection, practically annoying — always use the hostname the certificate was issued for.

What the status codes are telling you

The 405 is the most instructive case: WebDAV is HTTP with extra methods. Put a reverse proxy in front of your server that only allows GET and POST, and you end up with a server that looks perfect in a browser and is completely dead for WebDAV.

Connecting from outside — the Synology special case

One pattern keeps coming up: the connection works on the home Wi-Fi but not on cellular. Usually the client has a local IP stored that simply doesn’t exist outside that network.

Synology adds a twist: QuickConnect doesn’t carry WebDAV. Synology documents a list of its own packages that QuickConnect supports — WebDAV isn’t on it. For access from outside you need a real DDNS name with port forwarding for the WebDAV port, or a VPN into your home network. Without knowing that, you can spend an evening retyping credentials while the server simply isn’t reachable from the outside at all.

And if you do open the port: HTTPS only, never the plain HTTP port. Basic Auth over unencrypted HTTP means your password is readable in every open Wi-Fi you touch.

Which app to use — and what to look for

The App Store has several decent WebDAV clients, and the right pick depends on what you actually want to do. These are the points that make a difference day to day:

• Streaming instead of downloading. A video archive on your NAS isn’t much use if the app has to pull every file down in full first.
• How it handles certificates. An app that responds to a self-signed certificate with “turn off validation? yes/no” is dangerous. Deliberately remembering the certificate and raising an alarm on change is far better.
• Where the passwords live. Credentials belong in the system keychain, not in an app database.
• A real iPad layout. A scaled-up iPhone view on an iPad gets tiring fast.
• Offline behaviour. Without pinned files you’re staring at an empty list on the train.

Because those exact points bothered us, we built our own app: WebDAV Browser for iPhone and iPad. It ships with presets for nine providers, secures self-signed certificates via trust-on-first-use with SHA-256 pinning and raises an alarm when a certificate changes. Passwords live exclusively in the iCloud Keychain, search and text recognition run entirely on-device, and videos stream straight from the server. It requires iOS 26, is available in up to 14 languages, and the free version is fully usable with one server connection. It’s one option among several — but one where we can justify every design decision.

When WebDAV isn’t the right answer at all

Sometimes the wish behind “we need the files on our phones” is really something else. If field technicians should upload photos tied to a specific job, if inspection reports need structured capture, or if colleagues may only see certain folders, a file browser is the wrong tool. What you want isn’t a folder tree — it’s a process, with forms, permissions and a link into your existing system.

That’s the point where a custom app starts to make sense. We build them in SwiftUI for iPhone and iPad and connect them to the systems you already run. For how such a project unfolds and what it costs, see our piece on what an iOS app really costs — and whether native or cross-platform is the better fit is covered in native app or cross-platform.

Stuck on a WebDAV connection, or realising you actually need more than file access? Tell us briefly what you’re trying to do. We’ll take an honest look in a free first conversation and tell you whether it’s a setting, the right app — or a piece of software of your own.

Frequently asked questions