NotallyX: a local Android notes app that extends Notally

A fork that keeps the original app identity

NotallyX describes itself in one line: Notally, but eXtended. The original Notally project was developed by OmGodse under the GPL 3.0 licence, and NotallyX is licensed under the same licence in accordance with GPL 3.0, which is the correct thing to do for a derivative work.

What matters practically is the package identity. The Play Store listing, the F-Droid entry and the IzzyOnDroid repository all use the identifier com.philkes.notallyx, though the README does not describe a migration path from the original Notally app.

The distribution channels are the interesting part for anyone who cares about where an app comes from. The app is on Google Play, on F-Droid, and in the IzzyOnDroid repository,. Two independent open app stores alongside the Play Store is a good sign for a project that has no company behind it, because it gives you more than one place to obtain the binary.

The project is a default Android project written in Kotlin, with the standard Gradle layout at the root: app, build.gradle.kts, settings.gradle.kts, gradle.properties, a gradlew wrapper, fastlane metadata for the store listings, and a documentation directory that serves the project page.

What the extension actually adds over the original

The feature list is the argument for the fork, and it is worth separating what is about note content from what is about organisation.

On content, NotallyX adds rich text with support for bold, italics, mono space and strike-through, task lists with subtasks and an auto-sort that moves checked items to the end, reminders with notifications for important notes, and attachments of any file type such as pictures or PDFs. It also adds quick audio notes.

On organisation, there is sorting by title, last modified date or creation date, colour, pin and label, and clickable links to notes with support for phone numbers, email addresses and web URLs. There is undo and redo, a home screen widget for quick access to important notes, a biometric or PIN lock, configurable auto-backups, and the ability to display notes as a list or a grid.

There is also an import path, and this is where the project competes with existing note apps rather than with Notally. NotallyX can import from Evernote, Google Keep and Quillpad, so a user moving from a synced note service does not have to abandon their content. Alongside that there are actions to quickly remove checked tasks, quick sharing of notes by text, extensive preferences, an adaptive Android app icon, and support for Lollipop devices and up.

The result is a note app that has grown well past the minimal form, which is worth noting when the description still leads with the word minimalistic.

Beta builds live in their own applicationId with their own data

The beta policy is described with unusual clarity, and it is the detail most likely to matter to an installer.

The maintainer occasionally releases BETA versions during development, because getting feedback before a public release is valuable. Those beta releases have another applicationId from the release versions, which is why installing a beta shows up on the device as a separate app called NotallyX BETA. Beta versions also have their own data and do not use the data of the NotallyX app.

That is a good design decision, and it is the reason you can test a build without risking your notes. A separate applicationId means a separate data directory, so the beta cannot read or overwrite the stable app's content. It also means the beta is a separate install, taking extra space and needing separate removal, and that any change you make while testing lives in the beta sandbox only.

The current release list shows the pattern in action. v7.11.2 shipped on 2026-06-03, the beta tag v7.11.3-BETA on 2026-10-10, and v7.11.3 on 2026-10-11, so the beta for a version lived for about a day before the stable release followed it.

Beta builds are distributed from the GitHub releases page under the beta tag rather than through the stores, which is what makes the certificate check below relevant.

Verifying a downloaded APK against the certificate fingerprint

The README publishes a SHA256 certificate fingerprint so that anyone who downloads an APK can check it is the one the maintainer built:

D2:14:B6:05:7B:79:F8:25:09:DD:CD:1E:35:19:65:B3:C6:EC:C4:B2:A3:89:6E:5C:DF:88:5A:70:A0:B6:1D:FD

This is a small thing that projects often skip. An APK installed from outside a store is an executable that will run with your permissions, and publishing the signing certificate fingerprint gives a user a way to confirm authenticity without trusting the hosting.

The reason it matters most here is the beta channel, since beta builds come from a GitHub release page rather than from Google Play or F-Droid, where the store's own signature checks apply.

The same trust argument applies to the store versions. Because the app is on F-Droid and IzzyOnDroid as well as Play, a user who distrusts the Play build can install a version built from the source in this repository, and the fingerprint tells them which signer to expect.

For the record, the project also ships a Privacy-Policy.md and a CHANGELOG.md at the root, and a crashes.txt file at the root.

Building it, running the tests and formatting the code

The contributing section is direct about the workflow. The project is a default Android project written in Kotlin and the maintainer recommends using Android Studio for development, and asks that changes are tested with an Android device or emulator using the same Android SDK version as the targetSdk defined in build.gradle.

Two commands are named explicitly. Before submitting a pull request, make sure all tests still work:

./gradlew test

and run the formatter for common formatting:

./gradlew ktfmtFormat

The README notes that the formatting step is also executed automatically as a pre-commit hook, so a developer who clones the repository and commits without noticing will get the formatting applied anyway.

The contribution process itself is informal in a good way. The suggested route is to grab an open issue that has no other developer assigned yet, leave a comment saying you want to work on it, and then start by forking the repository. That is a lightweight way to avoid two people writing the same feature.

The tree also contains a .agents directory, an AGENTS.md file, a .scripts directory, a generate-changelogs.sh script and a misc directory, which suggests that release notes and some of the tooling are scripted rather than done by hand.

Crash reporting from inside the app and a crowd-sourced translation model

Two smaller processes are worth describing, because they show how a single-maintainer project handles the parts that usually need a support team.

The first is crash reporting. The README explains that when an unknown error occurs and the app crashes, a dialog appears from which a bug report can be created on GitHub with the crash details pre-filled. The user does not have to find the issue tracker, describe the problem and copy the stack trace by hand.

The second is translation. All translations are crowd sourced, and the repository points to a TRANSLATIONS.md file for details on how to contribute and which languages are available. A fastlane directory holds the per-language store metadata, including the images under fastlane/metadata/android/en-US, so the listing copy and screenshots follow the same layout.

Both approaches share a property: they push the work onto the people who have the context, the user with the crash and the user who speaks the language, and they do it through the project's existing infrastructure rather than through a support portal.

The same single-maintainer shape shows up in the funding link to Ko-fi in the README header, which is where donations for the project go.

Editorial conclusion

Use NotallyX if you want an offline Android notes app with rich text, subtasks, attachments, reminders and a biometric lock, and you are comfortable with a project maintained by one person. Do not pick it if you need multi-device sync, collaboration or a plugin ecosystem, because the README describes a local app whose extensions are about note content rather than about connecting to other accounts, and it is not a fork of a hosted service. Before installing, check the beta channel rules, since a beta build has a different applicationId and its own separate data, verify any downloaded APK against the SHA256 certificate fingerprint in the README, and note that the latest stable release is v7.11.3 from 2026-10-11 with the last push on the same day.

Frequently asked questions

Official sources

1. Crustack/NotallyX on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases