Make calendar attachments compatible with iOS

Is your feature request related to a problem? Please describe.

The current way of storing attachments in calendar events doesn't work with the native iOS calendar app. When I create a simple event with a file attachment (doesn't matter if uploaded from local device or picked from file storage), the event will look somewhat like this

BEGIN:VCALENDAR
PRODID:-//IDN nextcloud.com//Calendar app 6.1.0//EN
CALSCALE:GREGORIAN
VERSION:2.0
BEGIN:VEVENT
CREATED:20260202T111305Z
DTSTAMP:20260202T111337Z
LAST-MODIFIED:20260202T111337Z
SEQUENCE:2
UID:c21d80fa-5dfe-4442-899e-ea0b263d0811
DTSTART;VALUE=DATE:20260211
DTEND;VALUE=DATE:20260212
STATUS:CONFIRMED
SUMMARY:Test event
ATTACH;FMTTYPE=application/pdf;FILENAME=/2025-12-04_scan.pdf;X-NC-FILE-ID=1
 021328;X-NC-HAS-PREVIEW=true:/index.php/f/1021328
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT30M
SUMMARY:Test event
DESCRIPTION:This is an event reminder.
END:VALARM
END:VEVENT
END:VCALENDAR

The ATTACH uri is relative and points to something in the files app, which is both unsupported by iOS.
For reference, this is what an event pulled from iCloud calendar with an attachment looks like:

BEGIN:VCALENDAR  
X-WR-CALNAME:test  
VERSION:2.0  
CALSCALE:GREGORIAN  
PRODID:-//caldav.icloud.com//CALDAVJ 2550B599//EN  
BEGIN:VEVENT  
DTSTAMP:20260202T084449Z  
SUMMARY:test  
TZID:Europe/Berlin  
SEQUENCE:0  
UID:4f20b0ae-6837-48d4-b1fc-5f28910306eb  
CREATED:20260202T084449Z  
DTSTART;TZID=Europe/Berlin:20260202T093000  
DTEND;TZID=Europe/Berlin:20260202T103000  
ATTACH;FMTTYPE=application/pdf;SIZE=171916;FILENAME=VKD-DOCSIS-Interface-  
Specification-v1.04.pdf;MANAGED-ID=02130ddd-958f-41f3-a3d4-aa6a39c92ad8:  
https://gateway.icloud.com/caldav/1_MTc<...>XoDb/attach/4_GE3<... >U4E4O/VKD-DOCSIS-Interface-Specification-v1.04.pdf/YXR0<...>fuz  
END:VEVENT  
BEGIN:VTIMEZONE  
...
END:VTIMEZONE  
END:VCALENDAR

The first problem is that iOS doesn't like host-relative URLs and will give an error when trying to download the attachment. It identifies the server as "null" and throws the error on the left; when i try to download anyway it fails:

Then, when I prepend the scheme / host manually to the URI, the calendar app is able to resolve it and download a file, but it will always download the served content by the webserver instead of showing it in a webview (makes sense, after all the content-type is already given as application/pdf). It will just download the served HTML webpage and try to render it as PDF, so it will fail again. I can get the PDF display to work if I manually susbtitute the URL for the full WebDAV path of the uploaded file; it appears that the calendar app will send the login credential to the server for the file request as well.

the edited ATTACH line in the ICS file is now:

ATTACH;FMTTYPE=application/pdf;FILENAME=/c36f16645f7b58eebb01361561bf90dfa9
 9be2b9.pdf;X-NC-FILE-ID=1021451;X-NC-HAS-PREVIEW=true:https://nextcloud.my
 .domain/remote.php/dav/files/myuser/Calendar/c36f16645f7b58eebb01361561bf9
 0dfa99be2b9.pdf

Describe the solution you'd like

The ICS ATTACH property should contain a fully-qualified URL that directly links to the attachment webDAV url, so that the iOS calendar app can download and display it. That would change the current behavior of calendar attachments a bit, since files wouldn't be displayed in the nextcloud viewer anymore, but simply be downloaded by the browser (which would then usually show PDF files in its integrated viewer, which isn't too bad). At least for the web client, it would probably be nice to keep the nextcloud-integrated viewer e.g. for office files, maybe that could be done by storing the path to the nextcloud files app (i.e. what is currently in the ATTACH uri) in a custom property and using that from the web client.

This is somewhat related to #5001, as I read it; implementing RFC8607 will already require that the ATTACH uri points directly to the stored file. Even without implementing the full RFC8607 file upload capabilities, just having a valid URL in the iOS calendar would already be quite helpful to me without the ability of uploading / changing attachments from the phone.

Going further, I am reasonably sure that iOS calendar actually supports most of RFC8607 because iCloud seems to use it; note the MANAGED-ID property in the iCloud ICS event ATTACH line. I still have to do more testing on that side to see whether the calendar app will actually allow RFC8607 uploads to non-iCloud calendar servers;

Describe alternatives you've considered

No response

Additional context

No response

Start by tracing how calendar attachments are serialized into the ICS ATTACH property and how the current files-app URI is generated. Verify the change with an event containing an uploaded file: the exported ATTACH value should be a fully qualified WebDAV URL that iOS can download, while the existing calendar behavior remains understood.