Orgro puts an Emacs-grade Org Mode document on an iOS or Android phone

Org Mode on a phone, aimed at fidelity rather than task apps

Org Mode is an Emacs package that mixes plain text markup, a task system and a literate programming environment. The README describes it as a plain-text markup language like Markdown, but married to an application that is a literate programming environment and life organizer, in Emacs.

Orgro is a Flutter app for reading and editing Org documents on iOS and Android, and the author's stated motivation is specific. He started taking notes in Org Mode at work and then wanted to view them on his tablet in meetings, and on iOS you cannot open an .org file at all, because the OS does not even know it is plain text. The problem is not rendering Org syntax. It is file handling on a phone.

What distinguishes the app from other mobile Org tools is scope. The README says other mobile Org Mode apps seem focused on specific use cases like to-dos or task management, while Orgro is meant to be a well-rounded and high-fidelity experience for viewing, navigating and editing Org documents, with additional functionality added only when it fits well into the core without compromises.

That last clause is a design policy you can check against the feature list. Syntax highlighting for all Org Mode syntax structures, expand and collapse of sections, blocks and drawers, text reflow for narrow screens, a reader mode that hides extraneous markup, pretty table rendering, inline and block LaTeX rendering, visibility cycling, narrowing, plain text and regexp search, Sparse Tree style filtering, jumps to footnotes, to link targets and radio targets, and to src block code references. The manual at orgro.org/manual holds the details.

The parser and the display engine are separate libraries

The interesting engineering decision in Orgro sits outside the app. The author wanted to write a parser with PetitParser, and the result powers the application and is published on its own as org_parser. The display engine is separate again, available as org_flutter for any Flutter app that wants to render Org markup.

That split matters for two audiences. For the app's users it means the rendering is not locked to Orgro's own UI, and for developers it means the hard part, parsing Org's nesting, blocks, drawers and links, can be reused without adopting the app. The topics on the repository list emacs, org-mode, editor, viewer, flutter and ios, which matches a project that grew out of one person's Emacs habits and was then factored into pieces.

The display side is Flutter, and the repository layout shows the parts. There are android and ios platform directories, a lib directory for the Dart code, a web directory, an assets directory, a test directory, a l10n.yaml for localisation, a fastlane directory for store release automation, a config.ini.example, and a CHANGELOG.md. There are also two files that look out of place in a Dart project and are not: .dir-locals.el and .projectile, both Emacs tooling, left in the tree by someone who lives in Emacs.

Two spellcheck dictionaries, .aspell.en_GB.pws and .aspell.en_US.pws, sit at the top level as well, and they turn out to be part of the build rather than leftovers.

Getting the app onto your own device with flutter run

Orgro is distributed three ways: on the App Store, on Google Play, and on F-Droid, with the package identifier com.madlonkay.orgro. The README then gives the source route, and it is three steps:

