iOS 26.6 CalDAV account remains inactive after successful discovery and OPTIONS on principal URL

Issues
1

Issue Description

A CalDAV account configured with the native iOS account setup is accepted during setup, but afterwards appears as “Inactive” and no calendars are synchronized.

The server is Stalwart 0.16.17 and the client is iOS 26.6 (23G71).

The account has MFA enabled, so a Stalwart application password is used for CalDAV. Authentication with the application password works correctly.

The issue was reproduced with a clean iOS setup after removing all existing Stalwart CalDAV and CardDAV accounts and rebooting the iPhone.

HTTP logging shows that iOS successfully performs CalDAV discovery, reaches the authenticated principal URL and receives a successful OPTIONS response advertising calendar-access. After that response, iOS stops and never requests the calendar-home-set.

Independent curl tests confirm that the principal, calendar home and actual calendar collection are accessible.

Expected Behavior

After successful CalDAV discovery, iOS should continue querying the authenticated principal, obtain the calendar-home-set, discover the available calendar collections and activate the CalDAV account.

Actual Behavior

The account setup completes without an authentication error, but the CalDAV account is then shown as “Inactive” in iOS Settings.

No calendar becomes available.

The request sequence from iOS stops immediately after a successful authenticated OPTIONS request to the discovered principal URL.

No subsequent PROPFIND for calendar-home-set is sent by iOS.

Reproduction Steps

  1. Use a Stalwart account with CalDAV available.
  2. Enable MFA for the account.
  3. Create a Stalwart application password.
  4. On an iPhone running iOS 26.6, add a CalDAV account.
  5. Enter the Stalwart HTTPS hostname as server.
  6. Enter the account email address as username.
  7. Use the Stalwart application password.
  8. Enable SSL on port 443.
  9. Save the account.
  10. The setup completes without an authentication error.
  11. Open the account again in iOS Settings.
  12. The account is shown as “Inactive” and no calendar is synchronized.

The issue was also reproduced after deleting all existing Stalwart CalDAV and CardDAV accounts from the iPhone and rebooting it before creating the CalDAV account again.

Manually setting the account URL to the calendar home or directly to the default calendar did not resolve the problem.

Relevant Log Output

Client:
iOS 26.6 (23G71)
User-Agent: iOS/26.6 (23G71) accountsd/1.0

Observed request sequence:

PROPFIND /.well-known/caldav
→ HTTP 307
→ Location: /dav/cal

PROPFIND /dav/cal
→ HTTP 207 Multi-Status

OPTIONS /dav/pal/user%40example[.]com/
→ HTTP 200 OK

After this OPTIONS request, no further CalDAV request is sent by iOS.

The OPTIONS response includes:

DAV: 1, 2, 3, access-control, extended-mkcol, calendar-access, calendar-auto-schedule, calendar-no-timezone, addressbook

Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, COPY, MOVE, MKCALENDAR, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL

The PROPFIND on /dav/cal returns:

<?xml version="1.0" encoding="UTF-8"?>

<D:multistatus xmlns:D=“DAV:”>
<D:response>
<D:href>/dav/cal/</D:href>
<D:propstat>
<D:prop>
<D:current-user-principal>
<D:href>/dav/pal/user%40example[.]com/</D:href>
</D:current-user-principal>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:principal-URL/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
</D:multistatus>

iOS clearly extracts the current-user-principal from this response because its next request is:

OPTIONS /dav/pal/user%40example[.]com/

That request receives HTTP 200 and advertises calendar-access, after which iOS stops.

Independent authenticated curl tests confirm that these resources are accessible:

/dav/pal/user%40example[.]com/
/dav/cal/user%40example[.]com/
/dav/cal/user%40example[.]com/default/

A PROPFIND on the principal correctly returns the calendar-home-set, and a Depth: 1 PROPFIND on the calendar home returns the actual calendar collection.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

MySQL

Blob Storage

MySQL

Search Engine

MySQL

Directory Backend

Internal

Additional Context

The mail server is a production Stalwart installation and mail services themselves are working normally.

The CalDAV problem is limited to the native iOS CalDAV account setup.

Authentication is not the issue:

  • The normal account password is correctly rejected because MFA is enabled.
  • The Stalwart application password authenticates successfully.
  • The same application password works in authenticated curl DAV tests.

The issue was reproduced with all other Stalwart DAV accounts removed from the iPhone, so concurrent CardDAV traffic can be excluded.

