Adding Events to the User's Calendar from a Rork Max App: EventKit's Three-Tier Permissions and Write-Only Access

Adding Events with Zero Permission: EKEventEditViewController

The first option to consider is the flow that requests nothing. Since iOS 17, EventKitUI's EKEventEditViewController can be presented without any calendar permission. The edit sheet is rendered out-of-process by the system, and whatever the user saves is never readable by your app — that is what makes the permission unnecessary. No dialog means the drop-off point simply does not exist.

To use it from SwiftUI, wrap it in UIViewControllerRepresentable:

import SwiftUI
import EventKitUI
 
// Permission-free wrapper around the system event editor
struct EventEditSheet: UIViewControllerRepresentable {
    let title: String
    let startDate: Date
    let endDate: Date
    let notes: String
    @Environment(\.dismiss) private var dismiss
 
    func makeUIViewController(context: Context) -> EKEventEditViewController {
        let store = EKEventStore()               // never call a request-access API
        let event = EKEvent(eventStore: store)
        event.title = title
        event.startDate = startDate
        event.endDate = endDate
        event.notes = notes
 
        let vc = EKEventEditViewController()
        vc.eventStore = store
        vc.event = event                          // pre-filling initial values is allowed
        vc.editViewDelegate = context.coordinator
        return vc
    }
 
    func updateUIViewController(_ vc: EKEventEditViewController, context: Context) {}
 
    func makeCoordinator() -> Coordinator { Coordinator(dismiss: dismiss) }
 
    final class Coordinator: NSObject, EKEventEditViewDelegate {
        let dismiss: DismissAction
        init(dismiss: DismissAction) { self.dismiss = dismiss }
        func eventEditViewController(_ controller: EKEventEditViewController,
                                     didCompleteWith action: EKEventEditViewAction) {
            dismiss()                             // close on .saved or .canceled
        }
    }
}

Present it with .sheet. Because you can pre-fill the title and dates, the user's entire job is to glance at the content and tap Add — two gestures.

When prompting Rork Max, naming the exact structure pays off. This is the instruction that worked for me verbatim:

Add an "Add to Calendar" button on the event detail screen.
Implement it by wrapping EventKitUI's EKEventEditViewController in a
UIViewControllerRepresentable and presenting it as a sheet. Do NOT call
requestFullAccessToEvents or requestWriteOnlyAccessToEvents on EKEventStore.
Do NOT add any calendar usage description keys to Info.plist.

Spelling out which APIs must not be called produces far more repeatable generations than a vague "implement it without asking for permission."

Silent Event Creation with Write-Only Access

Sometimes routing every save through a system sheet is too much friction — say, automatically adding an event the moment a booking completes, or writing several events in one batch. That is what iOS 17's write-only tier, requestWriteOnlyAccessToEvents(), is for.

import EventKit
 
enum CalendarWriter {
    static let store = EKEventStore()
 
    // Confirm write-only access, then save the event
    static func addEvent(title: String, start: Date, end: Date,
                         alarmMinutesBefore: Int? = nil) async throws -> Bool {
        var status = EKEventStore.authorizationStatus(for: .event)
        if status == .notDetermined {
            _ = try await store.requestWriteOnlyAccessToEvents()
            status = EKEventStore.authorizationStatus(for: .event)
        }
        // Both .writeOnly and .fullAccess allow saving
        guard status == .writeOnly || status == .fullAccess else { return false }
 
        let event = EKEvent(eventStore: store)
        event.title = title
        event.startDate = start
        event.endDate = end
        event.calendar = store.defaultCalendarForNewEvents
        if let minutes = alarmMinutesBefore {
            event.addAlarm(EKAlarm(relativeOffset: TimeInterval(-minutes * 60)))
        }
        try store.save(event, span: .thisEvent)
        return true
    }
}

