Ancestors

Written by Dave DeLong on 2024-09-25 at 15:55

Somewhere inside me a rant is building about the state of EventKit and Contacts.framework on appleOS.

Potentially amazing frameworks that could enable some really fantastic productivity apps, but that have been seemingly abandoned for the past decade.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Adam Kemp :apple_inc: on 2024-09-25 at 16:00

@davedelong as an engineer working on EventKit I want to read your rant. Please write it!

=> More informations about this toot | More toots from AdamKemp@oliphaunt.social

Toot

Written by Dave DeLong on 2024-09-25 at 16:11

@AdamKemp ❤️

Basically, everything that Calendar.app can do, I want:

• granular event observation, not just "lol something changed”

• enable/disable delegate calendars

• programmatically add/remove sources

• attach structured metadata that's not just random notes

• get the original "template" for recurring events

• ask for date of next recurrence

• the entire calendar inbox/replied feature

• everything around modifying participants + seeing availability

• that's not event touching EventKitUI

=> More informations about this toot | More toots from davedelong@mastodon.social

Descendants

Written by Dave DeLong on 2024-09-25 at 16:15

@AdamKemp

• account sync status + initiating syncs + sync errors

• where is EventKitUI for macOS???

• probably a whole lot more

Basically, every non-Apple company I've worked at that needed user calendar info ended up ignoring EventKit entirely and directly integrating with Google, MS Access, etc because EventKit was so lacking.

Make it so that I'd never need to do that ever again.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Dave DeLong on 2024-09-25 at 16:20

@AdamKemp Then there's the super-low-hanging fruit of an actual Swift interface. For example, Swift has been out for 10 years: why is EKRecurrenceRule still exposing an array of NSNumbers??

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Nicolai Henriksen on 2024-09-25 at 16:41

@davedelong @AdamKemp Everything Dave says.

Handling of subscription calendars is very hard to understand for users. We cannot offer a simple interface to add and once added it is impossible to know for sure it happened. Not possible to help the user remove.

Birthday calendars are a black box.

List of calendars and sources impossible to match that of Calendar.ap.

=> More informations about this toot | More toots from gahms@mastodon.social

Written by Adam Kemp :apple_inc: on 2024-09-25 at 16:21

@davedelong I am curious what you mean by “programmatically add/remove sources”. What kind of feature are you looking to implement there?

=> More informations about this toot | More toots from AdamKemp@oliphaunt.social

Written by Dave DeLong on 2024-09-25 at 16:24

@AdamKemp when working on business apps, most users don't actually use Calendar.app; they use their calendar via browsers. That means they're entirely blind to EventKit anyway (and which is why I've historically ended up talking to APIs directly).

As part of app onboarding I’d want to offer the ability to add their account to Calendar.app so I can access it through EventKit instead of having to manually walk every user through Calendar.app's account preferences.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Adam Kemp :apple_inc: on 2024-09-25 at 16:29

@davedelong Ah, ok. I think something like that would have to be done through out of process UI flows because that's all backed by the Accounts framework (and keychain for credentials), which doesn't have any kind of TCC permission system.

=> More informations about this toot | More toots from AdamKemp@oliphaunt.social

Written by Dave DeLong on 2024-09-25 at 16:34

@AdamKemp Makes sense.

Other ideas:

• better way to identify sources and their account. Delegate calendars show up associated with an account in app settings, but are all discrete EKSources in code

• Identifying which sources are built-in vs added. If i've got the user's work email from other auth mechanisms, there's no apparent way to match that to an account's username, because i can't see the account at all

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Dave DeLong on 2024-09-25 at 16:36

@AdamKemp The fundamental idea here is that I want my app to intelligently offer stuff to the user, which means identifying work vs personal stuff as best as I can. In my case, I'd want my app to ignore the dozen+ personal calendars I have and focus on the calendars associated with my work account, perhaps noticing that the “Vacation and OOO" calendar is inactive and offer to activate it.

There's no way I can reliably do that, because the info I need to make those determinations isn't visible.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Dave DeLong on 2024-09-25 at 16:40

@AdamKemp so instead I find myself symbol-dumping EventKit, CalendarFoundation, CalendarUI, CalendarUIKit, Accounts, AccountsUI, etc trying to see if I can find where the info I need is available at all and then deciding if I want to foist that level of hacking and fragility on my users.

I want a level playing field for building a calendaring app.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Adam Kemp :apple_inc: on 2024-09-25 at 16:43

@davedelong FWIW, we don't have any real understanding of which accounts are "work" or "personal" either. There are heuristics we can use to guess, some of which would probably require SPI, but I'm not aware of any features we actually have to try to make that distinction right now.

=> More informations about this toot | More toots from AdamKemp@oliphaunt.social

Written by Dave DeLong on 2024-09-25 at 16:46

@AdamKemp right, but if I know (from other means) that the user's work email is “akemp@fruitco.com”, I can match that much more reliably to an account versus trying to deal with localized names of individual calendars or source types.

=> More informations about this toot | More toots from davedelong@mastodon.social

Written by Dave DeLong on 2024-09-25 at 16:47

@AdamKemp Thank you for listening to all of this, by the way. I know you can't comment on future plans of course, but I really really hope that stuff like this gets prioritized. Very little has changed in EventKit's public interfaces since its introduction into the SDK, but the way we use calendars has evolved dramatically. I want EventKit’s API to be amazing and capable for everyone, and right now I'm far better served by ignoring it entirely.

=> More informations about this toot | More toots from davedelong@mastodon.social