Caddy does not rewrite or filter DAV methods. The real iOS OPTIONS request reaches Stalwart and the successful HTTP 200 response, including the DAV capability headers, reaches the iPhone.

Security headers such as Content-Security-Policy and X-Frame-Options were also investigated. They do not block the native DAV requests.

The CalDAV hierarchy itself is functional when tested directly:

  • current-user-principal is returned
  • calendar-home-set is returned from the principal
  • the calendar home is accessible
  • the default calendar collection is accessible
  • calendar resources can be read

The unusual point is that iOS stops immediately after the successful OPTIONS request to the principal instead of continuing with a PROPFIND for calendar-home-set.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

2

Does your account have access to other shared accounts (such as groups or delegated accounts)? Apple Calendar does not support that so try with just one account and no shares.
If that is not the case, we will need logs from your Apple client. I am personally on iOS 16 and don’t have issues with our Stalwart v0.16.17 server.

As a side note, unfortunately the Apple calendar and contacts clients have multiple bugs and this might be just another one of them. In fact, the “assisted discovery” mode in Stalwart was added in order to deal with an Apple Calendar bug.

3

Thanks for the quick response.

No, this account does not have access to any shared, delegated or group accounts. It is just a single personal account with its own calendar.

I also reproduced the issue after removing all Stalwart CalDAV and CardDAV accounts from the iPhone, rebooting it, and then configuring only this single CalDAV account.

One potentially relevant difference is the iOS version: my client is iOS 26.6 (23G71), while you are testing with iOS 16.

On the server side I can see the following sequence from iOS 26.6:

PROPFIND /.well-known/caldav
→ 307 /dav/cal

PROPFIND /dav/cal
→ 207

OPTIONS /dav/pal/user%40example[.]com/
→ 200

After that, iOS sends no further CalDAV request.

The OPTIONS response advertises calendar-access and the expected DAV methods.

I can provide the corresponding server-side logs.

Regarding Apple client logs: I do not have a Mac available for live Console logging. I can generate an iOS sysdiagnose directly on the iPhone if that is useful. Could you please specify which Apple log or diagnostic data you would like to see, and preferably which files or sections from the sysdiagnose are relevant? I would prefer not to upload a complete sysdiagnose publicly because it contains unrelated system information.

4

Additional test on iPadOS 26.6:

I repeated the test on an iPad running iPadOS 26.6.

I removed both the existing Nextcloud CalDAV account and the Stalwart CalDAV account from the iPad, rebooted the device, and then configured only the Stalwart CalDAV account again.

Result: the Stalwart CalDAV account is still shown as “Inactive”.

I also manually changed the configured DAV path from the discovered principal path (/dav/pal/…) to the calendar path (/dav/cal/…), but the account remained inactive.

The same problem is therefore reproducible on both iOS 26.6 and iPadOS 26.6.

This appears to rule out an interaction with another CalDAV account on the Apple device and also indicates that manually overriding the DAV path does not resolve the issue.

5

Update: workaround found – CalDAV itself works

I was able to identify a working setup path on iOS 26.6.

The problem appears to depend on where the CalDAV account is added in iOS.

When adding the account through the Mail/account settings, authentication succeeds and iOS proceeds to the second configuration screen, but that screen is completely empty. No “Calendars” or “Reminders” switches are shown. The account is then created as “Inactive”.

Using the following path instead works:

Settings → Apps → Calendar → Calendar Accounts → Add Account → Other → Add CalDAV Account

Using exactly the same server, username and Stalwart app password, iOS takes a little longer during discovery and then displays both Calendars and Reminders with enabled switches.

After completing the setup I also verified synchronization:

Calendar synchronization works successfully.

During troubleshooting we had already verified that Stalwart correctly provides the CalDAV discovery hierarchy, principal URL, calendar-home-set and calendar collections. We also captured the iOS requests. With the failing setup path, accountsd stopped after discovery / OPTIONS on the principal and dataaccessd never started. With the working setup path, iOS recognizes the CalDAV services and synchronization starts normally.

So at least with:

  • iOS 26.6 (23G71)
  • Stalwart 0.16.17

this appears to be an iOS account-setup-path issue rather than a Stalwart CalDAV interoperability failure.

I am leaving this here as a workaround for other users who may encounter the same seemingly successful authentication followed by an empty service-selection screen and an “Inactive” CalDAV account.