Developers who review Synara’s documentation often notice the same thing right away:

“If ICS is so inconsistent, why does Synara still generate it?”

It’s a valid question. ICS is twenty-five years old, behaves unpredictably across vendors, and was never meant for real-time updates or two-way communication. It’s a fragile transport format that pretends to be a structured record.

So why not eliminate it completely?

Because the calendar ecosystem still relies on ICS, not by choice, but out of habit. If your software needs to reach users on Apple Calendar, Outlook Desktop, older versions of Gmail, or anything that doesn’t have a simple API, ICS is the only widely understood format.

The error is in thinking ICS is effective for this role. It’s not. That’s why Synara approaches ICS very differently from most platforms.

ICS is for transport, not truth.  

ICS is how clients import events, not how they manage them. Even when multiple clients accept the same file, they interpret it differently:

• Apple might remove fields during import.  
• Google may change recurrence rules without notice.  
• Outlook might alter timezone blocks.  
• Some clients see RSVP fields as suggestions.  
• Others ignore important metadata altogether.  

If you rely on ICS as a reliable source, everything falls apart over time.

Synara avoids that problem by keeping ACE as the main representation internally. ICS is generated from ACE, not the other way around. This way, even if a client scrambles the ICS during import, Synara’s version of the event remains accurate.

ICS is necessary because users haven’t changed their expectations.  

Even if Synara offers an API, supports JSCalendar, and provides ACE, most people still accept calendar invitations as they have for decades:

• via email  
• into whatever default client they use  
• often without calendar sync turned on  
• sometimes on devices that don’t support modern APIs at all  

If Synara stopped producing ICS, your attendees wouldn’t receive invites. This isn’t a technical issue; it’s about meeting user expectations.

Synara maintains ICS because email clients still require it.

ICS also matters for legacy systems beyond your control.  

Many organizations still:

• restrict outbound calendar sync  
• prohibit OAuth connections  
• use on-premises Exchange  
• depend on proprietary calendar systems  
• operate in mixed environments with partial updates  

For these users, ICS is the only connection available.

Synara doesn’t pretend these environments don’t exist. It aims to provide a safe way to engage with them without taking on their limitations.

ACE and JSCalendar tackle what ICS can’t.  

ICS can’t accurately represent a reliable, evolving event. It lacks true versioning, proper conflict resolution, and a way to reconcile vendor-specific actions.

That’s why Synara operates this way:

• You send JSCalendar.  
• Synara converts it into ACE as the official model.  
• ICS is generated from ACE solely for compatibility.  
• Webhooks always send ACE, never raw ICS.  
• Incoming changes from clients are converted back into ACE.  

ICS is positioned on the very edge of the system, not within it.

This setup allows you to support legacy clients without taking on their issues.

The long-term goal isn’t to sustain ICS.  
Synara supports ICS because the ecosystem needs it, not because ICS is worth keeping.

Over time, the aim is clear:

• JSCalendar for creation  
• ACE as the internal truth  
• Real APIs for sync  
• ICS only when absolutely necessary  

ICS belongs to the present, not the future, and Synara is built around that reality.