The repository builds five platforms, the page describes one, and a signing keystore sits in the root

Five platform directories and one documented download page

The page names Android twice. The title says Android, the subtitle says Android, and every one of the five download links is an Android app store or a release page for an Android package.

The repository root tells a different story. Alongside the main application module there are directories for a desktop target, an iOS target, a web target and a Wear target, plus a shared directory that the platforms presumably draw on. There is also a Gradle plugins directory, a local libraries directory, and a custom lint checks directory.

So the project is a multi-platform calendar whose distribution story is Android-only. That is not necessarily an inconsistency, since a Wear app and a phone app ship through the same store listing, and a desktop or web build may be in an early state. But a reader looking for the iOS version will not find it on the page, and one looking for the desktop build will not find it anywhere in the documentation.

The application identifier is the same across all five store links, and it is a personal-name identifier rather than an organisational one: the package is registered under a single maintainer's handle, not under a domain the project owns.

The open issue count is 203, which for a project of this age and size is the other number on the page a reader might want explained.

A signing keystore is committed at the repository root

The root listing contains a keystore file.

It sits between the Gradle wrapper and the privacy policy, next to a directory holding release automation. That combination is the reason it is worth naming: a release pipeline that signs builds and a signing key in version control are the two things that normally should not be in the same repository.

The file's name carries a nightly marker, so the most likely reading is that it signs a continuous or preview distribution rather than a store release, which is a common and fairly benign arrangement. Nothing on the page confirms that reading, and nothing states whether the key is protected by a passphrase, whether it is shared with anyone else, or whether it is used for anything beyond a pre-release channel.

So the honest statement is: the key is in the repository, the name suggests a nightly channel, and whether that matters depends on what the key can sign and who else has it. Anyone forking the project to publish their own builds should check that before reusing the pipeline.

The other root entries that describe process rather than code are a copy of the licence text, an acknowledgements file, a compatibility document, a privacy policy, and a frequently-asked-questions file written in Persian.

The licence text grants version 3 or later, the metadata records version 3

The repository's own metadata records the GNU General Public License, version 3.

The licence text in the project says something slightly wider. It grants the licence as published by the Free Software Foundation, either version 3 of the licence or, at your option, any later version. The copyright line runs from 2012 to 2026 and is held by the project's developers as a group rather than an individual.

The or-later clause is a real difference and it is easy to miss, because most tools that read licence metadata show only the base identifier. A downstream project that assumes it can only offer version 3 terms has less freedom than the grant actually gives, and a downstream project that assumes the metadata is authoritative could narrow the terms it passes on without noticing.

The Persian-language section of the page adds the reason, and it is a better licensing note than most projects include. The application reused source from other projects already under these terms, which obliges it to use the same terms, and because of that the maintainers cannot license it any differently. The page links a plain-language summary of the licence for readers who do not want the legal text, and then states the practical expectation in plain terms: publish the source of your modifications somewhere public, put a public link to it, and credit the original source properly.

Translations are managed on a hosted translation service rather than by pull request, linked from a badge in both language sections.

Three of the five download routes exist for one audience

The download section lists five places to get the application, in this order.

A commercial Android store, a free and open-source Android repository, the project's own release page, and then two Android stores that serve primarily Iran. The last two are the Iranian stores, and the frequently-asked-questions file in the repository is written in Persian, and the translation service badge is present in both language sections.

That is a coherent picture of a project whose primary audience is domestic, with an international route also served. It also explains something about the repository layout that would otherwise look odd: a Persian-only FAQ, a translation workflow rather than hand-edited string files, and release automation in the tree.

The releases page is the only route that is not a store, and it is the only one that would carry a build for a platform other than Android, since the other four are all keyed to the same application identifier on their respective platforms.

One thing the download section does not say is anything about which version each route carries, or whether they are in step. With the release history showing a gap of several months between the most recent tag and the last commit, that is a question worth asking rather than assuming.

Three releases in four weeks, then seven months of commits

