# CalendarKit: A Swift Day-View Calendar UI for iOS and Mac Catalyst

> CalendarKit is an MIT-licensed Swift library that renders an Apple Calendar-style day view and asks you to supply events through the EventDataSource protocol. It is a UI layer, not a calendar engine, and that boundary decides whether it fits your app.

**richardtop/CalendarKit** — 📅 Calendar for Apple platforms in Swift

- Repository: https://github.com/richardtop/CalendarKit
- Website: https://www.youtube.com/watch?v=cJ63-_z1qg8
- Stars: 2,702 · Forks: 363
- Language: Swift
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/richardtop-calendarkit

## What CalendarKit actually solves for an iOS developer

Building a day timeline by hand means positioning event views against hour lines, handling overlaps, scrolling to the current time, and redoing all of it for dark mode. CalendarKit exists to remove that work. The README describes it as a Swift calendar UI library for iOS and Mac Catalyst that "looks similar to the Apple Calendar app out-of-the-box, while allowing customization when needed." The library is split into multiple modules that can be used together or independently, so a project that only wants the day timeline does not have to take the whole thing. The intended user is an app developer who already has events somewhere (a local store, a server API, EventKit) and wants the presentation layer without writing layout code. It is not a scheduling service, not a sync engine, and not a replacement for EventKit's storage. The README points readers at a separate Sample App repository for reference and at two YouTube tutorials, including one titled "Create iOS Calendar App in Swift with CalendarKit." That framing is honest about the scope: you bring the data, CalendarKit brings the timeline.

## The EventDataSource contract and how the day view gets its events

The mechanism is a data source protocol, not a bindable model. You subclass DayViewController and implement EventDataSource, which must return an array of objects conforming to EventDescriptor for a given date. The README states that the protocol requires "an array of objects conforming to EventDescriptor protocol, specifying all the information needed to display a particular event," and that you may use the default Event class or write your own conforming type. The README's example override, eventsForDate(_ date: Date), pulls models from an app store, builds an Event per model, sets event.dateInterval from a DateInterval, and assigns event.text from the title, location and a formatted time range. After that handoff, the README says CalendarKit handles view layout and display. Input comes back through DayViewDelegate: the README shows overriding dayViewDidSelectEventView(_:) and dayViewDidLongPressEventView(_:) to react to taps and long presses. Note what is missing from that description. There is no documented diffing or incremental update path, no mention of how the view refreshes when your store changes, and no event-editing or drag-to-reschedule API. The data flow is one direction per query: date in, descriptors out, layout drawn. If your app needs to mutate events from the timeline, you are writing that interaction yourself and calling back into your own store.

## Installing CalendarKit with Swift Package Manager and showing a first day

The README documents Swift Package Manager as the installation route. In Xcode, open your project, choose File, then Swift Packages, then Add Package Dependency, paste the repository URL, and for Rules select Version (Up to Next Major). The repository also ships a CalendarKit.podspec and the README carries a CocoaPods version badge, so a Podfile entry is plausible, but the README's installation section only walks through the Xcode flow, so treat CocoaPods as undocumented here. The README's own usage example is the shortest path to a first day: subclass DayViewController and return descriptors from eventsForDate(_:).

```swift
override func eventsForDate(_ date: Date) -> [EventDescriptor] {
  var models = myAppEventStore.getEventsForDate(date) // Get events (models) from the storage / API

  var events = [Event]()

  for model in models {
      // Create new EventView
      let event = Event()
      // Specify DateInterval
      event.dateInterval = DateInterval(start: model.startDate, end: model.endDate)
      events.append(event)
  }
  return events
}
```

That override is copied from the README, with the text-formatting lines removed for length; the README's version also appends the title, location and a formatted time range into event.text. What you should see is a day timeline with one block per returned descriptor. Requirements are iOS 11.0+ and macOS (Catalyst) 10.15+, with Swift 5.7+; the 1.1.8 release note also names Swift 5.7+.

## Restyling the timeline with CalendarStyle, and where localization stops

Styling is a value-type swap rather than a theme system. The README's three steps are to create a CalendarStyle object (or copy an existing one), change its properties, and call updateStyle on the day view. The README gives this example:

```swift
let style = CalendarStyle()
style.backgroundColor = UIColor.black
dayView.updateStyle(style)
```

Because CalendarStyle is a plain object you mutate, you can build several variants and swap them at runtime, which is enough for a light and dark pair. The README states the default look already supports Dark Mode, so a custom style is an override, not a prerequisite. Localization is handled differently: CalendarKit "uses iOS default locale to display month and day names," and the first day of the week follows the iOS locale as well. That means month names, weekday names and week start are not yours to configure through CalendarKit; they come from the device. If your product needs a fixed week start regardless of device locale, or a language that differs from the system language, the README does not describe a hook for it. The screenshots in the README show German and Norwegian renderings, which is consistent with locale-driven output rather than a bundled string catalog you control.

## Where CalendarKit is the wrong tool