1. Install [Flutter](https://flutter.dev/)
2. Clone this repo
3. Attach your device and do `flutter run` from the repo root

That is the whole documented build instruction, and it is thin on purpose. The app is the deliverable, so the source route is for people who want to change it, not for packaging it themselves.

There is one complication hiding in the repository. The Makefile does not call the flutter binary on your PATH. It points at a copy inside the repository:

SHELL := /usr/bin/env bash
flutter := ./flutter/bin/flutter
dart := ./flutter/bin/dart
version_define = --dart-define=ORGRO_VERSION=$(shell sed -nE 's/version: *(([0-9.])+)\+.*/\1/p' pubspec.yaml)
walled_garden_define := --dart-define=ORGRO_WALLED_GARDEN=true
dart_defines = $(version_define) $(walled_garden_define)

A .gitmodules file sits at the top level, so the Flutter SDK is expected to be checked out into that directory. The version define is scraped out of pubspec.yaml rather than typed into a file, which keeps a single source of truth for the version number. The walled garden define is passed the same way, and the README does not explain what it changes, so treat it as a switch the build turns on rather than a documented feature.

The Makefile holds the workflow the README leaves out

Most of what a contributor needs is in the Makefile, not the README. The run target launches the app with the full environment:

run: ## Run app with full environment
	$(flutter) run $(dart_defines) $(args)

The test target runs the analyser and the test suite together, which is the pair you want green before opening a pull request:

test: ## Run tests
	$(flutter) analyze
	$(flutter) test

There are also generate, which runs pub get and gen-l10n, format-check, which runs the Dart formatter with a flag that fails the build when files differ, and dirty-check, which aborts if git reports uncommitted changes. A build target cleans stray backup files out of the assets directory before packaging, and a key_store variable extracts the keystore path from android/key.properties, which is where the signing configuration for Android release builds lives.

The localisation checks are the most involved part. The Makefile requires the locales en_US, en_GB and ja, diffs the set of translation keys in each arb file against the en base, and pipes the user-facing strings through aspell with a per-language personal dictionary. The failure mode of aspell here is that unknown words fail the check, which is why the two .aspell.pws files exist: to teach the spellchecker the words that a translator is allowed to use.

Org features that survive the trip to a phone, and the ones that do not

Reading and navigating are the strong half of the app. Beyond the display list, the navigation features include external links, section links and relative links to other Org files, which the README says works well with Org-roam, plus jumps to and from footnotes and to radio targets. Task management is functional too, with checkboxes, TODO state cycling, statistics cookies, and notifications for Org Agenda items including recurring ones.

Editing is where the phone gets in the way, and the README is honest about the shape of it. You can edit entire files or narrowed sections as plain text, with various insertion helpers, and there is some structured editing: tap to toggle checkboxes, slide sections to cycle TODO states, tap to edit timestamps through a date and time picker. In other words, the app gives you a text editor with a few gestures layered on top, rather than a full structured editor.

Two integrations are easy to miss. Orgro captures text and links from other apps through the standard OS share UI, and also handles org-protocol:// links, which is how an Emacs session hands a link to the phone. And it can decrypt and encrypt Org Crypt sections, currently with symmetric keys only, so a passphrase based scheme is outside what the app supports.

The app also honours document-local directives, specifically #+STARTUP:, #+TODO: and #+LANGUAGE:, along with some local variables. That is the mechanism by which a file you keep in Emacs opens in the phone app with the same visibility settings, the same keyword set and the same language.

GPL-3.0 code, a paid download, and no GitHub releases

The licence is GPL-3.0, with the text in the LICENSE file at the top level of the repository. For an application whose parser and renderer are published as separate libraries, that is the licence that lets org_parser and org_flutter be reused in closed source work only if the whole derived work is released, which is the usual trade and worth understanding before you embed org_flutter in a commercial Flutter app.

The project is also sold. The README asks readers to show their support by buying a copy or sponsoring the author, and the App Store and Google Play listings are where that purchase happens, and the F-Droid listing sits alongside them. The README does not spell out the pricing model or which builds are paid, so check the store listings for the current arrangement rather than assuming.

On maintenance, the repository is not archived and the last push was on 2026-10-15. There are no GitHub releases, so there is no tag history to consult and no published changelog on the releases page; the CHANGELOG.md file in the repository is where changes are recorded. The version number itself lives in pubspec.yaml, and the Makefile scrapes it out at build time, so the version a user sees and the version in the changelog come from the same source.

The project also notes that in the five or more years since it started, additional functionality was added only when it fits well into the core without compromises. That is a deliberate statement about scope, and it means a missing feature is more likely to be a decision than an oversight.

Where Orgro is the wrong tool

The clearest wrong case is if you need to author serious Org structure on the phone. The editing model is plain text with a handful of structured gestures, and anything beyond toggling a checkbox or changing a timestamp means writing markup by hand. Someone who drafts their day in Org, with elaborate planning blocks and refile targets, will find the phone app a reader with editing bolted on, which is what the author intended.

The second wrong case is Org Crypt with asymmetric keys. The README is specific that only symmetric keys are supported, so encrypted sections that rely on the asymmetric scheme are outside what the app supports.

The third is expecting the phone app to replace Emacs for Org-roam workflows. The relative links to other Org files are supported and the README says this works well with Org-roam, but that is a file-level integration. Capture through org-protocol:// and share-sheet import solve the problem of getting content onto the phone, not the problem of managing a roam graph from it.

The comparison with the vendor apps is worth stating plainly. A dedicated to-do app offers notifications, reminders and widgets that Orgro does not attempt to match, because Orgro is built around a document you already keep in Emacs. If your notes live somewhere other than an.org file, this app does not have an obvious place in your workflow, and the F-Droid build is a better thing to try first than a purchase.

Editorial conclusion

Orgro fits anyone who keeps notes or tasks in Org Mode and wants to read or edit them on a phone, especially people who already rely on Org-roam and on Org Crypt sections. It does not fit as a full Org editing environment, since the editing model is plain text plus a few structured gestures, and Org Crypt support is limited to symmetric keys. Before you rely on it, read the manual at orgro.org/manual for the feature list rather than the README summary, and note that there are no GitHub releases, so the version comes from pubspec.yaml and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. amake/orgro on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README