ICS isn’t the only problem - vendor APIs are the real mess. That’s why I’m building Synara.
When I wrote my last post about ICS being 25 years old, a bunch of people asked the same thing:
“Why not just use Google Calendar API, Outlook Graph, Apple Calendar, etc.?”
Because that’s where the actual pain is.
If you’ve ever tried to build anything around scheduling, you already know how bad it gets:
Google does things one way
Microsoft does things another
Apple doesn’t even give you a proper API
Timezones behave differently across each provider
Recurring rules drift
Update flows are inconsistent
RSVP handling is a lottery
Webhook support ranges from ‘OK’ to ‘lol no’
None of this is theoretical. I hit every single one of these while building an event system last month. The “calendar layer” becomes a pile of vendor-specific logic that you end up maintaining forever.
So I built Synara to remove all of that.
Instead of forcing developers to juggle three (incompatible) ecosystems, Synara does it for you and gives you a single, predictable model based on ACE - Active Calendar Events, the new event format I’m pushing as a modern successor to ICS.
What you get is simple:
One clean event schema (ACE)
One API surface
One webhook model
One set of rules that behave the same on every client
ICS still ships as a fallback because the world isn’t going to switch formats overnight. But everything internally is ACE, not the 1998 relic I had to fight with for weeks.
Developers shouldn’t have to negotiate with Google, Microsoft and Apple just to send a calendar invite or track a meeting. This layer should’ve been solved years ago.
If you’re curious, the landing page and developer console are live - I’d actually appreciate blunt feedback on both. I’m still improving the onboarding, examples, and SDKs.
Replies