I know I will probably get pushback over this, but CalDAV sucks. People say that it's great and that it's easy; yet if that were true there would be way more self-hosted CalDAV solutions out there and they would be far more ergonomic than what's available. I was not impressed with Radicale. Because there's really only one calendar file I wanted to serve to myself, I tried implementing my own CalDAV server just for that purpose and pretty much gave up because of how unintuitive and complicated it was merely to make a single file available. I can see why it would be needed if sharing a calendar with other people with calendar apps that support CalDAV, but I think it's kind of a waste of time if hosting a calendar for one's self.

Instead, initially went with the approach of hosting my dynamically updating iCal file in an S3 bucket and using ICSx5 on Android to sync with it. No CalDAV needed – just HTTPS.

However, FOSS calendars for Android still suck, and for some reason I couldn't get ICSx5 to work within GrapheneOS, so I now use almost the same approach but with Proton Calendar which happens to support calendars from direct links to iCal files. It's not perfect, but it suits my needs enough.

I think the author's approach for using iCalendar format is a good one, though what I've discovered is the amount of support for various iCalendar features varies drastically between calendar software. Rather than dealing with that headache, I somewhat gave up and decided to shove most metadata into the description field rather than use the respective properties.

EDIT: My use case is software I wrote to grab data from various sites (Eventbrite, Meetup, pub trivia companies, public event calendars, etc.), filter for only social events I would be interested in, and combine them into a single calendar I can view in my normal calendar software.