The clearest limitation is scope. The README documents a day view: DayViewController, eventsForDate(_:), DayViewDelegate. There is no month grid, no year view, no week view, and no agenda list described anywhere in the README. An app whose primary screen is a month calendar is not a fit, and stitching CalendarKit's day view under a month picker you write yourself is more work than the library saves. The second limitation is that events are display objects. The README's example builds Event instances inside eventsForDate(_:) and returns them; nothing in the README describes editing, dragging, resizing, or writing changes back. If your users expect to move an event by dragging it, that behaviour is not in the documented API surface. The third is data volume and refresh semantics: the protocol returns an array per date, and the README does not describe caching, incremental updates, or how the view reacts when the underlying store changes while the screen is open. For an app that syncs a busy calendar over the network, you will be managing reload timing yourself. Finally, the platform floor is Apple-only. Mac Catalyst is supported at macOS 10.15+, but there is no UIKit-for-Android story, no web target, and no React Native binding in the README, despite the "calendarkit react" phrasing people search for.

## How CalendarKit compares with FSCalendar and KVKCalendar

The realistic alternatives for a Swift calendar UI are FSCalendar and KVKCalendar, both of which appear in what people search alongside this project. The difference is the shape of the calendar, not the language. FSCalendar is built around a month grid with date cells, which is the opposite starting point from CalendarKit's day timeline; if your screen is a month with dots under dates, FSCalendar matches the mental model and CalendarKit does not. KVKCalendar is the closer comparison, because it covers multiple view modes rather than a single day view, which matters if you need to switch between day, week and month inside one screen. CalendarKit's trade is narrower scope in exchange for a timeline that already resembles Apple Calendar, including the hour grid and event block layout, and for a modular structure the README says can be used together or independently. None of these libraries stores your events. All three expect you to supply models and handle persistence, so the choice comes down to which layout you need and how much of the surrounding navigation you are willing to build. If you need one day rendered well and you control the rest of the navigation, CalendarKit's narrower surface is an advantage; if you need a month view on day one, it is the wrong pick.

## Licence, maintenance and the cost of upgrading

CalendarKit is MIT licensed, per the README and the LICENSE.md file in the repository root. MIT is permissive: you can use it in closed-source apps, and the obligation is essentially to keep the copyright and permission notice with the distribution. That is the general shape of the licence, not legal advice for your situation. On maintenance, the repository is not archived, and the last push was on 2026-09-12, so it is current. The release history is uneven rather than rapid: 1.1.0 (DateInterval API) in November 2021, 1.1.8 (Swift 5.7+) in March 2023, and 1.1.11 (iOS 18 style) in November 2024. The pattern suggests maintenance tracks Apple's platform changes rather than a steady feature cadence, which is reasonable for a UI library but means you should not expect frequent API churn or a fast feature roadmap. Upgrade cost is mostly the Swift and platform floor moving: the 1.1.8 note ties a release to Swift 5.7+, and the 1.1.11 note ties one to an iOS visual style. If you pin with Version (Up to Next Major) as the README instructs, minor releases arrive without a manifest edit, so review the release notes before bumping. The README directs bug reports and feature requests to the issue templates and usage questions to Stack Overflow under the calendarkit tag, which tells you where maintainer attention is expected to land.

## Conclusion

Adopt CalendarKit if you need an Apple Calendar-style day view on iOS 11.0+ or macOS (Catalyst) 10.15+ with Swift 5.7+, you already have a store that returns events for a date, and the built-in day layout is close enough that style changes through CalendarStyle cover the rest. Do not adopt it if you need month or year grids, an event editor, or recurring-event expansion: the README documents a day view driven by eventsForDate(_:) and nothing beyond that. Before committing, verify two things in your own build: that your model can produce DateInterval values for every event, and that overriding DayViewDelegate callbacks such as dayViewDidSelectEventView(_:) gives you the interaction you need, since the README shows only selection and long press.

## FAQ

### How do I install CalendarKit in an iOS project?

The README documents Swift Package Manager: in Xcode choose File, then Swift Packages, then Add Package Dependency, paste https://github.com/richardtop/CalendarKit.git, and select Version (Up to Next Major). CalendarKit ships a CalendarKit.podspec and a CocoaPods version badge, but the README's installation section only describes the Xcode flow.

### Does CalendarKit work on macOS?

Yes, through Mac Catalyst. The README lists requirements as iOS 11.0+ and macOS (Catalyst) 10.15+, with Swift 5.7+. There is no native AppKit target described.

### Is CalendarKit free to use in a commercial app?

The README states CalendarKit is available under the MIT license, with details in the LICENSE file. MIT permits use in closed-source applications provided the copyright and permission notice is retained.

### Can I change how CalendarKit looks?

Yes. The README's steps are to create a CalendarStyle object or copy an existing one, update its properties, and call updateStyle on the day view with the new style. The default appearance already supports Dark Mode.

### Does CalendarKit store or sync my events?

No. You implement EventDataSource and return an array of EventDescriptor objects for a given date, and the README says CalendarKit then handles view layout and display. Persistence and retrieval stay in your own store or API.

## Sources

- [License: MIT](https://github.com/richardtop/CalendarKit/blob/master/LICENSE)
- [Project website](https://www.youtube.com/watch?v=cJ63-_z1qg8)
- [README](https://github.com/richardtop/CalendarKit/blob/master/README.md)
- [Releases](https://github.com/richardtop/CalendarKit/releases)
- [richardtop/CalendarKit on GitHub](https://github.com/richardtop/CalendarKit)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/richardtop-calendarkit