The three most recent tags are version 10.1.1 on 2026-01-27, 10.1.2 on 2026-01-29 and 10.1.7 on 2026-02-19.

Two things about that sequence. The first two are two days apart, and the third is three weeks after the second, which is a normal release cadence for a maintained application. The versions in between are not in the list of the three most recent tags, so the numbering moved by six in one step and the intermediate tags either do not exist or are not among the most recent.

The gap that matters is at the other end. The last commit to the default branch is dated 2026-09-25, roughly seven months after version 10.1.7 was published. The repository is not archived, and the commits are recent, so this is not a dormant project. It is a project that ships infrequently relative to how often it is developed.

For a calendar that has shipped continuously since 2012, that is a reasonable pattern rather than a warning sign. What it does mean is that a store listing and the repository can be months apart, and that anyone reading the page for a current version has to check the store rather than the tag history.

The copyright range on the licence line, 2012 to 2026, is the other long-horizon number on the page.

The build section is two clicks and then nothing

The build instructions occupy two numbered steps.

Open the version control import dialog in Android Studio, paste the repository URL, and click the clone button. That is the whole of it. There is no stated JDK version, no Android SDK level, no Gradle command, and no note about which Android Studio release the project expects.

The tree makes clear that a command line exists, because a Gradle wrapper is committed with its platform-specific batch launcher, along with Kotlin DSL build files, a settings file, a properties file, a Gradle directory and a directory of custom Gradle plugins. So the project is set up to build outside the IDE; the documentation simply does not say how.

That matters most for two groups. Anyone on a continuous integration service, who cannot use an IDE import dialog and will have to infer the toolchain from the wrapper and the build files. And anyone on a platform where Android Studio's import flow behaves differently, which is the older-Android case the compatibility document was written for.

The submodule configuration file is committed as well, so at least one dependency lives outside the repository, and its version is pinned there rather than resolved at build time.

The repository carries its own lint, its own plugins and a committed IDE folder

A few of the root entries describe how the project is put together rather than what it does.

There is a directory of custom lint checks, which means the project enforces Android lint rules of its own on its own code rather than relying only on the platform defaults. There is a directory of custom Gradle plugins, built as a separate included build, which is a heavier arrangement than most applications need and usually reflects shared logic with the other platform targets. There is a local libraries directory, which is where a project keeps modules that ship as part of the app rather than from a repository.

The shared directory is the one that explains the multi-platform story. Code that five targets use belongs in one place, and the desktop, iOS, web and Wear modules are the consumers.

The IDE configuration folder is also committed, which is a matter of taste rather than correctness, though it does mean local settings can appear in diffs. The editor configuration file at the root is committed alongside it, so formatting is at least declared once.

The acknowledgements file and the compatibility document complete the picture of a project that has been running long enough to accumulate both, and the privacy policy sitting at the root rather than in a documentation site is what five different stores will each ask you to point at.

Editorial conclusion

This is an unusually long-lived and unusually broad open-source calendar, and the two things worth knowing before you use it are both in the repository rather than on the page. First, scope. The page describes an Android application and links to five Android stores, while the tree contains modules for desktop, iOS, web and Wear alongside the shared code they draw on, so the project is a multi-platform calendar whose distribution story is Android-only. If you want the iOS or desktop build, it is in the repository and not in the download section. Second, licensing. The value stored against the project metadata is the GNU General Public License version 3, and the licence text in the project grants version 3 or, at your option, any later version. Those are not the same grant, and the difference matters if you relicense downstream or rely on terms that only exist in a later version. Who should use it: anyone who wants a Persian calendar on Android without an account, from a project whose licence and translation pipeline are both open. Who should not: anyone who needs the current date from a document, because nothing here records one, or anyone who wants a supported build for a non-Android target. Two smaller things to verify. The build instructions are two clicks in Android Studio and stop there, with no JDK version, no Android SDK level and no command line, even though a Gradle wrapper and Kotlin DSL build files are in the tree. And a signing keystore file is committed at the repository root next to the release automation, which is worth checking before you assume it is a throwaway key.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes