Clendar: a minimal SwiftUI calendar app with a widget and Siri shortcuts

A personal WWDC learning project that became an App Store app

Clendar began as a UIKit app written by its author to keep up with new features announced at WWDC each year. At some point he decided to convert the whole app from UIKit to SwiftUI, and that conversion is preserved in the repository as a pull request, number 35.

The reason the project is worth reading is that it is a real, shipped application rather than a tutorial. The App Store listing exists, and the readme describes the app as a calendar made simpler, with the feature list covering widgets with customizable dark and light themes, keyboard shortcuts, Siri shortcuts, Apple Watch complications, custom app icons, natural language parsing, a lunar day view, built-in dark and light modes, accessibility support and localizations.

The name comes with its own footnote. The author says it is just Calendar without an a, that he thought it was unique, and that it turned out not to go down well with App Store Optimization and Search Engine Optimization. That is a small thing to know before you look at how the app presents itself.

The app targets the full Apple range rather than a single device. The topic list covers iOS, iPadOS, macOS, watchOS and Catalyst, and the top-level entries include separate targets for the main app, the watch app and its extension, the widget and the widget extension entitlements.

EventKit sits behind the author's own Shift package

The technical centre of the app is EventKit, Apple's calendar database, and the interesting choice is that it is not called directly.

The tech stack section lists EventKit and EventKit UI as a wrapper around the author's own Shift package. Shift is a separate repository of his, and the reason to mention it is that Clendar is not a single-target codebase with one dependency graph. It is an application whose data access layer is somebody's other open source project.

Around that sit the other Apple frameworks the feature list implies. WidgetKit provides the widget, SiriKit the Siri shortcuts, WatchKit the complications, and SwiftUI with UIKit interoperability the interface layer itself.

The top-level directory listing shows how many targets are in play. There is Clendar for the main app, ClendarWatchApp and ClendarWatchApp Extension for the watch, ClendarWidget for the widget, ClendarTests and ClendarUITests for the test targets, Packages for local Swift packages, Dependencies and Pods for the CocoaPods side, and fastlane plus scripts for release tooling. There is also a Configuration.storekit file, which is the StoreKit configuration used for testing in-app purchases locally, and a com.mono0926.LicensePlist.Output directory, which is the licence text plist that LicensePlist generates.

Building depends on CocoaPods and a Rosetta detour on M1

Getting the project to build is not a single step, and the readme is upfront about the awkward part.

The Makefile has two targets. The project target depends on clean, and the clean target removes the Pods directory outright with rm -rf Pods, so every full build starts by deleting the installed pods:

project: clean
	swift package generate-xcodeproj --enable-code-coverage
	ruby -e "require 'xcodeproj'; Xcodeproj::Project.open('Clendar.xcodeproj').save" || true
	bundle install
	bundle exec pod install || bundle exec pod install --repo-update --verbose

The sequence generates the Xcode project from the Swift package definition with coverage enabled, patches the project file with the xcodeproj Ruby gem, installs the Ruby bundle, and then installs the CocoaPods dependencies. The fallback to pod install with --repo-update --verbose exists because a stale pods repository is a common failure.

On Apple Silicon, the readme flags a specific problem and gives two ways around it. Either install the ffi gem and run pod install under the x86_64 architecture, using the commands `sudo arch -x86_64 gem install ffi` followed by `arch -x86_64 pod install`. Or open the terminal through Rosetta and run pod install there. The tip comes from a comment on issue 220, and the reason it exists is that a native gem dependency was not yet built for arm64 at the time. Since the repository also ships a .swift-version file, a .swiftformat configuration and a .swiftlint.yml, the project expects a specific toolchain rather than whatever Xcode happens to be installed.

The commit history shows the code is linted on every push through a SwiftLint workflow badge, and the .periphery.yml file configures a tool that finds unused code, which is a reasonable thing to keep in a project of this size.

The maintainer has stepped back, and the tags stopped in 2022

The most important thing to know about this repository is written at the very top of the readme, in a letter from the author.

He explains that for personal reasons he has not been able to dedicate much time to maintaining the app recently. He thanks the community for contributions over the years, says the app started as a personal project to catch up with annual WWDC changes, and says he looks forward to resuming work on Clendar. The sign-off is Clendar will always be in my heart.

The repository metadata tells the same story in a different form. The last push was on 2026-10-15, so commits are still landing on the main branch, but the newest tagged release is v3.6.1-108 from 2022-09-25, before v3.6.0-106 and v3.5.0-98. The branch is being worked on while the published release line is roughly four years behind.

The version scheme explains the numbering. Each tag pairs an app version with a build number, so the build number counts up independently of the marketing version.

For a user, the App Store is the version that matters, not the tags. For a developer reading the code, what matters is that the main branch has moved on since the last release and that the person who wrote it has said he is not maintaining it right now. The project is not archived, so it is still readable and buildable, and the MIT licence means it can be forked and continued without asking.

The repository also carries a SECURITY.md file, and the fastlane directory plus Configuration.storekit indicate a release process that was set up carefully even though it is not currently running at the pace of the commit history.

Where this differs from the stock iOS calendar

Apple ships a calendar app, so the honest comparison is against that rather than against other open source calendars.

The difference is in surface area rather than in the underlying data. Both talk to EventKit, both show the same events. Clendar adds a widget with its own dark and light themes, a set of keyboard shortcuts, Siri shortcuts, watch complications, a lunar day view, custom app icons and natural language parsing. The system calendar offers some of these in some form, and the App Store listing is where you can compare the current versions directly.

Natural language parsing is the feature with the most independent value, because entering an event by typing a phrase is faster than navigating a date picker. Keyboard shortcuts matter for anyone who lives in the app, and the watch complications extend that to the wrist.

The counterweight is that Clendar is a single person's project with a paused maintainer, so any comparison has to include that. The system calendar will be updated with every iOS release, gets features first, and has no single point of failure. Clendar is the better fit if the specific features above matter to you and you accept that bug fixes arrive when they arrive.

For developers, the more durable interest is the code. A complete SwiftUI application with a widget extension, a watch app and extension, EventKit wrapped in a reusable package, tests and UI tests, is a useful thing to read, and the author's SwiftUI notes are published separately as issues in his notes repository, along with a longer note in issue 342.

Editorial conclusion

Clendar suits an Apple developer who wants a readable SwiftUI reference for a shipped app with widgets, a watch extension and EventKit wrapped in a small package, and who is comfortable picking up a codebase whose owner has said he is stepping back. It does not suit a user looking for a maintained calendar, because the newest tag is v3.6.1-108 from 2022-09-25 even though the last push was on 2026-10-15. Before building it, run the project target from the Makefile on an Apple Silicon Mac using the Rosetta path for gem and pod install, and check the App Store listing for the version Apple currently ships.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vinhnx/Clendar on GitHub