Add NSCalendarsWriteOnlyAccessUsageDescription to Info.plist. The resulting dialog says, in effect, "this app can add events but cannot read them" — and the perceived weight is completely different. As mentioned up top, my grant rate went from under half with full access to the low eighties after switching to write-only. A small sample, but more than enough to confirm that the dialog's wording is what moves the number.

The constraint is equally clear: with write-only access you cannot read anything, so you cannot check whether you already created the same event. The practical workaround for double-taps and repeat visits is to store the saved event.eventIdentifier in UserDefaults as your own "already added" flag. Comparing identifiers you saved yourself requires no read permission.

Full Access Is Needed Less Often Than You Think

requestFullAccessToEvents() is only justified when reading, searching, or updating existing events is part of the requirement — typically features like "compute the user's free slots and suggest times" or reconciling against externally created events.

// Full access required: fetch the next 7 days of events for duplicate checks
static func fetchUpcoming(days: Int = 7) async throws -> [EKEvent] {
    guard try await store.requestFullAccessToEvents() else { return [] }
    let start = Date()
    let end = Calendar.current.date(byAdding: .day, value: days, to: start)!
    let predicate = store.predicateForEvents(withStart: start, end: end, calendars: nil)
    return store.events(matching: predicate)
}

My rule of thumb is blunt: do I need to render the user's existing events on screen? If not, full access is not needed. Defaulting to full access "just in case" makes the review wording heavier, drags the grant rate down, and buys you nothing. Escalating the tier after the requirement is confirmed is never too late.

Reminders Have No Write-Only Tier

Deadline-driven tasks often fit the standard Reminders app better than the calendar. But EventKit offers no write-only tier for reminders — requestFullAccessToReminders() is the only option.

// Reminders are full-access only. Defer the request until the moment of use
static func addReminder(title: String, due: DateComponents) async throws -> Bool {
    let store = EKEventStore()
    guard try await store.requestFullAccessToReminders() else { return false }
 
    let reminder = EKReminder(eventStore: store)
    reminder.title = title
    reminder.dueDateComponents = due            // e.g., specify down to hour and minute
    reminder.calendar = store.defaultCalendarForNewReminders()
    reminder.addAlarm(EKAlarm(absoluteDate: Calendar.current.date(from: due)!))
    try store.save(reminder, commit: true)
    return true
}

Given the asymmetry, decide which integration is primary. In this situation I prefer making the calendar (write-only) the main path and offering reminders as a secondary option. If your app's core is task management instead, it is worth inserting a one-screen explanation right before the first reminders request. The pre-permission priming approach I described for designing ATT pre-permission priming transfers to this dialog unchanged.

App Review and Purpose Strings: Avoiding the Rejection

In my experience, EventKit review feedback concentrates almost entirely on Guideline 5.1.1 — purpose strings that are not specific enough. Three points cover it:

1. Put the "what" and the "why" in one sentence. "This app uses your calendar" will not pass. Write something like "Used to add the start time of classes you book as an event on your calendar" — name what you write and why.
2. Request at the moment of use, never at launch. Batch-requesting permissions on first launch reads poorly no matter how polite the strings are, and it measurably lowers grant rates. Request when the button is tapped.
3. Keep the privacy label consistent. If event content never leaves the device, you do not declare calendar data collection in App Store Connect; if it does reach your server, a missing declaration is an instant rejection risk. A design that stays within write-only access also keeps this declaration minimal — another quiet advantage.

The same "step the permission down" philosophy appeared in iOS 18's contacts flow; reading this alongside the iOS 18 contact access button and limited-access design makes the multi-year trend visible: Apple is steadily replacing all-or-nothing prompts with graduated, minimal-scope tiers.

Wrapping Up: Start from the Permission-Free Path

The evaluation order that held up best for me — for grant rate, review, and implementation cost alike — is top-down: EKEventEditViewController (no permission) → write-only → full access. As a concrete first step, drop the EventEditSheet above into an existing detail screen and watch an event land on the calendar with no dialog at all. The absence of that one sheet changes how the feature gets used.