Unfortunately the entire write-only access feature is the right answer to the wrong question. No person and no app ever wants to add an event to a calendar. We may talk about "adding an event" colloquially, but what we mean is:
Add the event if it is not already there.
If the event is already there, modify it if necessary.
For a human example: when you confirm a meeting and say "I will put it in the diary", that does not mean that you open your diary, see the meeting is already in the diary, and then add it a second time. But that is what the assumptions behind the new API imply.
In my case the app is maintaining a one-a-day list of future "events" for the next 365 days (it does this in a separate calendar with a separate name, not in "Home" or "Work"). Each time the app is run it needs to add whatever future dates have not yet been added. The new API does not allow this because there is no way of knowing what has already been added. In addition (in parallel to your case): the exact content of the events may depend on app settings. When the user changes a setting the app needs to update the previously added events but again the new API does not allow this.
Both you and I would benefit from a concept of ownership, either on the calendar level or on the event level. "Tell me what events I have created and let me edit them", or "Tell me what events are in the calendar I own and let me edit them". The new API does not provide this and we will both have to stick with full access for now.
Adding a concept of ownership sounds easy but requires more resources and a certain amount of political will: for instance, how does "ownership" work when an event is shared with Google or Outlook? It is more work for Apple than just adding a "write permission" flag to EventKit as a whole.
I would love to give feedback on this and I am sure you would too – but it is not clear to me to whom, at the beta stage, such feedback should be directed. Probably I have missed something obvious here!
