# Open Apps — full directory > Generated 2026-09-04T01:37:14.044Z from 89 records. > Source: https://openappscout.com/apps · Regenerate with `pnpm build`. Each section below mirrors one record detail page. ## Index - [admin-portal](#admin-portal) — finance · flutter · 1753★ — Flutter (Dart) admin client for the Invoice Ninja v5 invoicing platform, shipping to iOS, Android, macOS, Windows, Linux - [Airdash](#airdash) — tools · flutter · 669★ — AirDrop-style file sharing to nearby devices over Wi-Fi and Bluetooth, no internet required. - [AltStore](#altstore) — tools · ios · 14272★ — AltStore is a sideloading app store for non-jailbroken iOS devices that re-signs installed apps with a personal Apple de - [apidash](#apidash) — tools · flutter · 2891★ — API Dash is a Flutter-based cross-platform API client for building, sending, and inspecting HTTP, GraphQL, and SSE reque - [app-finance](#app-finance) — finance · flutter · 134★ — Fingrom is a Flutter-built, ad-free, multi-currency personal finance app that ships to iOS, Android, macOS, Windows, Lin - [AppFlowy](#appflowy) — productivity · flutter · 76236★ — Bring projects, wikis, and teams together with AI. AppFlowy is the AI collaborative workspace where you achieve more wit - [Artsy](#eigen) — shopping · react-native · 3773★ — Artsy Eigen is the official iOS and Android client for artsy.net, built as a React Native app with native Swift and Kotl - [ATV-Bilibili-demo](#atv-bilibili-demo) — entertainment · ios · 3131★ — ATV-Bilibili-demo is an open-source Bilibili client demo built for Apple TV and its tvOS focus-driven interface. - [AudioKit](#audiokit) — media · ios · 11457★ — AudioKit is a Swift audio synthesis, processing, and analysis framework for iOS, macOS, tvOS, and visionOS that wraps AV - [Authier](#authier) — productivity · react-native · 14★ — Authier is an experimental AGPL password manager monorepo with a React Native client, browser extensions, and a web vaul - [BeeCount](#beecount) — finance · flutter · 2254★ — BeeCount is a Flutter-based local-first bookkeeping app for iOS, Android, and Web that offers five interchangeable sync - [Berty](#berty) — communication · react-native · 9290★ — Berty is a peer-to-peer messenger that runs entirely over the Wesh protocol on top of libp2p, so peers connect directly - [BikeShare](#bikeshare) — tools · ios · 828★ — SwiftUI, Jetpack Compose, Compose for Desktop and Compose for Web based Kotlin Multiplatform project (using CityBikes AP - [Blink Comparison](#blink-comparison) — tools · flutter · 300★ — Simplifies comparing photos of tamper-evident seals and patterns using your eyes - [BlueWallet](#bluewallet) — finance · react-native · 3282★ — Bitcoin wallet for iOS & Android. Built with React Native. - [brethap](#brethap) — tools · flutter · 85★ — Brethap is a Flutter meditation app that pairs a session timer with configurable six-phase breathing patterns, four sele - [Butterfly](#butterfly) — productivity · flutter · 1992★ — Butterfly is a Flutter note-taking and drawing app whose central object is an infinite canvas — pages hold freehand ink, - [cake_wallet](#cake-wallet) — finance · flutter · 1895★ — Cake Wallet is an open-source, non-custodial, multi-currency crypto wallet for iOS, Android, macOS, Linux, and Windows, - [Cap](#cap) — tools · tauri · 21587★ — Open source Loom alternative. Beautiful, shareable screen recordings. - [d1v.ai Mobile](#d1vai-app) — developer-tools · flutter · 7★ — A Flutter mobile workspace for creating or importing projects, continuing AI-assisted work, inspecting files, and monito - [Daily_You](#daily-you) — tools · flutter · 1283★ — Daily You is a privacy-first, offline-capable journaling app for capturing daily entries with text, mood ratings, photo - [EhPanda](#ehpanda) — media · ios · 3965★ — EhPanda is an unofficial iOS and iPadOS client for the E-Hentai and ExHentai galleries, written entirely in SwiftUI on t - [Ejimo](#ejimo) — tools · flutter · 60★ — A cross-platform emoji and symbol picker that goes beyond the system keyboard. - [Feather](#feather) — productivity · ios · 4643★ — Free on-device iOS/iPadOS application manager/installer, using certificates part of the Apple Developer Program. - [feed-flow](#feed-flow) — news · ios · 1195★ — FeedFlow is a minimalistic RSS Reader available on Android, iOS, macOS, Windows and Linux. Built with Kotlin Multiplatfo - [Flip](#flip) — games · flutter · 269★ — A Reversi board game implementation with a clean interface for casual play. - [Flutter Games](#flutter-games) — shopping · flutter · 345★ — Flutter app for purchasing and renting games - [Flutter WooCommerce app](#flutter-woocommerce-app) — shopping · flutter · 714★ — A ready-made app template for WooCommerce stores - [flutter_server_box](#flutter-server-box) — tools · flutter · 8634★ — A Flutter-based, cross-platform client for monitoring and administering remote Linux, Unix, and Windows servers over SSH - [flutter-pos-system](#flutter-pos-system) — developer-tools · flutter · 603★ — An offline-first Flutter point-of-sale app for small restaurants and shops that runs ingredient inventory, menu manageme - [GitUp](#gitup) — tools · ios · 12117★ — GitUp is a native macOS Git GUI built on a bespoke in-process Git toolkit (GitUpKit) that wraps a customized libgit2 for - [Habo](#habo) — productivity · flutter · 1500★ — Habo is a Flutter-based, privacy-first habit tracker for iOS and Android that keeps every habit, note, and streak on-dev - [Hacki](#hacki) — news · flutter · 1616★ — A clean Hacker News reader for iOS, with offline support and custom themes. - [Harbour](#harbour) — productivity · ios · 760★ — Docker/Portainer management app for iOS, iPadOS and macOS. - [Helm](#helm) — tools · flutter · 0★ — Helm is a macOS system toolkit that puts fifteen maintenance and monitoring tools behind one window and one menu-bar ite - [HorizonCalendar](#horizoncalendar) — productivity · ios · 3158★ — HorizonCalendar is Airbnb's declarative, performant iOS calendar UI framework that renders month and week views from a s - [IceCubesApp](#icecubesapp) — social-network · ios · 7053★ — IceCubesApp is a SwiftUI-native, multi-platform Mastodon client for iOS, iPadOS, macOS, and visionOS, built and maintain - [Immich](#immich) — tools · flutter · 113341★ — Self-hosted photo and video backup solution directly from your mobile phone - [Invoice Ninja](#invoice-ninja) — business · flutter · 1753★ — Companion app for the Invoice Ninja platform. Invoicing, expenses, time-billing, payments. - [ish](#ish) — productivity · ios · 20403★ — A Linux shell environment running on iOS, useful for command-line work on mobile devices. - [Joplin](#joplin) — productivity · react-native · 56227★ — Joplin is a free, open source note taking and to-do application. The mobile client is built with React Native and suppor - [Karakeep](#karakeep) — productivity · react-native · 28760★ — Karakeep is a self-hostable bookmark-everything application built on Next.js 16 + Hono + tRPC over Drizzle on SQLite wit - [Keybase](#keybase) — communication · react-native · 9245★ — Keybase Go Library, Client, Service, OS X, iOS, Android, Electron.. - [LibreTrack](#libretrack) — productivity · flutter · 364★ — Private, cross-platform package tracking app - [Linkwarden](#linkwarden) — productivity · react-native · 19672★ — Linkwarden is a self-hosted collaborative bookmark manager that captures every saved page as a screenshot, PDF, and HTML - [localmind](#localmind) — developer-tools · flutter · 199★ — A Flutter mobile chat client that connects to on-device LLMs and any OpenAI-compatible server — Ollama, LM Studio, OpenR - [Loofah](#loofah) — productivity · tauri · 3★ — Loofah is an MIT-licensed, local-first meeting notetaker for macOS that records and transcribes on-device and stores not - [MangoDisk](#mangodisk) — tools · tauri · 2096★ — MangoDisk is a safety-first disk cleaner and storage analyzer for macOS and Windows that scans locally, visualizes disk - [MarketMonk](#marketmonk) — tools · flutter · 60★ — A Flutter stock and portfolio tracker that combines Yahoo Finance market data, interactive charts, local trade records, - [Mathematics](#mathematics) — education · flutter · 144★ — Generate MCQ PDFs and question papers with answers and quiz mode. Useful for educators and students preparing for exams. - [Mattermost Mobile](#mattermost-mobile) — communication · react-native · 2714★ — Mattermost Mobile is the official React Native iOS and Android client for the self-hostable Mattermost messaging platfor - [medito-app](#medito-app) — health-and-fitness · flutter · 1308★ — Medito is a permanently-free Flutter meditation app maintained by the Medito Foundation that streams guided sessions, mu - [Memex](#memex) — productivity · flutter · 714★ — Memex is a Flutter-based, local-first AI journal for iOS and Android that captures text, photo, and voice fragments, run - [MetaMask Mobile](#metamask-mobile) — finance · react-native · 3017★ — MetaMask Mobile is the official Consensys-maintained mobile wallet for the Ethereum ecosystem, shipped as a React Native - [mhabit](#mhabit) — productivity · flutter · 1533★ — mhabit (Table Habit) is a Flutter-based micro-habit tracker that scores daily completion against configurable curves, st - [Mise](#mise) — business · flutter · 0★ — Mise is a self-hosted restaurant system for macOS that runs a till, a kitchen display, QR table ordering, and a back off - [Monekin](#monekin) — finance · flutter · 254★ — Monekin is an offline-first, open-source Flutter personal finance manager that tracks unlimited accounts, transactions, - [Notesnook](#notesnook) — productivity · react-native · 14487★ — Notesnook is a cross-platform, end-to-end encrypted note-taking app with web, desktop, and mobile clients that sync thro - [oinkoin](#oinkoin) — finance · flutter · 461★ — Oinkoin is an offline-first Flutter expense tracker that keeps every record in a local SQLite database, ships with biome - [one_second_diary](#one-second-diary) — media · flutter · 405★ — One Second Diary is a minimalist Flutter video diary app that lets you capture a one-to-ten second clip each day, then s - [OnionBrowser](#onionbrowser) — productivity · ios · 2670★ — An open-source, privacy-enhancing web browser for iOS, utilizing the Tor anonymity network - [Open Food Facts](#open-food-facts) — health-and-fitness · flutter · 1407★ — The mobile companion to Open Food Facts — scan barcodes, decode ingredient lists, and contribute new products to the ope - [OpenDesign](#open-design) — developer-tools · — · 93830★ — A local-first Apache-2.0 desktop and web application that turns any of 27 coding-agent CLIs into a design engine, produc - [peercoin_flutter](#peercoin-flutter) — finance · flutter · 32★ — peercoin_flutter is a self-custodial light wallet for Peercoin and Peercoin Testnet, written in Flutter and shipped to A - [PeopleInSpace](#peopleinspace) — tools · ios · 3427★ — PeopleInSpace is a Kotlin Multiplatform reference app that shares architecture and data code across iOS, Android, deskto - [Posnic POS](#posnic-pos) — business · javascript · 3★ — Posnic POS is offline-first open-source POS and billing software for retail shops and restaurants, built as a JavaScript - [Rainbow](#rainbow) — finance · react-native · 4386★ — Rainbow is a multi-chain Ethereum wallet for iOS and Android, built on React Native with Reanimated 3 and Shopify FlashL - [Rocket.Chat](#rocket-chat-react-native) — communication · react-native · 2413★ — Official Rocket.Chat mobile client — open-source team communication, channels, threads, file sharing, voice/video calls, - [Rockxy](#rockxy) — developer-tools · ios · 1343★ — A native macOS HTTP debugging proxy for inspecting HTTPS, API, WebSocket, and GraphQL traffic. - [roxum-ide](#roxum-ide) — developer-tools · flutter · 601★ — A mobile-first Flutter code editor and mini IDE for Android with LSP, an embedded terminal, Git/GitHub tooling, and opti - [rustdesk](#rustdesk) — developer-tools · flutter · 122512★ — RustDesk is a self-hostable, cross-platform remote desktop application written in Rust with a Flutter UI, offering an op - [Shieldxy](#shieldxy) — tools · ios · 1★ — An auditable macOS application firewall and connection monitor with explicit local network controls. - [sossoldi](#sossoldi) — finance · flutter · 1392★ — Sossoldi is an MIT-licensed, Flutter-built personal wealth manager that tracks net worth, expenses, income, and investme - [storypad](#storypad) — productivity · flutter · 951★ — Storypad is an offline-first Flutter diary and journal app that uses a timeline instead of folders, layers mood tracking - [Swift-Radio-Pro](#swift-radio-pro) — media · ios · 2939★ — Swift-Radio-Pro is a Swift iOS streaming-audio reference app that plays live radio from a list of stations, surfaces now - [SwiftHub](#swifthub) — tools · ios · 3117★ — SwiftHub is an iOS GitHub client built on RxSwift and MVVM-C clean architecture, wiring Moya (REST v3) and Apollo (Graph - [SwiftTerm](#swiftterm) — tools · ios · 1678★ — An Xterm/VT100-compatible terminal emulator implemented in Swift for iOS. - [thunderbird-ios](#thunderbird-ios) — communication · ios · 1173★ — Thunderbird for iOS – Open Source Email App for iOS. - [Tracexy](#tracexy) — developer-tools · ios · 126★ — A native, local-first macOS app for capturing live network traffic and investigating PCAP and PCAPNG files. - [Tura](#tura) — tools · tauri · 612★ — Build agent that uses 80% less token and delivers better results. - [Twenty](#twenty) — business · react · 56145★ — Twenty is an open-source CRM whose data model is a runtime artifact — every custom object, field, view, role, and AI age - [Unwrap](#unwrap) — tools · ios · 2333★ — Learn Swift interactively on your iPhone. - [UTM](#utm) — productivity · ios · 35331★ — Run virtual machines on iOS and macOS — Windows, Linux, and retro operating systems. - [Voicebox](#voicebox) — tools · tauri · 52225★ — Voicebox is a local-first AI voice studio that bundles seven TTS engines, Whisper STT, a Qwen3 LLM for refinement and pe - [waterfly-iii](#waterfly-iii) — finance · flutter · 703★ — Waterfly III is a Flutter-built Android and iOS client for the self-hosted Firefly III personal finance manager, wrappin - [Weiyu](#weiyu) — productivity · tauri · 20★ — Weiyu is a local-first Windows desktop app that turns readable WeChat messages into searchable daily briefings, with his - [wger](#wger) — health-and-fitness · flutter · 963★ — A Flutter workout and fitness tracker that syncs with the self-hosted wger server, supporting routines, exercises, and p - [xbmc](#xbmc) — tools · ios · 21172★ — Kodi is a free, open-source cross-platform media-center and entertainment-hub application written primarily in C++ with - [YouTrack Mobile](#youtrack-mobile) — productivity · react-native · 285★ — Official JetBrains YouTrack mobile app — issue tracking, agile boards, knowledge base, and notifications for YouTrack pr ## Apps ### admin-portal Flutter (Dart) admin client for the Invoice Ninja v5 invoicing platform, shipping to iOS, Android, macOS, Windows, Linux, and web from a single codebase. Uses Redux + built_value over a single AppState that carries up to ten UserCompanyState slots, talks to the Laravel backend over REST, and ships with a hand-built .foss swap-out that strips the proprietary dependencies for the F-Droid, Snap, and Flatpak builds. - slug: admin-portal - category: finance - stack: flutter - stars: 1753 - license: NOASSERTION - repo: https://github.com/invoiceninja/admin-portal - homepage: https://invoiceninja.com - url: https://openappscout.com/apps/admin-portal - lastCommit: 2026-08-21 - added: 2026-08-11 #### Detail # Invoice Ninja Admin Portal The admin portal is the operator half of [Invoice Ninja](https://invoiceninja.com): the app a business owner or bookkeeper opens to raise a quote, convert it to an invoice, chase the payment, and reconcile it against a bank feed. It is a pure client — all persistence lives in the separate [`invoiceninja/invoiceninja`](https://github.com/invoiceninja/invoiceninja) Laravel server (v5), which the portal talks to over REST. A public demo backend (`demo.invoiceninja.com`) is wired into the login screen so you can drive the whole UI before standing up your own instance. The thesis the rest of this review will defend: this is the most permissive self-host invoicing open-core line in the comparison set, wrapped around the only officially maintained cross-platform Flutter client in the self-host invoicing space — and both of those claims deserve to be qualified, because the licensing is not what it looks like at first glance and the desktop quality does not match the marketing. ## The whole money lifecycle, on six platforms One Flutter codebase ships the admin portal to iOS, Android, macOS, Windows, Linux (Snap and Flatpak), F-Droid, and web. The Flutter client wraps the full Invoice Ninja v5 surface — quotes, invoices, recurring invoices, credits, purchase orders, payments (Stripe, PayPal, Square, GoCardless), expenses, vendors, projects, time tracking, Kanban task boards, e-invoicing in twenty-plus regional formats (EN16931, PEPPOL, XInvoice, FatturaPA, Facturae, VERIFACTU, Order-X), recurring billing, custom designs, and a client portal on your own domain. Every entity gets a directory under `lib/redux/` and a parallel view/edit directory under `lib/ui/` (client, vendor, product, quote, invoice, recurring invoice, credit, purchase order, payment, payment term, expense, recurring expense, subscription, tax rate, bank account, bank transaction, transaction rule, project, task, task status, company gateway, webhook, token, design, schedule, report, group, user, and more). That repetition is the point: any entity is legible once you have read one. The Flutter client is genuinely cross-platform in the way the marketing copy claims, with one important caveat we will return to. ## The licensing story, which the README is silent on Two repositories, two non-OSI licenses. The Laravel backend ([`invoiceninja/invoiceninja`](https://github.com/invoiceninja/invoiceninja)) is under the [Elastic License 2.0](https://www.elastic.co/licensing/elastic-license) — source-available, not OSI-open, no hosting-as-a-managed-service, no "make a competing SaaS." The Flutter admin client ([`invoiceninja/admin-portal`](https://github.com/invoiceninja/admin-portal)) ships an `LICENSE.txt` declaring the "Attribution Assurance License (adapted from the original BSD license)" — copyright 2021 Hillel Coren — which requires prominent runtime attribution and prohibits trademark use of "Invoice Ninja" without written permission. This is materially different from the BSD/MIT/Apache the casual reader might assume from "adapted from BSD," and the project's own README is silent on which license applies. F-Droid lists the build under "Attribution" with a "Non-Free Network Services" anti-feature warning; the iOS App Store and the official site describe the app variously as "100% free" or "100% source-available." In practice, this means you can run your business on Invoice Ninja indefinitely, fork and modify the code, remove the branding (with the $40/year white-label license), and distribute the binary to other non-competing users. You cannot offer it as a competing SaaS, and you cannot use the "Invoice Ninja" trademark on derivative products. Anyone with a strict OSI-only requirement should not be here; readers who are fine with source-available and not running a competing hosted service can ignore the legal hair-splitting and run the thing. ## The most permissive self-host open-core line in the comparison set The single most important reader-facing fact about the self-host story is that the v5 backend binary ships with **every Pro and Enterprise feature compiled in**. The hosted SaaS tiers gate those features behind $14/month (Pro) or $18–$300/month (Enterprise) plans, but on self-host they are all present in the source. The only thing the $40/year white-label license buys is the removal of the "Created by Invoice Ninja" string from the client portal and the PDF outputs. The Flutter client uses the same "show-but-allow-with-banner" pattern: a Pro feature is visible in the UI, but on the free plan an "Upgrade to paid plan" banner is rendered. A `state.isProPlan` getter on the single `AppState` is the gate; `kAdvancedSettings` in `lib/constants.dart` is the list. Compared to the alternatives surveyed at the time of writing, this is uniquely generous. [Akaunting](https://github.com/akaunting/akaunting) hard-caps its BSL 1.1 free core at two users, one company, and a thousand invoices, with most useful features sold as separate App Store add-ons. [EspoCRM](https://github.com/espocrm/espocrm) is AGPL-3.0 (genuinely open) and bundles invoicing in the free core, but its Advanced Pack extension (Reports, BPM, Workflows) is paid at US$395 and must be uninstalled if the license lapses. [SolidInvoice](https://github.com/SolidInvoice/SolidInvoice) is true MIT, but with a narrower feature scope and no mobile app at all. [Crater](https://github.com/crater-invoice-inc/crater) is AGPL-3.0 and was last released in 2022. [InvoicePlane](https://github.com/InvoicePlane/InvoicePlane) is MIT but the v2 rewrite has not shipped a release in seven years. ## The five architectural decisions worth studying **1. A single `AppState` over Redux + `built_value` immutables.** Every domain has a five-file pattern under `lib/redux//`: `*_actions.dart`, `*_middleware.dart`, `*_reducer.dart`, `*_selectors.dart`, `*_state.dart`. JSON decode happens on a background isolate via `compute()`. The trade-off: the state size is enormous, and a refactor to feature-sliced reducers would be significant. The lesson: `built_value` as both wire-format and cache-format eliminates the domain/DTO boundary — and forces every reader to learn `Built` semantics. **2. Multi-tenancy via `BuiltList`.** A single `AppState` carries up to ten `UserCompanyState` slots, each with a full Redux substate tree (49 `EntityType` values across ~1,100 lines of `entities.dart`). Switching companies is a single `SelectCompany` action that triggers `RefreshData`. The trade-off: no synchronization between company slots, and switching always re-fetches. The lesson: indexing substate by user-tenant via a single enum-like action is a clean alternative to dynamic dispatch — unusual in this space, where most alternatives are single-company per install. **3. No business logic in the client.** Totals, taxes, line-item math, and PDF rendering all happen on the Laravel backend; the client displays pre-computed fields and POSTs/PUTs raw entities back. There is no SQLite, no IndexedDB, no offline queue. The trade-off: no offline support. The lesson: if the backend can do all math, a Flutter client can be a glorified read-cache — and ship to five platforms off one toolchain. **4. Plan gating via "show-but-allow-with-banner."** The `state.isProPlan` flag is computed from `account.plan` returned by the server, and the UI inserts upgrade banners into advanced settings screens rather than hiding them. The trade-off: heavy string-literal coupling between `kAdvancedSettings` and route strings. The lesson: if you must show-but-not-allow to drive conversions, a single computed boolean plus a centralized list of "feature keys" is the cleanest pattern. **5. Open-core boundary via a `.foss` file-swap ritual.** The README's "Steps to remove non-FOSS code" recipe asks the F-Droid, Snap, and Flatpak maintainers to manually copy `.foss` variants of `oauth.dart`, `app_review.dart`, `upgrade_dialog.dart`, `pinput.dart`, `AndroidManifest.xml`, and `pubspec.yaml` over the proprietary files. The `.foss` upgrade dialog is a no-op `Container()`; the `.foss` OAuth helper is a stub that returns `false`. The trade-off: this is a manual ritual, easy to get wrong, and the `settings.gradle.foss.kts` step in the README is itself a no-op — the actual Google Mobile Services plugin drop happens via `build.gradle.dev.kts` versus `build.gradle.prod.kts` at the app level. The lesson: file-swap open-core is dead-simple but error-prone, useful when the proprietary features are isolated single dependencies, and it does not scale to deeply embedded features. The README's no-op entry is itself an interesting editorial signal about how the recipe was authored and never cleaned up. ## The Linux desktop story, told honestly The marketing framing is that the Flutter desktop client is a differentiator. The community reality is that it is unstable on Linux: [the official forum thread](https://forum.invoiceninja.com/t/invoice-ninja-desktop-app-freeze/14451) documents a reproducible memory leak climbing from ~130 MB to >1.4 GB over twenty hours, with the maintainer (Hillel Coren) explicitly deferring to upstream [`flutter/flutter#73402`](https://github.com/flutter/flutter/issues/73402) rather than rewriting the desktop client. The [Manjaro forum](https://forum.manjaro.org/t/invoiceninja-does-not-start-via-snap-install/125509) records `BadAlloc` X crashes on launch and GTK theming warnings; the recommendation that emerges in both threads is to fall back to the web app. The maintainers' position is consistent across years; the marketing has not caught up. The desktop client is reasonable on macOS and Windows. It is rough on Linux. Plan accordingly. ## The data-egress story, which a self-hoster needs to know The Flutter admin-portal binary ships with hard-coded references to `sentry2.invoicing.co` (Sentry error reporting, gated by `account.reportErrors` but enabled by default on hosted accounts), `wss://ws.invoicing.co/app/ninja` (a WebSocket endpoint that is currently disabled in source but whose URL is still shipped), and `https://preview.invoicing.co/api/v1/live_preview` (PDF preview rendering, which the client always talks to even on a self-hosted install). Authentication tokens are stored in `SharedPreferences` with a base64-obscured `TokenEntity.obscureToken` — not encrypted; `flutter_secure_storage` is not in the dependency tree. On a rooted Android or jailbroken iOS device, the token is recoverable in plaintext. For a self-hoster with strict data-egress requirements, the path forward is to fork the client and remove the hard-coded endpoints; for everyone else, the Sentry DSN and the preview URL are annoyances but not deal-breakers. A related first-time self-hoster complaint, repeated across the official docs, GitHub issues, the YunoHost forum, and the TurnKeyLinux tracker, is the `API_SECRET` mismatch: the desktop and mobile clients will not log in to a self-hosted backend until the secret on the server matches the one shipped in `lib/.env.dart.example`. Official docs explicitly call this out as the number-one reason for mobile login failures. ## When to choose this, and when not to **Choose Invoice Ninja admin-portal when** you want the full v5 invoicing surface self-hosted without paying per feature, when you actually need cross-platform clients (iOS, Android, Windows, macOS, Linux, web) from one codebase, when you want a multi-company model with up to ten companies under one login, or when you want to host a custom-branded client portal on your own domain and you are fine with the source-available license. **Choose something else when** you need a true OSI-approved license (use EspoCRM for AGPL-3.0 plus CRM, or SolidInvoice for MIT); when your organization is in a regulated industry and strict data-egress controls make the hard-coded `invoicing.co` endpoints unacceptable without a fork; when your business logic really needs offline support (use a local-first ledger like [BeeCount](https://github.com/TNT-Likely/BeeCount)); when you need a full CRM underneath the invoicing (use EspoCRM); or when you want hosted-only with zero operational overhead (use FreshBooks, Wave, or InvoiceBerry and accept the recurring subscription). The central trade-off is this: **Invoice Ninja gives you the broadest self-host feature surface across the most platforms, on the condition that you accept a source-available license the README does not name, a Linux desktop client the maintainers acknowledge is rough, and a binary that ships hard-coded references to invoicing.co even on self-hosted installs.** The alternatives that beat Invoice Ninja on any single axis lose on at least one of those three dimensions. ## Watch this one - The new `invoiceninja/flutter` repo (27 stars, pushed 2026-08-16) is a candidate successor to `admin-portal`. Not yet canonical; worth a re-check in ninety days. - The late-2023 recharacterization of self-hosted "lifetime" licenses as 2-year terms is the most consequential governance event in the project's recent history. Anyone evaluating Invoice Ninja in 2026 should weight it. - The Flutter memory leak is still open against upstream Flutter. If a fix lands, the Linux desktop story changes materially. - The `API_SECRET` first-time-self-hoster pain is consistently the number-one community complaint and could be solved by a one-line client change to read the secret from the login URL. For a deeper look at the `.foss` open-core pattern itself, at the security and data-egress profile of the self-host client, or at a side-by-side comparison of self-host invoicing licensing on the ELv2 / BSL / MIT / AGPL axis, see the open-apps research archive under `.grove/research/invoiceninja/`. ### Airdash AirDrop-style file sharing to nearby devices over Wi-Fi and Bluetooth, no internet required. - slug: airdash - category: tools - stack: flutter - stars: 669 - license: MIT - repo: https://github.com/simonbengtsson/airdash - url: https://openappscout.com/apps/airdash - lastCommit: 2026-08-27 - added: 2026-06-07 ### AltStore AltStore is a sideloading app store for non-jailbroken iOS devices that re-signs installed apps with a personal Apple developer certificate and refreshes them in the background via a desktop companion to bypass Apple's 7-day signing limit. - slug: altstore - category: tools - stack: ios - stars: 14272 - license: AGPL-3.0 - repo: https://github.com/altstoreio/AltStore - url: https://openappscout.com/apps/altstore - lastCommit: 2026-07-14 - added: 2026-06-13 #### Detail # AltStore AltStore is a sideloading app store for non-jailbroken iOS devices. It ships its own signed IPA you install once, then leans on a small macOS / Windows / Linux companion called **AltServer** to install and refresh apps on demand. ## Why it matters - **Sideloading without jailbreaking.** Apple normally only lets apps installed via the App Store, TestFlight, or a paid Developer Enterprise Program provisioning profile stay on the device. AltStore uses the *personal* Apple developer certificate that comes free with any Apple ID to re-sign arbitrary `.ipa` files and install them through the same iTunes Wi-Fi sync channel AltServer exposes. - **The "refresh" trick.** A free personal certificate expires every seven days; sideloaded apps would stop launching. AltStore's `RefreshAppOperation` reconnects to AltServer whenever the iPhone is on the same network, re-signs each app's provisioning profile, and reinstalls it before the deadline — so apps survive indefinitely without the user noticing. This is the single feature that separates AltStore from TestFlight (90-day builds, app-controlled) and from the official App Store (App-Review-gated, no third-party distribution). - **Mature iOS reference code.** 14k+ stars, ~2.1M lines of Swift, an AGPL-3.0 license, and a clean split between the iOS app, the AltKit / AltSign shared frameworks, and the macOS companion. ## How it works The iOS app target (`AltStore/`) is a vanilla Swift / UIKit project that uses Storyboards, Auto Layout, Core Data, and Apple's `Network` framework. Discovery of nearby AltServer instances is done through Bonjour (`NetServiceBrowser`) over the local network, plus a fallback USB / XPC connection via `AltXPC` for wired installs. All communication runs over an encrypted `ServerConnection` carrying typed requests such as `BeginInstallationRequest` and `InstallProvisioningProfilesRequest`. Signing lives in the separate **AltSign** framework (vendored under `Dependencies/`). It talks to Apple's developer API on behalf of the user's Apple ID, asks for an `ad-hoc` provisioning profile, and re-signs the app bundle with that profile. **AltServer** is a thin macOS shell that forwards these signed bundles to the iPhone over iTunes Wi-Fi Sync, plus a privileged helper (`STPrivilegedTask`) that lets it install without user prompts. The refresh cycle is driven by iOS Background Fetch — `AppDelegate` runs an hourly background task that reconnects to AltServer and asks it to re-issue provisioning profiles for every installed app. Logs flow through `Logger.sideload` (`Logger(subsystem:category:)`) so the full lifecycle of a refresh is greppable from the device console. ## Caveats - **Apple policy is fragile.** AltStore depends on Apple's developer API continuing to issue free provisioning profiles for free Apple IDs. Apple has tightened these limits before (capping active apps to three and shortening the signing window); a future policy change could break the refresh mechanism. - **You need a host computer.** A Mac, Windows PC, or Linux box running AltServer has to be on the same network for refreshes to succeed. Without it, apps stop launching after seven days. - **Not a replacement for the App Store.** Apps distributed via AltStore are not reviewed by Apple, do not have IAP through StoreKit, and cannot use most App-Store-only entitlements (push notifications through APNs, Sign in with Apple, etc.). ## Deployment notes 1. **Install AltServer** on your Mac, Windows PC, or Linux box from and let it install the Mail plug-in so it can talk to iTunes / Apple Devices. 2. **Sideload the AltStore app** by opening on the iPhone, downloading the `.ipa`, and sharing it to AltServer. AltServer signs it with your Apple ID and pushes it back over Wi-Fi sync. 3. **Browse and install.** Open AltStore on the phone, add a source such as the AltStore marketplace, and tap Install. Background fetch keeps every installed app's provisioning profile alive as long as AltServer stays reachable on the same network. **Integration tip:** if you maintain a Grove-style directory like this one, link AltStore as the canonical example of a non-jailbroken sideloading workflow whenever you explain how `stack: ios` apps ship *outside* the App Store. ### apidash API Dash is a Flutter-based cross-platform API client for building, sending, and inspecting HTTP, GraphQL, and SSE requests, with code generation for 20+ languages and an optional LLM assistant called DashBot that runs locally or against a cloud model. - slug: apidash - category: tools - stack: flutter - stars: 2891 - license: Apache-2.0 - repo: https://github.com/foss42/apidash - url: https://openappscout.com/apps/apidash - lastCommit: 2026-09-01 - added: 2026-08-11 #### Detail # API Dash API Dash is a cross-platform API client that lives in a single Flutter codebase and ships to iOS, macOS, Windows, and Linux. It targets the HTTP-API work that Postman and Insomnia have owned for a decade, but distributes the app and its codegen as Apache-2.0. ## Why it matters - **One Flutter app, four platforms.** The mobile UX and the desktop UX share the same Dart widgets. The release artefacts in the repository cover `.deb`, `.rpm`, Windows installers, and a macOS `.dmg`, and the iOS app is shipped as a separate line in the changelog (`v0.4.0 — iOS Release`). - **Codegen breadth that rivals paid clients.** The `lib/codegen/` directory holds distinct template subdirectories per language family (`c/`, `csharp/`, `dart/`, `go/`, `java/`, `js/`, `julia/`, `kotlin/`, `php/`, `python/`, `ruby/`, `rust/`, `swift/`, `others/`). Concrete outputs include `curl`, `HAR`, Python (`requests`, `http.client`), Rust (`hyper`, `reqwest`, `ureq`, `Actix Client`), Go (`net/http`), JavaScript (`fetch`, `axios`, node.js variants), Swift (`URLSession`, `Alamofire`), and many more — all wired through a single `Codegen.getCode(...)` dispatcher in `lib/codegen/codegen.dart`. - **Imports the formats developers already have.** `packages/curl_parser`, `packages/postman`, `packages/insomnia_collection`, `packages/har`, and `openapi_spec` are each their own Melos workspace package, and `apidash_core`'s `import_export` barrel exposes one entry point that fans out to `curl_io`, `postman_io`, `insomnia_io`, and `har_io`. HAR is supported in both directions (export and import). - **Optional AI assistant.** DashBot is a full sub-app living under `lib/dashbot/` with its own `prompts/`, `repository/`, `services/`, `routes/`, `pages/`, and `widgets/`. It works against a local LLM or a cloud provider, so users who don't want cloud calls aren't forced into them. ## How it works The architecture is a textbook Flutter split: `lib/screens/` and `lib/widgets/` for the UI, `lib/providers/` for state, `lib/services/` for transport, `lib/models/` for the request/response types, and `lib/utils/` for helpers. The `lib/codegen/` tree is genuinely thin — `codegen.dart` is a `switch` over the `CodegenLanguage` enum that instantiates the right per-language generator and calls its `getCode()`. Multipart-aware generators (HAR, Java HttpClient, Python `requests`, Rust `actix`/`ureq`) receive a `boundary` parameter; node.js variants reuse the browser templates with an `isNodeJs: true` flag. The request model is shared via the `apidash_core` package, which is where the import-export contract lives. Each importer is its own package so the parser can be tested in isolation and reused outside the app. OpenAPI support piggybacks on the `openapi_spec` package's `OpenApi`, `Operation`, and `ParameterHeader` types. Response preview supports JSON, XML, YAML, HTML, SQL, plus image, PDF, and audio bodies, and SVG was added in v0.4.0. ## Caveats - **Still pre-1.0.** v0.5.0 is tagged WIP in the changelog. The feature matrix is honest about it: WebSocket, MQTT, and gRPC are listed as "issue tracked" alongside the working HTTP, GraphQL, SSE/Streaming, and AI surfaces. - **GSoC codebase velocity.** The repository is actively participating in GSoC 2026 with a published ideas list. Expect API churn and rough edges around the newer surfaces (workspace persistence, environment variables, GraphQL editor) that landed in v0.5.0. - **DashBot is opt-in plumbing.** The assistant is integrated, but wiring it to a working local model still requires bringing your own OpenAI-compatible endpoint or local runtime. ## Deployment notes Pre-built installers are the recommended path and live on the releases page: ```bash # Linux (.deb) sudo dpkg -i apidash-linux-x86_64.deb # macOS / Windows # Download the .dmg or .exe from # https://github.com/foss42/apidash/releases ``` To run from source: ```bash git clone https://github.com/foss42/apidash.git cd apidash flutter pub get melos bootstrap # wires the packages/* workspace flutter run -d linux # or -d macos / -d windows / -d ios ``` Prerequisites: Flutter 3.x with Dart 3, GNU Make / `gcc` on Linux for the desktop build, and Xcode for the macOS and iOS targets. **Integration tip:** if you curate an Open Apps record tagged `api-client` or `developer-tools`, link API Dash alongside the Postman and Insomnia entries rather than as a replacement — its real niche is the codegen breadth and the Apache-2.0 / Flutter portability story, not workspace sync. ### app-finance Fingrom is a Flutter-built, ad-free, multi-currency personal finance app that ships to iOS, Android, macOS, Windows, Linux, and the Web from a single Dart codebase, with P2P device sync and end-to-end encryption. - slug: app-finance - category: finance - stack: flutter - stars: 134 - license: NOASSERTION - repo: https://github.com/lyskouski/app-finance - url: https://openappscout.com/apps/app-finance - lastCommit: 2026-09-02 - added: 2026-08-11 #### Detail # Fingrom (app-finance) Fingrom is an open-source, ad-free personal finance manager built with Flutter from a single Dart codebase and shipped to iOS, Android, macOS, Windows, Linux, and the Web. Its aim is to be "intuitive, efficient, and inclusive" — a privacy-respecting alternative to commercial money trackers, distributed under CC BY-NC-ND 4.0. ## Why it matters - **True cross-platform.** One `lib/` directory, eight platform folders (`android`, `ios`, `macos`, `linux`, `linux-flatpak`, `linux-appimage`, `windows`, `web`). The same widgets, charts, and transaction logic run on a phone, a desktop, or a browser tab. - **Multi-currency and crypto from the ground up.** Accounts can hold fiat and cryptocurrency side by side, with frozen balances keyed by update date so historical imports don't corrupt running totals. - **Forecast-grade analytics.** Fingrom ships a Monte Carlo budget simulator, OHLC candlestick charts per account, an Income Health Radar, YTD expense bars, and a category bar-race visualization that turns the year into a one-glance story. - **P2P sync without a cloud account.** Devices discover each other with `peerdart` / WebRTC and reconcile directly, with WebDAV and file-based recovery as fallbacks. There is no central server required. ## How it works The app follows a conventional Flutter layered structure: private `_classes`, `_configs`, `_ext`, and `_mixins` modules form the core, while `pages/`, `components/`, `design/`, `charts/`, and `l10n/` make up the presentation layer. State is driven by `provider` and `solidart`; persistent storage uses `shared_preferences` and `path_provider`; data import/export runs through `csv` and `excel`. Transactions are entered with category prediction, can be split across multiple budget categories, and support recurring rules with an Android home-screen widget for "what's due today". Budget categories honor monthly limits expressed either as absolute amounts or as a fraction of income (0.0–1.0), aggregated on weekly, monthly, or yearly timelines with configurable start-of-week and start-of-month days. Security wraps the whole thing: data is encrypted at rest, gated by biometric auth (`local_auth`) plus optional TOTP (`simple_totp_auth`) and recovery codes. Import paths are open — `CSV`, `QIF`, and `OFX` in; `XLSX` out — so users are not locked in. ## Caveats - **Non-commercial license.** CC BY-NC-ND 4.0 forbids commercial use and derivative works; improvements must flow back upstream. - **License metadata is `noassertion`.** The repo does not declare a single OSI-recognized license, so downstream re-use needs careful review of every third-party asset. - **Wide release surface.** Builds target eight platforms and at least four mobile stores plus Linux Snap/Flathub/AppImage, which means the test matrix is large and release cadence is uneven. ## Deployment notes ```bash git clone https://github.com/lyskouski/app-finance.git cd app-finance flutter pub get flutter run -d chrome # or any other target device ``` **Minimum:** any device that runs a recent Flutter SDK (>=3.0.5, <4.0.0). No backend required for single-device use; WebDAV or a second peer is needed only for sync and recovery. **Integration tip:** if you curate an Astro/Grove directory, Fingrom is the canonical "self-hosted personal finance" example for any app tagged `finance-app`, `budget-tracker`, or `money-manager` — its single-codebase-to-eight-platforms story is also a strong reference for cross-platform Flutter showcases. ### AppFlowy Bring projects, wikis, and teams together with AI. AppFlowy is the AI collaborative workspace where you achieve more without losing control of your data. The leading open source Notion alternative. - slug: appflowy - category: productivity - stack: flutter - stars: 76236 - license: AGPL-3.0 - repo: https://github.com/AppFlowy-IO/AppFlowy - url: https://openappscout.com/apps/appflowy - lastCommit: 2026-09-01 - added: 2026-07-06 #### Detail # AppFlowy AppFlowy is a self-hostable, open-source productivity workspace that pairs a Notion-style block editor with database views (Grid, Board, Calendar), real-time multi-user collaboration, and an optional AI assistant. The data plane is Rust with a Yrs CRDT; the UI is a single Flutter codebase covering macOS, Windows, Linux, iOS, and Android. The product is genuinely local-first, but the open-core split means that a self-hosted multi-seat deployment requires a paid commercial license. ![AppFlowy workspace — block editor with a Grid database view](/images/appflowy/workspace.png) *AppFlowy's Notion-shaped workspace: a block editor on the left, a Grid database view on the right, both running on a local-first Rust+Flutter stack.* ## What AppFlowy is, and what it isn't trying to be AppFlowy's pitch is straightforward: build a Notion-shaped workspace that runs on your hardware, with your data in your database, in an open-source repository you can fork. The interesting engineering decision is that the maintainers did not try to do this in JavaScript. The data layer is **Rust** — split across `flowy-core`, `flowy-document`, `flowy-database2`, `flowy-folder`, `flowy-ai`, `flowy-search`, `flowy-storage` — and the UI is a single **Flutter** codebase that produces desktop, mobile, and web builds from one Dart tree. The FFI bridge between them is Protobuf-serialized, type-generated, and exposes the data layer as a typed API to the UI. This is the right architecture for a cross-platform productivity app with real-time collaboration. Rust gives you SQLite, CRDT, file I/O, and AI inference without paying JavaScript's memory tax; Flutter gives you a single UI codebase that produces a real native rendering, not a WebView. The editor is a first-party `appflowy_editor` Flutter package that replaced `flutter_quill` in 2022 — owning your editor is the right call when you need Notion-style block behavior with collaborative cursors, slash menus, and database views. ## Local-first, but with strings attached The "local-first" claim is real. Writes go to local SQLite first, then sync to the server. The Yrs CRDT (the Rust port of Yjs) handles conflict resolution. But the open-source product is not the same product as the hosted one. The community-edition `AppFlowy-Cloud` is AGPL-3.0 and freely self-hostable, **but** the documented self-host tier is **one user seat plus three guest editors**. Larger seats require a per-server commercial license (`SELF_HOST_LICENSE_AGREEMENT.md`) at $11.88/month/server with annual renewal. The desktop and mobile clients remain AGPL-3.0. This is a real open-core split. The framework maintainers are explicit about it: the AppFlowy-Cloud README states the project is "adopting an open-core model" while "AppFlowy Web and AppFlowy Flutter will remain open source." The self-host pricing page lists tiers per server, not per seat, which is itself a useful operational simplification if you want one internal-only deployment for a small team. ## The "end-to-end encryption" claim is marketing The marketing site says "end-to-end encryption." The self-hosting security documentation describes TLS in transit and server-side encryption (encrypted volumes for PostgreSQL, MinIO server-side encryption with KMS, optional S3 AES256). These are different claims. Server-side encryption means the cloud operator can read your data; E2EE means they cannot. The mismatch has been picked up by reviewers; a Reddit thread titled "Let's address the elephant in the room: end-to-end encryption" exists on r/AppFlowy. Treat the "E2EE" claim as marketing-grade until proven otherwise, and do not put regulated data on an AppFlowy Cloud deployment without confirming the actual encryption boundary. ## The sync and import story is the weak link The two most damaging criticisms in the AppFlowy community are about sync reliability and Notion import. The OpenTechHub November 2025 review called sync "the true killer issue." An iOS App Store review from July 2026 says: "I lost data multiple times both on mobile and desktop app." A closed issue from October 2025, **#8112** ("Full data loss in case of migration problems due to data storage in RocksDB"), was a real incident tied to the local store on a migration path before the project reverted to SQLite. The Notion import story is structurally lossy for a reason that is not AppFlowy's fault. Notion's official export is Markdown + CSV; **Notion does not export Notion databases through the export endpoint**. Whatever AppFlowy imports from a Notion export cannot include the database rows, properties, or relations that made the original workspace useful. Multiple open issues (#8937, #8862, #8789, #8744) complain about "Notion import is broken." The right mental model is "import pages, not workspaces." ## Where AppFlowy is the best choice - A single user or small team that wants Notion-shaped features with local-first writes, can stomach the AGPL-3.0 + commercial self-host split, and is willing to back up the SQLite file. - A developer who wants to fork a Notion-shaped productivity app and is willing to maintain a CRDT-based Rust core. ## Where AppFlowy is not the right choice - A team of 20+ that wants free self-hosting. The commercial self-host license is per-server and not cheap at $11.88/month. - A user with regulated data expecting E2EE. The marketing says yes; the docs describe server-side encryption. - Anyone whose primary use case is "import my Notion workspace." The import is lossy by design. - A mobile-first team. Mobile sync has the most data-loss complaints in the community. ## Deployment notes The reference install is the `AppFlowy-Cloud` Docker Compose stack: `appflowy_cloud` (the Rust server), `gotrue` (auth), `postgres`, `minio` (or any S3), `redis`, and a reverse proxy. The maintainers publish a self-hosting security guide with an automated backup script that covers PostgreSQL dump, MinIO storage, and `.env` (daily cron @ 02:00, 30-day retention, optional off-site via AWS S3 sync, rsync, or Restic with 7 daily / 4 weekly retention). ## Developer lessons worth borrowing - **Own your editor.** The `appflowy_editor` rewrite from `flutter_quill` was the difference between "Markdown app" and "Notion competitor." The editor is the product, not the chrome around it. - **Type your FFI boundary.** Protobuf codegen at the FFI seam (Dart and Rust both consume the same types) is a friction-killer for cross-language refactors. Many "Rust + Flutter" projects get this wrong; AppFlowy gets it right. - **Local-first needs a real backup story.** The official self-host backup script is the right answer (PostgreSQL dump + MinIO + `.env`). If you self-host, wire that script to your off-site target on day one. - **Open-core is a deliberate trade.** A per-server commercial self-host license at $11.88/month funds the Rust core development. The AGPL-3.0 client remains free. ## How AppFlowy compares The "Notion-shaped workspace" market is the most crowded open-source comparison category, and the honest answer is that the right tool depends on which Notion feature you actually need. | Project | License | Storage model | E2EE | Block editor | Database views | Sync target | Best for | |---|---|---|---|---|---|---|---| | **AppFlowy** | AGPL-3.0 (client) + commercial self-host license | Local-first SQLite, cloud sync via AppFlowy-Cloud | No (server-side encryption, not E2EE) | First-party block editor (formerly `flutter_quill`) | Grid, Board, Calendar | Self-hosted (per-server commercial fee) or AppFlowy Cloud | A small team that wants a real Notion alternative and is willing to back up the SQLite file | | **Notion** | Closed-source SaaS | Hosted only | No | Block editor | Grid, Board, Calendar, Gallery, Timeline, List | Notion Cloud | A team that wants zero setup and the broadest feature set, and can accept the price | | **Obsidian** | Source-available (free for personal use) | Local Markdown files | N/A (data is local) | Markdown-based | Dataview plugin (community) | Local file system + optional paid Sync | A single user who wants durable Markdown files and is willing to invest in plugins | | **Anytype** | Source-available (Any Source Available License 1.0) | Local-first (Anysync) | Yes (peer-to-peer) | Block editor (some Notion-like features) | Grid, Board, Calendar | Peer-to-peer / self-hosted Anytype Hub | A user who wants E2EE + local-first + block editor, and accepts alpha-quality collaboration | | **Logseq** | AGPL-3.0 | Local Markdown / Org files | N/A (local) | Outliner + block editor | Queries, advanced | Local file system + optional paid Sync | A knowledge worker who thinks in outliner and queries rather than databases | | **AFFiNE** | MIT (client) | Local-first (CRDT) | No | Block editor + whiteboard | Grid, Board, List | Local + paid AFFiNE Cloud | A user who wants both Notion's database views and Miro's whiteboard in one tool | | **Outline** | BSL 1.1 (source-available) | Hosted only | Partial | Block editor | Limited | Outline Cloud / self-hosted | A team that needs a wiki with team permissions, not a personal workspace | **Pick AppFlowy** if you want Notion-shaped features with local-first writes, can stomach the AGPL-3.0 client + commercial self-host license, and do not need a self-hosted free-tier for > 4 users. **Pick Notion** if the team is small enough to pay for the real product and you need the broadest feature set. You are paying for the polish, not the data ownership. **Pick Obsidian** if you already think in plain Markdown and want the most durable file format. You give up the database views. **Pick Anytype** if E2EE is the headline feature. The trade is a younger collaboration story and the Any Source Available License. **Pick Logseq** if your work is "thinking on paper" rather than project management. The block-level reference graph is the strongest in the category. **Pick AFFiNE** if you need a whiteboard and a database in the same canvas. The single-author project is past v1 but the collaboration story is still maturing. **Pick Outline** if your real need is a team wiki with permissions, not a personal workspace. ## Verified sources - AppFlowy repository: - Self-hosting tier and pricing — `SELF_HOST_LICENSE_AGREEMENT.md` in the AppFlowy-Cloud repo. - E2EE Reddit thread — r/AppFlowy, "Let's address the elephant in the room: end-to-end encryption". The marketing site claim vs the self-hosting security documentation mismatch is in that thread. - Sync and import issues — AppFlowy GitHub issues #8112, #8937, #8862, #8789, #8744 (representative; not exhaustive). - Notion import scope — Notion's official export documentation; confirms that Notion does not export Notion databases through the export endpoint. - Comparison to Obsidian / Logseq / Anytype — these are positioning summaries, not affiliated reviews. ### Artsy Artsy Eigen is the official iOS and Android client for artsy.net, built as a React Native app with native Swift and Kotlin modules for browsing artworks, following artists and galleries, and participating in live timed auctions. - slug: eigen - category: shopping - stack: react-native - stars: 3773 - license: MIT - repo: https://github.com/artsy/eigen - url: https://openappscout.com/apps/eigen - lastCommit: 2026-09-03 - added: 2026-06-07 #### Detail # Eigen Eigen is the iOS and Android client for [Artsy](https://www.artsy.net), the largest online art marketplace. Artsy ships it to the App Store and Google Play as the public face of its catalogue of artists, artworks, galleries, and live timed auctions. ## Why it matters - **A major cultural institution, not a side project.** Eigen is the official consumer app for artsy.net — a 3.8k-star, MIT-licensed repo with ~166 contributors. Collectors open it to follow galleries or bid at Sotheby's online sales. - **Live auction bidding is a first-class flow.** Eigen has a dedicated `src/app/Components/Bidding` tree (`Screens`, `Validators`, `Context`, `Helpers`) for the timed-bidding UX: lot countdowns, bid validation, and bid-confirmation screens. A missed bid is a lost sale, so the app tracks server time and treats the auction lifecycle as a state machine. - **Open-by-default engineering.** Eigen runs CircleCI with Fastlane and exposes the same Relay pipeline that powers artsy.net. ## How it works The app is **React Native + TypeScript** in `src/app/`, organised by `Components/`, `Scenes/`, `Navigation/`, `store/`, and `system/`. Native shells are thin: `ios/Artsy` holds an `AppDelegate.swift`; the Android side under `android/app/src/main/java/net/artsy/app` contains `MainActivity.kt` and `MainApplication.kt`. CocoaPods ties iOS together via `ios/Podfile` (iOS 16.6, Hermes, plus Artsy pods like `ORStackView`). All data flows through **Relay + Artsy's Metaphysics GraphQL gateway**. `src/app/system/relay/defaultEnvironment.ts` composes a LIFO middleware pipeline — `cacheMiddleware` (500-request, 15-min cache), `persistenceMiddleware`, `metaphysicsURLMiddleware` (URL from `unsafe__getEnvironment().metaphysicsCDNURL`), `rateLimitMiddleware` (100 reqs / 1 s, sampled Sentry reporting), and `errorMiddleware`. The schema is a 44k-line `data/schema.graphql`, regenerated by the metaphysics codegen bot, and consumed via Relay artifacts in `src/__generated__/`. The **artwork imagery pipeline** layers progressive components (`FullScreenLoadingImage`, `ImageWithFallback`, `MasonryStatic`) on top of `SDWebImage`, with signed Cloudfront-style URLs returned by Metaphysics so a low-res preview swaps in before the high-res tile. ## Caveats - **Art-only, not general e-commerce.** Eigen is a curated art-discovery surface, not a Shopify-style storefront. The schema is wired for artists, artworks, editions, and sales. - **Rate-limited Metaphysics.** The Relay layer caps requests at 100/s by default and throws on overflow. Forks must respect this throttle or risk tripping the gateway. - **Artsy-specific OAuth.** Bidding, identity verification, and order history need an Artsy OAuth client ID plus a `metaphysicsCDNURL` / `predictionURL` pair pointing at a staging cluster. Real builds need `keys.json` from `keys.example.json`. ## Deployment notes The repo ships a full **Fastlane** setup (`fastlane/`) for TestFlight and Play Store submission, plus CircleCI workflows that build and snapshot-test. Native targets assume iOS 16.6 and a recent Android SDK / NDK; CocoaPods pulls the full pod graph on first iOS build. The codegen pipeline that produces `src/__generated__/` requires the checked-in `data/schema.graphql`; point at a different Metaphysics host and you must regenerate before building. ```bash git clone https://github.com/artsy/eigen.git cd eigen yarn install cp keys.example.json keys.json # fill in Artsy OAuth + Sentry keys yarn ios # or: yarn android ``` **Integration tip:** if you're building any art, auction, or gallery app, Eigen is the cleanest open reference for stitching **Relay + persisted queries + a throttled GraphQL gateway + live auction UX** together. Mirror its `defaultEnvironment.ts` middleware stack and `Bidding/Screens` shape before designing your own. ### ATV-Bilibili-demo ATV-Bilibili-demo is an open-source Bilibili client demo built for Apple TV and its tvOS focus-driven interface. - slug: atv-bilibili-demo - category: entertainment - stack: ios - stars: 3131 - license: GPL-2.0 - repo: https://github.com/yichengchen/ATV-Bilibili-demo - url: https://openappscout.com/apps/atv-bilibili-demo - lastCommit: 2026-09-02 - added: 2026-06-13 #### Detail # ATV-Bilibili-demo ## Why it matters ATV-Bilibili-demo explores what a third-party Bilibili client can feel like on Apple TV: large, glanceable rows of video artwork, remote-first selection, and playback designed for a ten-foot interface. It is especially useful as a study of tvOS focus-engine conventions rather than as a production-ready replacement for an official client. The project is sometimes described as an early SwiftUI tvOS example, but its current source is UIKit-based. That evolution is instructive in its own right: custom controls such as `BLButton` explicitly become focusable, then add scale, shadow, blur, and horizontal motion effects when focus moves onto them. Feed cells start and stop marquee titles with focus changes, making remote navigation legible without relying on touch interactions. ## How it works A `UITabBarController` subclass builds configurable tabs through `TabBarPageVCFactory`. Available destinations include live streams, recommendations, TV recommendations, popular and ranking feeds, following, favorites, search, history, watch-later, and personal pages. Most screens are collection-view-driven UIKit controllers; SnapKit supplies layout constraints, while TVUIKit and the native tvOS focus engine support the living-room interaction model. Networking is split between `ApiRequest` and `WebRequest`, both using Alamofire. `ApiRequest` signs app-style requests with an app key, timestamp, and MD5 signature for QR login, feeds, and season data. `WebRequest` handles cookie and CSRF authentication, WBI-signed JSON REST calls, protobuf danmaku endpoints, playback URLs, engagement actions, and history reporting. It is mostly private web/API integration rather than conventional HTML scraping, although the daily-coin query parses the legacy `exp.php` page. AVPlayer-based playback, live danmaku, subtitles, HDR options, and UPnP/DLNA support extend the demo beyond simple browsing. ## Caveats This is explicitly a demo and study project, not an official Bilibili product. Its app-style and web endpoints are undocumented implementation details, so signatures, cookies, response models, or playback rules can change without notice. Account credentials and third-party unsigned builds deserve particular care. The README says the app has never been published through the App Store or an authorized TestFlight, and warns against paid or unauthorized distributions. The repository does publish unsigned nightly IPA artifacts, so normal use requires sideloading. Development continued through July 2026, but that activity does not imply stable APIs or production support. ## Deployment notes Clone the repository, open `BilibiliLive.xcodeproj` in a current Xcode release, allow Swift Package Manager to resolve the pinned packages, and select the shared `BilibiliLive` scheme. Build for an Apple TV simulator for interface exploration, or choose a connected Apple TV for playback and network behavior that depends on real hardware. Installing on hardware requires an Apple Developer account, a development team, a unique bundle identifier, and a tvOS provisioning profile. Because the project is not an App Store release, expect to re-sign your own build or the unsigned nightly IPA and to manage certificate expiration yourself. Review signing settings and any endpoint-related constants before entering a Bilibili account. **Integration tip:** treat the API layer as replaceable infrastructure and keep focus behavior isolated in reusable controls, so Bilibili endpoint changes do not force a rewrite of the tvOS navigation experience. ### AudioKit AudioKit is a Swift audio synthesis, processing, and analysis framework for iOS, macOS, tvOS, and visionOS that wraps AVFoundation and a C-backed DSP engine. - slug: audiokit - category: media - stack: ios - stars: 11457 - license: MIT - repo: https://github.com/AudioKit/AudioKit - url: https://openappscout.com/apps/audiokit - lastCommit: 2026-07-26 - added: 2026-06-13 #### Detail # AudioKit AudioKit is an open-source Swift audio framework for Apple platforms that combines a high-level node graph on top of AVFoundation with a C-backed DSP engine. It is the default choice for anyone shipping synths, samplers, guitar-amp sims, or analysis tools to the App Store without writing a custom audio pipeline. ## Why it matters - **Two layers, one package.** The Swift module wraps `AVAudioEngine` and `AVAudioNode` with a node/connection graph you can reason about in Swift, while `AudioKitEX` / `CAudioKitEX` add the real-time DSP kernels in Objective-C++ so audio work happens off the main thread and away from the garbage-collected heap. You write nodes in Swift; the per-sample loops are C++. - **Compared to lower-level alternatives.** `STK` (Synthesis ToolKit) and Maximilian are great C++ DSP libraries, but you bring your own host, host-side node graph, MIDI plumbing, and AU wrapper. JUCE is the closest peer: cross-platform, C++, with its own IDE and licensing model. AudioKit's bet is "Swift on Apple, with the C++ tucked underneath" — you keep Xcode, SwiftUI, and the App Store, but the audio thread is still native code. - **What ships with it.** A built-in `Mixer` and `MatrixMixer`, oscillators (`MorphingOscillator`, `FMOscillator`, `PhaseDistortionOscillator`, `DynamicOscillator` from the Soundpipe extension), filters (`MoogLadderFilter`, `ResonantFilter`, plus standard `BandPass`/`HighPass`/`LowPass`), `CostelloReverb`, `Delay`, `Distortion`, `DynamicsProcessor`, a `MIDISampler` and `MIDIPlayer`, an `AppleSequencer` that plays Standard MIDI Files, and analysis taps for amplitude and FFT. - **Apps you can build.** Standalone synths, drum machines, audio effects AUv3 plug-ins, pitch trackers, tuners, MIDI utilities, generative-music playgrounds, and music-education apps. ## How it works The repo is organized as a monorepo with three layers. The top-level `Sources/AudioKit` package is the Swift-only shell: it defines the `Node` protocol (every effect, generator, mixer, and player conforms to it), an `AudioEngine` that wraps `AVAudioEngine`, MIDI input handling in `Sources/AudioKit/MIDI`, the `AppleSequencer` in `Sources/AudioKit/Sequencing`, file I/O helpers, and analysis taps (`AmplitudeTap`, `FFTTap`, `RawDataTap`, `NodeRecorder`) under `Sources/AudioKit/Taps`. A small `@Parameter` property wrapper declares automatable parameters; the engine takes care of routing control changes through the AU parameter tree. The DSP engine lives in the companion `AudioKitEX` package, in the `Sources/CAudioKitEX` Objective-C++ target. A typical node is tiny: `GainDSP.mm` is roughly twenty lines — a struct derived from `DSPBase`, a `ParameterRamper` for click-free gain changes, and a `process(FrameRange)` loop that multiplies each input sample by the ramped gain. More interesting kernels (oscillators, the Moog ladder filter, the Costello reverb, the FDN reverb) live in companion packages: `SoundpipeAudioKit` brings in the bulk of the classic oscillator and filter catalogue, `DunneAudioKit` adds the sampler and modulation effects, and `STKAudioKit` ports the Synthesis ToolKit physical models (clarinet, flute, bowed string, etc.). Each companion wraps its C/C++ kernel as an `AudioUnit` (`AK_REGISTER_DSP`) that AudioKit's `AudioEngine` can attach like any other node. MIDI is first-class. `MIDIInstrument` in the Swift module is an `open class` that conforms to `Node`, `MIDIListener`, and `NamedNode`; it owns an `AVAudioNode`, calls `MIDIDestinationCreateWithBlock` to subscribe to incoming packets, and translates them into note-on / note-off calls on its subclasses. `MIDISampler` and `MIDIPlayer` build on top of it, and the `AppleSequencer` schedules MIDI files against the same clock. ## Caveats - **API surface is huge and moves between majors.** AudioKit 5 was a near-total rewrite from AudioKit 4; the Cookbook repo explicitly notes that "most of the examples that were inside of AudioKit are now in this single iOS / macOS Catalyst application" and "will continue to evolve as AudioKit does." Code from an older version rarely ports without manual changes. - **Audio-thread safety rules apply.** Any Swift work that touches DSP parameters must go through `ParameterRamper` or the AU parameter address system; allocating, locking, or logging on the audio thread is a fast path to glitches. The framework enforces most of this, but custom DSP subclasses inherit the responsibility. - **Test on real hardware.** The Simulator's audio path is not representative — sample-accurate scheduling, MIDI latency, and AUv3 host behavior only show up on a physical iPhone, iPad, or Mac. Headless tests use `engine.startTest()` / `render()` to generate buffers offline, but final tuning needs a device. ## Deployment notes Add the framework via Swift Package Manager (the README points users at the official Package Collection URL — `File > Add Package Dependencies… > Add Package Collection…` with `https://swiftpackageindex.com/AudioKit/collection.json`) so Xcode can resolve AudioKit, AudioKitEX, and any of the extension packages together. The collection catalog also exposes AudioKitUI (controls and visualization), the Cookbook recipes, and the standalone components like `Keyboard`, `Waveform`, `PianoRoll`, and `Tonic` (music theory). The legacy CocoaPods badge still appears on the README for projects that haven't migrated, and Carthage is documented in older guides, but new installs should use SPM. For an example app, clone `AudioKit/Cookbook` next to the framework: each recipe is a single Swift file with a `Conductor` (signal-flow setup), `Data` (state), and SwiftUI `View`, which is the fastest way to see a working oscillator, sampler, or MIDI file player. **Integration tip:** if you build an iOS music or audio utility, pull in `AudioKit` plus exactly one extension package (`SoundpipeAudioKit` for oscillators and filters, `DunneAudioKit` for a sampler, `STKAudioKit` for physical models) rather than the whole collection — each adds DSP weight and build time, and most apps only need one family of nodes. ### Authier Authier is an experimental AGPL password manager monorepo with a React Native client, browser extensions, and a web vault for credentials and TOTP codes. - slug: authier - category: productivity - stack: react-native - stars: 14 - license: AGPL-3.0 - repo: https://github.com/authier-pm/authier - homepage: https://www.authier.pm/ - url: https://openappscout.com/apps/authier - lastCommit: 2026-09-02 - added: 2026-09-01 #### Detail # Authier Authier is an open-source password manager for login credentials and time-based one-time password (TOTP) secrets. Its public user-facing clients are a web vault and extensions for Chrome, Firefox, and Microsoft Edge; the Firefox extension also runs on Firefox for Android. ## What the codebase includes - A React browser extension with Manifest V2 and Manifest V3 builds, vault management, password autofill, and TOTP support. - A separate React web vault for viewing and editing credentials, TOTP records, devices, and account settings. - A React Native mobile client in the monorepo, although native mobile builds are not currently listed as supported public downloads. - An Elysia API deployed through a Cloudflare Worker adapter, plus shared TypeScript schemas and cryptographic code used across clients. - An Astro marketing and documentation site that publishes the current security model, download routes, privacy policy, and practical security caveats. ## Security model in the repository Authier derives the client encryption key from the master password and a per-account salt using PBKDF2 with SHA-512 and 600,000 iterations. Vault items are encrypted with AES-256-GCM and a fresh initialization vector before synchronization, so the API receives encrypted credential and TOTP payloads rather than those secrets in plaintext. Accounts can be configured to require approval from an existing trusted device before a new client enrolls and begins vault synchronization. TOTP synchronization can also be disabled per device. These controls are useful code to inspect, but they do not remove the need to protect every unlocked client and keep independent recovery options. ## Why it is useful to study The repository shows how one TypeScript monorepo coordinates browser-extension, web, React Native, API, schema-generation, and encryption concerns for a security-sensitive product. It also exposes the practical edges that simpler examples often omit: multi-step-login autofill, device enrollment, encrypted synchronization, TOTP import/export, and separate Manifest V2 and V3 builds. The [security architecture](https://www.authier.pm/security) documents the intended cryptographic flow, while the [official download page](https://www.authier.pm/download) identifies the currently supported clients. ## Caveats Authier is a young, experimental password manager and has not published an independent third-party security audit. Public source makes the implementation inspectable, but it is not a substitute for a professional audit, a long operating history, or broad real-world review. For important secrets, an established audited password manager is the more conservative default. The native mobile clients remain source code rather than a current supported store release, and the project does not currently document self-hosting as a supported deployment route. Evaluate the repository and its limitations before using it beyond a low-risk test vault. ### BeeCount BeeCount is a Flutter-based local-first bookkeeping app for iOS, Android, and Web that offers five interchangeable sync backends (the self-hosted BeeCount Cloud, iCloud, Supabase, WebDAV, and any S3-compatible store), AI-assisted capture via a dual on-device/cloud OCR pipeline, multi-ledger accounting with per-ledger currencies, and offline-first storage on Drift over SQLite. - slug: beecount - category: finance - stack: flutter - stars: 2254 - license: NOASSERTION - repo: https://github.com/TNT-Likely/BeeCount - url: https://openappscout.com/apps/beecount - lastCommit: 2026-08-31 - added: 2026-06-07 #### Detail # BeeCount BeeCount (蜜蜂记账) is a local-first bookkeeping app for iOS, Android, and Web written in Flutter. Entries live in a Drift/SQLite database on the device, and the user chooses between five sync backends without changing a line of code: the self-hosted BeeCount Cloud, iCloud Drive, Supabase, WebDAV, and any S3-compatible store (Cloudflare R2, AWS S3, MinIO). The same binary that talks to iCloud on your iPhone can be repointed at a Dockerised BeeCount Cloud on a NAS and keep syncing. ## Why it matters - **Five interchangeable sync layers.** Sync is implemented as separate packages under `packages/flutter_cloud_sync_*` (`supabase`, `webdav`, `icloud`, `s3`) plus `flutter_cloud_sync` for the self-hosted BeeCount Cloud. A user can move from a zero-config iCloud flow to a fully self-hosted deployment without rebuilding the binary or losing history. - **AI-assisted capture.** A dual-engine OCR pipeline — on-device TFLite plus Zhipu GLM-4 in the cloud — recognises Alipay, WeChat, and UnionPay screenshots. Android uses an accessibility service to capture them automatically; iOS uses a Shortcuts back-tap. Voice entry and a chat assistant (`flutter_ai_kit` + `flutter_ai_kit_zhipu`) round out the capture surface. - **Multi-ledger as a first-class concept.** Each ledger has its own currency, its own accounts, and its own budget. BeeCount Cloud adds shared ledgers with Owner/Editor roles and AES-256-encrypted backups that fan out to R2/S3/WebDAV/B2 in parallel. - **MCP support.** Pair the app with BeeCount Cloud and any Model Context Protocol client can read or write the ledger, turning the bookkeeping data into a tool for AI assistants rather than a silo. ## How it works The app is a single Flutter project that pulls in `flutter_ai_kit`, `flutter_ai_kit_zhipu`, and `flutter_ai_kit_openai` for the LLM surface, and the four `flutter_cloud_sync_*` packages for the sync surface. Local persistence is `drift` (^2.20.2) over `sqlite3_flutter_libs`, with state exposed as `flutter_riverpod` (^2.5.1) providers. `fl_chart` (^0.68.0) powers the analytics screens, `table_calendar` (^3.1.0) drives the date picker, and `home_widget` (^0.9.2) publishes the 6 content-type × 12 variant widget matrix to the launcher. CSV import and YAML config export handle migrations from Alipay/WeChat bills, `fl_chart` powers the trend views, and `archive` plus `crypto` handle the encrypted-backup pipeline. Build flavours separate dev from production (`--flavor dev` / `--flavor prod --release`), and `build_runner` codegen is run once per pull to refresh the Drift schema and Riverpod adapters. The `packages/` folder is a small monorepo inside the repo — the four sync backends plus three AI kits are local-path dependencies declared in `pubspec.yaml`. ## Caveats - **Business Source License.** Free for personal use, learning, research, and open-source contributions. Commercial deployments require a paid licence — see `COMMERCIAL_LICENSE.md` and contact `sunxiaoyes@outlook.com`. - **AI features need a key.** OCR cloud mode and the chat assistant require a Zhipu API key; the on-device TFLite OCR works offline but with a smaller model and lower accuracy on edge-case receipts. - **Self-hosted Cloud adds ops surface.** The Dockerised BeeCount Cloud (FastAPI + React + WebSocket) needs PostgreSQL, Redis, and a reverse proxy; small deployments may be happier on iCloud or Supabase. - **No HarmonyOS build.** A community port exists but is marked discontinued; the supported matrix is iOS, Android, and Web. ## Deployment notes Pick a sync backend during first-run onboarding. For the self-hosted option, deploy BeeCount Cloud (FastAPI + React + WebSocket) via the provided `docker-compose.yml`, then point the app at its URL. The iOS build expects Xcode 15+ and a minimum iOS 15.5; Android targets API 21+. The repo publishes signed APKs (universal, armeabi-v7a, x86_64), an AAB, and a TestFlight slot at every release — see the latest tag under `/releases` for downloads. ```bash git clone https://github.com/TNT-Likely/BeeCount.git cd BeeCount flutter pub get dart run build_runner build --delete-conflicting-outputs flutter run --flavor dev ``` ### Berty Berty is a peer-to-peer messenger that runs entirely over the Wesh protocol on top of libp2p, so peers connect directly via mDNS, Bluetooth Low Energy, or Tor with no central server in the loop. - slug: berty - category: communication - stack: react-native - stars: 9290 - license: NOASSERTION - repo: https://github.com/berty/berty - url: https://openappscout.com/apps/berty - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # Berty Berty is a peer-to-peer messenger that runs entirely over the **Wesh protocol**, an SDK built directly on **libp2p**. There is no central server, no account creation, and no phone number requirement — peers find each other and exchange encrypted messages using whatever transports are available: mDNS on the LAN, Bluetooth Low Energy nearby, multipeer connectivity on iOS, Android Nearby, or Tor for remote anonymous links. ## Why it matters - **Serverless by design.** Most "private messengers" still depend on a hosted relay you have to trust. Berty has no such dependency: it treats the network as adversarial and routes around it. In an internet shutdown, a protest, or an area with no cellular coverage, two Berty users on the same Wi-Fi or within BLE range can still talk. - **Different trust model from Signal / Matrix.** Signal centralizes metadata-minimized message routing through trusted servers; Matrix federates between independently operated homeservers. Briar is the closest philosophical neighbor, but is Tor-only and Java-only. Berty is the only mature option that pairs a Go-based protocol SDK with first-class native iOS and Android apps and multiple local transports. - **Group messaging without a homeserver.** Groups are CRDT-style collections replicated over OrbitDB on top of IPFS. Adding a member to a group is a key exchange, not an invitation through someone else's server. ## How it works The **Wesh protocol** lives in `go/pkg/bertyprotocol`. It manages identities, accounts, multi-device membership, group membership, encrypted message routing, and an application lifecycle so that downstream apps can focus on UI. Group messages are stored as append-only CRDT log entries that are gossiped between members over whatever libp2p transports are reachable. The transport stack is configurable per launch: `-p2p.mdns` (default on) for LAN discovery, `-p2p.ble` for nearby BLE, `-p2p.multipeer-connectivity` for Apple Continuity-style discovery, `-p2p.nearby` for Android Nearby, and Tor via the `-anonymity` preset which forces `-tor.mode=required` and disables the local transports. Reachability through NAT is handled by autorelay, static relays, or a dedicated `rdvp` (rendez-vous point) server that you can self-host — note that the rdvp is a discovery hint only and never sees message contents. The Go core ships as two CLI binaries, `berty daemon` (a full Wesh node) and `berty mini` (a CLI messenger), plus a gomobile-generated framework in `go/framework/bertybridge` that the mobile clients import. The current mobile app is an Expo/React Native build under `berty-bridge-expo/` that consumes the native module via gomobile. ## Caveats - **Pure-P2P overhead.** Each device continuously announces and scans on multiple transports. Battery drain is noticeably worse than for a centralized messenger, especially on Android where BLE scanning is still relatively costly. - **Slow message delivery when offline.** If both peers are unreachable at send time, the message stays in the local outbox until at least one of them gets a path through. There is no store-and-forward server in the loop. - **Project cadence.** The Go protocol layer and Expo bridge are still receiving commits (releases continue to ship — the latest is v2.471.14 from July 2026), but the Android and iOS client UIs have moved to maintenance mode. Treat it as a working SDK and reference client, not a polished daily-driver messenger. ## Deployment notes The fastest path is the **Google Play** build for Android or the **App Store** build for iOS. F-Droid has historically carried the APK once F-Droid reviewers accept a build; otherwise you can sideload the latest signed APK from the GitHub release of `v2.471.14`. After install, two devices pair by either being on the same LAN, exchanging a deep link / contact invite, or scanning a multi-string Berty share code generated by the contact card UI. For developers, the SDK entrypoint is `berty.tech/berty/v2/go/pkg/bertyprotocol`. A Go service embeds the protocol by calling `protocol.New()` and wiring the resulting service into a libp2p host; the same code path powers `berty daemon`, so anything the CLI can do, your embed can do. **Integration tip:** if you run a directory of privacy / censorship- circumvention apps, Berty is the canonical reference for any project tagged `p2p`, `libp2p`, or `offline-first` — it is one of the very few production stacks where the mobile app, the protocol SDK, and the relay daemon all ship from one monorepo. ### BikeShare SwiftUI, Jetpack Compose, Compose for Desktop and Compose for Web based Kotlin Multiplatform project (using CityBikes API http://api.citybik.es/v2/). Uses Room for local persistence. - slug: bikeshare - category: tools - stack: ios - stars: 828 - license: Apache-2.0 - repo: https://github.com/joreilly/BikeShare - url: https://openappscout.com/apps/bikeshare - lastCommit: 2026-09-02 - added: 2026-06-13 ### Blink Comparison Simplifies comparing photos of tamper-evident seals and patterns using your eyes - slug: blink-comparison - category: tools - stack: flutter - stars: 300 - license: GPL-3.0 - repo: https://github.com/proninyaroslav/blink-comparison - url: https://openappscout.com/apps/blink-comparison - lastCommit: 2026-06-30 - added: 2026-06-07 ### BlueWallet Bitcoin wallet for iOS & Android. Built with React Native. - slug: bluewallet - category: finance - stack: react-native - stars: 3282 - license: MIT - repo: https://github.com/BlueWallet/BlueWallet - url: https://openappscout.com/apps/bluewallet - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # BlueWallet BlueWallet is a Bitcoin wallet focused on privacy, with first-class support for on-chain transactions, Lightning Network payments, and hardware-wallet integration. ## Why it matters - **Multi-wallet model.** BlueWallet organises funds into separate wallets (Savings, Spending, Trading) so balances are not accidentally commingled. - **Lightning done right.** The Lightning wallet supports channel-open, channel-close, MPP, and zero-conf channels through the bundled LDK node. There is no custodial intermediary. - **Hardware wallet integration.** Connect a Coldcard, Ledger, or Trezor and sign transactions air-gapped; BlueWallet never holds the seed. ## How it works BlueWallet is a React Native application; the same JavaScript code ships to iOS and Android. Storage is encrypted with a user-supplied passphrase using `crypto-js` AES-256; the seed is BIP-39 encoded and never leaves the device. Lightning support uses LDK (Lightning Dev Kit) running in-process via a JSI bridge; channels are persisted to the encrypted storage layer alongside on-chain wallet metadata. The wallet talks to electrum and Esplora servers over Tor by default. ## Caveats - **Onboarding friction.** Setting up a Lightning channel requires the user to pick a node operator and fund a channel. First-run UX is improving but is not yet "press one button". - **iOS-only features.** Apple policy blocks some Lightning integrations; the iOS build ships with a subset of the Android feature set. - **License is MIT for the wallet code, with portions under various permissive upstream licenses** — read each bundled component's license before forking. ## Deployment notes ```bash # Mobile app — install from the App Store or Play Store # https://bluewallet.io # For local development: git clone https://github.com/BlueWallet/BlueWallet.git cd BlueWallet npm install npm run start ``` **Minimum:** an iPhone running iOS 14+ or an Android phone running Android 8+. Lightning functionality requires either a custodial compromise or running your own LDK-compatible node. **Integration tip:** BlueWallet is the rare mobile-first wallet that takes Lightning seriously; if you are cataloguing wallets for a Bitcoin-aware directory, prioritise it over the "Lite wallet" alternatives. ### brethap Brethap is a Flutter meditation app that pairs a session timer with configurable six-phase breathing patterns, four selectable audio tones, per-phase vibration, and optional text-to-speech cues, persisting every completed session in a local Hive store. - slug: brethap - category: tools - stack: flutter - stars: 85 - license: GPL-3.0 - repo: https://github.com/jithware/brethap - url: https://openappscout.com/apps/brethap - lastCommit: 2026-08-07 - added: 2026-08-11 #### Detail # Brethap Brethap is a meditation timer built in Flutter that layers a fully configurable six-phase breathing pattern on top of a stopwatch-style session. Every completed session is persisted locally, so the same app doubles as a practice journal surfaced through list, calendar, and stats views. The maintainer calls it a "yama" — a minimalist, distraction-free sit. ## Why it matters - **Breath pacing as a first-class primitive.** Each cycle is broken into inhale, inhale-hold, inhale-tail, exhale, exhale-hold, and exhale-tail, every phase independently adjustable in 0.1-second increments. The six-tenths-of-a-second granularity is unusual for a free app and is what makes presets like 4-7-8 or physiological sigh feel right rather than approximate. - **Multi-channel cues stay in sync.** A single `Timer.periodic` loop ticks every 100 ms and fires phase transitions that drive audio tone playback (`audioplayers`), per-phase vibration (`vibration`), optional text-to-speech announcements (`flutter_tts`), and an expanding-and-contracting central circle. The visual diameter is scaled from the configured inhale/exhale durations so the UI breathes in real time with the user. - **Offline-first practice log.** Sessions are stored in a Hive box, viewable as a list or a `table_calendar`-backed monthly calendar with weekly filtering and per-month totals. A CSV exporter is wired up through the `csv` package for users who want to analyse their sits elsewhere. - **Wear OS build.** A separate, slimmed-down watch app ships from the same project, letting a user start a session from the wrist without pulling out a phone. ## How it works The Flutter app is structured around three persisted boxes. A `Preference` Hive type stores inhale, exhale, audio index, vibration, TTS, and duration fields; a `Session` type stores completed sit records with start/end timestamps, breath count, and an optional description. The home widget loads the active preference on init, probes device capabilities (`vibration` support, `wakelock_plus`, `audioplayers` initialisation, optional `watch_connectivity`), and then drives the cycle counter from the 100 ms periodic timer. When the user starts a session, the floating action button switches to a stop icon and the timer loop begins. Phase boundaries are calculated by summing the configured inhale/exhale array slots in milliseconds; each transition fires `_onInhale`/`_onExhale` and the hold variants in parallel. Audio cues are four short tones bundled in the `audio/` asset directory, picked from per-phase dropdowns and previewable from the preferences screen. Vibration patterns can be tuned for session-end feedback and per-breath taps independently. Text-to-speech optionally announces phase changes and remaining session time. On completion, the widget stamps a `Session` record, calls `addSession` to persist it, fires a final haptic and audio cue, and disables the wake lock. The preferences screen offers five numbered preset slots — long-press to save the current configuration, short press to load — and a menu of built-in patterns that includes 4-7-8, Box, and physiological sigh. Landscape orientation widens the sliders for finer adjustments. The codebase is small and focused: a single `main.dart`, the `home_widget.dart` driving the live session, plus `sessions_widget.dart`, `sessions_calendar_widget.dart`, `preferences_widget.dart`, and a Hive-backed `wear.dart` for the companion watch face. The project pins its Flutter version via `.fvmrc`, uses Fastlane + GitHub Actions for CI, and supports localisation through `l10n.yaml`. ## Caveats - **No native iOS / macOS release.** The project ships Android, web, and Wear OS builds. iOS and macOS users currently have to run the reduced-feature web build — there is no official native build for Apple platforms. - **GPL-3.0 license.** All derivative works must remain open source under the same terms, which rules out a closed fork or a paid App Store port without releasing the source. - **Single-user, on-device data.** Sessions live in a local Hive store with no built-in cloud sync or multi-device migration. Exporting to CSV is the only way to move history off-device. - **TTS quality depends on the platform TTS engine.** The optional breath and duration announcements rely on whatever the OS provides, which can be inconsistent across devices and locales. ## Deployment notes ```bash # Build for Android (Google Play / F-Droid release path) git clone https://github.com/jithware/brethap.git cd brethap fvm install # honours .fvmrc flutter pub get flutter build apk --release flutter build appbundle --release ``` The repository also includes a `fastlane/` directory with the metadata and signing configuration used for the F-Droid and Play Store releases, and `.github/workflows` for CI on every push. Web builds use the standard `flutter build web` flow, and the companion Wear OS app lives in a separate path inside the same repo, gated by the same Flutter toolchain. **Minimum:** Android 6.0+ for the full feature set, including `vibration` and `wakelock_plus`; the web build runs in any modern browser but ships without vibration and with a reduced audio selection. The Wear OS build requires Wear OS 3 or newer. **Integration tip:** if you are cataloguing mindfulness apps, Brethap is a strong "configurable pattern" reference — pair it with a simpler breath-pacer that targets only one or two presets to show the spectrum from fixed to fully programmable meditation timers. ### Butterfly Butterfly is a Flutter note-taking and drawing app whose central object is an infinite canvas — pages hold freehand ink, text, shapes, images, areas, and waypoints in a custom `.bfly` document model, with optional WebDAV sync, OneNote import, and PDF/SVG export. - slug: butterfly - category: productivity - stack: flutter - stars: 1992 - license: AGPL-3.0 - repo: https://github.com/LinwoodDev/Butterfly - url: https://openappscout.com/apps/butterfly - lastCommit: 2026-09-02 - added: 2026-08-11 #### Detail # Butterfly Butterfly (branded as **Linwood Butterfly**) is a Flutter note-taking app where the primary artifact is an infinite drawing canvas. Notes are organized into pages, and each page is a free-form composition of hand-drawn ink, text, shapes, images, areas, and waypoints. It is positioned as a cross-platform alternative to OneNote with stylus-first input on Android, Windows, Linux, and the Web. ## Why it matters - **Canvas-first note model.** Butterfly is not a Markdown editor with a paper background; the canvas *is* the model. A `PersistedDocumentState` holds pages, viewports, and tool state, and `perfect_freehand` plus `one_dollar_unistroke_recognizer` are first-class dependencies for ink smoothing and gesture recognition. - **Custom document format.** Native files use the `.bfly` extension (and `.tbfly` for templates). The format, converters, and sync protocol are factored out into a sibling Dart package, `butterfly_api`, that the Flutter app consumes via a `path:` dependency. This is a well-executed monorepo split: the shared schema, converters (note, text, color, Xournal++ `.xopp`, ID helpers), and protocol types live next to the app and can be reused by the server. - **Local-first with optional WebDAV.** A custom `lw_file_system` layer treats local storage, IndexedDB on web, and any WebDAV endpoint as interchangeable backends. There is no required cloud account; users point the app at Nextcloud, ownCloud, or any standards-compliant WebDAV server. ## How it works The Flutter client is organized around a Bloc/Cubit state machine (`flutter_bloc`, `replay_bloc`, `rxdart`) under `app/lib/bloc/` and `app/lib/cubits/`. Services under `app/lib/services/` mediate file I/O, rendering, and imports. The `view_painter.dart` top-level file plus per-element renderers under `app/lib/renderers/` translate the document model into paint operations; elements are typed (pen, text, shape, image, area, waypoint) and editable in place. The shared `api/lib/src/` package contains four parallel subsystems: `converter/` (color, note, text, Xournal++, ID), `helpers/`, `models/` (the document schema), and `protocol/` (network payloads). A separately versioned `api/` *server* in the repository (Apache-2.0, distinct from the AGPL-3.0 client) is a thin service that speaks the same protocol and is the optional backend for multi-device sync. The deliberate license split keeps the API service embeddable without dragging the client into AGPL. Importers and exporters are first-class: OneNote files flow through `onenote_parser`, Xournal++ via `xopp.dart`, and images/PDFs/SVGs are handled by `image`, `pdfrx`, and `xml`. The app advertises `.bfly, .tbfly, .pdf, .jpg, .jpeg, .png, .gif, .bmp, .ico, .md, .one, .onepkg` as recognized file types, so opening an exported artifact in another tool (or back into Butterfly) is the documented round-trip. ## Caveats - **AGPL-3.0 on the client.** The Flutter app is AGPL-3.0. The `api/` server is Apache-2.0, so deploying the server as a hosted service is friendlier than the client would suggest. - **Monorepo git refs.** Several internal packages (`settings_leap`, `material_leap`, `networker`, `lw_file_system`, `keybinder`) are pulled from `github.com/LinwoodDev/dart_pkgs` via Git URLs rather than published versions, which makes reproducible builds depend on a moving target until those packages are tagged. - **Pre-1.0 versioning.** `pubspec.yaml` reports `2.6.0-beta.5+193` on the `develop` branch, so APIs and the `.bfly` format are still in flux between minor versions. ## Deployment notes The easiest way to run Butterfly is the prebuilt release for Android, Windows, Linux, or Web. For self-hosted sync, the repo also ships a `Dockerfile` and `docker-compose.yml` that bring up the Apache-2.0 `api/` server next to whatever WebDAV-compatible store you front it with. The default client configuration points at local storage; the WebDAV URL is configured per device in the app settings, not via a mandatory account. ### cake_wallet Cake Wallet is an open-source, non-custodial, multi-currency crypto wallet for iOS, Android, macOS, Linux, and Windows, built with a Flutter UI over per-chain Dart plugin packages that bridge to native C/C++ wallet code (notably the monero_c wrapper around wallet2 for Monero). - slug: cake_wallet - category: finance - stack: flutter - stars: 1895 - license: MIT - repo: https://github.com/cake-tech/cake_wallet - url: https://openappscout.com/apps/cake_wallet - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # Cake Wallet Cake Wallet is an open-source, non-custodial multi-currency crypto wallet for iOS, Android, macOS, Linux, and Windows. It is the most prominent open mobile wallet for Monero and a credible general-purpose alternative for Bitcoin, Ethereum, Litecoin, and a long tail of chains — all from one Flutter app. ## Why it matters - **The Monero reference on mobile.** Cake Wallet is the wallet most Monero users install first. It implements subaddresses, multiple accounts, restore-height based scanning, view-key-only wallets, and batch sends — the features that make XMR usable on a phone. The same codebase ships a stripped-down Monero-only app called Monero.com under the same repository. - **One app, many chains.** Beyond Monero the wallet supports Bitcoin, Bitcoin Cash, Litecoin (with MWEB), Ethereum and EVM chains (Polygon, Arbitrum, Base), Solana, Tron, Nano, Zano, and Decred. Each chain gets its own dedicated Dart plugin package — `cw_monero`, `cw_bitcoin`, `cw_evm`, `cw_solana`, `cw_tron`, `cw_nano`, `cw_zano`, `cw_decred`, `cw_dogecoin`, `cw_wownero`, `cw_zcash`, `cw_mweb`, `cw_bitcoin_cash` — so adding a chain is a matter of dropping in another package rather than forking the UI. - **Non-custodial by construction.** Seeds and view keys never leave the device. The wallet supports its own exchange flow (built on partner providers), buy/sell with fiat on-ramps, Tor-only connections, custom node URLs, OpenAlias, Unstoppable Domains, Yats, and FIO for human-readable addresses — all without any account signup. ## How it works The repo is a Flutter monorepo. The user-facing app lives in `lib/` and is a single Flutter target that consumes the `cw_*` packages as path dependencies. Each `cw_*` package follows the standard Flutter plugin shape: Dart code in `lib/`, platform glue in `android/`, `ios/`, `macos/`, `linux/`, and `windows/`. The shared core (`cw_core`) defines the wallet interface that every chain-specific package implements, and `cw_shared_external` bundles the native dependencies — Boost, OpenSSL, libsodium — that the per-chain plugins link against. The Monero plugin is the most interesting because Monero's wallet2 does not run on Dart. `cw_monero` consumes a Dart shim called `monero` from the mrcyjanek/monero_c repository, which in turn wraps monero-project's `wallet2_api.h` C interface; the actual FFI calls go through a platform plugin (`cw_monero_plugin.cc`, `CMakeLists.txt`) compiled per platform. Subaddress derivation, key image generation, and transaction construction all happen in that C/C++ layer; the Dart side just orchestrates scan passes and balance queries. The Bitcoin-family packages (`cw_bitcoin`, `cw_litecoin`, `cw_bitcoin_cash`, `cw_dogecoin`, `cw_mweb`, `cw_zcash`) reuse the `bitcoin_base` / `blockchain_utils` Dart forks in `pubspec_base.yaml` plus hardware-wallet bindings (`ledger_flutter_plus`, `trezor_connect`, `bitbox_flutter`) for air-gapped signing. State management is MobX; persistence is Hive with a code-generated adapter layer. Networking is `dio` plus `web_socket_channel` for chain daemons that push; `socks5_proxy` gives Tor support. The dependency tree is heavily customised — most crypto primitives pull from `cake-tech/*` forks (`bech32`, `web3dart`, `nostr_tools`, `qr_flutter`, `cake_backup`) rather than upstream packages, which makes the project robust but means `dependency_overrides` in `pubspec_base.yaml` is long and worth reading before bumping. ## Caveats - **Heavy fork surface.** Almost every cryptographic package is a cake-tech or community fork. The result is a wallet that ships the patches it needs but is harder for an outside contributor to reason about; bumping a major dependency is non-trivial. - **Buy/sell/exchange is partner-mediated.** The in-app exchange and fiat on-ramp features rely on third-party providers and require KYC at their end even though the wallet itself is non-custodial. The Monero-only flow can route through Tor; the partner-mediated flows cannot. - **Build complexity.** Compiling Monero's wallet2 across five platforms needs Boost, OpenSSL, libsodium, CMake, and per-OS toolchains; CI publishes signed APKs, IPAs, MSIX, and AppImage artifacts but local builds from `cw_monero/linux/` are not turnkey. ## Deployment notes ```bash # Mobile — install from the official stores # iOS: https://apps.apple.com/app/cake-wallet/id1334702548 # Android: https://play.google.com/store/apps/details?id=com.cakewallet.wallet # APK: https://github.com/cake-tech/cake_wallet/releases # Linux (AppImage) # https://github.com/cake-tech/cake_wallet/releases (cake_wallet.AppImage) # Build from source — Flutter 3.x + the native deps above git clone https://github.com/cake-tech/cake_wallet.git cd cake_wallet flutter pub get flutter run -d linux # or android, ios, macos ``` **Minimum:** iOS 13+ or Android 6+ for the mobile builds; macOS 11+, a recent Ubuntu LTS, or Windows 10/11 for the desktop builds. Monero sync from genesis wants ~50 GB; a `restore_height` cuts that to roughly the wallet's age. **Integration tip:** if you are cataloguing open wallets, treat Cake Wallet as the "more chains" entry next to single-chain peers like BlueWallet (Bitcoin/Lightning). The `cw_*` package split is also a useful reference for anyone designing a pluggable, multi-chain Flutter wallet — the `cw_core` interface is the contract every chain has to satisfy. ### Cap Open source Loom alternative. Beautiful, shareable screen recordings. - slug: cap - category: tools - stack: tauri - stars: 21587 - license: NOASSERTION - repo: https://github.com/CapSoftware/Cap - homepage: https://cap.so - url: https://openappscout.com/apps/cap - lastCommit: 2026-09-03 - added: 2026-07-24 #### Detail # Cap Cap is an open-source screen recorder that pairs three modes in one Tauri-based desktop binary: Instant (record and get a share link), Studio (record locally and edit), and Screenshot (capture and beautify). The recording pipeline is first-party Rust across macOS (ScreenCaptureKit), Windows (DXGI), and Linux (PipeWire). The web app and the share viewer are Next.js + React 19 with an Effect-typed HTTP layer. The recording pipeline, the editor, the web app, and the self-hosting recipe are in the AGPL-3.0 repo; the paid tiers gate AI, custom domain, password protection, viewer analytics, and team workspaces on the cloud. ## Three modes, one binary, first-party capture ![Cap's three-recordings menu — Instant, Studio, and Screenshot modes in one Tauri-based desktop binary](/images/cap/three-modes.png) *Cap's three-recordings menu in one Tauri-based desktop binary: Instant mode for fast share links, Studio mode for local record-then-edit, and Screenshot mode for capture-and-beautify.* Cap's product is unusual because it ships three distinct screen- recording modes in one Tauri-based desktop binary. **Instant Mode** records screen + camera + microphone, uploads chunked video to S3-compatible storage while you record, and produces a share link immediately on stop — the Loom-equivalent flow. **Studio Mode** records locally to disk, then edits in a built-in editor (backgrounds, padding, rounded corners, drop shadows, cursor effects, zoom-to-click, trimming, captions, music, export to MP4/GIF). **Screenshot Mode** is a hotkey capture with a beautify window. The capture stack is first-party and platform-specific. There is **no use of `captrs` or `nokhwa`** — Cap ships its own platform-specific capture crates prefixed `scap-`: - **`scap-screencapturekit`** — macOS, wraps Apple's **ScreenCaptureKit** via a vendored fork of the `cidre` crate. - **`scap-direct3d`** — Windows, **DXGI Desktop Duplication**. - **`scap-ffmpeg`** — cross-platform fallback using FFmpeg's `gdpirab` (Windows) / `avfoundation` (macOS) / `x11grab` (Linux). - **`scap-cpal`** — audio capture wrapper around `cpal`. - **`scap-targets`** — enumerates displays and windows. The camera follows the same pattern: `camera-avfoundation`, `camera-directshow`, `camera-mediafoundation`, `camera-ffmpeg`, plus `camera-effects` for blurring and backgrounds. The encoding crates are `enc-avfoundation`, `enc-mediafoundation`, `enc-ffmpeg`, `enc-gif`. The recording state machine uses the **`kameo` actor framework** — an unusual pick. Each actor owns its state (RecordingState, camera feed, mic, capture) and communicates via channels. The muxer is the source of truth; recording happens to disk first, so a network blip doesn't drop frames. The `cap-muxer-protocol` crate is the contract for the chunked upload to S3. ## The open-core split is healthier than most The paid tiers turn knobs that are mostly cloud conveniences, not codec or editor features. **Desktop License** ($29/year or $29 lifetime) enables commercial use of the local Studio features. **Cap Pro** ($12/user/month or $8.16/user/month annual) unlocks unlimited share links, AI (titles, transcripts, chapters), custom domain, password protection, viewer analytics, Loom importer, and custom S3 / Google Drive. **Enterprise** adds SOC 2 / ISO 27001 compliance (confirmed August 2026), SAML SSO, SCIM, and managed self-hosting. The recording pipeline, the codecs, the editor, the web app, and the self-hosting recipe are all in the AGPL-3.0 repo. The open-core gates are AI, custom domain, password protection, viewer analytics, and team workspaces. This is a healthier split than most "open core" projects: the things you might want to fork (codec, editor, web viewer, self-host) are open; the things you would not want to fork anyway (cloud storage, AI, identity) are paid. ## The relicense happened, and it matters The project started under **GPLv3** at the initial commit (e1b6ce9, November 17, 2023) with no copyright holder assigned. On **January 3, 2024** — six weeks later — commit `522e38c` ("Add Cap Software, Inc") replaced the LICENSE with the AGPLv3 text and added "Copyright (c) 2023-present Cap Software, Inc." For an end user or downstream contributor, the practical difference is: under the original GPLv3 you could run a modified Cap as a network service without publishing your changes; under AGPLv3 you must publish them. The change is consistent with the founder's stated commercial strategy (a hosted SaaS competing with Loom) but **was not publicly announced in a blog post or news item**. AGPLv3 is the right license for a project with a hosted commercial strategy; the lack of a public announcement is the part worth naming. ## The instant-share architecture The instant-share flow is the part of the product that is genuinely interesting: 1. User clicks record in Cap Desktop. 2. Tauri Rust backend spawns platform capture (ScreenCaptureKit / D3D / PipeWire) plus camera + microphone. 3. Frames are encoded to H.264 and written to a muxer (`cap-muxer`) that produces chunks suitable for resumable upload. 4. Each chunk is uploaded to S3-compatible storage while the next chunk is captured. Presigned URLs are obtained from the cap-web API. 5. On stop, the desktop binary POSTs a "complete" event with the chunk manifest. 6. Cap-web marks the video as ready, generates a slug, and returns a share URL. 7. The viewer page lazily transcodes / builds HLS or progressive MP4 via either MediaConvert or the in-house media-server, and the link is immediately shareable. The web app (`apps/web`) is Next.js 16.3, React 19.2, with **Turbopack** in dev. AWS S3 (with presigned URLs for direct browser-to-S3 upload) and CloudFront CDN signing are first-class. MySQL via Drizzle ORM + `@effect/sql-mysql2`. The web API uses the **Effect** framework (`@effect/platform`, `effect`, RPC) and serves via Hono routing. ## The recent security audit In July 2026, user **DPS0340** filed **issue #2033** documenting an audit of `apps/web` that found missing access checks on multiple endpoints. `getVideoAnalytics` had **no auth at all**, allowing private video view counts to be read. Four PRs (#2029–#2032) were opened to fix. **Issue #2039** documented 7 of 13 `RATE_LIMIT_IDS` declared but never called, with endpoints having no rate limiting. This is a real and recent disclosure. The project's response (four PRs in quick succession) is a positive signal, but the audit findings are worth flagging. ## Where Cap is the best choice - A user who wants a free, open-source Loom alternative with self-hosting and first-party 4K/60fps capability in Studio Mode. - A team that can pay $12/user/month for AI, custom domain, password protection, and team workspaces. - A user who wants to self-host the web app and the share viewer (Docker Compose with `cap-web`, `media-server`, `mysql`, `minio`). ## Where Cap is not the right choice - A user who needs a mobile app. There is no iOS or Android recorder; only the share viewer is mobile-responsive. - A user who wants a free tier for commercial use. The free tier is personal-use only; commercial use requires a $29/year Desktop License. - A user who needs E2E-encrypted share links. The default is HTTPS only; the cap-web server has the S3 keys. - A user on a strict permissive license. AGPL-3.0 is the strictest of the mainstream open-source licenses for network use. - A user who needs Screen Studio-quality cinematic zoom on macOS. Cap has zoom-on-click and zoom-on-text, but Screen Studio's automatic "click zoom" is still the better cinematic experience. ## Deployment notes The self-host stack is `docker compose up -d` from the repo root, which spins up `cap-web` (Next.js) on port 3000, `media-server` (FFmpeg-based processor), `mysql` (8.0), `minio` (S3-compatible), plus a `minio-setup` one-shot bucket creator. Default credentials are public in the repo (`MYSQL_PASSWORD=cap-local-pwd-123`, `MINIO_ROOT_PASSWORD=cap-minio-pwd-456`) — the docs explicitly call this out and require replacement before production. One-click Railway template and a separate Coolify template are available. Point Cap Desktop at your own server via Settings → "Cap Server URL". Optional AI by adding API keys for AssemblyAI (transcription) and Groq / OpenAI (summaries). Optional OAuth (Google/Apple) and email (Resend). ## Developer lessons worth borrowing - **The "Rust + Tauri + TypeScript" split is the right one for cross-platform system apps in 2026.** Tauri v2 with `tauri-specta` typed bindings gives you a smaller binary than Electron; the Rust core owns capture, encoding, mux, upload; the TypeScript layer never touches raw frames. - **The `scap-*` family is the right capture abstraction.** Platform-agnostic interface, platform-specific impls via Cargo feature flags. Cap and RustDesk both ship this pattern; both are good case studies. - **The kameo actor model for the recording state machine is unusual and worth studying.** "Many input streams, one output muxer" is a clean fit for actors. The muxer is the source of truth; recording happens to disk first. - **Chunked upload during recording is the right pattern for "instant share."** The muxer chunks frames into uploadable segments; each segment is uploaded independently; the server stitches them on playback. The desktop binary can survive network blips because the recording is on disk first. - **Open-core gating should be on cloud conveniences, not codecs.** Cap's gates are AI, custom domain, password protection, viewer analytics, team workspaces. The recording pipeline, the editor, the web app, and the self-hosting recipe are all in the AGPL-3.0 repo. This is the model to emulate. - **A public relicense deserves a public announcement.** Cap's GPLv3 → AGPLv3 change in the first six weeks was not publicly explained. AGPLv3 is the right license for a project with a hosted commercial strategy; the lack of a blog post is the part worth naming. - **A security audit is a feature.** DPS0340's July 2026 audit found real bugs in `apps/web`; the team's response (four PRs in quick succession) is a positive signal. The lesson: welcome external audits, treat the findings as a roadmap, ship the fixes publicly. ## How Cap compares The screen-recording landscape in 2026 is a long spectrum from "free streaming tool" to "professional post-production". The honest positioning of Cap is that it is the only Loom-class product that is also a serious self-host. | Project | License | Capture engine | Editor | Self-host | Free self-host usable | Best for | |---|---|---|---|---|---|---| | **Cap** | AGPL-3.0 (commercial Desktop License required for commercial desktop use) | First-party Rust: ScreenCaptureKit (macOS), DXGI (Windows), PipeWire (Linux) | Built-in Studio editor (zoom, captions, backgrounds, MP4/GIF export) | Yes (Docker Compose with `cap-web`, MySQL, MinIO) | Yes (default credentials must be changed) | A free Loom alternative that you can also self-host, with first-party 4K capture on every desktop OS | | **Loom** | Closed-source SaaS | Browser/desktop record | Web editor only | No | N/A | A team that wants zero setup and can pay per-seat | | **Screen Studio** | Closed-source, paid (~$30–50 lifetime) | macOS-only, excellent cursor/zoom effects | Built-in post-production | No | N/A | macOS users who want cinematic, share-quality output and are willing to pay once | | **OBS Studio** | GPL-2.0 | Cross-platform, scene-based | No built-in editor | N/A (it is a capture tool, not a recorder) | Yes | Live streaming, scene composition, anything that needs to overlay multiple sources | | **ScreenFlow** | Closed-source, paid | macOS + iOS | Full non-linear editor | No | N/A | macOS users who need non-linear editing and are willing to pay $169 | | **Camtasia** | Closed-source, paid ($300 perpetual) | Windows + macOS | Full non-linear editor + interactive quizzes | No | N/A | Corporate training content with quizzes and LMS integration | | **Tella** | Closed-source SaaS | Browser/desktop record | Web editor only | No | N/A | Async team communication without Loom's pricing | | **Kap** | MIT | Cross-platform (Electron-based) | Crop / export only | No | Yes (per user) | A simple, free, open-source recorder without instant share | | **Screenity** | MPL-2.0 | Chromium web extension | Browser-based trim | No | Yes (free) | Privacy-first browser-only recording | **Pick Cap** if you want a real Loom alternative with self-hosting and first-party capture quality, and you accept the AGPL-3.0 commercial licensing terms. **Pick OBS** if your real goal is streaming or composition, not recording. **Pick Screen Studio** if you are on macOS and produce share-quality content professionally — Cinematic zoom-to-click and cursor effects remain better there than anywhere else. **Pick ScreenFlow or Camtasia** if you need a non-linear editor for training content. Cap's Studio editor is a recorder-plus-effects tool, not a Premiere replacement. **Pick Kap** if you want a free, open-source recorder for personal use and do not need instant share links. ## Verified sources - Cap GitHub repository: - `cap-muxer`, `cap-muxer-protocol`, `scap-*` crate family — directly inspectable in the repo. - Re-license commit `522e38c` (Cap Software, Inc.), January 3, 2024 — `git log -- LICENSE` on the repository. - Security audit — issue #2033 (DPS0340, July 2026) and follow-up PRs #2029–#2032 and #2039. - AGPL-3.0 vs commercial tier pricing — reproduce by cloning `cap-web` and reading the license blocks in `apps/web`. - Screen Studio vs ScreenFlow vs Camtasia positioning — based on the publishers' own feature pages (each is a closed-source product). ### d1v.ai Mobile A Flutter mobile workspace for creating or importing projects, continuing AI-assisted work, inspecting files, and monitoring preview and deployment state from iOS or Android. - slug: d1vai-app - category: developer-tools - stack: flutter - stars: 7 - license: MIT - repo: https://github.com/d1vai/d1vai_app - homepage: https://www.d1v.ai - url: https://openappscout.com/apps/d1vai-app - lastCommit: 2026-09-01 - added: 2026-08-31 ### Daily_You Daily You is a privacy-first, offline-capable journaling app for capturing daily entries with text, mood ratings, photo memories, and Markdown notes — all stored locally with no accounts, ads, or telemetry. - slug: daily_you - category: tools - stack: flutter - stars: 1283 - license: GPL-3.0 - repo: https://github.com/Demizo/Daily_You - url: https://openappscout.com/apps/daily_you - lastCommit: 2026-09-02 - added: 2026-08-11 #### Detail # Daily You Daily You is a Flutter-built, offline-first daily journal that keeps every entry on-device — no accounts, no ads, no telemetry. Its tagline, "Every day is worth remembering," frames the app as a private space for capturing thoughts, rating mood, attaching photos, and writing Markdown notes that you fully own. A backup-and-restore flow plus an "Import From Another App" path make it a credible migration target for users leaving hosted journal services. ## Why it matters - **Local-first by design.** Entries, tags, templates, and photo blobs live in a SQLite database on the device (with optional external storage), so the journal works without a network and stays exportable as plain JSON. - **Cross-platform parity.** A single Flutter codebase targets Android, iOS, Linux, macOS, Windows, and Snap, so desktop and phone share entries through the standard backup-restore flow. - **Mood and flashbacks.** Each entry carries an optional mood score, and a `flashback_manager` resurfaces "on this day" entries from prior years — a private TimeHop whose tone you can tune by excluding low-mood days. - **F-Droid friendly.** A Nix flake, an `AppImageBuilder` config, and reproducible Android builds let the app ship on F-Droid, IzzyOnDroid, and GitHub Releases without modification. ## How it works The app is structured around a thin DAO layer over `sqflite`: each domain entity (entries, tags, tag categories, images, templates) has its own DAO under `lib/database/`, and `app_database.dart` wires migrations. A `provider`-based state tree feeds a Material 3 UI with pages for the home timeline, entries list, edit page, statistics (backed by `fl_chart`), and a settings page that hosts backup, restore, import, theme, notification, and calendar options. The standout piece is `lib/flashback_manager.dart`: given the current locale and calendar (Gregorian or Jalali, via the `shamsi_date` dependency), it walks reversed entries and groups past entries by day, week, month, and year, producing a surfaced "memories" feed on the home page. Notifications come from `flutter_local_notifications` plus `android_alarm_manager_plus` for random daily reminders, and `local_auth` gates the app behind biometrics where supported. ## Caveats - **No cloud sync.** Daily You does not ship its own sync server; you move data between devices manually via backup files, WebDAV, or shared external storage. - **Single user.** There is no concept of multiple journals or accounts in the data model — one install, one author. - **GPL-3.0.** Fine for personal use and community forks, but commercial derivative apps must publish their changes. - **Jalali is opt-in.** Persian-calendar users get full date handling, but switching back to Gregorian can leave flashback grouping inconsistent until enough entries accrue. ## Deployment notes For end users, the simplest path is installing from F-Droid or IzzyOnDroid on Android; iOS, macOS, Windows, and Linux builds live on the GitHub Releases page. To build from source: ```bash git clone https://github.com/Demizo/Daily_You.git cd Daily_You nix develop # or: install Flutter (>=3.0) and `flutter pub get` flutter run ``` **Minimum:** Any device that runs Flutter 3.0+. Expect ~50–100 MB of local storage for a year of mixed text-and-photo entries; SQLite keeps lookup fast well past 10,000 entries. **Integration tip:** in a directory like this one, pair Daily You with any privacy- or self-hosting-tagged record. If you already list `immich` or `joplin`, position Daily You as the "private diary" counterpart — same GPL-3.0 / no-account philosophy, but for the short-form reflections that don't belong in a note-taking app. ### EhPanda EhPanda is an unofficial iOS and iPadOS client for the E-Hentai and ExHentai galleries, written entirely in SwiftUI on top of Point-Free's Composable Architecture, with a Combine/Kanna scraping layer and Core Data persistence. - slug: ehpanda - category: media - stack: ios - stars: 3965 - license: MIT - repo: https://github.com/EhPanda-Team/EhPanda - url: https://openappscout.com/apps/ehpanda - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # EhPanda EhPanda is an unofficial iOS/iPadOS client for the E-Hentai and ExHentai gallery sites, built entirely in SwiftUI on top of Point-Free's Composable Architecture (TCA). ## Why it matters Most SwiftUI apps that get held up as reference implementations are todo lists. EhPanda is a real, shipping, 1.1M-line-of-Swift application — search, paginated lists, a full-screen image reader, account login, comments, ratings, torrents, archive downloads — and it is 100% SwiftUI with no UIKit view layer to fall back on. That makes it one of the most useful large-scale SwiftUI codebases to read. It is also a rigorous TCA codebase. State, actions, and reducers are composed from `AppReducer` down through per-screen reducers (`AppRouteReducer`, `AppLockReducer`, and a reducer per feature folder), with side effects modelled as publishers rather than scattered through views. If you want to see whether TCA survives contact with a real app, this is the sample. The caveat is unavoidable: the sites it talks to host adult user-generated manga and doujinshi, much of it of contested legal status depending on jurisdiction. The README itself disclaims responsibility for the content and tells users they browse at their own risk. Read the code for the architecture; understand what the app is actually for before you install it. ## How it works The view layer lives in `EhPanda/View/`, split into `Home`, `Search`, `Detail`, `Reading`, `Favorites`, `Setting`, `TabBar`, `Support`, and `Migration`. `Home` covers frontpage, popular, watched, and toplists; `Detail` renders the gallery page with previews, comments, tags, and torrent/archive actions; `Reading` is the paged/vertical image reader with gesture handling (the v2.8.1 release notes list a reader gesture fix and Liquid Glass adaptation). `EhPanda/Network/` is where the scraping happens. There is no API — E-Hentai serves HTML, so every request conforms to a `Request` protocol that returns `AnyPublisher` and pipes `URLSession.dataTaskPublisher` → a three-attempt `genericRetry()` → `Kanna.HTML` → a domain-specific `Parser.parse*` function → error mapping into `AppError` (`.parseFailed`, `.networkingFailed`). URLs are centralised in `URLUtil`/`Defaults.URL`. Login and settings submission are URL-encoded form POSTs; session state rides on `URLSession`'s shared cookie storage, including the `igneous` cookie ExHentai requires. `DomainResolver.swift` and the `DF*` files handle domain-fronting and a custom `URLProtocol` for regions where the sites are blocked. Nice detail: `GalleryDetailRequest` has a fallback that strips invalid UTF-8 bytes when the page's encoding is broken. `EhPanda/Database/` is Core Data (`Model.xcdatamodeld` + `Persistence.swift`, with `MODefinition/` entities and a versioned `Migration/` folder) holding gallery metadata, reading state, history, and appearance settings so re-opening a gallery does not re-scrape. ## Caveats The legal grey area is the headline caveat. The upstream galleries are adult content of varying legality by country, and the app is a client with no moderation of its own. Bundled tag translators and category filters help, but the responsibility sits with the user. Consequently the app is not on the App Store and effectively cannot be — distribution is a GitHub Releases `.ipa` plus an `AltStore.json` source manifest. Maintenance has been intermittent: months of zero commits in early 2026 followed by a burst around the v2.8.1 release in July. It is MIT-licensed with ~22 known contributors, so the bus factor is thin. ## Deployment notes There is no `docker compose up` here. You either download `EhPanda.ipa` from Releases and sideload it with AltStore/SideStore (re-signing every seven days on a free Apple ID), add the repo's `AltStore.json` as a source, or open `EhPanda.xcodeproj` and build to your own device. The current release targets iOS/iPadOS 26.0+. Runtime requirements are modest: network access, photo library write permission for saving images, Face ID/Touch ID if you enable the app lock, and background download entitlements. ExHentai access additionally needs a valid E-Hentai account cookie obtained through the in-app login flow — the app cannot fabricate it. Content filtering is configured server-side via the E-Hentai profile and mirrored by `EhSettingRequest`/`SubmitEhSettingChangesRequest`, so category exclusions set in-app propagate to the account. **Integration tip:** if you catalogue iOS apps, treat EhPanda as the canonical "large production SwiftUI + TCA codebase" reference and tag it `sideload-only` — never assume an App Store link exists. ### Ejimo A cross-platform emoji and symbol picker that goes beyond the system keyboard. - slug: ejimo - category: tools - stack: flutter - stars: 60 - license: GPL-3.0 - repo: https://github.com/albemala/emoji-picker - url: https://openappscout.com/apps/ejimo - lastCommit: 2026-05-21 - added: 2026-06-07 ### Feather Free on-device iOS/iPadOS application manager/installer, using certificates part of the Apple Developer Program. - slug: feather - category: productivity - stack: ios - stars: 4643 - license: GPL-3.0 - repo: https://github.com/claration/Feather - url: https://openappscout.com/apps/feather - lastCommit: 2026-08-31 - added: 2026-06-13 ### feed-flow FeedFlow is a minimalistic RSS Reader available on Android, iOS, macOS, Windows and Linux. Built with Kotlin Multiplatform, Jetpack Compose and SwiftUI. - slug: feed-flow - category: news - stack: ios - stars: 1195 - license: Apache-2.0 - repo: https://github.com/prof18/feed-flow - url: https://openappscout.com/apps/feed-flow - lastCommit: 2026-09-03 - added: 2026-06-13 ### Flip A Reversi board game implementation with a clean interface for casual play. - slug: flip - category: games - stack: flutter - stars: 269 - license: BSD-3-Clause - repo: https://github.com/RedBrogdon/flutterflip - url: https://openappscout.com/apps/flip - lastCommit: 2026-06-28 - added: 2026-06-07 ### Flutter Games Flutter app for purchasing and renting games - slug: flutter-games - category: shopping - stack: flutter - stars: 345 - license: 0BSD - repo: https://github.com/searchy2/FlutterGames - url: https://openappscout.com/apps/flutter-games - lastCommit: 2026-04-16 - added: 2026-06-07 ### Flutter WooCommerce app A ready-made app template for WooCommerce stores - slug: flutter-woocommerce-app - category: shopping - stack: flutter - stars: 714 - license: BSD-2-Clause - repo: https://github.com/woosignal/flutter-woocommerce-app - url: https://openappscout.com/apps/flutter-woocommerce-app - lastCommit: 2026-05-23 - added: 2026-06-07 ### flutter_server_box A Flutter-based, cross-platform client for monitoring and administering remote Linux, Unix, and Windows servers over SSH — combining real-time status charts, an embedded xterm terminal, SFTP file transfer, and Docker / systemd / S.M.A.R.T. management on iOS, Android, macOS, Linux, and Windows. - slug: flutter_server_box - category: tools - stack: flutter - stars: 8634 - license: AGPL-3.0 - repo: https://github.com/lollipopkit/flutter_server_box - url: https://openappscout.com/apps/flutter_server_box - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # Flutter Server Box Flutter Server Box (package name `server_box`, branded "ServerBox") is a cross-platform client for monitoring and administering remote servers. It packages what would normally require a desktop SSH workstation — a terminal, SFTP browser, live system telemetry, and container / service management — into a single Flutter codebase that ships to iOS, Android, macOS, Linux, and Windows. Despite the name it is not a headless server itself; it is the *console* you keep open while your Linux VPS, NAS, Raspberry Pi, or shared hosting box does its work. ## Why it matters - **Truly cross-platform admin surface.** The same app runs on a phone, a tablet, a MacBook, and a Linux desktop, with the watchOS companion app providing at-a-glance status from the wrist. For an operator who needs to ssh into a flaky VPS from a phone while away from a laptop, that is a meaningfully better experience than juggling Termux and a separate status app. - **Real telemetry, not just a terminal.** ServerBox renders live charts for CPU, sensors (temperature, fan, voltage via `lm_sensors`), GPU (parsed from `nvidia-smi` XML), network, disk, and S.M.A.R.T. health, plus a Docker / process / systemd manager. The information sources are standard CLI tools on the host, so a vanilla Ubuntu or Raspberry Pi OS install is enough — no proprietary agent is required for the core features. - **Optional companion agent unlocks background features.** A small standalone binary called [ServerBoxMonitor](https://github.com/lollipopkit/server_box_monitor) is published separately and installed on the managed host. With it in place, the app gains server-push notifications (alerts fired server-side rather than on a client poll) and home-screen widgets that refresh in the background. Without it, ServerBox is still fully functional on demand; with it, the app behaves more like a passive monitoring dashboard. ## How it works The Flutter client holds server credentials locally and talks to each host over a single SSH session. The SSH layer is `dartssh2` (vendored in the repo as `packages/dartssh2`), which implements the SSH2 protocol natively in Dart — there is no shell-out to `ssh` or `paramiko`, so the same code path runs on every platform including iOS where shelling out would be blocked. The terminal view is a vendored `xterm` package, and the embedded terminal is the same xterm.js-derived widget TerminalStudio publishes, fed live bytes from a `dartssh2` channel. State management is Riverpod 3 with code generation (`riverpod_generator`, `riverpod_annotation`), persistence uses `hive_ce` for local server profiles, and the build pipeline is a custom Dart script `dart run fl_build -p PLATFORM` (defined in `fl_build/`) that wraps `flutter build` per platform. i18n runs through Flutter's standard `intl` + ARB pipeline, with English, Simplified and Traditional Chinese, German, French, Dutch, Indonesian, Turkish, and Ukrainian hand-maintained and a long tail of auto-generated locales. Charts use `fl_chart` for the standard line/area series and a custom `circle_chart` for the at-a-glance ring gauges on the server detail screen. The repo also contains a small `watch_connectivity` package that bridges to the watchOS app, and a `plain_notification_token` package that powers home-screen widget refresh on Android without depending on Firebase. ## Caveats - **AGPL-3.0.** The license is copyleft: redistributing the app binary obliges you to publish your modifications. Acceptable for personal and internal use; for a branded commercial fork you will either keep the source open or negotiate separately. - **No built-in web UI.** ServerBox is a native client only. If you need a browser-based console for the same fleet, you are looking at a different project (e.g. a self-hosted shellhub or apache guacamole). - **Credentials are stored locally.** Server profiles and SSH keys live in app-local Hive storage, with optional biometric lock on supported devices. There is no central team / shared vault primitive — this is a personal sysadmin tool, not an enterprise PAM replacement. - **ServerBoxMonitor is a separate repo.** Treat the optional companion agent as a different dependency with its own release cadence; the two projects version independently and not every release of the Flutter app is tested against every release of the monitor. ## Deployment notes The client ships through the usual consumer channels; there is no self-hosted "server" to install. ```bash # Mobile and desktop installers # iOS / macOS: App Store # macOS also: brew install --cask server-box # Android: F-Droid, OpenAPK, GitHub Releases, or the project's CDN # Linux / Windows: GitHub Releases or CDN (AppImage / portable .zip) # Build from source (requires Flutter >= 3.11 with Dart >= 3.44) git clone https://github.com/lollipopkit/flutter_server_box.git cd flutter_server_box flutter pub get dart run build_runner build --delete-conflicting-outputs flutter run -d # or: dart run fl_build -p android # android / ios / macos / linux / windows ``` On the managed host, the only requirement is a reachable SSH daemon and the standard CLI tools ServerBox queries (`uptime`, `ps`, `systemctl`, `docker`, `smartctl`, `nvidia-smi`, `sensors`, `cat /proc/...`). For the optional background-push and home-widget features, install [ServerBoxMonitor](https://github.com/lollipopkit/server_box_monitor) on the host and point the client at it. **Integration tip:** if you maintain a directory like this one and want a working "SSH-based fleet management" example, ServerBox is a good reference for a Flutter app that wraps a non-HTTP protocol (`dartssh2` over a Dart socket) and surfaces structured data from remote shells — the `lib/data/model/server/` + per-status provider split in `lib/view/page/server/` is a clean pattern for turning parsed `stdout` into typed Riverpod state on every platform from one codebase. ### flutter-pos-system An offline-first Flutter point-of-sale app for small restaurants and shops that runs ingredient inventory, menu management, customer demographics, order taking, Bluetooth receipt printing, custom analytics charts, and Google Sheets export entirely on-device with no remote backend. - slug: flutter-pos-system - category: developer-tools - stack: flutter - stars: 603 - license: Apache-2.0 - repo: https://github.com/evan361425/flutter-pos-system - url: https://openappscout.com/apps/flutter-pos-system - lastCommit: 2026-08-06 - added: 2026-08-11 #### Detail # Flutter POS System Flutter POS System is an offline-first point-of-sale app built in Flutter for small restaurants, cafes, and shops. The project targets a single phone or tablet running the counter: an owner sets up ingredients and menu items, a cashier rings up orders, the system decrements stock automatically, prints a Bluetooth receipt, and at the end of the day the data can be exported to Google Sheets for reconciliation — all with nothing leaving the device unless the operator chooses to push it out. ## Why it matters - **Offline-first by design, not by retrofit.** Every row lives in `sqflite` + `sembast` on the phone; the app needs no internet connection at the counter. Connectivity only matters for the optional Google Sheets export, Firebase Analytics / Crashlytics telemetry, and the Google sign-in that authorises that export. - **End-to-end POS workflow in one binary.** The app covers the full loop a small operator needs and stops there: ingredient → menu → order → cash register → Bluetooth receipt → daily balance → analytics. There is no ERP feature creep, and the cash-register math is purpose-built rather than a generic shopping cart. - **Customer demographics as a first-class field.** The customer model captures age and gender for the analytics dashboard, so a single-shop owner can build the demographic charts a chain POS would gate behind a SaaS subscription. - **Built-in analytics.** Charts render with Syncfusion (line + pie, plus a custom-axes mode), so the owner can answer "what sold best on Wednesday" without exporting anything. ## How it works The codebase (package name `possystem`, v2.12.x) is organised around feature folders under `lib/` — `models/`, `services/`, `ui/`, `helpers/`, `components/`, plus a `settings/` surface — with `go_router` driving navigation and `provider` for state management. Each domain (ingredients, menus, orders, customers) is its own folder, so adding a new entity type is a localised change rather than a sweeping refactor. Local storage is layered: `sqflite` for relational entities (orders, menu items, ingredients), `sembast` for document-style records (settings, transit exports), and `shared_preferences` for small flags. Receipt printing goes over Bluetooth through the `blue_thermal_printer` family against 58mm and 80mm thermal printers. The "Transit" feature packages orders, menus, and other tables as JSON or Excel (via a custom `excel` dependency pinned in `pubspec.yaml`) and pushes them to a Google Sheet through `googleapis` with `google_sign_in` for OAuth. Firebase is wired in for telemetry only — `firebase_analytics`, `firebase_crashlytics`, `firebase_performance`, and `firebase_in_app_messaging` — and localization runs through Flutter's standard `intl` + ARB pipeline (English and Chinese hand-maintained). The responsive layout adapts between phone and tablet widths. ## Caveats - **Android-first.** The Play Store release is the supported channel; iOS is "coming soon" per the README and there is no TestFlight build in the repo. Operators who need iOS today are piloting with Android tablets or sideloading. - **Single-device, single-merchant model.** There is no multi-store or multi-user server; two cashiers on two devices at once run separate stores unless reconciled via the Sheets export. Deliberate small-shop scope but worth knowing up front. - **Custom pinned dependencies.** `pubspec.yaml` references `packages` and `excel` from a custom Git repo rather than pub.dev, so `flutter pub get` needs that source reachable. Locked-down build environments without the Git remote will fail to resolve. - **Syncfusion license.** Charts are powered by Syncfusion's Flutter package, which carries its own community-license terms — above a certain revenue threshold a Syncfusion license is required even though the app itself is Apache-2.0. ## Deployment notes ```bash # Android — install from the Play Store # https://play.google.com/store/apps/details?id=com.evanhoe.possystem # Local development git clone https://github.com/evan361425/flutter-pos-system.git cd flutter-pos-system flutter pub get flutter run -d # or ios once available ``` **Minimum:** an Android 6+ phone or tablet, plus a Bluetooth thermal receipt printer (58mm or 80mm) if you want paper receipts. The app itself runs on a low-end device — there is no server to provision, no cloud tenant to pay for, and no account to register before you can take your first order. **Integration tip:** if you curate an Open Apps directory like this one and want a real-world Flutter example that ties together on-device persistence (`sqflite` + `sembast`), Bluetooth hardware, an analytics dashboard (Syncfusion), and a Sheets export via Google APIs — without any of those pieces needing a server — Flutter POS System is one of the cleanest end-to-end reference implementations you will find. ### GitUp GitUp is a native macOS Git GUI built on a bespoke in-process Git toolkit (GitUpKit) that wraps a customized libgit2 fork and re-implements everything else — including its own rebase engine — to keep operations and the live commit graph fast on large repositories. - slug: gitup - category: tools - stack: ios - stars: 12117 - license: GPL-3.0 - repo: https://github.com/git-up/GitUp - url: https://openappscout.com/apps/gitup - lastCommit: 2026-07-27 - added: 2026-06-13 #### Detail # GitUp GitUp is a native macOS Git client that treats the commit graph as a first-class object: a live, interactive map of every ref and every commit in the repository that you can drag, reorder, squash, split, fix up, and roll back. It is the front half of a two-layer project; the back half is **GitUpKit**, an in-house Git toolkit that replaces the usual libgit2 bindings with a thin, opinionated Objective-C API. ## Why it matters - **The map is the product.** Where Tower, Sourcetree, and GitKraken push you into list views, GitUp renders the full commit DAG (`GIGraphView` in `GitUpKit/Interface/`) and lets you edit history visually: drag a commit to rebase, split a commit by hunk, run an interactive fixup chain, then undo all of it because the same operations are wired into `NSUndoManager`. - **Time Machine-style snapshots.** Every meaningful mutation goes through `GCLiveRepository -performOperationWithReason:argument:…` which, per the header comment, "automatically updates snapshots and registers an undo action with `NSUndoManager`." A snapshot is just a reflog entry you can rewind to with one click — a feature that exists nowhere in upstream Git or in most GUI clients. - **Custom rebase engine, not libgit2's.** GitUpKit only uses a *minimal* subset of libgit2 (via a customized fork at `git-up/libgit2`) and "reimplements everything else on top of it, including its own rebase engine." That is why history rewrites stay interactive even on multi-thousand-commit repos where other clients freeze the UI. - **Distinct from peers.** Tower and Fork lean on libgit2 end-to-end; Sourcetree wraps system Git in a heavyweight UI; GitKraken ships a cross-platform Electron shell. GitUp is single-platform, single-process, and AppKit-native, which is the trade-off that buys the responsiveness. ## How it works The codebase is split cleanly in two. `GitUp/` is the macOS app shell — `AppDelegate.m` boots Sparkle, registers a custom `DocumentController`, opens repos through `GCLiveRepository alloc initWithExistingLocalRepository:` and pushes every document into a Map / Commit / Stashes window mode. `GitUpKit/` is the reusable framework, itself two sub-layers: `Core/` (Foundation-only, OS X + iOS compatible) holds the Git abstractions, and `Interface/`, `Views/`, `Components/`, and `Utilities/` add the AppKit-specific UI on top. The performance story comes from `GCLiveRepository`. Rather than polling the on-disk repo, it exposes a `GCLiveRepositoryDelegate` protocol with `repositoryDidUpdateState / History / Stashes / Status / Snapshots / Search` callbacks plus matching `GCLiveRepository…DidUpdateNotification` posts, and runs the heavy reads on background queues so the main thread keeps drawing the map. `Document.m` wires those notifications straight into KVO/toolbar state and re-uses the same `XCTest`-backed fakes used by GitUpKit's own unit tests. Search is also in-process: `prepareSearchInBackground:withProgressHandler:completion:` indexes the working tree off the main thread and exposes `findCommitsMatching:` for instant results. Repository access itself is bespoke. `GCRepository` is a wrapper over the minimal libgit2 surface; `GCRepository+Reset`, `+HEAD`, `+Status`, `+Reflog`, `+Config`, `+Bare` are Objective-C categories that implement everything libgit2 does not — and `GCLiveRepository` adds a *new* `GCRepository` instance inside `performOperationInBackgroundWithReason:` so a backgrounded clone or submodule init does not block the foreground observer. The `DEBUG` preprocessor flag enables extra consistency checks; the README explicitly warns this "can significantly affect performance," which is the visible reason Debug builds feel sluggish and Release builds feel instant. ## Caveats - **macOS-only.** The UI layer depends on AppKit. There is no iPad or iPhone build of GitUp itself; the `iGit` example in `Examples/` shows what a port looks like, and the iOS-compatibility stops at the Foundation-only Base Layer. - **GitUpKit is not a published framework.** It is `git submodule`-vendored alongside the app and is not packaged for CocoaPods, SwiftPM, or Homebrew. The `Examples/` directory (GitDown, GitDiff, GitY, iGit) is the only documented way to build against it, and they all need the GitUpKit Xcode project open. - **GPL v3 only.** Any app that links GitUpKit inherits the GPL terms, which is why almost every third-party user is a personal tool rather than a closed-source commercial client. - **Unmaintained-looking cadence.** The repo shows 1–13 commits per month in 2026 with 369 open issues and only 2 open PRs, so bug fixes for new macOS releases can lag. ## Deployment notes **Install the binary:** download the latest `GitUp.zip` from the [Releases page](https://github.com/git-up/GitUp/releases) (the current stable is the v1.5.0 "Tahoe Release") and drag `GitUp.app` into `/Applications`. A community-maintained Homebrew cask is also available: `brew install --cask gitup`. **Build from source:** ```bash git clone --recursive https://github.com/git-up/GitUp.git cd GitUp open GitUp/GitUp.xcodeproj ``` Xcode is required. If you do not have a paid Apple Developer team, delete the "Code Signing Identity" build setting on the `Application` target, or drop a `DEVELOPMENT_TEAM.xcconfig` into `Xcode-Configurations/`. The first launch will offer to install a `/usr/local/bin/gitup` shim so you can open repos from the terminal with `gitup .` or `gitup map /path/to/repo`. **Integration tip:** if you maintain a Grove-style directory like this one, link GitUp as the canonical example of a single-process native macOS tool whenever you explain the trade-off between shipping a cross-platform Electron shell (GitKraken) and squeezing every last millisecond out of one platform with a custom Git library. ### Habo Habo is a Flutter-based, privacy-first habit tracker for iOS and Android that keeps every habit, note, and streak on-device by default and only syncs through an end-to-end encrypted Supabase backend. - slug: habo - category: productivity - stack: flutter - stars: 1500 - license: GPL-3.0 - repo: https://github.com/xpavle00/Habo - url: https://openappscout.com/apps/habo - lastCommit: 2026-06-15 - added: 2026-08-11 #### Detail # Habo Habo is a minimalist, privacy-first habit tracker for iOS and Android built in Flutter by a single maintainer. It stores habits locally in SQLite by default, requires no account to use, and only reaches the network when the user opts in to Habo Sync — a zero-knowledge layer that runs on top of any Supabase project, including one you host yourself. ## Why it matters - **Zero-knowledge sync, not just "encrypted in transit."** Habo derives a 256-bit key from the user's Master Password using Argon2id (19 MB, 2 iterations) and encrypts every record with AES-GCM 256 before it ever leaves the device; the Supabase backend only ever sees ciphertext and metadata. The encryption code lives in a dedicated `EncryptionService` that wraps the `cryptography` and `flutter_secure_storage` packages and is small enough to audit. - **A real habit model, not a checklist.** Habits carry Atomic-Habits-style fields (`cue`, `routine`, `reward`, `sanction`, `accountant`) plus a `twoDayRule` toggle. Day entries are typed (`clear`, `check`, `fail`, `skip`, `progress`), so a "skip" can break a streak but a "fail" preserves the history — and numeric habits track a target, a partial value, and a unit for things like "drink 2 L of water." - **Self-hostable without forking.** The `supabase/` directory ships migrations and a `delete-account` edge function; pointing Habo at your own Supabase project is a `npx supabase link && npx supabase db push && npx supabase functions deploy` away. The hosted sync tier uses RevenueCat under the entitlement `Habo Sync`, but flipping the self-hosted toggle short-circuits the paywall. - **Cross-platform polish.** The same Flutter codebase targets iOS, Android, macOS, Linux, and a 170×170 home-screen widget that renders today's completion progress as a circular painter. Themes ship in five flavors — device, light, dark, OLED, and Material You — and the app supports biometrics via `local_auth`. ## How it works The app boots in `main.dart`, which loads `.env` secrets, restores any custom Supabase URL/anon key from `SharedPreferences`, then hands off to a `ServiceLocator` that wires the SQLite repositories, the notification service, and the sync stack. The repository layer is deliberately split: abstract `HabitRepository`, `EventRepository`, `CategoryRepository`, and `BackupRepository` interfaces in `repositories/` are implemented by the corresponding `sqlite_*_repository.dart` classes, so the persistence backend is swappable. The UI is built around a single `HabitsManager` provider. It owns the in-memory `SplayTreeMap` of events per habit and recomputes streaks on every check-in. The home screen (`habits_screen.dart`) draws a `table_calendar`-based grid per habit, an inline `InButton` / `OneDayButton` for logging, and a `SyncStatusIndicator` that listens to `SyncStatus` enum changes emitted by `SyncManager`. When sync is enabled, `SyncManager` (a `WidgetsBindingObserver`) pushes deltas when the app backgrounds and pulls when it foregrounds, with a debounce timer to coalesce rapid edits. The Master Password screen, account password screen, delete-account screen, and email verification view all live under `lib/screens/` and feed into the same `SyncService`. Translations are generated from the 20+ `.arb` files in `lib/l10n/` via `flutter_intl`, and the community contributes new locales through Weblate rather than GitHub PRs. ## Caveats - **One-person project.** Habo is maintained solo by Peter Pavlenko; a broken release or stalled roadmap has no fallback maintainer, so self-hosters should track upstream closely. - **Sync is opt-in but paywalled.** The free app fully works offline; cross-device sync needs either the "Habo Sync" subscription (RevenueCat) or the effort to stand up your own Supabase project, apply migrations, and deploy the edge function. There is no peer-to-peer or LAN-only sync. - **Mobile-only by design.** Although the `linux/` and `macos/` Flutter folders ship, the UX is centered on a phone habit loop — no web build, no desktop polish, and no tablet-specific layouts. - **License is GPL-3.0.** Acceptable for personal use; any commercial fork has to publish its modifications. ## Deployment notes ```bash git clone https://github.com/xpavle00/Habo.git cd Habo flutter pub get flutter run # mobile / desktop ``` For the self-hosted sync backend: ```bash cd supabase npx supabase link --project-ref npx supabase db push npx supabase functions deploy delete-account ``` Then in the app open **Settings → Server**, paste your Supabase URL and anon key, and tap **Test Connection & Save**. Pre-built binaries are available on Google Play, the App Store, and IzzyOnDroid; the F-Droid listing is community-maintained. **Integration tip:** if you curate a Grove-style directory like this one, Habo is the canonical example for any record tagged `habit-tracker` *or* `e2e-encryption` — the encryption service is small enough to read in a sitting, and the Supabase migration set is a clean template for "optional sync" in other self-hostable apps. ### Hacki A clean Hacker News reader for iOS, with offline support and custom themes. - slug: hacki - category: news - stack: flutter - stars: 1616 - license: GPL-3.0 - repo: https://github.com/Livinglist/Hacki - url: https://openappscout.com/apps/hacki - lastCommit: 2026-09-03 - added: 2026-06-07 ### Harbour Docker/Portainer management app for iOS, iPadOS and macOS. - slug: harbour - category: productivity - stack: ios - stars: 760 - license: AGPL-3.0 - repo: https://github.com/rrroyal/Harbour - url: https://openappscout.com/apps/harbour - lastCommit: 2026-07-23 - added: 2026-06-13 ### Helm Helm is a macOS system toolkit that puts fifteen maintenance and monitoring tools behind one window and one menu-bar item, covering storage, hardware metrics, and clipboard history. - slug: helm - category: tools - stack: flutter - stars: 0 - license: MIT - repo: https://github.com/devShakib015/helm - homepage: https://devshakib.jumyn.com/apps/helm - url: https://openappscout.com/apps/helm - lastCommit: 2026-09-02 - added: 2026-09-01 #### Detail # Helm Helm is a macOS toolkit that collects fifteen system tools behind one window and one menu-bar item. It is MIT licensed, built with Flutter, and makes no network calls. ## What the codebase includes - Monitors for memory, CPU, GPU, sensors, battery, and network, each keeping 24 hours of history as a chart rather than only a live reading. - A process manager attached to the CPU page, real SMC temperature reading on the sensors page, and battery levels for connected accessories such as AirPods and Magic Keyboards. - A storage suite: a disk overview that accounts for purgeable space, a disjoint category breakdown, a squarified treemap explorer with breadcrumb drill-down, a junk cleaner, a large-and-old file finder, a byte-for-byte duplicate finder, and APFS snapshot thinning. - An app uninstaller that removes leftovers, startup-item management, and a privacy tool. - Clipboard history with a global quick-paste popup handling text, images, and file copies, plus a colour picker, a keep-awake toggle, and quick actions. - A configurable live menu-bar item, per-metric alert thresholds, and a login-item watchdog that reports when an app adds itself to startup. ## Why it is useful to study Reading genuine macOS system state from a Flutter app is the substance here. Purgeable disk space, SMC sensor temperatures, APFS snapshots, and accessory battery levels each need platform work that a cross-platform UI framework does not provide, and the repository shows one way to wire that up while keeping a single design language across fifteen surfaces. The storage tooling is more complete than most open-source equivalents. The category breakdown is built to be disjoint so the totals reconcile with About This Mac instead of contradicting it, junk cleaning pre-selects only the safe categories and leaves the risky ones opt-in, and the duplicate finder compares byte-for-byte and always keeps one copy. ## Safety model Removal goes to the Trash rather than deleting in place, so anything the app clears can be recovered. Emptying the Trash is the single destructive action and is confirmed explicitly. ## Caveats macOS 10.15 or later, universal for Apple Silicon and Intel. There is no Windows or Linux target and the app is not portable to one, since most of its value comes from macOS-specific system access. Depending on SMC sensors and storage internals means the app tracks details that Apple can change between macOS releases, so some readings need maintenance over time. ### HorizonCalendar HorizonCalendar is Airbnb's declarative, performant iOS calendar UI framework that renders month and week views from a single content value type, scaling from simple date pickers up to fully featured calendar apps on virtually infinite date ranges. - slug: horizoncalendar - category: productivity - stack: ios - stars: 3158 - license: Apache-2.0 - repo: https://github.com/airbnb/HorizonCalendar - url: https://openappscout.com/apps/horizoncalendar - lastCommit: 2026-08-12 - added: 2026-06-13 #### Detail # HorizonCalendar HorizonCalendar is Airbnb's declarative iOS calendar UI library — a `UIView` subclass whose visible state is a pure function of a single `CalendarViewContent` value type, much like a SwiftUI view is a function of its state. It renders month and week layouts, supports single-day and multi-day range selection, and was built to power every date picker and full-screen calendar inside the Airbnb iOS app. ## Why it matters - **Pioneered the declarative calendar pattern on iOS.** Where most date pickers of its era were imperative (`UICollectionViewDataSource` plus ad-hoc layout code), HorizonCalendar inverted the model: you describe *what* the calendar should show by composing `CalendarViewContent` and its provider closures, and the view diffs and animates to match. That same shape — single value type, render-as-pure-function — is the same conceptual move SwiftUI made for view trees in general, and HorizonCalendar got there first for calendars specifically. - **Scales to virtually infinite date ranges.** The library is documented to cover roughly 100,000 years of dates with constant memory and scroll performance. That comes from a custom layout engine (not `UICollectionView`) that lays out only what is visible, anchors new frames to previously laid-out items, and gives its internal `UIScrollView` a very large content size with content insets aligned to the boundary month as you approach the ends. - **Airbnb origin, now in maintenance mode.** HorizonCalendar shipped out of Airbnb's mobile team and was maintained for years by Bryan Keller and Bryn Bodayle. The last meaningful release was v2.0.0 in late 2023; commits since then are mostly CI and compatibility fixes (iOS 26 hit-testing, accessibility crash guard). Airbnb has publicly scaled back its open-source iOS work, so adopt cautiously for new production code. ## How it works The model/view split is the load-bearing idea. `CalendarView` is a `UIView` subclass (not a `UIViewController` and not built on `UICollectionView`); its only job is to take a `CalendarViewContent` and turn it into visible, scrollable months or weeks. You update the view by calling `setContent(_:)` or the `animated:` variant — there is no `reloadData`, no data-source protocol. `CalendarViewContent` is a value type that bundles the date range, the layout direction (`.vertical` or `.horizontal`), the calendar, and a set of provider closures: - `dayItemProvider` returns a `CalendarItem` for each individual day. - `dayRangeItemProvider` returns a different `CalendarItem` for a day that belongs to a selected range. - `monthHeaderItemProvider`, `dayOfWeekItemProvider`, `monthBackgroundItemProvider`, `overlayItemProvider` round out the hookable slots. A `CalendarItem` is a model-and-view pair: it conforms to `CalendarItemViewRepresentable`, which requires an `InvariantViewProperties` type (set once per view, e.g. font and color) and a `Content` type (the per-date payload), plus `static makeView(withInvariantViewProperties:)` and `static setContent(_:on:)`. The view pool reuses views by type and hash of the invariant properties, then calls `setContent` to refresh the per-day payload. SwiftUI views skip the boilerplate via `.calendarItemModel`. Layout is incremental and anchored. On each layout pass, `VisibleItemsProvider` walks outward from a known visible item using a `LayoutItemTypeEnumerator` and asks a `FrameProvider` for each frame, short-circuiting with known offsets (e.g. a day's frame is the previous day's frame plus its width). `ItemViewReuseManager` diffs the new `Set` against the previous set, decides which views to reuse, and the view calls `setContent` on each. The internal scroll view is given a very large content size; when the first or last month approaches a boundary, content insets are re-aligned to make those edges feel natural. Multi-day range selection uses a long-press-then-pan gesture. `multiDaySelectionLongPressGestureRecognizer` starts the interaction, `multiDaySelectionPanGestureRecognizer` fires the `multiDaySelectionDragHandler` callback with each day crossed, and a `CADisplayLink` auto-scrolls when the drag approaches a viewport edge so more days can be selected. The library deliberately does *not* own the selection state — your handler converts the `DayComponents` into your model, regenerates `CalendarViewContent` with `dayRangeItemProvider` set for the chosen range, and calls `setContent` to reflect it visually. ## Caveats - **Maintenance status.** Last meaningful release was v2.0.0 in December 2023; commits since then are sparse compatibility work. For a long-lived production app, treat it as a stable-but-frozen dependency: pin to a known version, vendor a fork if you need to patch iOS 26+ regressions, and budget for the possibility that no one will land your PR. - **API has been stable since v1.0.** The provider-closure model has not been broken by the v2 release, so code written against the original docs still compiles, but the `UIKit` core is the API — there is no first-class SwiftUI `CalendarView` you can drop into a SwiftUI hierarchy the way you would a `List`. The `CalendarViewRepresentable` shim works but is a thin wrapper. - **DisplayLink-driven animations break some accessibility tests.** The library uses `CADisplayLink` for its auto-scroll-while-dragging animation; that path can crash under UI test runners. Set the environment variable `HORIZON_CALENDAR_DISABLE_DISPLAY_LINK=true` to short-circuit it during automated UI tests. ## Deployment notes Add the package via Swift Package Manager: ```swift .package( name: "HorizonCalendar", url: "https://github.com/airbnb/HorizonCalendar.git", from: "1.0.0" ) ``` CocoaPods (`pod 'HorizonCalendar'`) and Carthage (`github "airbnb/HorizonCalendar"`) are still documented in the README for projects on those managers, but SPM is the path the maintainers point new users at. The deployment target is **iOS 11.0+**, Swift 5+, Xcode 10.2+ — old enough that you can drop it into a long-supported app without raising your minimum. For a working playground, clone the repo and open `Example/HorizonCalendarExample.xcworkspace` (not the `.xcodeproj`). The example covers single-day selection, day-range selection, selected-day tooltips, and scroll-to-day-with-animation, in both vertical and horizontal layouts. The SwiftUI path lives alongside the UIKit demos in the same workspace. **Integration tip:** even if you do not ship HorizonCalendar to production, the repo is one of the cleanest public examples of the "view is a pure function of a content value type" pattern in UIKit. Read `Sources/Public/CalendarView.swift` and `Docs/TECHNICAL_DETAILS.md` before you design your own data-driven UIKit component — the visible-item / frame-provider / view-reuse split generalizes well beyond calendars. ### IceCubesApp IceCubesApp is a SwiftUI-native, multi-platform Mastodon client for iOS, iPadOS, macOS, and visionOS, built and maintained primarily by a single developer (Dimillian). - slug: icecubesapp - category: social-network - stack: ios - stars: 7053 - license: AGPL-3.0 - repo: https://github.com/Dimillian/IceCubesApp - url: https://openappscout.com/apps/icecubesapp - lastCommit: 2026-08-31 - added: 2026-06-13 #### Detail # IceCubesApp IceCubesApp is a SwiftUI-native Mastodon client that ships to iPhone, iPad, Mac, and Apple Vision Pro from a single Swift-package workspace. It is built and maintained almost entirely by one developer (Thomas "Dimillian" Ricouard) and has become a reference SwiftUI codebase for the fediverse community. ## Why it matters - **Pure SwiftUI, no UIKit escape hatches.** The whole UI is written in declarative SwiftUI using `@Observable`, environment objects, `safeAreaBar`, `ToolbarSpacer`, and modern concurrency primitives. Reading `TimelineView.swift` is the closest thing the Apple ecosystem has to an idiomatic SwiftUI reference implementation, and Dimillian regularly publishes teardowns that double as a learning resource. - **One codebase, four Apple platforms.** The same Swift packages produce builds for iOS 18+, iPadOS 18+, macOS, and visionOS 1+, with a dedicated sidebar UI on iPad and Mac. The multi-platform targets share the network, model, and design-system packages verbatim, so feature parity is the default rather than a porting exercise. - **A real single-maintainer story.** With ~7k GitHub stars, ~150 contributors on paper, but the bulk of recent commits and release work going through Dimillian, IceCubesApp is a useful counterpoint to the corporate-backed Ivory (Tapestry) and the official Mastodon-iOS: it shows what one SwiftUI-native developer can ship when the API is small and the platform APIs are coherent. ## How it works The repository is a multi-target Xcode workspace plus a `Packages/` directory of local Swift packages. `Models`, `DesignSystem`, `Env`, `NetworkClient`, `Timeline`, `StatusKit`, `Conversations`, `Notifications`, `Account`, `Lists`, `Explore`, `MediaUI`, and `AppAccount` each own a slice of the app, and the main `IceCubesApp/` target plus extensions (Action, Share, Widgets, Intents, Notifications) consume them as libraries. Networking lives in `Packages/NetworkClient`. `MastodonClient` is an `@Observable` class built on plain `URLSession` — no third-party HTTP library — with a `JSONDecoder` configured for snake_case conversion. Endpoints are organized into small, focused files under `Endpoint/` (Accounts, Statuses, Timelines, Notifications, Streaming, Oauth, Push, Polls, Tags, etc.), each conforming to an `Endpoint` protocol that exposes the path, method, and `queryItems`. Auth is standard Mastodon OAuth via Apple's `WebAuthenticationSession`, with tokens stored in the Keychain and attached as `Bearer` headers (or as a WebSocket subprotocol for streaming). Mutable client state is guarded by `OSAllocatedUnfairLock`, which keeps the class provably `Sendable` under Swift 6's strict concurrency mode. Timeline rendering goes through `TimelineView` (in `Packages/Timeline`), which binds to a `TimelineFilter`, drives a `TimelineViewModel`, and observes a `StreamWatcher` for live updates. Pull-to-refresh fires haptics and a sound, the streaming toggle opens a long-lived `URLSessionWebSocketTask`, and a Bodega-backed SQLite cache restores the last read position across account switches. Media uploads use multipart `URLSession` tasks with an `UploadProgressDelegate` for progress callbacks. ## Caveats - **Single-maintainer bus factor.** Release cadence and issue triage are dominated by Dimillian. The monthly commit counts in the GitHub sync data show stretches of zero activity — perfectly normal for a one-person project, but worth flagging if you intend to depend on a specific feature landing. - **App Store politics.** Third-party Mastodon clients have been repeatedly threatened or rejected by Apple's review (Ivory was famously removed and reinstated). IceCubesApp has weathered the same scrutiny; TestFlight betas come and go, and the shipping App Store build can lag behind `main` by weeks when Apple pushes back on a release. - **SwiftUI on visionOS is still rough.** The visionOS target works but leans on iOS-style layouts that have not been deeply rethought for spatial computing; floating windows, immersive spaces, and eye-tracking interactions are not first-class. ## Deployment notes There is no public TestFlight link at the time of writing — Dimillian runs closed betas announced on the project's GitHub Discussions and Mastodon account. The shipping build is on the App Store at [`apps.apple.com/us/app/ice-cubes-for-mastodon/id6444915884`](https://apps.apple.com/us/app/ice-cubes-for-mastodon/id6444915884). To build from source you need Xcode 16+ and an Apple Developer account: ```bash git clone https://github.com/Dimillian/IceCubesApp.git cd IceCubesApp cp IceCubesApp.xcconfig.template IceCubesApp.xcconfig # fill in DEVELOPMENT_TEAM and BUNDLE_ID_PREFIX open IceCubesApp.xcodeproj ``` The template xcconfig is the only piece you need to edit; the project then resolves the local `Packages/` automatically. Sideloading onto your own device works with a free or paid Apple ID by setting the target signing team to your personal team and disabling Push Notifications / App Groups (those require a real Developer Program enrollment). **Integration tip:** if you operate a directory or review site that categorises open-source Apple apps, treat IceCubesApp as the canonical "SwiftUI-native, multi-platform" reference next to the more UIKit-flavored Ivory (Tapestry) and the official Mastodon-iOS client. ### Immich Self-hosted photo and video backup solution directly from your mobile phone - slug: immich - category: tools - stack: flutter - stars: 113341 - license: AGPL-3.0 - repo: https://github.com/immich-app/immich - url: https://openappscout.com/apps/immich - lastCommit: 2026-09-03 - added: 2026-06-07 #### Detail # Immich Immich is a self-hosted photo and video backup service that runs on your own hardware and ships native iOS and Android apps written in Flutter. It does on-device-class machine learning on the server — face recognition, CLIP-based natural-language search, OCR, duplicate detection — without sending your library to anyone. The result feels close to Google Photos while keeping your data on a disk you control, under an AGPL-3.0 license that the maintainers deliberately cannot relicense more permissively. ![Immich timeline view — grouped photos with date rail](/images/immich/timeline.png) *Immich's timeline view, the closest implementation of Google Photos' grouped-by-date UX outside of Google itself.* ## From a side project to a Google-Photos-shaped standard Immich is the rare self-hosted app whose UX compares favorably to its commercial counterparts. Browse the timeline, the photos you took last summer are in the right place. Search for "beach," you get the beach photos, not the ones tagged `#beach` in a folder hierarchy. The reason it feels this way is the same reason it took seven years to ship: the maintainers built a system rather than a front end. The architecture has three moving parts. The server is a **NestJS** application in TypeScript that owns the REST API, the WebSocket layer, and the metadata database. The mobile clients are a single **Flutter** codebase covering iOS, Android, and the F-Droid build. The machine-learning work — face detection, face embeddings, CLIP search, OCR — lives in a **Python FastAPI** microservice that talks to the server over HTTP. None of these are optional: removing the Python service turns Immich into a less interesting photo sync tool. What makes the ML split interesting is the **ONNX-only** inference stack. The team does not depend on PyTorch; they ship the **ONNX Runtime** with backend flavors for CUDA, ROCm, OpenVINO, ArmNN, and RKNN. Choosing which hardware accelerator you want is a Docker image tag. A household with an Intel iGPU and a family with an NVIDIA RTX card run the same code with a different image name. The Python service caches models in memory, runs ONNX directly, and exposes a stable HTTP contract. The **vector search** path is equally deliberate. v3.0 migrated from `pgvecto.rs` to a custom **Postgres 14 build with VectorChord** baked in. The trade is operational — you run a forked Postgres image — but the upside is that vector search is just a column in the same database, not a separate service to deploy. The philosophy is: one operational database, not three. ## The license was the point In February 2024 the project moved from MIT to **AGPL-3.0**. The accompanying discussion on GitHub is unusual in that the maintainers explicitly justified *not* adopting a Contributor License Agreement. Their reasoning: without a CLA, no future acquirer or hostile fork can relicense the codebase. The community response on Hacker News and r/selfhosted was overwhelmingly positive — people who self-host care about this more than they care about a permissive license, and the AGPL's "network use is distribution" clause is exactly the protection they want. The decision has a cost. Any company that wants to ship a hosted fork of Immich must either publish its modifications under AGPL or stay on the last MIT release (v1.118.x) and lose new features. That's the intended outcome. The team's commercial path is support contracts and a partnership with **FUTO** for a managed backup service announced in v2.7.0 — not a SaaS fork of the open-source code. ## What the architecture is not Immich has chosen to be a few things well and to admit what it is not. The `UPLOAD_LOCATION` is a filesystem bind mount; **there is no native S3 backend**. This is a real limitation if you want to back up to Backblaze B2 or Cloudflare R2 — every "Immich on the cloud" thread rehashes it. **External libraries are single-owner** — a family of four cannot pool their phone libraries into a single shared library the way Apple Family Sharing works. Shared albums do not show up in face recognition or full-text search. There is **no encryption at rest**; the upload directory is plain files. These are not bugs. They are product decisions the team has not yet made. The **ML pipeline is fragile in ways that matter**. An OCR memory leak in v2.2.0 ballooned the container to 12 GB RAM on certain models; an OpenVINO regression in v2.5.2 broke Intel hardware acceleration. Both were eventually fixed, but the pattern is clear: a young ML pipeline shipped under aggressive release cadence will have rough edges. Running multiple minor versions behind the latest is a common survival tactic for self-hosters. ## Security has matured in public The **GitHub Security tab** for Immich has 10 published advisories in 2026 alone, including a critical one-click XSS-to-account-takeover (GHSA-8244-8vpr-vp9c, June 2026) and an API key privilege-escalation bug (GHSA-237r-x578-h5mv, January 2026). The pattern is familiar for a fast-moving app: access-control and OAuth bugs surface as the codebase grows. What matters is the response, and the response has been on a normal disclosure cadence with patches released alongside. ## Where Immich is the best choice - A family or individual leaving Google Photos, willing to spend $300–$800 on a mini PC or used enterprise desktop, with at least 2 CPU cores and 8 GB RAM. - A user who values face recognition and natural-language search and is willing to keep the ML container healthy. - A tinkerer who wants the same code to run on a Raspberry Pi 5 (slow but functional) and on a Synology (recommended, with QuickSync transcoding). ## Where Immich is not the right choice - A small business with 50 users and admin needs the project has not invested in. Use **Ente** if E2EE is the headline feature, **PhotoPrism** if you have an existing library and want best-in-class AI, or **Nextcloud Memories** if you are already on Nextcloud. - A user who needs S3-backed storage, encryption at rest, or multi-owner external libraries. - A user unwilling to keep up with monthly migrations. The 0.5.x → v2.0 → v3.0 transitions each required manual database steps. ## Deployment notes The reference install is `docker compose up -d` against the official `docker/docker-compose.yml`. Five containers: `immich-server` (port 2283), `immich-machine-learning` (CPU by default; tag-swap for GPU), `redis` (actually **Valkey**), `database` (the custom VectorChord Postgres), and `immich-microservices`. Hardware-accelerated transcoding is a separate `hwaccel.transcoding.yml` override. Maintainers recommend 6 GB RAM minimum, 8 GB recommended, with a recent x86-64-v2 CPU; the ML container can take another 2–3 GB RAM when the CLIP model is loaded. Backups are two-part: a `DatabaseBackup` job that writes a `pg_dump` to `BACKUP_LOCATION`, and a separate backup of the `${UPLOAD_LOCATION}` tree. Restoring is the reverse: put the upload tree back, restore the SQL dump, restart. The two halves are independent — the database is metadata, the tree is the bytes — and you must back up both. ## Developer lessons worth borrowing - **The HTTP boundary between server and ML service is the right call.** It buys you GPU isolation, independent scaling, and a clean second-language boundary. For projects that need ML inference alongside a web app, this is the architecture to study. - **ONNX-only inference is a "freedom of hardware" decision.** More work than just using PyTorch, but it makes the same code run on CUDA, ROCm, OpenVINO, ArmNN, and RKNN. - **Hexagonal architecture in the server** (`src/repositories/` vs `src/services/`) makes swapping storage backends, ML clients, and queue implementations a matter of interface changes. - **Custom Postgres builds are not as scary as they sound.** VectorChord was a deliberate "one operational database" choice; the maintenance cost is small relative to running a separate vector store. ## How Immich compares The honest self-hosted photo space in 2026 has four credible answers. Each makes a different trade-off; none is "better" in the abstract. | Project | License | E2EE | ML pipeline | Storage backend | Multi-user | Best for | |---|---|---|---|---|---|---| | **Immich** | AGPL-3.0 | No (TLS in transit only) | ONNX Runtime; CLIP + face + OCR + duplicates | Filesystem bind mount (no native S3) | Yes (self-hosted multi-user) | The closest Google Photos equivalent for a single user or family that already runs Docker | | **PhotoPrism** | AGPL-3.0 | No | TensorFlow-based (older, slower path for image classification) | Local filesystem + optional S3 | Yes (Community edition in 2024 altered the license) | A large existing library that needs ingestion and fast browsing; favorites tagging | | **Ente** | AGPL-3.0 + source-available | **Yes** (XChaCha20-Poly1305, libsodium) | On-device in the mobile client; server-side enrichment is optional | S3-compatible (Ente Cloud or self-host) | Yes (paid plan required for self-host multi-user) | Users who want true E2EE before the bytes leave the phone | | **Nextcloud Memories** | AGPL-3.0 (Nextcloud) | Whatever Nextcloud provides (server-side encryption with E2EE in Nextcloud 29+) | Optional via the `recognize` app | Nextcloud primary storage | Yes (Nextcloud users) | People already running Nextcloud for files/calendar and who want photos bolted on | | **Lychee** | MIT | No | None | Local filesystem or S3 | No (single-user) | The simplest possible photo dump — a Slick carousel viewer, no ML, no timeline curation | **Pick Immich** if face recognition, CLIP search, and a polished timeline are the headline features and a small Docker compose stack is acceptable. **Pick PhotoPrism** if you have hundreds of thousands of existing photos to import, you care about EXIF and favorites, and you do not need E2EE. **Pick Ente** if the *only* thing that matters is end-to-end encryption and you are willing to fund either a subscription or a self-host fee. **Pick Nextcloud Memories** if Nextcloud is already the substrate for your files. The memories app is feature-light compared to Immich but inherits Nextcloud's sharing, mobile sync, and admin model. **Pick Lychee** if you want a photo gallery, not a photo *manager*. No ML, no multi-user, no maintenance burden; just a clean web UI for a folder of images. ## Verified sources - Immich GitHub repository: - VectorChord / vector search migration tracking (server README, servers image). - Security advisories: Immich GitHub Security tab — 10 published advisories in 2026, including GHSA-8244-8vpr-vp9c (XSS-to-account-takeover, June 2026) and GHSA-237r-x578-h5mv (API key privilege escalation, January 2026). - License relicensing discussion, February 2024 — GitHub issue thread and r/selfhosted / Hacker News follow-ups. - PhotoPrism community edition license change, January 2024 — see PhotoPrism's "Our Journey" blog post. - Ente architecture and E2EE design — Ente's open-source documentation at . - Nextcloud Memories app — Nextcloud App Store listing. - Lychee maintainer docs — . ### Invoice Ninja Companion app for the Invoice Ninja platform. Invoicing, expenses, time-billing, payments. - slug: invoice-ninja - category: business - stack: flutter - stars: 1753 - license: NOASSERTION - repo: https://github.com/invoiceninja/flutter-mobile - homepage: https://invoiceninja.com/ - url: https://openappscout.com/apps/invoice-ninja - lastCommit: 2026-08-21 - added: 2026-06-06 ### ish A Linux shell environment running on iOS, useful for command-line work on mobile devices. - slug: ish - category: productivity - stack: ios - stars: 20403 - license: NOASSERTION - repo: https://github.com/ish-app/ish - url: https://openappscout.com/apps/ish - lastCommit: 2026-08-22 - added: 2026-06-13 ### Joplin Joplin is a free, open source note taking and to-do application. The mobile client is built with React Native and supports full sync via Nextcloud, Dropbox, OneDrive, WebDAV, and Joplin Cloud. - slug: joplin - category: productivity - stack: react-native - stars: 56227 - license: NOASSERTION - repo: https://github.com/laurent22/joplin - url: https://openappscout.com/apps/joplin - lastCommit: 2026-09-03 - added: 2026-06-07 #### Detail # Joplin Joplin is a free, open-source, cross-platform note-taking and to-do app that stores your notes as plain Markdown files, syncs them to a target of your choice, and supports end-to-end encryption on top of any sync backend. The desktop client is Electron + React; the mobile apps are React Native; the self-hostable server is Node.js. The project has been maintained for nearly a decade by a small lead-contributor team, with a public warrant canary, a stable plugin API, and a real cross-platform feature surface. ![Joplin desktop client — Markdown editor with renderer split-pane](/images/joplin/editor.png) *Joplin's desktop client: a Markdown editor on the left, the rendered preview on the right. The same data renders identically on iOS, Android, and the web client.* ## Plain Markdown is the product Joplin's most important design decision is also the least visible: a note is a row in SQLite with a Markdown body and a `body_html` column. Attachments are separate `Resource` rows on disk. The `.jex` export format is a tar of the same data, lossless, with geolocation, updated time, and tags preserved. This is not a quirky data-model choice — it is the reason the project has survived nine years. Your notes are always plain text on disk, in a portable container, readable by anything that can read Markdown. If Joplin disappeared tomorrow, your library would still be readable in any text editor. The trade is real. The same plain-Markdown principle means the in-app editor is a Markdown editor with WYSIWYG sugar, not a Notion-style block editor. Joplin supports the standard Markdown extensions (KaTeX, Mermaid, code blocks, footnotes, TOC, deflists, ABC notation, Fountain) and a small whiteboard fence, but it does not have a database view layer. People who want AppFlowy-shaped databases should use AppFlowy; people who want durable Markdown files should use Joplin. ## Sync is genuinely multi-target, and E2EE is genuinely optional Joplin's sync model is the most flexible in the open-source notes space. The supported targets are **Joplin Cloud**, **Joplin Server** (self-hostable), **Nextcloud** (via WebDAV), **WebDAV** (Apache, Nginx, DriveHQ, Fastmail, HiDrive, InfiniCLOUD, Mailbox.org, OwnCloud, Seafile, Stack, Synology, WebDAV Nav, Zimbra, Infomaniak kDrive), **Dropbox**, **OneDrive**, **local filesystem**, and **S3** (AWS, Backblaze, Cloudflare R2, DigitalOcean Spaces, Linode, Scaleway, UpCloud, Tebi — labeled Beta). E2EE is available on top of any of them. E2EE is **opt-in, not default**. A single master key (protected by your password) encrypts notes, notebooks, tags, and resources. **The password is unrecoverable** — both the docs and the maintainer are explicit. The setup must be done sequentially, one device at a time; enabling on multiple devices in parallel can produce multiple keys. This is the kind of design that gives end-to-end encryption its teeth, and it is the same design that produces the most common user complaint: "I forgot my master password and now my notes are unreadable." The Joplin Server license is the part of the project that is not what casual readers assume. The desktop and mobile clients are AGPL-3.0-or- later. The `packages/server/LICENSE.md` is a **proprietary "Joplin Server Personal Use License"** that forbids commercial hosting. The commercial path is **Joplin Server Business** at €30–€40/user/year, which includes source access, publishing, sharing, and priority support. ## Three editor backends over a shared renderer The most underappreciated piece of Joplin's architecture is the editor strategy. The desktop wrapper `NoteEditor.tsx` selects one of five implementations at runtime: **TinyMCE 6.8.5** (the default WYSIWYG), **CodeMirror 6** (the new Markdown view, with `@lezer/markdown` parser), **CodeMirror 5** (the legacy Markdown path, kept for users who set `editor.legacyMarkdown`), **PlainEditor** (the safe-mode fallback), and **Whiteboard** (a tldraw-style canvas behind a ` ```whiteboard ` fence). The mobile Rich Text Editor is a separate **ProseMirror** code path, introduced in Joplin 3.4 (September 2025), explicitly described as "behaving differently from the desktop Rich Text Editor in many cases." This is unusual and worth studying. Most apps pick one editor and live with its limitations. Joplin runs two rich-text editor code paths (TinyMCE on desktop, ProseMirror on mobile) plus two Markdown paths (CM5 legacy, CM6 new) over a shared `MarkupLanguage` and a shared `renderer` package. The cost is maintenance; the win is the right editor for each platform's UX expectations. ## A decade of one-maintainer stewardship Joplin is functionally maintained by **Laurent Cozic** (`laurent22`) with a small set of recurring contributors. The repo has 11,670,490 lines of TypeScript, 619 open issues, and 20 open PRs. A pinned issue from June 2026, **#15625 ("Pull requests from new contributors are temporarily paused")**, is an open admission of capacity constraints. The single-maintainer pattern is not inherently bad, but it works only if there is a clear funding path and a public commitment to succession. Joplin has the funding: Patreon, GitHub Sponsors, Liberapay, PayPal, IBAN, plus Joplin Cloud subscriptions and Joplin Server Business. The project has a public **warrant canary** updated every 60 days, signed with a published key (current statement date 2026-06-19, valid until 2026-08-18). The warrant canary is a legal-stance commitment, not a popularity signal, and it is rare in open-source notes. ## Where Joplin is the best choice - A user with an existing WebDAV, Nextcloud, or S3 setup who wants their notes encrypted on top of storage they already pay for. - A power user who wants plain-Markdown files they can grep, back up, and read in any text editor, with E2EE available when they want it. - A user who values the warrant canary and the open plugin API more than a polished mobile experience. - An org that wants Joplin Server Business and is willing to pay €30–€40/user/year for the multi-user features. ## Where Joplin is not the right choice - A user with a 50k-note library who lives on mobile. The Android and iOS apps are heavy and slow at scale; the maintainer has acknowledged this in the issue tracker. - A team that needs real-time multi-user editing in the way Notion or AppFlowy do it. Joplin's conflict resolution is "last write wins" with a conflict notebook — functional, not collaborative. - A user who wants a free, fully open-source self-hostable server. The Joplin Server license is proprietary; you can self-host for personal use, but commercial hosting requires a paid license. - A user who needs a database/block view layer. Joplin is a Markdown app, not a Notion competitor. ## Deployment notes The reference install is the `joplin/server:latest` Docker image on port 22300, with **SQLite by default** (PostgreSQL recommended for production). The `STORAGE_DRIVER` config can put item contents in the database, on the filesystem, or in S3. Reverse-proxy recipes for Apache and Nginx are in the server README. The most common production setup is Postgres + S3 + Nginx + a daily `pg_dump` + an S3 lifecycle policy. E2EE setup: enable it in one device first, set the master password, wait for the initial encryption sync to complete (this can be slow on large libraries — the docs suggest letting it run overnight). Then enable on the second device, enter the same password, and wait again. Do not enable on multiple devices in parallel. ## Developer lessons worth borrowing - **The plain-Markdown data model is the project.** Joplin has survived nine years and many corporate competitors because a note is a row with a Markdown body. Own the format you depend on. - **Sync over a file API driver is an anti-corruption layer.** The `file-api-driver-*` abstraction (one per sync target) is a textbook example of putting the messy real-world providers behind a clean interface. Every app that has more than one storage backend has had to learn this; Joplin is a good case study. - **Three editor backends over a shared renderer is allowed.** The cost is maintenance, the win is per-platform UX. - **A warrant canary is a feature.** Updating a signed statement every 60 days is a legal-stance commitment, not a popularity signal. Few open-source projects do it; Joplin does. - **The single-maintainer pattern works only with a public funding path and an honest capacity signal.** Joplin has both; the bus factor is real and acknowledged. ## How Joplin compares The "open notes" market in 2026 splits into two questions: what is the file format, and who can read your notes. Joplin's answer — plain Markdown files plus optional E2EE — is the most portable of the lot. | Project | License | File format | E2EE | Multi-target sync | Editor style | Best for | |---|---|---|---|---|---|---| | **Joplin** | AGPL-3.0 (client) + proprietary "Joplin Server Personal Use License" (server) | Plain Markdown + SQLite | Yes (opt-in, master key, irrecoverable) | Joplin Cloud, Joplin Server, Nextcloud, WebDAV, Dropbox, OneDrive, local FS, S3 (Beta) | WYSIWYG (TinyMCE) or Markdown (CodeMirror 5/6) | A user with an existing WebDAV / Nextcloud / S3 setup who wants encrypted notes on top of storage they already pay for | | **Obsidian** | Source-available (free for personal use) | Plain Markdown | N/A (local) | Local + optional paid Sync | Markdown-based | A single user who wants durable Markdown files and the plugin ecosystem | | **Logseq** | AGPL-3.0 | Plain Markdown / Org | N/A (local) | Local + optional paid Sync | Outliner + block editor | A knowledge worker who thinks in outliner and queries | | **Anytype** | Source-available (Any Source Available License 1.0) | Local-first (Anysync) | Yes (peer-to-peer) | Anytype Hub | Block editor | A user who wants E2EE + local-first + a growing collaboration story | | **Standard Notes** | AGPL-3.0 (server) + proprietary (some clients) | Encrypted backups | Yes (XChaCha20-Poly1305, Argon2id) | Standard Notes Cloud (paid) or self-hosted | Plain markdown, rich text via extensions | A user who wants durable E2EE on a free self-host stack | | **Notesnook** | AGPL-3.0 + source-available | Encrypted vault (monorepo) | Yes (XChaCha20-Poly1305, Argon2id, Vericrypt) | Notesnook Cloud (paid) or self-hosted | Rich text, markdown | A user who wants externally verifiable E2EE (Vericrypt) more than Markdown durability | | **Notion** | Closed-source SaaS | Proprietary | No | Notion Cloud | Block editor | A team that wants collaboration, not a personal note archive | **Pick Joplin** if you already have a sync target (WebDAV, Nextcloud, S3, Dropbox) and want your notes to be plain Markdown files on disk that you can still read in 10 years if Joplin disappears. **Pick Obsidian** if you only need single-device notes and want the deepest plugin ecosystem. Trade-off: no real sync story without paying. **Pick Logseq** if your note-taking is journal-style and you want outliner + queries. Trade-off: no mobile-first experience. **Pick Anytype** if E2EE + local-first is the headline feature and you can accept alpha-quality collaboration. **Pick Standard Notes** if you want a free self-hostable E2EE notes server and do not care about Markdown durability. **Pick Notesnook** if you want to be able to prove your E2EE claim to a third party (Vericrypt). The trade-off is an encrypted vault rather than plain Markdown files. **Pick Notion** if the real need is collaboration, not a personal note archive. ## Verified sources - Joplin repository: - Joplin Server license — `packages/server/LICENSE.md` (proprietary "Joplin Server Personal Use License" prohibiting commercial hosting). - Joplin Server Pricing — (€30–€40 per user per year for Business). - Joplin warrant canary — (current statement date 2026-06-19; valid until 2026-08-18). - Editor strategy — `NoteEditor.tsx` in the desktop client; mobile ProseMirror editor introduced in Joplin 3.4 (September 2025). - Comparison facts about other projects — drawn from each project's own published documentation; not affiliated reviews. ### Karakeep Karakeep is a self-hostable bookmark-everything application built on Next.js 16 + Hono + tRPC over Drizzle on SQLite with Meilisearch full-text and semantic search, capturing links, notes, images, and PDFs into a tagged personal archive with on-demand AI auto-tagging. - slug: karakeep - category: productivity - stack: react-native - stars: 28760 - license: AGPL-3.0 - repo: https://github.com/karakeep-app/karakeep - url: https://openappscout.com/apps/karakeep - lastCommit: 2026-08-31 - added: 2026-06-13 #### Detail # Karakeep Karakeep (formerly Hoarder) is a self-hostable "bookmark-everything" application that captures links, notes, images, and PDFs into a single tagged archive and runs AI tagging plus full-text and semantic search against the pile. It is a self-hosted Pocket/raindrop replacement purpose-built for power hoarders. ## Why it matters - **Capture is multi-front.** Karakeep ships a Next.js web client, a React Native mobile app on iOS and Android, Chrome and Firefox browser extensions, a Safari extension, an RSS auto-hoarder, and a browser bookmark importer via floccus. Anything you save ends up in the same bucket regardless of where it came from. - **AI works on demand.** Tagging, summarisation, and full-page archiving happen via OpenAI-compatible APIs (Ollama included) and run through a worker pipeline, so the on-device path stays simple and the heavy lifting lives outside the request thread. - **Agents and CLIs are first-class.** The repo ships an MCP server (`@karakeep/mcp`), a published "Karakeep skill" for agentic tools like OpenClaw and Hermes, and a TypeScript CLI (`karakeep`) that talks to the server over tRPC. Granular API key scopes keep read-only agents from having admin rights. ## How it works The monorepo (`apps/`, `packages/`, `tooling/`) is a pnpm + Turborepo workspace. `apps/web` is a Next.js 16 app router frontend that calls the Hono API in `apps/workers` over tRPC 11; persistence is Drizzle ORM on `better-sqlite3` (`packages/db`, with 94 migrations), and full- text plus semantic search is delegated to Meilisearch 1.41. NextAuth (with the Drizzle adapter) handles sessions and OAuth. Crawling uses Playwright + Readability, `monolith` for full-page archives, `yt-dlp` for video, and `tesseract.js` for OCR; everything is orchestrated by the workers process which talks to a headless Chromium container over the Chrome DevTools Protocol. A browser extension (`apps/browser-extension`), a React Native + Expo mobile app (`apps/mobile`), a CLI (`apps/cli`), and an MCP server (`apps/mcp`) all consume the same SDK (`packages/sdk`). The OpenAPI spec is generated from `packages/open-api`, and `packages/e2e_tests` covers the API surface end to end. ## Caveats - **Single-binary storage.** Assets and HTML live on the local filesystem inside `/data`; there is no native S3 backend, so scaling past a single host means mounting a remote volume rather than plugging in object storage. - **Headless Chrome is part of the stack.** The reference Docker Compose pulls `gcr.io/zenika-hub/alpine-chrome` for crawling — it works but adds memory overhead and the SSRF surface has been the source of repeated security advisories (see GHSA-g647-327m-79g9 and GHSA-7rx4-c5vx-g8w3 in the 0.32.0 release notes). - **AI quality depends on your provider.** Tagging and summarisation are best-effort; on cheap models you will get noisy tags and have to bulk-edit. With Ollama locally you avoid the cloud cost but the CPU/GPU budget is on you. - **AGPL-3.0** across the board; commercial forks must publish modifications. ## Deployment notes ```bash git clone https://github.com/karakeep-app/karakeep.git cd karakeep/docker cp .env.sample .env # Set NEXTAUTH_SECRET and MEILI_MASTER_KEY in .env docker compose up -d ``` The reference stack is three containers: `web` (the Next.js + worker AIO image on port `3000`), `chrome` (Alpine Chromium on port `9222` for the crawler), and `meilisearch` (v1.41). For bare-metal Debian or Ubuntu, the repo's `karakeep-linux.sh` script installs Node 24, pnpm, Meilisearch, Chromium, and ffmpeg, then lays down systemd units for `karakeep-web`, `karakeep-workers`, `karakeep-browser`, and `meilisearch` under `/etc/karakeep/`. **Minimum:** 2 CPU and 4 GB RAM handle a personal archive comfortably; budget more for the crawler when you subscribe to many RSS feeds, and plan storage around the `/data` volume (the script defaults to `/var/lib/karakeep`). **Integration tip:** drop the Karakeep MCP server config into an existing Astro/Grove-style directory's agent runtime — alongside the web bookmarklet and the `karakeep` CLI you get a write-only capture path that an AI assistant can call without touching the dashboard. ### Keybase Keybase Go Library, Client, Service, OS X, iOS, Android, Electron.. - slug: keybase - category: communication - stack: react-native - stars: 9245 - license: BSD-3-Clause - repo: https://github.com/keybase/client - url: https://openappscout.com/apps/keybase - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # Keybase Keybase is an open-source, end-to-end-encrypted chat, file-sharing, and identity-verification platform written primarily in Go. Its distinguishing feature is not the cryptography itself but the identity-plus-proofs model: a Keybase user owns a cryptographic identity that they publicly link to their Twitter, GitHub, Reddit, Hacker News, Bitcoin, Zcash, and personal website accounts through signed proof statements rather than OAuth. ## Why it matters - **Identity anchored in proofs.** Every Keybase user has a per-device keypair plus an optional paper key for recovery. New devices are added by reciprocal signatures that chain back to the original — and to social-media proofs — so anyone can verify that `chris` on Keybase is the same person as `chris` on Twitter and GitHub. The verification is outbound, meaning the recipient does not need a Keybase account to receive an encrypted message; if they later sign up and prove control of one of those identities, the sender's client "rekeys" the message on the fly. - **Chat and KBFS on the same identity.** Keybase Chat (defined by the `protocol/avdl/chat1/` Avro IDL) and the Keybase File System (`go/kbfs/libkbfs/`) ride on top of that same identity. KBFS mounts at `/keybase/` on macOS and Linux (FUSE) and at `K:\` on Windows (Dokan), exposing `/keybase/private/` (end-to-end encrypted), `/keybase/public/` (signed, public), and `/keybase/team/` (encrypted team folders). Each top-level folder's mutations are tracked in a Merkle tree (`go/merkletree2/`) so any node can be re-verified independently. - **Post-acquisition status.** Zoom acquired Keybase in May 2020 to bootstrap end-to-end encryption for Zoom Meetings; in October 2023 the team announced end-of-life, and the consumer apps (desktop, Android, iOS) and encrypted file-sharing service were discontinued on 2024-09-15. The Go client, the chat1 protocol definitions, KBFS, and the Stellar wallet integration remain on GitHub under BSD-3 and are still useful as reference implementations. ## How it works The repo is structured around a long-running local service written in Go. `go/keybase` is the CLI front-end; `go/service` is the daemon that listens on a Unix domain socket (macOS/Linux) or named pipe (Windows). The daemon holds the unlocked device keys in memory, so a single device-level login unlocks the CLI, the desktop GUI, and the KBFS mount simultaneously. React Native (`shared/desktop`, `shared/ios`, `shared/android`) is the shared UI layer; the native macOS app in `osx/` is developed in parallel with the Electron desktop client. Wire formats are defined in `protocol/avdl/` as Avro IDL — `keybase1` for the core API, `chat1` for messaging (with `chat_ui`, `commands`, `unfurl`, `notify` submodules), `gregor1` for the push system that drives out-of-band notifications, and `stellar1` for the wallet relay protocol. KBFS itself splits into many subpackages under `go/kbfs/`: `libkbfs` holds the core logic, `kbfscrypto` the per-block crypto, `kbfsmd` the top-level-folder metadata, and `libfuse` / `libdokan` the OS-specific mount glue. The Merkle tree implementation in `go/merkletree2/` is what lets KBFS verify that a client's view of a folder is current without trusting the server. ## Caveats - **The hosted service is gone.** No new signups are possible and existing keys will not be available forever; anything you build today should treat Keybase as a read-only codebase. - **Security history.** Keybase users were targeted in a 2018 Stellar phishing campaign that mimicked legitimate airdrop pages to harvest wallet seeds; in 2021 a bug in the Coinbase verification flow briefly allowed attackers to bind arbitrary Twitter handles to their identities. These were user-side and integration issues, not breaks of the underlying crypto, but they remain instructive. - **Practical audience.** The user base that flocked to Keybase during the 2020–2021 E2EE boom has largely moved on to Signal and Matrix; chat rooms are mostly dormant. ## Deployment notes ```bash # CLI client — install from the GitHub release tarball curl -O https://github.com/keybase/client/releases/download/v6.6.3/keybase-v6.6.3.tar.xz tar -xJf keybase-v6.6.3.tar.xz sudo ./keybase_6.6.3/install # Or build from source (requires Go 1.19+) git clone https://github.com/keybase/client.git cd client/go go install -tags production github.com/keybase/client/go/keybase keybase # Desktop / mobile # Pre-built binaries for macOS, Windows, Linux, iOS, Android lived # at https://keybase.io/download prior to the 2024-09-15 shutdown. # KBFS — FUSE on Linux/macOS, Dokan on Windows sudo /usr/local/bin/keybase mount ls /keybase/private/ ``` **Minimum:** Linux 5.x or macOS 11+ with FUSE installed for KBFS; any modern desktop OS for the CLI alone. Building from source needs Go 1.19 plus Node 4.x for the Avro IDL tooling. **Integration tip:** the Go packages under `go/kbfs/libkbfs/`, `go/chat/`, and `go/merklestore/` are the parts most worth importing. A chat or file-share project that wants identity-plus-proofs semantics can model itself on `libkb`'s chain of device and paper keys, on `merkletree2` for tamper-evident folder history, and on the Avro definitions in `protocol/avdl/chat1/api.avdl` for a battle-tested message schema — even if you never ship a Keybase client. ### LibreTrack Private, cross-platform package tracking app - slug: libretrack - category: productivity - stack: flutter - stars: 364 - license: GPL-3.0 - repo: https://github.com/proninyaroslav/libretrack - url: https://openappscout.com/apps/libretrack - lastCommit: 2026-06-30 - added: 2026-06-07 ### Linkwarden Linkwarden is a self-hosted collaborative bookmark manager that captures every saved page as a screenshot, PDF, and HTML snapshot to defend against link rot. - slug: linkwarden - category: productivity - stack: react-native - stars: 19672 - license: AGPL-3.0 - repo: https://github.com/linkwarden/linkwarden - url: https://openappscout.com/apps/linkwarden - lastCommit: 2026-09-02 - added: 2026-06-13 #### Detail # Linkwarden Linkwarden is a self-hosted, open-source collaborative bookmark manager that solves link rot by automatically preserving every saved page as a screenshot, a PDF, and a single-file HTML copy. It ships with a Next.js web client, a React Native mobile app, and an asynchronous archiving worker, all driven by a Postgres + Meilisearch backend. ## Why it matters - **Defensive archiving baked in.** Unlike Pinboard (which only stores the URL) or Raindrop (a commercial SaaS with optional paid screenshots), Linkwarden captures three independent renderings of every saved page on your own hardware. It also pushes a copy to the Wayback Machine when configured, so a bookmark survives even if your instance dies. - **Collaboration, not just solo use.** Linkwarden adds multi-user workspaces with per-member permissions, sub-collections, and public sharing — closer to a shared research drive than the single-user bookmark managers it is often compared to (e.g. linkding, Shaarli). - **A real reader experience.** Saved pages open in a distraction-free reader view with highlighting and annotations; the highlight data is stored alongside the link in Postgres and searchable through Meilisearch. ## How it works The repository is a Yarn (v4) workspaces monorepo with three apps: `apps/web` (Next.js 15.3 on React 19.1 with NextAuth for SSO over ~60 identity providers), `apps/worker` (a long-running Node process supervised by a `tsx`-based auto-restart loop), and `apps/mobile` (a React Native client published to the iOS App Store and Google Play). `apps/web` uses Prisma against PostgreSQL 16 for relational data and Meilisearch v1.12.8 for full-text search; both run alongside the app in the published `docker-compose.yml`. When a user POSTs a link, `postLink` validates the payload with Zod, runs an SSRF check, deduplicates against existing URLs (with and without `www.`), enforces subscription link caps, fetches title and headers, then writes a `Link` row to Postgres. The worker, started by `worker.ts` via `concurrently`, polls every `ARCHIVE_SCRIPT_INTERVAL` seconds (default 10) and runs `linkProcessing`, RSS polling, AI auto-tagging, and `startIndexing`. Archiving uses Playwright (Chromium), Mozilla Readability, DOMPurify, and the Rust `monolith` binary bundled in the multi-stage Dockerfile; rendered artifacts land in the `./data` volume or in S3-compatible storage when `SPACES_*` variables are set. ## Caveats - **Resource weight.** Each capture spins up Chromium via Playwright, plus a Rust `monolith` build step inside the container image; the archive volume grows quickly for active users. - **License is AGPL-3.0.** Acceptable for personal self-hosting and community use; commercial forks must publish their modifications, which constrains some enterprise deployments. - **AI features are optional and external.** Auto-tagging supports OpenAI, Anthropic, OpenRouter, Perplexity, Azure, and Ollama, but only Ollama runs locally; the other providers send prompt content off-host unless you skip tagging. ## Deployment notes ```bash git clone https://github.com/linkwarden/linkwarden.git cd linkwarden cp .env.sample .env # set NEXTAUTH_URL, NEXTAUTH_SECRET, POSTGRES_PASSWORD docker compose up -d ``` Three containers come up: `postgres` (port 5432, volume `./pgdata`), `meilisearch` (no exposed port, volume `./meili_data`), and `linkwarden` (host port `3000`, volume `./data`). The Dockerfile healthchecks `/` on `127.0.0.1:3000`. Public images are pulled from `ghcr.io/linkwarden/linkwarden:latest`. **Minimum:** 2 CPU, 4 GB RAM, 20 GB for the base install — Chromium and the archive volume push practical needs closer to 8 GB and 50+ GB for a heavy user. Reverse-proxy with TLS in front of port 3000; SMTP and S3-compatible storage are optional but recommended for production. **Integration tip:** Linkwarden is the rare bookmark tool that bundles its own preservation pipeline; if you operate a directory of self-hosted apps, it makes a much stronger reference example than a plain "save-URL" manager for any entry tagged `archiving` or `self-hosted`. ### localmind A Flutter mobile chat client that connects to on-device LLMs and any OpenAI-compatible server — Ollama, LM Studio, OpenRouter — with markdown rendering, voice input, and an MCP tool layer. - slug: localmind - category: developer-tools - stack: flutter - stars: 199 - license: MIT - repo: https://github.com/abdulmominsakib/localmind - url: https://openappscout.com/apps/localmind - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # localmind LocalMind is a Flutter mobile chat client for talking to AI models without sending your conversations to anyone else's infrastructure. It speaks directly to user-configured servers — on-device inference, local Ollama or LM Studio instances, or any OpenAI-compatible API such as OpenRouter — with no middleware, account, telemetry, or subscription in between. ## Why it matters - **True privacy floor.** Zero analytics, no first-party servers, and no fallback proxy. Every byte leaves the device only if the user points the app at a server they trust, and conversation history is stored in encrypted Hive locally. - **Runs models on the phone.** GGUF and LiteRT checkpoints (Gemma, Qwen, DeepSeek R1 and friends) execute directly on iOS or Android via `llamadart` and `flutter_gemma`, so the same app works fully offline once a model is downloaded. - **MCP for tool use.** The app ships a Model Context Protocol client, so a running model can be wired to local or remote MCP servers for file access, shell actions, or web APIs — toggled per server. - **Multi-server by design.** Multiple inference endpoints can coexist with live health monitoring, live model swapping mid-conversation, streaming SSE, expandable reasoning traces (for DeepSeek R1-style models), markdown + syntax highlighting, voice I/O, and image attachments for vision models. ## How it works The codebase is a clean Flutter project (`lib/bootstrap`, `lib/core`, `lib/features`, `lib/services`, `lib/l10n`) with Riverpod for state and `go_router` for navigation. The `features` folder is organised as vertical slices — `chat`, `conversations`, `models`, `on_device`, `mcp`, `personas`, `servers`, `settings`, `saved_messages`, `cloud_sync`, `lm_studio_catalog`, `stt`, `tts`, `voice_mode`, `sidebar`, `onboarding` — so each capability owns its own UI and controllers. Persistence is dual-layered: ObjectBox (`objectbox` + `objectbox_flutter_libs`) holds the relational chat history, while Hive (with `flutter_secure_storage` for secrets) holds lightweight key-value preferences. Networking is plain `dio` to whatever OpenAI-compatible endpoint the user configured, with `url_launcher` for external links and `aws_signature_v4` for the optional S3 cloud-sync target that ships with end-to-end encryption. ## Caveats - **On-device inference is hardware-bound.** A 7B GGUF on a mid-tier Android will be slow; phones older than ~2022 may not run useful models at all. The cloud / local-server paths are the realistic default for most users. - **Single-user app.** There is no notion of shared accounts or team workspaces — this is a personal client, not a SaaS frontend. - **MCP tools are a power feature.** A misconfigured MCP server can give a model shell access; treat endpoint URLs with the same care you would give any LLM agent tool. - **iOS App Store status is unclear.** The repo publishes source only; distribution is via `flutter run` or sideload at present. ## Deployment notes ```bash git clone https://github.com/abdulmominsakib/localmind.git cd localmind flutter pub get flutter run ``` For on-device inference you also need a GGUF or LiteRT model — either pull one through the in-app Model Manager (HuggingFace integration) or drop a file into the app's documents directory. For local-server mode, run Ollama or LM Studio on the same network and add the endpoint under Settings → Servers; OpenRouter or any custom OpenAI-compatible host works the same way. **Integration tip:** if you curate a directory like Astro/Grove for self-hosted or privacy-first tooling, LocalMind pairs naturally with any project that exposes an OpenAI-compatible API — Ollama, LM Studio, vLLM, llama.cpp's server mode — and is one of the cleanest reference apps for showcasing on-device LLM UX in Flutter. ### Loofah Loofah is an MIT-licensed, local-first meeting notetaker for macOS that records and transcribes on-device and stores notes as ordinary Markdown. - slug: loofah - category: productivity - stack: tauri - stars: 3 - license: MIT - repo: https://github.com/bart6114/loofah - homepage: https://loofah.io - url: https://openappscout.com/apps/loofah - lastCommit: 2026-09-03 - added: 2026-08-31 ### MangoDisk MangoDisk is a safety-first disk cleaner and storage analyzer for macOS and Windows that scans locally, visualizes disk usage, and lets users review paths and sizes before removal. - slug: mangodisk - category: tools - stack: tauri - stars: 2096 - license: GPL-3.0 - repo: https://github.com/harry0703/MangoDisk - homepage: https://mangodisk.app/ - url: https://openappscout.com/apps/mangodisk - lastCommit: 2026-09-03 - added: 2026-09-03 #### Detail # MangoDisk MangoDisk is a local-first disk cleaner and storage analyzer for macOS and Windows. It combines the jobs that often require several utilities—finding large files, inspecting caches, locating exact duplicates, removing application leftovers, managing startup items, and repairing common system problems—while keeping the cleanup decision visible. ## What the codebase includes - A Tauri 2 desktop shell and Vue 3 interface shared across macOS and Windows. - A Rust workspace that contains filesystem scanners, platform adapters, cleanup rules, duplicate detection, operation history, and CLI support. - Read-only scanning by default, with paths, categories, sizes, and estimated reclaimable space shown before cleanup. - A treemap and list view for drilling into the folders and files consuming the most storage. - Exact duplicate detection based on file content, with selection logic that keeps at least one copy in each group. - Application uninstall workflows that distinguish rebuildable leftovers from data that may contain personal files. - Startup management, system optimization, and maintenance actions with platform-specific safety checks. - Signed desktop releases, portable and CLI builds, multilingual documentation, and automated release packaging. ## Why it is useful to study Disk utilities sit close to destructive filesystem operations, so the interesting part is not just how many paths an app can scan. MangoDisk exposes a practical safety boundary: discovery and analysis happen first, removal requires an explicit action, and the result is recorded. Its cleanup rules are public and organized by operating system and software domain, which makes the reasoning behind supported targets auditable. The repository also demonstrates a cross-platform architecture where the reusable Rust core serves both the desktop interface and command-line client. Platform-specific implementation details remain separated from shared models and scanning logic, while the Vue layer focuses on presenting large result sets and confirmation workflows. ## Caveats Cleanup, permanent deletion, application uninstall, and system changes can be irreversible. Review selected paths and keep reliable backups of important files. Some actions require administrator privileges or a restart. MangoDisk currently packages macOS and Windows builds; Linux is not a supported release target. The application changes quickly, so readers evaluating the source should use the current release notes and repository documentation rather than screenshots from third-party articles. ## How to run it Download the current macOS disk image, Windows installer, or Windows portable build from the project website or GitHub Releases. Homebrew installation is also documented for macOS, and standalone command-line builds are available for both supported operating systems. ## Verified sources - MangoDisk repository: - Project website: - Latest release: - Cleanup rule library: - English documentation: - Japanese documentation: - Simplified Chinese documentation: - Traditional Chinese documentation: ### MarketMonk A Flutter stock and portfolio tracker that combines Yahoo Finance market data, interactive charts, local trade records, and multiple account support. - slug: marketmonk - category: tools - stack: flutter - stars: 60 - license: MIT - repo: https://github.com/brandonp2412/MarketMonk - url: https://openappscout.com/apps/marketmonk - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # MarketMonk MarketMonk is a Flutter stock and portfolio tracker for following symbols, recording trades, and comparing investment performance across accounts. It uses Yahoo Finance data for prices and candles, while keeping the portfolio ledger in local SQLite storage rather than requiring a hosted account. ## Why it matters - **A real ledger, not just a watchlist.** The app records opens and closes with quantity, execution price, commission, trade date, and realized profit or loss. It derives positions, average cost, cost basis, current value, gain, and allocation from those trades, so the portfolio view reflects transaction history. - **Useful market views.** Charts support 5-day through 10-year periods, searchable ticker selection, favorites, refresh, currency display, and a weekend market-closed indicator. Portfolio charts can show multiple accounts as separate lines, while the portfolio page combines holdings into an allocation pie chart and filterable legend. - **Portable broker data.** Built-in CSV parsers handle Tiger Brokers activity statements and Interactive Brokers Flex Query or activity statements. The import code understands quoted fields, escaped quotes, embedded newlines, BOMs, stock-only rows, and buy/sell direction, making migration from a broker export practical. ## How it works The `lib/main.dart` entry point initializes Flutter, loads `SettingsState`, and hydrates an `AccountManager` before mounting the app. The home screen is a kept-alive `PageView` with Charts, Portfolio, and Holdings tabs plus a floating bottom navigation control. Material 3 themes can use device dynamic colors or a user-selected seed; pure-black dark mode is also available. Drift manages a SQLite database containing `Trades` and `Candles`, stored in the platform application-support directory. Each non-default account gets a named database such as `market-monk-.sqlite`; switching accounts closes the current connection, opens the new file, and clears price-sync caches. On refresh or resume, MarketMonk fetches Yahoo Finance candles and latest prices in the background while Drift streams local changes into the UI. The chart layer resamples longer ranges and uses `fl_chart` through the `TickerLine` widget. ## Caveats - **Market data is an external dependency.** Yahoo Finance requests can be unavailable, delayed, or incomplete, and the repository does not present MarketMonk as a trading or execution platform. - **Local data needs care.** Account databases live on the device, so users should use the CSV export/share flow for backups or transfers. Renaming and deleting accounts manipulate SQLite files, and the default account cannot be deleted. - **Importer coverage is deliberately narrow.** The CSV workflow targets the two documented broker formats; other exports may require transformation before import, and Interactive Brokers realized P/L is filled as zero at execution. ## Deployment notes The repository is a conventional Flutter project with Android, iOS, Linux, macOS, web, and Windows targets, plus Google Play, F-Droid, and Microsoft Store distribution references. For development, install Flutter and follow the Drift migration workflow when changing `lib/tables.dart`: bump `schemaVersion` in `lib/database.dart`, generate migrations with `dart run drift_dev make-migrations`, add the migration step, and run `dart run build_runner build -d`. The project is MIT-licensed. ### Mathematics Generate MCQ PDFs and question papers with answers and quiz mode. Useful for educators and students preparing for exams. - slug: mathematics - category: education - stack: flutter - stars: 144 - repo: https://github.com/j-j-gajjar/mathematics/ - url: https://openappscout.com/apps/mathematics - lastCommit: 2026-06-07 - added: 2026-06-07 ### Mattermost Mobile Mattermost Mobile is the official React Native iOS and Android client for the self-hostable Mattermost messaging platform, giving enterprise and dev teams on-device access to channels, threads, calls, and push notifications backed by the same REST and WebSocket API as the web and desktop clients. - slug: mattermost-mobile - category: communication - stack: react-native - stars: 2714 - license: Apache-2.0 - repo: https://github.com/mattermost/mattermost-mobile - url: https://openappscout.com/apps/mattermost-mobile - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # Mattermost Mobile Mattermost Mobile is the official mobile client for Mattermost, the open-source, self-hostable Slack alternative trusted by developer teams, regulated enterprises, and government agencies. It wraps the same Mattermost server API used by the web and desktop apps in a React Native shell with native iOS and Android bridges. ## Why it matters - **Self-hostable Slack alternative.** Mattermost competes directly with Slack and Microsoft Teams but ships as a single binary you can install on your own infrastructure. The mobile client is the on-the-go surface for that same server, so users see the same channels, threads, and direct messages on their phone as on their desktop. - **Enterprise and dev-team audience.** Adopters include security-focused orgs that need on-prem control over chat data. The mobile app is localized in 21 languages and supports SSO, MFA, Intune enrollment, and Mattermost Enterprise Mobility Management (`@mattermost/react-native-emm`) out of the box. - **Production-grade scale.** Around 2,700 stars, 1,600+ forks, monthly releases, and 219+ contributors. The project ships on the App Store and Google Play Store, with a parallel TestFlight / Play beta track via Fastlane. ## How it works The app is a **React Native 0.83.9** project (Expo 55) with TypeScript as the dominant language. Native iOS lives under `ios/` (Swift, with a `NotificationService/` extension target that mutates APNs payloads before display) and native Android lives under `android/` (Kotlin and Java). A standalone `share_extension/` target handles the iOS share sheet. Build automation runs through Fastlane with separate lanes for `dev`, `beta`, `release`, and `pr` per platform, plus an iOS simulator lane. The mobile app talks to a Mattermost server over two channels. REST requests go through `app/client/rest/`; the live event stream comes in via a WebSocket managed by `app/managers/websocket_manager.ts`. The local mirror of server state is a **WatermelonDB** reactive SQLite database under `app/database/`, with models, schema migrations, and reactive subscriptions that drive UI in `app/screens/`. Screens are split per concern: `app/screens/{channel, post, thread}` for the channel / post / thread model, `home/` for the tabbed root, `login/sso/mfa/` for auth, and a `products/` tree that ships optional integrations like **Mattermost Calls** (`react-native-webrtc`) and Playbooks. Messaging itself uses a `commonmark` renderer with custom markdown extensions, syntax highlighting, and file attachments. Push delivery on iOS uses `react-native-notifications` against APNs, and on Android against FCM, with server-side fan-out from the mattermost-push-proxy. ## Caveats - **Server version coupling.** Each mobile release targets a minimum Mattermost server version — v2.42.2 requires server v10.11.0 ESR or newer. Operators on older servers must coordinate upgrades or stay on older mobile builds. - **Self-compiled apps own their push infrastructure.** If you build the app from source instead of using the store builds, you must also deploy and operate your own `mattermost-push-proxy` instance; the app does not fall back to a hosted push relay. - **Wide native test matrix.** The official support window is iOS 16.0+ and Android 7.0+, but the build matrix spans four Android ABIs (arm64-v8a, armeabi-v7a, x86, x86_64) plus iOS device and simulator. Detox drives the E2E suite, so contributors need both Xcode and Android Studio set up. ## Deployment notes Pre-built store binaries are the default path: download Mattermost from the App Store or Play Store, point it at any Mattermost server URL, and log in with SSO or email/password. Self-hosters typically pair the mobile build with a Mattermost server behind NGINX (or another reverse proxy) that terminates TLS and forwards WebSocket upgrades on the APIv4 path — a misconfigured proxy shows up immediately as a persistent "Connecting..." bar. To self-compile, follow the developer setup guide at `developers.mattermost.com/contribute/mobile/developer-setup/`. The typical flow is `npm install` (Node 22.11+ or 24.15+), `bundle install` for the Fastlane / CocoaPods gems, `cd ios && pod install`, then either `npx react-native run-ios` / `run-android` for development or `fastlane ios release` / `fastlane android release` for store-ready artifacts. The `share_extension/` target, iOS Notification Service Extension, and Android FCM service all build in the same Xcode / Gradle step. **Integration tip:** if you maintain a Grove / Astro directory like this one, list Mattermost Mobile as the canonical example for any app tagged `self-hosted` and `communication` that targets both iOS and Android — its server-coupled release model and self-managed push proxy are the exact pattern most enterprise reviewers want to see. ### medito-app Medito is a permanently-free Flutter meditation app maintained by the Medito Foundation that streams guided sessions, multi-day courses, and themed packs from a CMS-backed catalogue, pairing each track with a `just_audio` + `audio_service` foreground player and an optional background-sound bed. - slug: medito-app - category: health-and-fitness - stack: flutter - stars: 1308 - license: AGPL-3.0 - repo: https://github.com/meditohq/medito-app - url: https://openappscout.com/apps/medito-app - lastCommit: 2026-09-02 - added: 2026-08-11 #### Detail # Medito Medito is a 100% free, non-commercial meditation app for Android and iOS, maintained by the Medito Foundation (a registered Dutch nonprofit) and shipped from a single Flutter codebase. It targets both first-time practitioners and people deepening an existing practice, and it makes a deliberate promise in the README: no ads, no spam, no sign-up, no paywall. ## Why it matters - **Permanently free, foundation-backed.** There is no Stripe path, no in-app purchase, and no ad SDK wiring anything in. The Foundation funds development and content licensing, so the product never has to optimise for retention metrics the way consumer meditation apps do. - **Rich, CMS-driven content model.** The app streams its library from a backend, not from a baked-in asset bundle. Contributors can add Packs (themed collections such as "Sleep" or "Stress"), Paths (ordered multi-day courses like the 30-day intro), and individual Tracks (single guided sessions) without shipping a new release. - **Production-grade audio on Flutter.** Playback is built on `just_audio` plus `audio_service`, so the player keeps running as a foreground notification when the screen is off or the app is backgrounded, and the user can hand off to a Bluetooth headset without losing position. An optional `background_sound` layer mixes rain, white noise, and similar beds under the guided voice. - **Volunteer-friendly Mock mode.** A third run mode (alongside Development and Production) intercepts every network call and serves hardcoded sample data, so a new contributor can `flutter run` the full UI without provisioning Firebase, Stripe, or CMS credentials. This is a striking contrast to most Flutter apps that gate local builds on real backend keys. ## How it works The Flutter app is split into clean layers. `lib/models/` defines the content domain — Packs, Paths, Tracks, Sessions, and the user-side models (favorites, local stats, audio-completion events). `lib/repositories/` and `lib/services/` wrap the REST API and the `audio_service` notification surface. `lib/providers/` exposes state via `provider` (Riverpod code generation lives behind `build_runner` in newer versions), and `lib/views/` is organised by screen: `home`, `explore`, `pack`, `path`, `track`, `player`, `favorites`, `stats`, `settings`, `onboarding`, and a small `debug` surface that the Foundation uses internally. Playback starts in `PlayerView`, which is fed a Track object and delegates to a singleton audio handler. The handler exposes a stream of position and playing-state events so the UI can re-render progress without polling. Background sounds are a second independent audio context that can be toggled on top of any Track. Session completion is detected by listening for the audio handler's `completed` event and persisted locally with `shared_preferences` and small Hive-style JSON files, which then feed the `Stats` view. Build and release tooling is unusually thorough for a volunteer project: Fastlane for store submissions, Shorebird for OTA Dart patches, Maestro for UI flows, and a `VERIFY_APK.md` document that instructs sideload users to confirm APK signatures against the Foundation's published key — a notable trust measure given the wave of malicious meditation-app clones on third-party stores. ## Caveats - **Content license is mixed.** The app code is AGPL-3.0, but the in-app content is licensed separately. Some tracks are original Creative Commons content, others are aggregated from third parties under their own terms; the README is explicit that the Foundation cannot police downstream re-use of aggregated content. - **Backend keys required for real content.** Mock mode lets you build the app, but if you want to publish a fork with live content you still need API credentials from the Foundation. - **No web/desktop target.** Despite being Flutter, the project is intentionally mobile-only — no `flutter run -d chrome` story and no desktop build configuration. - **Volunteer onboarding is human-paced.** The Foundation asks prospective code contributors to email Katie directly with a CV and hours-of-week commitment, rather than self-serve via a CLA bot. ## Deployment notes ```bash git clone https://github.com/meditohq/medito-app.git cd medito-app flutter pub get # Mock mode — no keys required flutter run --flavor mock ``` The Foundation distributes signed builds through the Play Store, the App Store, and GitHub Releases (APK). Sideloaders should follow `VERIFY_APK.md` and confirm the APK signature matches the Foundation's published certificate before installing. **Integration tip:** Medito is a useful reference app for any Grove record tagged `meditation`, `mindfulness`, or `wellbeing`, and its Mock-mode pattern is worth borrowing for any Flutter project that wants to lower the contributor bar without leaking staging data. ### Memex Memex is a Flutter-based, local-first AI journal for iOS and Android that captures text, photo, and voice fragments, runs them through a multi-agent skill system on a BYO-LLM, and weaves them into timeline cards, P.A.R.A.-organized Markdown knowledge, and chart-driven insights. - slug: memex - category: productivity - stack: flutter - stars: 714 - license: GPL-3.0 - repo: https://github.com/memex-lab/memex - url: https://openappscout.com/apps/memex - lastCommit: 2026-09-02 - added: 2026-06-07 #### Detail # Memex Memex is an open-source, local-first AI journal for iOS and Android. It captures life in fragments — text snippets, photos, voice memos, shared files — and routes them through a multi-agent skill system that turns the noise into a timeline of structured cards, a Markdown knowledge base filed with the P.A.R.A. methodology, and chart-driven insight cards. Everything stays on the device, and LLM traffic goes phone-to-provider with no Memex-operated server in the loop. ## Why it matters - **Local-first Markdown archive.** Every record is a Markdown file on disk plus a SQLite row. Drift backs the database; the file tree is the export. One tap and the entire journal is a folder of `.md` files you can rsync, version, or hand to another tool. - **Multi-agent skill system.** `dart_agent_core` is the runtime; each capability (timeline card, PKM filing, schedule, knowledge insight, companion chat) is a `SKILL.md` file that follows the open [Agent Skills](https://agentskills.io) standard. Skills declare event triggers, accept per-agent LLM config, and can execute JavaScript — including `fetch()` — inside a Flutter JS sandbox. - **Bring-your-own LLM with zero intermediary.** Memex talks directly to OpenAI, Claude, Gemini, AWS Bedrock, DeepSeek, Kimi, Qwen, Doubao, Zhipu GLM, Ollama, OpenRouter, and a handful of Chinese providers. Prompts never pass through a Memex backend because there isn't one. - **AI companions with persistent memory.** Custom characters with SillyTavern V2 JSON + PNG card import, auto-commentary reacting to new timeline entries, and 1v1 chats that remember across sessions. - **On-device ML where it pays off.** Google ML Kit does text recognition and image labeling, `sherpa_onnx` plus Silero VAD handles voice transcription, and `health` / `pedometer` / `geolocator` enrich entries with context the journal then becomes the only place that has. ## How it works The Flutter app is organized as `agent/`, `db/`, `data/`, `domain/`, `llm_client/`, `ui/`, and `utils/`. User input flows through asset preparation into the orchestrator agent, which dispatches to specialist skills — timeline card, PKM filing, schedule update, knowledge insight. Background tasks handle character comments, memory curation, and user-authored custom agents. State is `provider` + MVVM; routing is `go_router`; navigation surfaces `flutter_map`, `fl_chart`, and a `webview_flutter` Markdown renderer. A local Android plugin (`agent_background_android`) plus `workmanager` keep long-running jobs alive outside the foreground. ## Caveats - **Mobile-only.** No web client, no desktop build — this is a phone journal that happens to ship Flutter code, not a Flutter desktop app. - **BYO-LLM cost.** Quality of every AI feature (card extraction, entity linking, insight charts, companion chat) tracks the model you point it at. Cheap tiers give noisy tags; on-device Ollama works but the latency is yours. - **Android release APK is 260 MB.** Voice models (`silero_vad.onnx`) and the Jieba dictionary ship inside the binary, which is the price of running everything offline. - **GPL-3.0** across the project; commercial forks must publish modifications. ## Deployment notes Install Memex v1.0.37 from the App Store, Google Play, or the GitHub release APK. Build from source with Flutter ≥ 3.6 and either Xcode (for iOS) or Android Studio: ```bash git clone https://github.com/memex-lab/memex.git cd memex flutter pub get cd ios && pod install && cd .. flutter run --flavor globalDev ``` Pick your LLM provider in Settings → AI before the first capture, and configure an iCloud Drive or local-folder backup target so the Markdown tree survives a phone swap. ### MetaMask Mobile MetaMask Mobile is the official Consensys-maintained mobile wallet for the Ethereum ecosystem, shipped as a React Native app with native iOS and Android modules that supports multi-chain accounts, a built-in dapp browser, and self-custodial key management. - slug: metamask-mobile - category: finance - stack: react-native - stars: 3017 - license: NOASSERTION - repo: https://github.com/MetaMask/metamask-mobile - url: https://openappscout.com/apps/metamask-mobile - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # MetaMask Mobile MetaMask Mobile is the official Consensys-maintained mobile wallet for the Ethereum ecosystem. It is a self-custodial, multi-chain, dapp-capable wallet shipped to the App Store and Google Play, and it is the largest production React Native codebase in the crypto wallet space. ## Why it matters - **The default mobile wallet for Ethereum.** Tens of millions of users reach MetaMask through the iOS and Android apps. Anything that breaks here (dapp connectivity, signing, swaps) is felt across the whole ecosystem, so the codebase is engineered for defensive change rather than novelty. - **Multi-chain as a first-class concern.** The `app/` tree carries dedicated `multichain-accounts/`, `multichain-bitcoin/`, `multichain-stellar/`, and `multichain-tron/` modules alongside the EVM core, with newer EVM L2s (Linea, Base, Arbitrum, Optimism, Polygon, BNB, zkSync) wired through the same accounts UI rather than a single Ethereum-only flow. - **React Native + native modules, not a pure web wrapper.** The `ios/` and `android/` trees host real native code (Swift / Obj-C on iOS, Kotlin / Java on Android) for biometrics, secure key storage, WebView, networking, and the React Native bridge (`RCTScreenshotDetect`, `RNTar` / `RnTar.swift`). Native side matters whenever you need to touch the secure enclave, Keychain, Android Keystore, or the in-app browser. - **Production-grade surface area.** ~76M lines of TypeScript dominated, with mature test infra (Jest, Detox E2E, Storybook), Expo Dev Build support, and OTA updates via `ota.config.js`. The latest tagged release is 8.3.0 and ~300 contributors have touched the tree. ## How it works The app is a single React Native workspace rooted at `app/`. State is split across the legacy Redux layer (`actions/`, `reducers/`, `selectors/`, `store/`) and a newer controller architecture in `app/core/`, which uses the `messengers/` directory and the controller-messenger pattern inherited from the MetaMask extension. The key controllers are the `KeyringController` (HD seed phrase, hardware wallets via Ledger, Snap-based keys), the `TransactionController` (gas estimation, retry / speed-up / cancel, nonce management, security alerts), and the `AccountsController` (per-chain account discovery, naming, and ordering). The dapp layer is split across `app/core/RPCMethods/`, the `BackgroundBridge`, and the `WalletConnect` directory. In-app dapps run inside a WebView that exposes an EIP-1193 provider, and external dapps connect via WalletConnect v2 (and legacy v1 relay) plus the deeplink-based universal provider. EIP-1193 requests from the page are routed through `RPCMethods` to the controller engine, which queues them, runs them against the keyring, and returns a signed result or an error sheet for user confirmation. The transaction signing flow is the same one a dapp calls and a user confirms in-app: `eth_sendTransaction` or `eth_signTypedData_v4` -> controller engine -> keyring sign -> gas + nonce enrichment -> broadcast via Infura (an `MM_INFURA_PROJECT_ID` is required even for local dev) -> surfaced in the Activity feed. Native modules cover the parts JS cannot: `RCTScreenshotDetect` fires when a screenshot is taken so the app can blur sensitive screens, `RNTar` / `RnTar.swift` extract tarballs used by the in-app browser, and the iOS / Android shells wrap Keychain and Keystore access for the seed phrase and private keys. Biometric unlock flows through `app/core/Authentication/` and a `LockManagerService` that gates the wallet behind FaceID / Touch ID / Android BiometricPrompt. ## Caveats - **Massive, opinionated surface area.** ~2 GB checkout, ~300 contributors, controllers and screens that have accreted since the 2018 fork. Patterns range from modern to legacy within the same tree, so a fork is more like inheriting a city than a starter repo. Treat the controller-messenger pattern in `app/core/` as the cleanest seam; treat the Redux tree as read-mostly. - **Regulatory and compliance load.** MetaMask is a regulated product. Onboarding enforces geo-blocking, KYC hand-offs to partner ramps, and feature flags for staking / Perps / Predict that vary by jurisdiction. A self-hosted fork has to make its own call on which flows to enable. - **Non-custodial at scale is hard.** Keys live on the device, recovery is a 12-word phrase, and every signing surface is a potential phishing vector. The app surfaces security alerts, permission revocation, and Snap sandboxing, but the non-custodial model still means there is no rollback button for a signed transaction. ## Deployment notes ```bash git clone https://github.com/MetaMask/metamask-mobile.git cd metamask-mobile yarn setup:expo # recommended; uses Expo Dev Build + @expo/fingerprint echo "MM_INFURA_PROJECT_ID=..." > .js.env yarn watch yarn install:ios:dev # or: yarn install:android:dev ``` For native-side work, use `yarn setup` then `yarn start:ios` / `yarn start:android`, and provide base64-encoded Firebase config in `GOOGLE_SERVICES_B64_IOS` and `GOOGLE_SERVICES_B64_ANDROID`. iOS builds need the pinned Xcode plus CocoaPods; Android builds need the SDK on `PATH` and a JDK 17. CI ships TestFlight, Play internal, and APK / AAB artifacts through `builds.yml` and the runway release bot. **Test environments:** Jest for unit and view tests, Detox for end-to-end on real devices, and a Storybook for the component library. Staging / production split is gated by remote feature flags plus per-environment `.js.env` files; Sentry is wired in for crash reporting and `ota.config.js` handles OTA updates without re-submitting the binary. **Integration tip:** if you are studying MetaMask Mobile as a reference for a non-custodial wallet, the cleanest paths in are `app/core/KeyringController`, `app/core/TransactionController`, and `app/core/RPCMethods` for the provider layer; the `multichain-accounts/` tree is the right starting point if you are extending chain coverage beyond EVM. ### mhabit mhabit (Table Habit) is a Flutter-based micro-habit tracker that scores daily completion against configurable curves, stores everything locally, and syncs across devices through any WebDAV endpoint. - slug: mhabit - category: productivity - stack: flutter - stars: 1533 - license: Apache-2.0 - repo: https://github.com/FriesI23/mhabit - url: https://openappscout.com/apps/mhabit - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # mhabit (Table Habit) mhabit, marketed under the name **Table Habit**, is a Flutter-built micro-habit tracker that treats each habit as a colored row in a calendar and scores daily completion against a configurable growth curve. It is local-first, requires no account, and syncs across devices through any WebDAV endpoint you already control — Nextcloud, Koofr, or a self-hosted server. The single-author project ships builds for Android, iOS, macOS, Windows, and Linux via Google Play, the App Store, F-Droid, Flathub, and the Microsoft Store. ## Why it matters - **Two scoring models, not just streaks.** "Do" habits track how often you completed them and how recently; "don't" habits (e.g. "no smoking") track the gap since the last slip. Both render as growth-curve charts that smooth out missed days instead of resetting to zero. - **WebDAV sync, no vendor.** Any standards-compliant WebDAV server becomes your backend. There is no proprietary relay, no account, and no telemetry — the payload is a SQLite snapshot over HTTPS. - **Material 3 + Dynamic Color.** On Android 12+ the app theme derives from your wallpaper; per-habit color overrides and `flex_color_picker` give you fine control over the calendar. - **Loop Habit Tracker migration.** Native JSON export plus a CSV importer compatible with Loop Habit Tracker makes mhabit a drop-in destination for users leaving a dormant project. - **Truly global.** 18+ languages on Weblate, full RTL support for Arabic, Hebrew, and Persian, and locale-correct date and number formatting throughout. ## How it works The codebase is a Flutter monorepo managed with Melos, with internal packages like `mhabit_color_builder` and `mhabit_proxy_builder` isolating UI generation and proxy boilerplate from the app shell. State uses `provider` and `rxdart`; routing runs through `go_router`; persistence sits on `sqflite` with `flutter_secure_storage` holding secrets and `shared_preferences` holding settings. Habit data renders through two chart engines: `fl_chart` for the growth-curve detail view and `simple_heatmap_calendar` for the grid that dominates the home screen. `animated_reorderable_list` keeps habit-group rearrangement smooth on older Android devices, and `flutter_local_notifications` handles reminders. The WebDAV sync flow, built on `simple_webdav_client`, conflict-checks the server's last-modified timestamp before committing the local snapshot. ## Caveats - **Single-user assumption.** The data model is one install, one author — no multi-user or shared-household mode. - **WebDAV sync is DIY.** You need an existing WebDAV endpoint (or must stand one up); there is no hosted option. - **No home-screen widgets yet.** Android and iOS widgets are on the roadmap but not shipped as of v1.26. - **Indie release cadence.** Updates are frequent but support rests with a single maintainer. - **License is Apache-2.0.** Permissive enough for commercial forks, but adopters should review the trademark posture around the "Table Habit" name. ## Deployment notes For end users, the simplest path is installing from a familiar store — Google Play, the App Store, F-Droid, Flathub, or the Microsoft Store. To build from source: ```bash git clone https://github.com/FriesI23/mhabit.git cd mhabit flutter pub get flutter run ``` **Minimum:** A device capable of running Flutter 3.x. Storage stays well under 50 MB for typical habit histories, and SQLite keeps lookups fast well past several years of daily entries. **Integration tip:** in a directory like this one, pair mhabit with any `local-first` or `privacy-focused` record — it is the counterpart to hosted habit apps the way Daily You is the counterpart to hosted journals, and a clean example of WebDAV as a sync substrate for indie Flutter projects that want to avoid running their own backend. ### Mise Mise is a self-hosted restaurant system for macOS that runs a till, a kitchen display, QR table ordering, and a back office from one machine on the restaurant's own network. - slug: mise - category: business - stack: flutter - stars: 0 - license: MIT - repo: https://github.com/devShakib015/mise - homepage: https://devshakib.jumyn.com/apps/mise - url: https://openappscout.com/apps/mise - lastCommit: 2026-09-02 - added: 2026-09-01 #### Detail # Mise Mise is a restaurant system that runs on a single Mac inside the venue. It covers the till on the floor, a kitchen display on the pass, QR table ordering for guests, and a back office for the menu and the numbers — with no cloud service in the path. ## What the codebase includes - A Flutter macOS client for the till, the kitchen display, and the back office, sharing one design language and one data model. - An embedded PocketBase server that owns the data and runs on the same machine, so the network boundary is the restaurant's own wi-fi. - A guest-facing QR ordering surface that sends orders straight to the kitchen display. - ESC/POS receipt printing to any network thermal printer, addressed by IP rather than a driver. - Shift handling with a counted opening float and a counted closing drawer, and reporting broken down by item, by server, and by hour, with CSV export. ## Integrity rules worth reading The interesting part of the project is what it refuses to do, and those refusals are enforced rather than advisory. A bill total cannot be edited from a terminal. It is computed on the server from the line items, the configured tax, and the service charge, so a tampered client cannot change what a bill costs. A discount cannot exceed the bill it applies to, and money cannot be taken against a cancelled bill. Orders snapshot the name and price of every item at the moment of sale, so repricing the menu today leaves yesterday's bills untouched. On the staffing side, the last owner account cannot be deleted or disabled, and a manager cannot reset an owner's PIN. These are ordinary requirements in commercial point-of-sale software and are rarely visible in an open codebase, which is most of what makes this one useful to study. ## Data and privacy All data lives in one folder on the machine that runs it. The project states there is no telemetry, no analytics, and no outbound reporting, backups are a folder copy, and uninstalling the app leaves the data in place. ## Caveats macOS is the only packaged target today. Windows and Linux build from the same source but are not published as binaries. Builds are unsigned, so the first launch requires right-click then Open. The project is explicit that it does not pay for an Apple Developer certificate, and points to building from source as the alternative. Guest QR ordering is reachable over the venue's wi-fi only. Public online ordering would mean exposing the machine to the internet, which the project rules out deliberately rather than by omission. ### Monekin Monekin is an offline-first, open-source Flutter personal finance manager that tracks unlimited accounts, transactions, budgets, goals, investments, and debts across 50+ currencies, storing every byte on-device in SQLite with no account, no ads, and no internet connection required. - slug: monekin - category: finance - stack: flutter - stars: 254 - license: AGPL-3.0 - repo: https://github.com/enrique-lozano/Monekin - url: https://openappscout.com/apps/monekin - lastCommit: 2026-08-31 - added: 2026-08-11 #### Detail # Monekin Monekin is an open-source, offline-first personal finance manager written in Flutter from a single Dart codebase and currently shipping to Android (Google Play) and Windows (GitHub releases / Microsoft Store). It targets users who want unlimited accounts, transactions, budgets, goals, investments, and debts without ever handing their ledger to a third party — every byte lives in a local SQLite database, and the app works without an internet connection. ## Why it matters - **Truly local-first.** No accounts, no cloud sync, no telemetry. Storage is a single SQLite file managed through [Drift](https://github.com/simolus3/drift) (formerly Moor), with the schema split across `lib/core/database/sql/`. Backups export to a local file that can be restored on another device. - **Real feature surface, not a sample.** Monekin ships multi-account bookkeeping, recurring-transaction automation for bills and subscriptions, budgets with category icons, savings goals, net-worth tracking, investment and debt ledgers, 50+ currencies with customizable exchange rates, CSV import/export, and an `fl_chart`-powered statistics screen. - **Material You theming.** `dynamic_color` derives a palette from the Android 12+ wallpaper, with an AMOLED dark mode and accent picker as fallbacks. The layout collapses to an `AppNavigationSidebar` on tablet and desktop. - **Mature, not abandoned.** First released on Google Play in October 2021 (originally Ionic + Angular), migrated to Flutter in 2023, the codebase has over 1,000 commits and is at release `9.2.1+920001` with active PRs and a translated UI. ## How it works The codebase follows a clean three-tier split under `lib/`. `lib/app/` is feature-organised by domain — `accounts`, `transactions`, `budgets`, `categories`, `currencies`, `debts`, `goals`, `home`, `settings`, `stats`, `tags`, `onboarding` — each with its own pages and widgets. `lib/core/` is the framework-independent layer: `database/` wraps Drift, `models/` defines typed records, `services/` exposes `UserSettingService`, `AppDataService`, and `PrivateModeService` as `.instance` singletons, `routes/` owns navigation, and `presentation/` collects shared themes, animations, and widgets. State management is deliberately lightweight: two global maps (`appStateSettings`, `appStateData`) hold preferences and app flags, an `appStateKey` `GlobalKey` exposes `refreshAppState()` so any widget can trigger a root rebuild, and the root reads from those maps inside `build()`. Internationalization runs through `slang`, charting through `fl_chart`, and the desktop frame through `bitsdojo_window` on Windows. ## Caveats - **AGPL-3.0 license.** Acceptable for personal use; commercial forks must publish their modifications. - **Limited platform reach today.** Android and Windows are shipping; iOS, macOS, Linux, and the Web are not yet first-class targets despite the Flutter codebase making them technically reachable. - **In-app purchase dependency.** `in_app_purchase` is bundled in `pubspec.yaml`, so any source build needs to configure billing or strip the plugin — the README still markets the app as "free, forever". - **Backup portability.** Backups are local files; there is no built-in cross-device sync, so migrating between phones requires a manual export/import cycle. ## Deployment notes ```bash git clone https://github.com/enrique-lozano/Monekin.git cd Monekin flutter pub get dart run build_runner build --delete-conflicting-outputs flutter run -d android # or: flutter run -d windows ``` **Minimum:** Flutter 3.44.1, Dart `>=3.10.1 <4.0.0`, plus a recent Android SDK or Windows 10+ for the desktop target. Drift's code-generation step (`build_runner`) must run after a fresh clone and after any schema change in `lib/core/database/`. **Integration tip:** if you curate an Astro/Grove directory like this one, Monekin is a clean reference for any record tagged `offline-first` or `money-manager` — its Drift schema split, feature-organised `lib/app/` layout, and singleton-service state model are easy to lift into a similar Flutter project. ### Notesnook Notesnook is a cross-platform, end-to-end encrypted note-taking app with web, desktop, and mobile clients that sync through a zero-knowledge server. - slug: notesnook - category: productivity - stack: react-native - stars: 14487 - license: GPL-3.0 - repo: https://github.com/streetwriters/notesnook - url: https://openappscout.com/apps/notesnook - lastCommit: 2026-09-02 - added: 2026-06-13 #### Detail # Notesnook Notesnook is a cross-platform note-taking application that encrypts every note, attachment, and notebook on the user's device before it leaves the device. The server only ever sees opaque ciphertext, so a Notesnook operator (self-hosted or SaaS) cannot read your notes even if they wanted to. ![Notesnook vault — encrypted notes list with notebook sidebar](/images/notesnook/vault.png) *Notesnook's encrypted vault: the server stores only ciphertext, the client unlocks with an Argon2id-derived key, and the same vault syncs across the web, desktop, and mobile clients.* ## Why it matters - **Real end-to-end encryption, not marketing.** Notes are encrypted locally with **XChaCha20-Poly1305** (libsodium's IETF AEAD), and the master key is derived from your password with **Argon2id** at the interactive cost profile (`crypto_pwhash_ALG_ARGON2ID13`). The `packages/crypto` wrapper exposes a single `NNCrypto` interface to every client so the same primitives run on web, desktop, and mobile. - **Different from the SaaS notes market.** Evernote and Notion hold your plaintext and read it for search, AI features, and ads. Obsidian is local-only with no real sync story. Joplin encrypts at rest, but the key handling is per-note; Notesnook's key chain is designed around a single Argon2id-derived vault key that protects every attachment and notebook. - **Verifiable claims.** The Notesnook team ships **Vericrypt**, a separate binary that ingests an encrypted vault and proves the ciphertext can only be decrypted with the user's password — anyone can run it without trusting the app. ## How it works The repository is an NPM workspaces monorepo. `apps/web` is a Vite + React client, `apps/desktop` is an Electron shell that reuses the web build, and `apps/mobile` is a React Native app (iOS + Android). Shared code lives under `packages/core` (database, API client, sync protocol) and `packages/crypto` (the `NNCrypto` wrapper around `@notesnook/sodium`). On first launch the client generates a vault key, derives a key-wrapping key from the user's password via Argon2id, and encrypts the vault key under that wrapper. Notes are encrypted with `crypto_aead_xchacha20 poly1305_ietf_encrypt` using fresh 24-byte nonces; large attachments stream through `crypto_secretstream_xchacha20poly1305` with explicit message/final tags. The server only stores per-user metadata (timestamps, vault version) plus the ciphertext blobs and forwards deltas between clients. Identity keypairs are X25519 (`crypto_box_key pair`), used for vault-to-vault sharing. ## Caveats - **No password recovery.** Argon2id is the entire protection; lose the password and the vault is unreadable. Notesnook ships a multi-factor attestation ("Monograph") you can save as a paper backup, but if you do not, you are trusting your password. - **Server is still required for sync.** You can self-host it, but there is no offline peer-to-peer mode — between the first write on device A and the first read on device B, the encrypted blob has to land on a server. - **GPL-3.0.** Permissive enough for personal and internal use, but any networked derivative must publish its source. ## Deployment notes ```bash git clone https://github.com/streetwriters/notesnook.git cd notesnook npm install npm run bootstrap npm run build:web # build the web client npm run start:web # vite dev server (apps/web) npm run start:desktop # electron dev shell ``` Mobile: ```bash cd apps/mobile npm install npm run install-pods # iOS only npm run run-android # or: npm run run-ios ``` **Minimum:** any modern laptop for the web/desktop client. The mobile build needs the Android SDK (API 34) or Xcode 15+. **Integration tip:** in a Grove-style directory, Notesnook is the canonical `productivity` + `e2ee` example — surface it whenever you have an app that needs a "private notes" anchor or when you want to contrast server-side-searchable SaaS notes with zero-knowledge sync. ### oinkoin Oinkoin is an offline-first Flutter expense tracker that keeps every record in a local SQLite database, ships with biometric app-lock and CSV import, and adds wallets, recurring records, and tags behind a paid PRO build that doubles as the project's funding model. - slug: oinkoin - category: finance - stack: flutter - stars: 461 - license: GPL-3.0 - repo: https://github.com/emavgl/oinkoin - url: https://openappscout.com/apps/oinkoin - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # Oinkoin Oinkoin is a privacy-first personal-finance tracker written in Flutter. Every expense, income, transfer, and recurring pattern lives in a local SQLite database (`sqflite` on mobile, `sqflite_common_ffi` on desktop) — the app never makes a network call, never asks for runtime permissions beyond biometric app-lock, and ships to Android, iOS, Linux, Windows, and macOS from a single Dart codebase. Android is the actively published target; iOS and desktop packages live in the tree but are not distributed. ## Why it matters - **Offline by structure.** `ServiceConfig` wires up only the local SQLite singleton (`SqliteDatabase.instance`, schema version 28), `SharedPreferences`, and the file system for backups. There is no telemetry endpoint in the runtime, so the privacy claim is architectural, not just policy. - **Real domain model.** `lib/models` carries first-class types for `Record`, `Category`, `Wallet`, `Profile`, `RecurrentRecordPattern`, and tag associations. Wallet-to-wallet transfers store a separate `transferValue` so the same movement updates two wallets without double-counting in statistics; categories support emoji icons, custom colours, and a soft-archived state. - **Charts over the same model.** `community_charts_flutter` powers the balance and per-category views; the `statistics/` module exposes aggregated lists, balance charts, and CSV export built on top of the same `Record` type the UI uses. - **PRO as the funding model.** The free build covers the daily-driver workflow; a paid unlock (also free on F-Droid) adds encrypted backup/restore (`encrypt` + `crypto`, AES-encrypted JSON written to `/storage/emulated/0/Documents/oinkoin`), recurring patterns, tags, and custom date ranges. Donations also go via Bitcoin, Monero, and Buy Me a Coffee. - **24 locales.** Translation files in `assets/locales/` cover English, Italian, German, French, Spanish, both Portuguese variants, Russian, Arabic, Chinese, Turkish, Polish, and more, managed through `i18n_extension`. ## How it works `lib/main.dart` bootstraps timezone data, `local_auth`, package info, home-screen quick actions (`add_expense` / `add_income`), and a `talker_flutter` logger before handing off to `lib/shell.dart`. The shell is a bottom-nav scaffold with four per-tab navigators (Records, Categories, Wallets, Settings); each tab keeps a `GlobalKey` so quick actions and deep links can refresh the right state without rebuilding the tree. `SqliteDatabase` is a singleton that opens `movements.db` at `getDatabasesPath()` on mobile and under the application documents directory on desktop, routing through `SqliteMigrationService` to bring older installs up to the current schema version. `BackupService` wraps that database in an AES-encrypted JSON envelope, and `RecurrentRecordService` materialises patterns into `Record` rows anchored to the pattern's original IANA timezone so DST shifts do not drift the recurrence. Other dependencies that earn their place: `intl` for locale-aware currency rendering, `share_plus` for backup share sheets, `emoji_picker_flutter` for category icons, `file_picker` for imports, `flutter_speed_dial` for the add-record FAB, `month_picker_dialog` for stat drill-downs, `flutter_colorpicker` for categories, `auto_size_text` for dense tiles, and `app_review_dialog` for the gentle rating nudge. ## Caveats - **Android-first distribution.** Google Play ships the free build and the paid PRO build; F-Droid carries PRO for free but lags Play by a release or two. iOS, Linux, Windows, and macOS targets are in the repo but not published. - **PRO gates serious workflows.** Backup/restore, recurring records, tags, and custom date ranges sit behind the paid unlock; either accept those gaps or pull F-Droid's free PRO build. - **Single-device by design.** There is no cloud sync — backups are local JSON files (encrypted in PRO, plain in free). - **GPL-3.0 license.** Forks must publish source modifications; fine for personal use, restrictive for closed-source redistribution. ## Deployment notes Download the latest APK from the GitHub releases page (built by the in-repo GitHub Actions workflows), install from Google Play, or grab PRO from F-Droid. Pairing the GitHub release URL with [Obtainium](https://github.com/ImranR98/Obtainium) gives self-updating installs. ```bash git clone https://github.com/emavgl/oinkoin.git cd oinkoin flutter pub get flutter run -d android # or ios / linux / macos / windows ``` Schema changes go through `SqliteMigrationService`; if you fork, bump the static `SqliteDatabase.version` and add a migration step. The backup envelope is JSON containing categories, wallets, records, tags, and profile rows, optionally AES-encrypted with a user-supplied passphrase. ### one_second_diary One Second Diary is a minimalist Flutter video diary app that lets you capture a one-to-ten second clip each day, then stitch your recordings into a shareable compilation movie of your life. - slug: one_second_diary - category: media - stack: flutter - stars: 405 - license: MIT - repo: https://github.com/KyleKun/one_second_diary - url: https://openappscout.com/apps/one_second_diary - lastCommit: 2026-08-31 - added: 2026-08-11 #### Detail # One Second Diary One Second Diary is a Flutter video journal that turns a daily recording habit into a shareable "movie of your life." Each day you record or upload a clip between one and ten seconds; over months and years those clips are stitched into a compilation you can play back or hand off to friends and family. The whole concept traces back to [Cesar Kuriyama's TED talk](https://www.ted.com/talks/cesar_kuriyama_one_second_every_day), and the project ships with an explicit minimalist-plus-privacy ethos: no accounts, no ads, no payments, no analytics. ## Why it matters - **The one-second-per-day ritual, demystified.** Most "1 Second Everyday" apps either lock the export behind a subscription or upload everything to a server. This one stores every clip locally in the device's DCIM folder and uses on-device FFmpeg for the rendering, so the diary never leaves the phone. - **Real per-clip editing.** Before a clip is filed it goes through a `SaveVideoPage` that trims it via `video_trimmer`, lets the user pick a profile, choose a date format and color, type a custom subtitle, and toggle automatic geotagging. A retry loop re-attempts location lookup up to three times before falling back to manual entry, which is what makes the calendar view actually feel like a journal. - **Year-over-year playback.** A dedicated movies viewer stitches selected days (or a whole calendar year) into a single H.264 MP4 using `ffmpeg_kit_flutter_new`. Output is 1080p with audio, bitrated at roughly what `libx264 -crf 20 -preset slow` produces, so the compiled film is watchable on a TV rather than just on the phone screen. - **Practical daily nudges.** `flutter_local_notifications` schedules a daily reminder, the app can start recording when you press a volume button (`flutter_android_volume_keydown`), and `timezone`-aware scheduling means reminders fire correctly when you travel. ## How it works The app uses **GetX** for routing and state — `lib/bindings/`, `lib/controllers/`, `lib/routes/`, and `lib/pages/` follow the classic GetX shape. Recording is handled by the official `camera` plugin, gallery fallback uses `image_picker` plus the `wechat_assets_picker` fork, and `flutter_colorpicker` plus `flutter_calendar_carousel` drive the on-clip styling and the calendar grid view. The interesting part is the rendering pipeline. `lib/utils/video_encoder.dart` probes the bundled FFmpeg build with `ffmpeg -hide_banner -encoders`, parses the result with a regex against the standard ` V....D ` rows, and then picks the best H.264 encoder available per platform: `h264_videotoolbox` first on iOS, `libx264` first on Android, with `h264_mediacodec` and `h264_videotoolbox` as fallbacks. The chosen encoder is reused for every per-day save and every movie export, so the bitrate and quality stay consistent across the whole compilation. The wrapper itself (`lib/utils/ffmpeg_api_wrapper.dart`) is intentionally thin: it centralises the GPL-vs-LGPL build swap behind a single import so that swapping the FFmpeg-Kit distribution only touches one file. Storage lives under the DCIM folder via `media_store_plus`. The app stores profiles as separate subdirectories so a single install can hold a "personal" diary and a "family" diary side by side. Daily notifications are scheduled through `flutter_local_notifications`, the camera orientation is locked via `native_device_orientation`, and `wakelock_plus` keeps the screen on while recording. Nine languages are bundled under `lib/lang/`. The compiled "movie of your life" is generated by selecting days from the calendar and feeding them through the same encoder used for individual saves — the result is then handed off to `share_plus`, so the same export path works whether you want to post to a messaging app or save to the gallery. ## Caveats - **Android-first.** The shipping target is Android (Google Play, minimum Android 7+ for v1.6 and Android 8+ for the upcoming Flutter upgrade). iOS builds run from the same codebase, but the maintainer documents the gaps in `docs/ios.md`; you should read that file before testing on a Mac. - **FFmpeg binary size.** Bundling `ffmpeg_kit_flutter_new` ships a full FFmpeg binary in the APK/AAB. The release APK is large for a Flutter app, and the GPL-vs-LGPL build choice matters if you intend to redistribute. - **No cloud sync.** There is no built-in backup or multi-device sync. If you want to preserve your diary across phones you have to rely on the device backup or hand-copy the DCIM folder. - **Single-developer project.** Maintenance is driven by KyleKun with sponsorship via GitHub Sponsors and Buy Me a Coffee. Issues are tracked on GitHub and PRs are welcome, but release cadence is whatever the maintainer has bandwidth for. ## Deployment notes ```bash git clone https://github.com/KyleKun/one_second_diary.git cd one_second_diary flutter pub get flutter run # connected Android device or emulator flutter build apk --release ``` The simplest path for end users is the Google Play listing at [`com.kylekun.one_second_diary`](https://play.google.com/store/apps/details?id=com.kylekun.one_second_diary). For contributors the `android/`, `ios/`, and `fastlane/` folders are all committed; `flutter_local_notifications` and `wakelock_plus` require a foreground service declaration on Android 13+, and the release builds ship with split-per-ABI APKs plus a universal APK. **Minimum:** Android 7+ (v1.6 line) or Android 8+ (the in-progress Flutter upgrade). iOS 15+ once you build from source. The app is fully offline; no server, no backend, no API key. **Integration tip:** if you maintain a Grove-style directory like this one, One Second Diary is a strong reference for any project tagged `diary` or `flutter-app` that wants to demonstrate on-device video composition with FFmpeg without the usual SaaS trade-offs. ### OnionBrowser An open-source, privacy-enhancing web browser for iOS, utilizing the Tor anonymity network - slug: onionbrowser - category: productivity - stack: ios - stars: 2670 - license: NOASSERTION - repo: https://github.com/OnionBrowser/OnionBrowser - url: https://openappscout.com/apps/onionbrowser - lastCommit: 2026-08-11 - added: 2026-06-13 ### Open Food Facts The mobile companion to Open Food Facts — scan barcodes, decode ingredient lists, and contribute new products to the open database. - slug: open-food-facts - category: health-and-fitness - stack: flutter - stars: 1407 - license: Apache-2.0 - repo: https://github.com/openfoodfacts/smooth-app - url: https://openappscout.com/apps/open-food-facts - lastCommit: 2026-09-03 - added: 2026-06-07 ### OpenDesign A local-first Apache-2.0 desktop and web application that turns any of 27 coding-agent CLIs into a design engine, producing HTML prototypes, PDFs, PPTX decks, images, and HyperFrames MP4 against a portable `DESIGN.md` brand contract, with BYOK across OpenAI / Anthropic / Azure / Google / Ollama and an MCP stdio server for agent-native integration. - slug: open-design - category: developer-tools - stack: — - stars: 93830 - license: Apache-2.0 - repo: https://github.com/nexu-io/open-design - url: https://openappscout.com/apps/open-design - lastCommit: 2026-09-03 - added: 2026-09-01 #### Detail # OpenDesign OpenDesign is a portable design runtime. That framing matters more than the "open-source Claude Design alternative" line its marketing leads with, because Claude Design is not the thing it replaces — Claude Design is one of five realistic shortlist members that all share the same architectural contract: model and delivery are coupled. OpenDesign is the only entry in that shortlist that decouples them. The artifact surface (HTML prototype, PDF, PPTX, MP4) is repo-shaped and version-controllable. The brand contract (`DESIGN.md`) is a Markdown file you commit. The model layer is pluggable across 27 coding-agent CLIs plus a BYOK proxy to any OpenAI-compatible endpoint. Every other realistic option — Claude Design, v0, Lovable, Bolt.new, Figma Make — picks your model for you. That decoupling is the load-bearing claim. It is also, in practice, more constrained than the README frames it. The 27 CLIs are normalized at the *daemon* level through a `RuntimeAgentDef` registry, but each provider has a hardcoded wire shape: adding a new BYOK target means a new proxy route, a new `registerByokToolChatProxy` call, and a new tool catalog entry. The "agent-agnostic" line is real, but it is real at the level of "we maintain 27 integrations," not "drop in any model." ## The artifact surface is the part that holds up The four artifact types — HTML prototype, PDF, PPTX, MP4 — come out of one shell, against one brand file. That combination is unique in the shortlist. Claude Design ships PDF + PPTX + HTML. Figma Slides ships `.pptx`. v0, Lovable, Bolt.new are web-app-only. HyperFrames — agent HTML/CSS/GSAP rendered into deterministic MP4 via headless Chrome and FFmpeg (`hyperframes@0.8.1`, bundled as an npm dep) — is OpenDesign-only. The carve-out documented in `apps/daemon/src/prompts/media-contract.ts` explains why the renderer runs in the *daemon* process rather than the spawned agent: macOS `sandbox-exec` wraps Claude Code's Bash tool, and under it puppeteer's Chrome subprocess hangs partway through frame capture. The daemon is unsandboxed and renders reliably; the agent only authors composition HTML. This is a real architectural decision — the renderer is a daemon subsystem, not an agent tool — and it is the kind of detail the README does not foreground. `DESIGN.md` is the other portable piece. It is a Markdown file with `tokens.css`, a `USAGE.md`, a components manifest, and a rich-file index. When composing the system prompt the daemon reads the file body — not a copy, not a `{{ design_system }}` substitution, not a section- pruned excerpt — and injects it between the craft reference layer and the skill body. Brand tokens win on conflict. The validator in `tools-connectors-cli.ts` rejects "thin" design rules under 800 chars and missing canonical sections. The result is that you can commit one `DESIGN.md` and apply it across many repos with any of the 27 agents. ## Three preview surfaces, three isolation models The README calls it a "sandboxed iframe preview." That collapses three different isolation models that exist in the same repo: - **Live HTML preview**: served into a `srcdoc` iframe with `sandbox="allow-scripts allow-forms"`. Scripts allowed, network not. - **Brand gallery**: served into an iframe with `sandbox=""`. Fully locked down. - **Powered preview** (for WebGL, Worker, WASM, SharedArrayBuffer artifacts): cross-origin isolation instead of sandbox — sets `Document-Isolation-Policy: isolate-and-credentialless`, removes CSP. A reader who believes "sandboxed" is uniform is wrong, and that is a documentation gap worth knowing before you ship. ## The security model is the strongest part of the OSS build The BYOK proxy at `/api/proxy/{provider}/stream` enforces SSRF at the daemon edge: `validateExternalApiBaseUrl` performs DNS resolution and blocks RFC1918, loopback, link-local, CGNAT, IPv6 ULA/link-local, metadata IPs, and the multicast block. DNS rebinding is defeated by pinning validation to the actual connection (`createValidatingLookup`). `fetch` calls are paired with `redirect: 'error'` to defeat 3xx→private hops. v0.20.0 closed a DNS-trick bypass for BYOK media downloads (PR #6072). The MCP stdio server (`od mcp`) is stateless: it holds no state, never touches the filesystem, and exits after 30 minutes of inactivity. Every tool call resolves to `fetch()` against `OD_DAEMON_URL`. Spawned agents that call back into the daemon get short-lived, endpoint- and operation- scoped bearer tokens (15-minute TTL) — not the user's `OD_API_TOKEN`. Browser-extension origins (`chrome-extension://`, `moz-extension://`) require an explicit pairing flow that mints a long-lived `odlt_…` token (stored hashed as sha256); without pairing those origins are rejected. CORS is implemented inline per route, not via middleware. The `/api` guard enforces strict loopback-only origin validation. Non-browser clients (no Origin header) are always allowed. ## The open-core line is real, but not where the README draws it OpenDesign is genuinely Apache-2.0 and genuinely usable with zero plan credits — the OSS build ships a free tier that supports local CLI and BYOK. The commercial boundary is not about gating the core; it is about *convenience*. Paid Cloud tiers (Go $10, Plus $20, Pro $100, Max $200, Team $63/seat) add hosted model credits and image resolutions. The real open-core lines are subtler than the README draws them: 1. **Plan credits are locked to the OpenDesign app.** The pricing page is explicit: "Plan-included unlimited credits and free generations cannot be used via MCP/CLI/API." If you want to use a paid model outside the app, you must BYOK. 2. **AMR / Vela Cloud is the default for image generation.** `vela/gpt-image-2` is the default model in `apps/daemon/src/media/ models.ts:43`. The AMR API at `https://amr-api.open-design.ai` has no BYOK alternative for `vela/*` models — the wallet endpoint calls that API. Even on a "BYOK-only" install, the image path routes through the operator's managed cloud unless the user manually changes the default. 3. **Always-on safety / reliability telemetry bypasses the consent toggle.** `apps/daemon/src/analytics.ts:204-220` calls this out explicitly. `PRIVACY.md:13-15` does disclose it ("Safety and reliability telemetry is always enabled in builds configured with a telemetry destination"), but no README mention of "telemetry opt-out" reveals the third channel. A reader who toggles off analytics is *not* actually off everything. 4. **v0.18.1+ forces a mandatory cloud sign-in on launch.** Issue #6599 (19+ comments, no maintainer revert) reports a full-page "Sign in" screen with no skip option. The community fork `tony-box/open-design v0.18.1` (15 reactions) removes the gate. Maintainer position is "identity first, runtime second." ## Where OpenDesign wins, where it loses **Pick OpenDesign** if you want OSS + self-host + BYOK + agent-agnostic, your artifact is not a deployable web app (slides, decks, prototypes, images, MP4), or you need a portable design contract across repos via `DESIGN.md`. **Pick Claude Design** if you are already on Claude Pro/Max/Team and want first-party connectors to Lovable, Replit, Vercel, Canva, Gamma, Wix, Adobe, Miro. Those handoffs are why a non-Anthropic-locked tool cannot fully substitute. **Pick v0** if the deliverable is a deployable Next.js app on Vercel. **Pick Lovable** if the deliverable is a hosted full-stack app with managed DB/auth and you do not want per-seat billing. **Pick Bolt.new** if you want token-metered, dev-shaped chat-to-app with private NPM and design-system knowledge at the Teams tier. **Pick Figma Make / Slides** if the deliverable is a Figma file for designer handoff and you need real collaborative editing. ## Deployment notes The OSS build is genuinely usable. Install paths: macOS / Windows desktop installers, Docker compose on port 7456, Vercel preset, Nix flake + mise, source build via `pnpm tools-dev run web`. Node `~24` and pnpm `10.33.x` are required for source. Self-host caveats worth knowing in advance: - **No first-party `Dockerfile`, `docker-compose.yml`, `mise.toml`, or Nix config is checked into the repo.** `QUICKSTART.md` references a `deploy/` directory and the Sealos App Store, but reproducible builds depend on the published Docker image, not first-party build artifacts. - **No shipped Linux desktop.** ≥9 issues ask for Linux support; the AppImage either does not ship or fails to boot; the Flatpak PR remains draft. - **Self-hosting behind an enterprise / VPN-internal model gateway requires `OD_ALLOWED_INTERNAL_HOSTS`** — the SSRF guard rejects RFC1918 by default. - **v0.18.1+ users must have network access to even launch the app.** Air-gapped users should stay on v0.17.0 or use the community fork until #6599 is resolved. ## Verified sources - Repository and license — ; `LICENSE` (Apache-2.0). - Architecture and skills protocol — `docs/architecture.md`, `docs/skills-protocol.md`, `AGENTS.md` at commit `c9eb23027fc252662cd00c03f08562f298dfafec`. - Releases and security fixes — (v0.17.0 → v0.20.1, including v0.20.0 SSRF fix PR #6072). - Cloud pricing and commercial boundary — . - Forced-login issue and community fork — ; . - Realistic-shortlist comparison facts — each competitor's own published pricing and product pages (claude.com, v0.app, lovable.dev, bolt.new, figma.com), not affiliated reviews. ### peercoin_flutter peercoin_flutter is a self-custodial light wallet for Peercoin and Peercoin Testnet, written in Flutter and shipped to Android, iOS, and the Web from a single Dart codebase that talks to public ElectrumX servers. - slug: peercoin_flutter - category: finance - stack: flutter - stars: 32 - license: AGPL-3.0 - repo: https://github.com/peercoin/peercoin_flutter - url: https://openappscout.com/apps/peercoin_flutter - lastCommit: 2026-07-22 - added: 2026-08-11 #### Detail # peercoin_flutter peercoin_flutter is a self-custodial light wallet for Peercoin and Peercoin Testnet, written in Flutter and shipped to Android, iOS, and the Web from a single Dart codebase. It is the most actively maintained open-source wallet for the Peercoin cryptocurrency and serves as a reference implementation for non-Bitcoin UTXO chains on Flutter. ## Why it matters - **Light client over ElectrumX.** The wallet never downloads a blockchain. Instead it speaks the ElectrumX protocol (TCP/JSON-RPC plus WebSocket subscriptions) to public Peercoin Electrum servers, keeping the install size small enough that the same codebase rebuilds cleanly for mobile stores and the Web. - **Crypto stack worth reading.** Seed material follows BIP-39 (`bip39: ^1.0.6`), with primitives from `crypto: ^3.0.3`, and the signing layer pulls in `frosty: ^2.0.0` + `frosty_flutter: ^2.0.2` for FROST threshold-signature support. Heavy lifting lives in the sibling `coinlib` library, which is consumed via a `dependency_overrides` git pin on the `16kb-align` branch. - **Real mobile-store distribution.** The project ships through F-Droid, Google Play, the Apple App Store, and TestFlight for open beta, plus a web build deployed at wallet.peercoin.net via the `peanut` global tool. CI is a Codemagic pipeline plus GitHub Actions for static analysis and unit tests, with `flutter_driver` end-to-end coverage under `test_driver/`. - **Mature Flutter plumbing.** State is `provider: ^6.0.3`, persistence is `hive_ce: ^2.10.1` with code-generated adapters, secrets live in `flutter_secure_storage: ^9.0.0`, and biometrics come from `local_auth`. The UI is fully internationalized through Weblate with `intl: ^0.20.2` and ships with `flutter_localizations`. ## How it works The repository is a conventional Flutter app: `lib/` holds the Dart source, `protos/` defines a `marisma.proto` compiled via `protoc --dart_out=grpc:lib/generated`, and platform folders (`android/`, `ios/`, `web/`) hold the standard per-target glue. Generated code includes Hive adapters (`dart run build_runner build`), launcher icons (`dart run flutter_launcher_icons:main`), and the splash screen (`dart run flutter_native_splash:create`); CI checks these artifacts in. Networking splits between `web_socket_channel: ^2.1.0` for the ElectrumX subscription stream and `http: ^0.13.3` for one-shot RPCs. Connectivity state is surfaced through `connectivity_plus: ^6.1.3`, and the app declares both `background_fetch: ^1.7.0` and `flutter_local_notifications: ^17.0.0` so balance alerts can fire without the wallet being foregrounded. QR flows use `qr_flutter: ^4.0.0` for receive and `qr_code_scanner_plus: ^2.0.10+1` for the scanner, and address-book autocomplete runs on `flutter_typeahead: ^5.2.0`. ## Caveats - **Will not mint.** Despite Peercoin being a proof-of-stake chain, the wallet explicitly does not participate in block minting; it is a transaction-only client. Users who want staking rewards must run a full node or use a separate staking tool. - **Forked crypto dependencies.** `coinlib_flutter` and `frosty_flutter` are pinned via `dependency_overrides` to community forks on the `16kb-align` branch. Upstream releases have not yet shipped this alignment, so the overrides have to be removed manually once they land — and `flutter_logs` is pulled from a personal fork (`ced1check/flutter_logs`) with a TODO referencing two open issues. - **AGPL-3.0.** The license is copyleft: any network-served derivative must publish its modifications. Personal and internal use is fine, but a branded commercial fork needs to either stay open or negotiate separately. - **"Use at own risk."** The README flags the wallet as in "constant development" and explicitly warns users to use at their own risk — budget accordingly if you treat this as a primary store of funds. ## Deployment notes ```bash # Mobile — install from the official stores # Android: F-Droid or Google Play ("Peercoin") # iOS: App Store and TestFlight open beta # Web build (deployed at wallet.peercoin.net) flutter pub global activate peanut flutter pub global run peanut -b production # Build from source git clone https://github.com/peercoin/peercoin_flutter.git cd peercoin_flutter flutter pub get dart run build_runner build --delete-conflicting-outputs dart run flutter_launcher_icons:main dart run flutter_native_splash:create flutter run -d chrome # or -d , -d ``` **Minimum:** any device that runs a recent Flutter SDK (Dart `>=3.2.0 <4.0.0`) plus the `coinlib` library built separately per its own instructions. No full node is required — only a reachable ElectrumX server URL, which the user picks in Settings. **Integration tip:** if you are cataloguing open wallets, peercoin_flutter is a clean reference for a non-Bitcoin UTXO Flutter wallet that uses FROST threshold signatures and ships to mobile + Web from one tree. Pair it with single-chain peers like BlueWallet or chain-agnostic peers like Cake Wallet to round out a multi-chain directory. ### PeopleInSpace PeopleInSpace is a Kotlin Multiplatform reference app that shares architecture and data code across iOS, Android, desktop, web, and wearable clients. - slug: peopleinspace - category: tools - stack: ios - stars: 3427 - license: Apache-2.0 - repo: https://github.com/joreilly/PeopleInSpace - url: https://openappscout.com/apps/peopleinspace - lastCommit: 2026-09-02 - added: 2026-06-13 #### Detail # PeopleInSpace PeopleInSpace is John O'Reilly's Kotlin Multiplatform reference app for exploring who is currently in space and tracking the International Space Station. Its shared Kotlin code supports native and Compose-based clients while a small Ktor service supplies astronaut and ISS data. ## Why it matters PeopleInSpace has been evolving since 2019, making it a useful record of how Kotlin Multiplatform architecture has matured rather than a narrowly frozen sample. The project is listed in the official Kotlin Multiplatform documentation and Google Dev Library, and its README connects the implementation to an extensive series of articles about SwiftUI interop, Kotlin Flow, Koin, SQLDelight, async/await, and Compose Multiplatform. The breadth is unusually practical for a demo: one repository targets iOS with SwiftUI, Android with Jetpack Compose, Wear OS, desktop with Compose for Desktop, and the browser with Kotlin/Wasm. The shared `common` module also supports JVM use, while separate backend and MCP server modules show that the same domain code can extend beyond graphical clients. ## How it works The Gradle build separates shared concerns from platform entry points. `common` contains KMP domain models, view models, Koin wiring, SQLDelight persistence, Ktor networking, and shared Compose UI. Platform modules include `app`, `wearApp`, `PeopleInSpaceSwiftUI`, `compose-desktop`, and `compose-web`; `backend` hosts a Ktor server, and `mcp-server` exposes shared functionality through the Kotlin MCP SDK. Clients inject a Ktor `HttpClient` into `PeopleInSpaceApi` and make suspending GET requests to the project's App Engine proxy at `/astros.json` and `/iss-now.json`. Typed bodies are decoded with Kotlinx Serialization. The backend supplies astronaut records and proxies the ISS location request to Open Notify, so platform clients do not contact Open Notify directly. Coroutines provide the asynchronous model. `PeopleInSpaceRepository` performs its initial refresh in a `MainScope`, exposes completion through `StateFlow`, and converts SQLDelight queries into a `Flow>` on `Dispatchers.Default`. ISS position updates use a cold flow that polls every ten seconds, logs transient failures, and continues unless the coroutine is cancelled. ## Caveats This remains a demonstration and learning project, not a production crew-tracking service. Its repository refresh replaces the local people table wholesale, network errors are logged rather than surfaced comprehensively to the UI, and upstream availability matters; the Open Notify service uses an HTTP endpoint and can be intermittent. KMP shares networking, storage, state, and some Compose UI effectively, but native presentation still requires platform work. The iOS target is a SwiftUI application opened and maintained in Xcode, while Android, Wear OS, desktop, and web have their own launch modules, packaging, and platform-specific behavior. ## Deployment notes Use JDK 17 and a recent Android Studio. Run the Android client from the `app` configuration or with `./gradlew :app:installDebug`; Wear OS uses `wearApp` or `./gradlew :wearApp:installDebug`. Shared JVM tests run with `./gradlew :common:jvmTest`. For iOS, open `PeopleInSpaceSwiftUI` in Xcode and build the selected simulator or device target. Desktop runs with `./gradlew :compose-desktop:run`, while the Wasm browser client uses `./gradlew :compose-web:wasmJsBrowserDevelopmentRun`. The local backend starts with `./gradlew :backend:run` and exposes test data at `http://localhost:9090/astros_local.json`. **Integration tip:** use the repository as a KMP starting point when you want a working example of shared Ktor, serialization, SQLDelight, coroutines, and dependency injection feeding both native SwiftUI and Compose-based clients. ### Posnic POS Posnic POS is offline-first open-source POS and billing software for retail shops and restaurants, built as a JavaScript/Electron desktop app with a local MongoDB-backed checkout. - slug: posnic-pos - category: business - stack: javascript - stars: 3 - license: AGPL-3.0 - repo: https://github.com/Posnic/POS - homepage: https://posnic.io/ - url: https://openappscout.com/apps/posnic-pos - lastCommit: 2026-09-03 - added: 2026-09-02 #### Detail # Posnic POS Posnic POS is a desktop point-of-sale and billing app for retail shops and restaurants. The local edition runs the till and its database on hardware the shop controls, while the public source also includes setup, support, update, backup, and optional cloud-activation surfaces around that local workflow. ## What the codebase includes - An Electron desktop shell with a local Node.js API and a MongoDB-backed data store. - Checkout and billing flows for sales, returns, held bills, part payments, receipts, and reports. - Inventory and purchasing screens for item stock, suppliers, purchase entries, and stock-aware selling. - Restaurant-oriented support such as kitchen order ticket handling and receipt printer integration. - Backup, restore, update, startup, hardware, and log-management surfaces that are part of the packaged desktop app rather than separate examples. - Release packaging for Windows, macOS, and Linux through GitHub Releases. ## Why it is useful to study Open-source POS codebases are often narrow web demos or inventory samples. Posnic is useful because it shows the messier desktop concerns that real shop software has to handle: local database startup, first-run setup, retail hardware, offline checkout, update safety, backup safety, receipts, and support context. The repository also keeps operational documents next to the code. The README, self-hosting notes, hardware matrix, privacy page, governance policy, release verification guide, and third-party notices make it possible to review both the application behavior and the packaging boundary. ## Caveats Posnic-owned source is AGPL-3.0-only. Release packages include separately licensed components, including MongoDB Community Server under SSPL-1.0, so downstream packagers should read the third-party notices and package evidence before redistributing binaries. Windows is the best-tested retail-hardware target. macOS and Linux builds are published, but hardware validation is thinner there. Operators should also expect normal first-launch trust warnings while signing and notarization mature. The project is young and low-star. Treat it as a codebase worth inspecting, not as a popularity signal. ## How to run it ```bash git clone https://github.com/Posnic/POS cd POS npm install npm start ``` The development app downloads and runs its local database during setup. For packaged users, the current downloads live on the v1.6.1 GitHub release. ## Verified sources - Posnic POS repository: - Posnic website: - Latest release: - User guide: - Self-hosting guide: - Hardware matrix: - Release verification: - Third-party notices: ### Rainbow Rainbow is a multi-chain Ethereum wallet for iOS and Android, built on React Native with Reanimated 3 and Shopify FlashList for fast mobile UX and broad NFT, DeFi, and swap coverage. - slug: rainbow - category: finance - stack: react-native - stars: 4386 - license: GPL-3.0 - repo: https://github.com/rainbow-me/rainbow - url: https://openappscout.com/apps/rainbow - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # Rainbow Rainbow is a mobile-first Ethereum wallet for iOS and Android, plus a browser extension, that covers far more than a plain ETH balance: it speaks to Ethereum mainnet and a wide set of L2s, surfaces an NFT gallery and a swap aggregator, hosts an in-app dapp browser, and includes Hyperliquid perpetuals and a Polymarket integration. It is also one of the most-cited examples of what a polished React Native crypto app can feel like in the hand. ## Why it matters - **Multi-chain by design.** Rainbow treats Ethereum mainnet, Optimism, Arbitrum, Base, Polygon, BNB Chain, Zora, and a long tail of L2s as first-class destinations, not an afterthought. Chain switching, per-chain balances, and per-chain swap routing are wired through the same UI rather than buried behind a network dropdown. - **NFT, DeFi, and swap coverage in one app.** The Discover screen surfaces NFT collections, a swap sheet backed by the in-house `@rainbow-me/swaps` aggregator, Hyperliquid perpetuals (`@nktkas/hyperliquid`), and a Polymarket prediction-market flow (`@polymarket/clob-client-v2`). The wallet therefore reads less like a key-store and more like a small Web3 home screen. - **React Native as a UX bet.** Rainbow was one of the first wallets to commit fully to React Native for crypto, and it was simultaneously one of the first to feel native on iOS. The combo of Reanimated 3 worklets, Shopify FlashList for long lists (transactions, NFTs, token lists), Skia for chart rendering, and Gorhom's bottom-sheet gives the app the snap that other RN wallets struggled to match for years. - **Post-acquisition, still shipping.** The rainbow-me team was acquired by OrangeFun in 2024, but the open-source repo on the `develop` branch is still active — recent commits land weekly, the latest tagged release is v2.0.39, and 70+ contributors have touched the codebase. The license is GPL-3.0 and the project remains a usable reference implementation, not a tombstone. ## How it works The codebase is a single React Native 0.81 workspace that ships to three targets from one tree: iOS, Android, and a browser extension. State is split across Recoil (per-screen UI), Redux (wallet and settings), Zustand (newer stores), and `@tanstack/react-query` (RPC and GraphQL caching). Persistence is handled by `react-native-mmkv`, which gives the app a sync storage API that does not stall the JS thread on cold launch. The chain layer is `viem` 2.x with `ethers` 5.x still pinned for legacy code paths. WalletConnect v2 is wired through `@walletconnect/core` plus `@walletconnect/react-native-compat` and the newer `@reown/walletkit`; dapps connect via a relay, the in-app browser is `src/screens/DiscoverSheet/`, and approval sheets live in `src/screens/WalletConnectApprovalSheet.tsx`. Hardware-wallet support runs through `@ledgerhq/hw-app-eth`, and Coinbase Wallet hand-off uses `@coinbase/mobile-wallet-protocol-host`. Name resolution happens in `src/handlers/web3.ts`: `resolveNameOrAddress` checks whether the input is a hex address, and if not falls through to Unstoppable Domains (`@unstoppabledomains/resolution`) and then to ethers' `provider.resolveName` on Ethereum mainnet. Passkeys (`react-native-passkeys`) sit alongside the seed-phrase flow as a modern recovery option. Swaps live in `src/__swaps__` for the Swaps V2 rewrite (feature-flagged, not yet in production) and in the existing `src/screens/Swap/` and `@rainbow-me/swaps` package for the shipped flow. ## Caveats - **Acquired project, unclear long-term direction.** Rainbow was acquired by OrangeFun in 2024, and the open-source repo still ships releases, but roadmap decisions now sit inside a corporate parent. If you are evaluating Rainbow as a base for a new wallet, treat upstream as a fast-moving target rather than a stable dependency. - **No native desktop build.** There is a browser extension, but Rainbow has never shipped a first-party macOS or Windows desktop wallet. Heavy desktop users will still pair it with a separate wallet such as Frame or Rabby. - **Mobile-wallet limits.** Even with Ledger support via USB or Bluetooth, the practical ceiling for any phone-only wallet is dapp-browsing ergonomics, signing latency, and the lack of a true full-node view. Treat Rainbow as a hot wallet for daily activity, not as a cold-storage replacement. ## Deployment notes ```bash git clone https://github.com/rainbow-me/rainbow.git cd rainbow mise install # pins Xcode, Node, Ruby, JDK corepack enable yarn install # requires gh auth or a GITHUB_TOKEN yarn setup yarn start # Metro yarn ios # or open ios/Rainbow.xcworkspace in Xcode yarn android # requires JDK 17 (Zulu), not Studio's bundled JDK 21 ``` iOS builds need the Xcode version pinned in `.xcode-version` plus CocoaPods (`yarn install-pods`). Android builds need Azul Zulu 17 exported as `JAVA_HOME`, the Android SDK on `PATH`, and at least 4096 MB of IDE heap — the default 2048 MB makes Gradle sync drag. External contributors must supply their own `.env` (Etherscan, Infura, ETH Gas Station, Imgix, plus a `google-services.json` for the Android Firebase project) since the prod keys live only inside the org. **Test environments:** Jest is the default unit runner; Detox or end-to-end flows live under `e2e/` for the screens that talk to hardware wallets or WalletConnect peers. The internal `develop` branch is the source of truth — `main` is rarely the latest. **Integration tip:** if you want to fork the wallet rather than build from scratch, `@rainbow-me/swaps`, `@rainbow-me/provider`, and `@rainbow-me/sdk` are published as standalone npm packages and are the cleanest seams to copy; the Reanimated worklet layer under `src/worklets/` and the FlashList usage in `src/screens/` are the cleanest patterns to lift if you only want the feel. ### Rocket.Chat Official Rocket.Chat mobile client — open-source team communication, channels, threads, file sharing, voice/video calls, end-to-end encrypted. - slug: rocket-chat-react-native - category: communication - stack: react-native - stars: 2413 - license: MIT - repo: https://github.com/RocketChat/Rocket.Chat.ReactNative - url: https://openappscout.com/apps/rocket-chat-react-native - lastCommit: 2026-09-03 - added: 2026-06-07 ### Rockxy A native macOS HTTP debugging proxy for inspecting HTTPS, API, WebSocket, and GraphQL traffic. - slug: rockxy - category: developer-tools - stack: ios - stars: 1343 - license: AGPL-3.0 - repo: https://github.com/RockxyApp/Rockxy - homepage: https://rockxy.io - url: https://openappscout.com/apps/rockxy - lastCommit: 2026-09-03 - added: 2026-08-27 ### roxum-ide A mobile-first Flutter code editor and mini IDE for Android with LSP, an embedded terminal, Git/GitHub tooling, and optional on-device GGUF model chat. - slug: roxum-ide - category: developer-tools - stack: flutter - stars: 601 - license: MIT - repo: https://github.com/heckmon/roxum-ide - url: https://openappscout.com/apps/roxum-ide - lastCommit: 2026-08-25 - added: 2026-08-11 #### Detail # Roxum IDE Roxum IDE is a mobile-first code editor and mini IDE for Android, built in Flutter. The app pairs a Rust-backed editor engine with an embedded terminal, Git/GitHub tooling, LSP-driven language services, and optional on-device AI completion, all in a single APK that runs without root. ## Why it matters - **Real editor on a phone.** The editor surface is provided by [`code_forge`](https://github.com/heckmon/code_forge), the author's own Flutter package that wraps a Rust core using rope and sum-tree data structures (the same shape the Zed editor uses). Multi-cursor edits and large files stay responsive on mid-range Android hardware. - **LSP, not regex.** Settings configures Language Server Protocol servers for popular languages — proper completions, hover docs, go-to-definition, and diagnostics instead of text-based highlighting. - **Bring-your-own AI.** The model picker covers Gemini, Claude, OpenAI, Grok, DeepSeek, Groq, TogetherAI, Perplexity, OpenRouter, Fireworks, and a custom endpoint, with selectable agentic protocols (OpenAI-compatible, Anthropic Messages, Gemini Function Calling, or none). GitHub Copilot is wired in via device-code OAuth. - **Offline AI.** GGUF models can be downloaded or sideloaded for in-app chat and inline completion without a network round trip. - **Bundled toolchain.** First launch materialises `bin/`, `lib/`, and `git-core` directories, symlinks bundled `lib*.so` files onto conventional names (`bash`, `sh`, `python`, `kotlinc`, ...), and drops a Node binary so the embedded xterm frontend has something to talk to. ## How it works State is split across roughly a dozen BLoCs that `main.dart` wires together with `MultiBlocProvider` (`ConfigBloc`, `FolderBloc`, `RepoStatusBloc`, `GithubAuthCubit`, `AIBloc`, `CopilotBloc`, and more). Each isolates a concern so the 2,500+ line `EditorPage` can stay focused on tabs, dirty-file tracking, the drawer, and previews. Git and GitHub support runs on top of `git-core` invoked through the embedded shell. `RepoStatusBloc` parses `git status`, `git branch`, `git stash`, and `git log` directly, while `GithubAuthCubit` stores the OAuth token in `flutter_secure_storage` and caches the user JSON in `SharedPreferences`. AI chat history is serialised the same way, and AI-suggested edits are applied through `diff_match_patch` hunks. `settings.dart` exposes light/dark mode, an editor theme picker, eight bundled monospaced fonts (Fira Code, Cascadia, Hack, DejaVu Sans Mono, Inconsolata, JetBrains Mono, Proggy, Source Code Pro), and per-theme terminal presets rendered in a live `xterm` preview. ## Caveats - **Android-only.** No iOS build. The start-screen symlink map and the Termux integration are all Android-specific. - **Large download.** Compilers and interpreters live in Git LFS, so a fresh clone is light but a release build is not. - **Termux is the backend.** Heavy workflows depend on Termux having its `pkg` packages up to date. - **Single-maintainer pace.** The repo is owned by a solo author, so feature requests and Copilot outages can take time. The MIT licence lets the community fork, but there is no organisation behind it. ## Deployment notes Roxum IDE ships as a Play Store app, with APKs on the GitHub Releases page for users in regions without Play access. ```bash git clone https://github.com/heckmon/roxum-ide.git cd roxum-ide flutter pub get git lfs pull cd android && ./gradlew :app:bundleRelease # convert AAB to APK with bundletool, then: bundletool install-apks --apks=app.apks ``` **Minimum device:** Android 8+ (API 26) with ~300 MB free for the installed toolchain assets. LSP servers and GGUF models add more on top. **Integration tip:** if you run a directory site (Astro, Grove, Next.js), Roxum IDE is a good "see it in action" example for any app tagged `mobile-ide`, `flutter`, or `developer-tools` — it shows off what a self-contained Flutter + Rust FFI project looks like end to end. ### rustdesk RustDesk is a self-hostable, cross-platform remote desktop application written in Rust with a Flutter UI, offering an open-source alternative to TeamViewer and AnyDesk for screen sharing, file transfer, and unattended access. - slug: rustdesk - category: developer-tools - stack: flutter - stars: 122512 - license: AGPL-3.0 - repo: https://github.com/rustdesk/rustdesk - url: https://openappscout.com/apps/rustdesk - lastCommit: 2026-09-03 - added: 2026-08-11 #### Detail # RustDesk RustDesk is an open-source, self-hostable remote-desktop application written in Rust with a Flutter UI, supporting Windows, macOS, Linux, iOS, Android, and a web client. It speaks a custom protobuf-over-TCP/UDP protocol with end-to-end encryption (X25519 + XSalsa20-Poly1305), uses TCP hole-punching for direct P2P, and falls back to a relay server when NAT traversal fails. The client and the basic server are AGPL-3.0; the features that make it enterprise-ready (web console, OIDC SSO, audit logs, address-book sync, mobile console) are in a closed-source commercial Pro tier. ## The right architecture, built in the right language The standard remote-desktop client in 2026 is a heavy C++/Qt binary with platform-specific capture paths and a fragile codec layer. RustDesk rejected that pattern. The system layer — capture, codec selection, input, networking, crypto — is **Rust**. The UI is **Flutter** (after the project migrated away from Sciter in 2022). The FFI bridge is `flutter_rust_bridge` v1.80. The same Rust code ships as `cdylib + staticlib + rlib`, which is the cleanest production example of the "Rust core, three targets" pattern. The capture stack is platform-specific and well-chosen: - **macOS**: Apple's **ScreenCaptureKit** via the `cidre` crate (vendored fork). ScreenCaptureKit is the only modern path to high-FPS, low-latency capture without TCC gymnastics. - **Windows**: **DXGI Desktop Duplication** via `scap-direct3d`. - **Linux**: **PipeWire** via the `pipewire` crate, with the **XDG portal** (`ashpd`) for permission prompts. X11 fallback via `x11rb` + `xfixes`. PulseAudio/PipeWire for audio via `cpal`. The `scap-*` crate family is the unifying abstraction. The recording crate is platform-agnostic; the platform-specific impls plug in via Cargo feature flags. This is the textbook way to write cross-platform Rust. The video codec is FFmpeg-driven, with hardware acceleration via NVENC, VA-API / QuickSync, and VideoToolbox. Codec selection is env-var / CLI, not a GUI. ## They built their own protocol, and that's the right call RustDesk is **not VNC, not RDP, not Guacamole at the wire level**. It is a custom protobuf-over-TCP protocol with **KCP** (a fast ARQ reliable UDP) underneath for transport, plus hole-punching rendezvous. The team owns the key exchange, the codec negotiation, the relay semantics, and the mobile-friendly compression. The cost is real: the same deserialization path that bit them in CVE-2022-41082 bit them again in CVE-2025-31186. The two-server split is the classic VoIP/P2P architecture: - **`hbbs`** — the ID/rendezvous server on port 21116 (TCP + UDP). Tiny packet-per-online-client traffic; can run on a $5 VPS. - **`hbbr`** — the relay server on port 21117. Forwards opaque TCP traffic when direct P2P fails. The relay sees ciphertext only, because session encryption happens at the application layer with the host's public key. The split is deliberate: hbbs is essentially a directory (different trust posture, different scaling profile), hbbr is a packet forwarder (different scale, different cost). This is the same architecture Janus/Mediasoup and WebRTC SFU designs converge on. ## End-to-end encryption is the headline The crypto stack is the part of RustDesk that is genuinely strong: - **Key exchange**: X25519 ECDH (NaCl `crypto_box_keypair`). - **Symmetric cipher**: XSalsa20 stream cipher with Poly1305 MAC (NaCl `crypto_box_beforenm`). - **Library**: `nacl` crate — wrapper around libsodium / NaCl. - **Key distribution**: host publishes its Curve25519 public key in the `hbbs` console; the client pastes it under Settings → Network → ID/Relay Server. The relay hop is encrypted, which means a compromised `hbbr` cannot read session contents. The metadata is exposed (which IDs are online, traffic volume per session), and the FAQ leaks the bandwidth range: 30 KB/s to 3 MB/s at 1920×1080 with screen updates. There are two documented footguns: 1. **Direct-IP / LAN mode is unencrypted by design** (the FAQ is explicit). Direct IP access is disabled by default for this reason. 2. **Key mismatch errors are common.** The hbbs key is per-server; clients must be told which key to trust, and the first connection must deliver the key. ## The security history is real, and the response is on cadence RustDesk has had two severe unauthenticated-RCE CVEs in three years, both in `hbbs`'s deserialization path. The pattern is the same: insecure use of `serde_json::from_slice` combined with `rmp_serde` decoder. The first (CVE-2022-41082, CVSS 9.8) was a critical RCE that initially triggered a panic (DoS) before being exploited for full RCE. Fixed in 1.2.0. The second (CVE-2025-31186, CVSS 8.1) was a March 2025 unauthenticated RCE in the same class. Fixed in 1.4.1. Anyone self-hosting should be on **1.4.9** (current as of 2026-07-06) and should firewall `hbbs` from the public internet unless behind a reverse proxy with strong ACLs. The response has been on a normal disclosure cadence. Patches ship alongside advisories. ## The Pro split is real The OSS edition is fully self-hostable and includes end-to-end encryption, file transfer, audio, clipboard, multi-monitor, Wake-on-LAN, privacy mode, 2FA TOTP, and the whiteboard. The Pro edition gates: - **WebSocket web client** (the OSS web client is a Flutter-web build that talks to ports 21118/21119, which are Pro-only). - **TCP hole punching alongside WebSocket** (Pro). - **User/group management, address book sync, audit logs** (Pro). - **OIDC SSO, multi-tenant, web console, mobile console** (Pro). - **API access** (Pro). Pricing is **$11.88/month for self-hosted Pro** (annual billing) and **$9.90/month for cloud-hosted Individual**. You are paying rent on infrastructure you operate for the Pro tier, which is itself notable. The OSS-only path is genuinely usable for a 1-to-1 remote-support workflow. It is not a polished enterprise product on par with TeamViewer or AnyDesk for non-technical end users. ## Where RustDesk is the best choice - A technical user who wants to self-host an end-to-end-encrypted remote-desktop with mobile clients. - An SMB that can accept the $11.88/month/server Pro license for the audit logs, address book, and web console. - A privacy-conscious user replacing TeamViewer or AnyDesk. ## Where RustDesk is not the right choice - A non-technical user who wants to "just connect to my mom's PC." TeamViewer or AnyDesk will be easier. - An enterprise with hundreds of endpoints and MDM requirements. TeamViewer is still the incumbent. - A user who needs sub-16ms latency for creative work. Parsec is the right tool. - A user who needs a clientless browser-based gateway. Apache Guacamole is the open-source answer there. - Anyone self-hosting without firewalling `hbbs` aggressively. ## Deployment notes Self-hosting is the explicit default path. The `rustdesk-server` repo ships Docker Compose, Kubernetes manifests, and bare-metal instructions. The required ports are: | Port | Purpose | |---|---| | 21114 | TCP — needed for Pro users without an SSL proxy | | 21115 | TCP — NAT test / heartbeat | | 21116 | TCP + UDP | ID registration and rendezvous (hbbs) | | 21117 | TCP — Relay (hbbr) | | 21118-21119 | TCP — WebSocket (Pro web client) | TLS is optional and supported via Let's Encrypt behind nginx/Caddy. The relay traffic is end-to-end-encrypted at the application layer regardless of TLS, so TLS is for control-channel authentication, not for media confidentiality. Generate a Curve25519 keypair on the server, paste the public half into the client. Stay on 1.4.x for the hbbs deserialization fix. ## Developer lessons worth borrowing - **The "Rust + Flutter" split is right for cross-platform system apps.** Rust owns the system layer (capture, codec, networking, crypto); Flutter owns the UI. The FFI bridge is `flutter_rust_bridge` with type generation. - **The two-server split (`hbbs` + `hbbr`) is the classic VoIP/P2P pattern.** Different scaling profiles, different trust posture, different cost. Worth studying for any project that needs rendezvous + relay. - **Rolling your own protocol means owning its security review.** The two `hbbs` deserialization CVEs are the cost. The lesson: if you must roll your own, audit the deserialization path before shipping, not after. - **Hardware-accelerated capture is platform-specific.** The `scap-*` crate family is the right abstraction: platform-agnostic interface, platform-specific impls via Cargo feature flags. - **The web client gives up direct TCP hole punching.** Browsers don't expose raw TCP. The Flutter-web build is relay-only, which is why the Pro tier exists for it. ## How RustDesk compares The "remote access" market is dominated by closed-source SaaS. RustDesk is the strongest open-source answer for direct TCP/UDP remote control across Windows, macOS, Linux, iOS, Android, and the browser. | Project | License | Self-host | Cross-platform | "Direct" connection | Browser client | License | Best for | |---|---|---|---|---|---|---|---| | **RustDesk** | AGPL-3.0 (server + client) | Yes (one Docker image, hbbs + hbbr) | Windows, macOS, Linux, iOS, Android, Web (Flutter) | Yes (default, with relay fallback) | Yes (Flutter web; Pro adds more features) | Free for personal use; Pro adds audit logs, 2FA, custom branding, advanced web features | A small team or homelab that wants TeamViewer-class control without a SaaS dependency | | **TeamViewer** | Closed-source | No (hosted service) | Windows, macOS, Linux, iOS, Android, Web | No (always routed through TeamViewer servers) | Yes | Paid | A large enterprise with vendor support contracts and global compliance needs | | **AnyDesk** | Closed-source | No (hosted service) | Windows, macOS, Linux, iOS, Android, Web | No | Yes | Paid | A team that wants a lighter, faster alternative to TeamViewer | | **Parsec** | Closed-source | No (hosted service) | Windows, macOS, Linux, Android | Direct P2P with NAT traversal | No | Free for personal use; paid for teams | Low-latency cloud gaming, design work, collaboration on graphically intensive apps | | **NoMachine** | Free for personal use / commercial license | No (hosted service) | Windows, macOS, Linux, iOS, Android | Direct | Yes (HTML5) | Free for personal use | A user who wants a polished NX protocol with hardware acceleration | | **Apache Guacamole** | Apache-2.0 (server) | Yes (HTML5 + Java) | Browser only (clientless) | Direct through gateway | Yes (browser-only) | Free | A sysadmin who wants a browser-based bastion to RDP/VNC/SSH without per-user clients | | **MeshCentral** | Apache-2.0 | Yes (Node.js) | Browser + native agents | Through MeshCentral server | Yes | Free | An admin who wants a self-hosted management console with remote desktop, terminal, and file transfer | **Pick RustDesk** if you want a TeamViewer-class experience on your own hardware with a permissive AGPL-3.0 license and a real self-host story. **Pick TeamViewer / AnyDesk** if your organisation has a vendor contract and you need SLA-backed support. **Pick Parsec** if the workload is graphical (design, video, games) and you want the lowest possible latency. **Pick NoMachine** if you want a polished NX protocol with hardware acceleration and do not need self-hosting. **Pick Apache Guacamole** if the deployment is a browser-only bastion that needs to broker RDP, VNC, and SSH sessions centrally. **Pick MeshCentral** if you want a self-hosted management console with remote desktop, terminal, and file transfer in one tool. ## Verified sources - RustDesk repository: - RustDesk server docs — `hbbs` (relay) and `hbbr` (relay) Docker images at . - License — `LICENSE` in the repository (AGPL-3.0). - Pro tier features — . - Comparison facts about other products — drawn from each vendor's own published feature pages; not affiliated reviews. ### Shieldxy An auditable macOS application firewall and connection monitor with explicit local network controls. - slug: shieldxy - category: tools - stack: ios - stars: 1 - license: AGPL-3.0 - repo: https://github.com/RockxyApp/Shieldxy - homepage: https://rockxy.io/shieldxy - url: https://openappscout.com/apps/shieldxy - lastCommit: 2026-08-09 - added: 2026-08-27 ### sossoldi Sossoldi is an MIT-licensed, Flutter-built personal wealth manager that tracks net worth, expenses, income, and investments across iOS, Android, macOS, Windows, Linux, and the Web from a single Dart codebase. - slug: sossoldi - category: finance - stack: flutter - stars: 1392 - license: MIT - repo: https://github.com/RIP-Comm/sossoldi - url: https://openappscout.com/apps/sossoldi - lastCommit: 2026-08-24 - added: 2026-08-11 #### Detail # Sossoldi Sossoldi is a free, MIT-licensed wealth management app built with Flutter by the RIP-Comm community. It exists to replace a blogger's Google Sheets net worth tracker with a friendly mobile and desktop client, so non-technical users can track net worth, expenses, and investments without touching a spreadsheet. The codebase is a single Dart project that ships to iOS, Android, macOS, Windows, Linux, and the Web. ## Why it matters - **Truly cross-platform from one tree.** The repo contains `android/`, `ios/`, `macos/`, `windows/`, `linux/`, and `web/` folders alongside a shared `lib/`. The same screens, charts, and database code run on a phone, a desktop, or a browser tab. - **Local-first by design.** All financial data is stored on the device using `sqflite` (with `sqflite_common_ffi` for desktop and `sqlite3_flutter_libs` for the native bindings). There is no required backend, so privacy-sensitive totals never leave the device unless the user explicitly shares them. - **Modern Flutter stack.** State is managed with `flutter_riverpod` (3.x) plus `riverpod_annotation` and `riverpod_generator`, models are built with `freezed` and `json_serializable`, and `fl_chart` powers the charts. Code generation runs through `build_runner`, and the project is pinned to Flutter 3.10.7 via an `.fvmrc` file. - **Polished UX foundation.** Assets include a custom NunitoSans font family (regular + italic weights from 200 to 900), native splash screens, generated launcher icons, and `fl_chart` visual reports — all batteries-included in the repo. ## How it works The `lib/` directory follows a conventional layered layout: `constants/`, `model/` (domain entities), `providers/` (Riverpod state), `services/` (persistence and platform plumbing), `pages/` (screen-level UI), `routes/`, and `ui/` (reusable widgets). The entry point is `lib/main.dart`, which wires the Riverpod providers into the route tree. Persistence is built around SQLite. `sqflite` provides the database on mobile, while `sqflite_common_ffi` activates the desktop bindings on macOS, Windows, and Linux. `path_provider` resolves the database file location, `shared_preferences` stores small settings, and `flutter_local_notifications` plus `timezone` power recurring transaction reminders. `local_auth` gates access behind biometrics on devices that support it. The Phase 1 feature set covers a Dashboard, a Movements page, basic Onboarding, and basic Settings, with bank account balances entered manually (PSD2 Open Banking API integration is on the roadmap). Visualization uses `fl_chart`; imports and exports flow through the `csv` and `file_picker` packages; `device_info_plus`, `package_info_plus`, `url_launcher`, and `permission_handler` fill in the platform-introspection glue. The test suite runs on `test` with `flutter_lints` enforcing style, and `dependency_validator` keeps the dependency tree honest. ## Caveats - **Early-stage roadmap.** The Phase 1 list (expenses, income, basic statistics, local-only storage) is still in progress; investment tracking, multi-currency, tax, and PSD2 integration are planned but not yet shipped. - **Spreadsheet-first origins.** The data model is designed around a single user's net worth tracker, so multi-user or household scenarios are not yet supported. - **Cross-platform data sharing is manual.** Cross-platform sharing is listed as a feature, but in the current build users move data between devices via import/export rather than sync, so there is no automatic cloud reconciliation. ## Deployment notes ```bash git clone https://github.com/RIP-Comm/sossoldi.git cd sossoldi fvm install # honors .fvmrc (Flutter 3.10.7) flutter pub get dart run build_runner build --delete-conflicting-outputs flutter run # or: flutter run -d chrome ``` **Distribution:** official builds are published on the [App Store](https://ios.sossoldi.com), [Google Play](https://android.sossoldi.com), and [F-Droid](https://f-droid.org/it/packages/com.ripster.sossoldi/). Project documentation lives at ; community chat is on Discord (`discord.sossoldi.com`). **Integration tip:** if you curate an Astro/Grove directory like this one, Sossoldi is the canonical "local-first Flutter finance" example for any app tagged `personal-finance` or `wealth-management` — its single-codebase-to-six-platforms story also makes a strong reference for cross-platform Flutter showcases. ### storypad Storypad is an offline-first Flutter diary and journal app that uses a timeline instead of folders, layers mood tracking, photo memories, and customizable typography over a local ObjectBox store with optional Google Drive sync. - slug: storypad - category: productivity - stack: flutter - stars: 951 - license: GPL-3.0 - repo: https://github.com/theachoem/storypad - url: https://openappscout.com/apps/storypad - lastCommit: 2026-08-26 - added: 2026-08-11 #### Detail # Storypad Storypad is an open-source diary and journal app for Android, iOS, and macOS that ships from a single Flutter codebase. Despite the name suggesting a fiction-writing or Wattpad-style platform, it is a private, on-device journaling tool modeled closer to Day One than a publishing surface: every entry lives on one reverse-chronological timeline, with no folders or notebooks to organize. ## Why it matters - **Timeline-first model.** The product bet is that most journal apps bury users in folder/tab structure they never revisit. Storypad collapses everything into a single infinite timeline ordered by entry date, with a "throwback" surface that surfaces past entries written on this day in previous years. - **Customizable writing surface.** Entries are built on a customized fork of `flutter_quill` (pinned to a specific commit via `git:` ref) that exposes 1300+ Google Fonts, per-entry color theming, lists, headers, and embedded photo memories. Mood tracking layers on top with 45+ curated emotion tags. - **On-device by default, cloud as opt-in.** The primary store is `objectbox` (NoSQL) running locally; Firebase (Firestore, Auth, Storage, Analytics, Crashlytics, Remote Config) is wired in for users who explicitly enable Google Drive backup. Local-only users can keep their diary completely offline. - **Privacy gates that actually work.** PIN, FaceID, and fingerprint unlock are implemented via `local_auth` and `flutter_secure_storage`, so the OS-level biometric prompt gates app entry rather than being purely a UX flourish. - **Monetization that respects free users.** Pro features (templates, backgrounds, relaxing sounds, period calendar, voice journal, markdown export, writing stats, pinned notes, auto-backup) are gated behind a one-time `purchases_flutter` purchase. The core journaling loop is fully usable without paying. ## How it works The architecture is a textbook Flutter MVVM split. `lib/models/` holds the ObjectBox entities (`Story`, `StoryPage`, `Asset`, `Moment`, etc.); `lib/views/` and `lib/widgets/` hold the UI tree; `lib/view_models/` hold the per-screen ChangeNotifier business logic; and `lib/providers/` wires it together with a three-tier Provider scope (global `ProviderScope`, view `ChangeNotifierProvider`, widget `StatefulWidget`). The writing surface (`lib/views/quill/`) is a thin wrapper around the forked `flutter_quill` package that adds Storypad-specific delta handling and asset embedding. Local persistence is an ObjectBox database with the schema defined in `objectbox-model.json` and generated by `objectbox_generator`. Cloud sync is split across `lib/services/cloud/` modules that talk to Firebase Firestore for metadata and Firebase Storage for media. Backup and restore flow through `tar` for export bundles and a custom sync engine that reconciles ObjectBox state with Firestore documents. The `bin/dev` entrypoint exposes platform-specific runners: `--community` (Android), `--community-ios` (iOS), and `--community-macos` (macOS), with `flutter_flavor`-style build config under `android/app/build.gradle.kts` and `ios/Flutter/`. ## Caveats - **GPL-3.0.** Modifications and forks must stay open-source under the same license, which is unusual for a personal app and worth flagging for downstream use. - **Firebase is in the dependency graph regardless of choice.** Even users who never sign in have Firebase Crashlytics, Analytics, and Remote Config compiled into the binary; only Firestore/Auth/Storage are gated behind the cloud-sync toggle. - **Pre-1.0 versioning.** Version `2.32.1+798` in `pubspec.yaml` is not yet on a SemVer-stable release. Expect occasional schema churn on the ObjectBox side. - **macOS is desktop-flavored mobile, not a native windowing app.** The desktop build shares most of the mobile UI rather than offering a distinct macOS layout. ## Deployment notes ```bash git clone https://github.com/theachoem/storypad.git cd storypad flutter pub get dart run build_runner build # ObjectBox + copy_with codegen bin/dev --community # Android bin/dev --community-ios # iOS (requires Xcode + signing) bin/dev --community-macos # macOS (requires macOS host) ``` Prerequisites: Flutter 3.x with Dart 3, Xcode for iOS/macOS targets, Android Studio for Android, and a Firebase project (optional) if you want to test the cloud-sync path. **Integration tip:** if you curate an Open Apps record tagged `diary`, `journal`, or `offline-first`, link Storypad alongside Day One and similar entries — its real niche is the single-timeline UX and the GPL-3.0 commitment to keeping the on-device store open, not feature parity with commercial journals. ### Swift-Radio-Pro Swift-Radio-Pro is a Swift iOS streaming-audio reference app that plays live radio from a list of stations, surfaces now-playing metadata and album art, and integrates with the lock screen and Control Center. - slug: swift-radio-pro - category: media - stack: ios - stars: 2939 - license: MIT - repo: https://github.com/analogcode/Swift-Radio-Pro - url: https://openappscout.com/apps/swift-radio-pro - lastCommit: 2026-07-05 - added: 2026-06-13 #### Detail # Swift-Radio-Pro Swift Radio Pro is a Swift iOS streaming-audio app template that wires up the complete radio-station experience: a list of stations loaded from JSON, live-stream playback, now-playing metadata and album art, background audio, and lock-screen / Control Center / CarPlay controls. It has been forked and re-skinned into dozens of App Store apps and is widely cited as the canonical iOS starting point for live-radio apps. ## Why it matters - **Reference architecture for iOS radio.** The project demonstrates the full streaming-radio pattern end-to-end: stations JSON, audio session, streaming player, metadata refresh, album art, lock-screen controls, and an About screen. For anyone building a music, talk, or radio app on iOS, it is the most-cited starting point in the open-source scene. - **Built on FRadioPlayer.** The streaming layer wraps [FRadioPlayer](https://github.com/fethica/FRadioPlayer), a community project that handles ICY metadata parsing, iTunes artwork lookups, and the AVPlayer wiring in one place. Swift Radio Pro is the showcase app for that library and a good place to see it used in anger. - **Reference, not actively shipped.** The repo has been quiet for years and now receives only sporadic maintenance by the original author and contributors. Treat it as a starting template: read the code, copy the patterns you like, and update the iOS / Swift APIs to current versions before shipping. ## How it works The app boots from `SceneDelegate`, which kicks off `AudioSetupService.shared` to configure everything before the first station plays. `setupAudioSession()` activates an `AVAudioSession` with `.playback` category, `.mixWithOthers`, and `.allowBluetoothHFP` so the stream keeps going when the device locks, Bluetooth headsets connect, or another app's audio is already playing. `setupFRadioPlayer()` enables autoplay and points the player at the `iTunesAPI` artwork provider so album images get filled in when the stream's own metadata only ships the track title. `setupRemoteCommandCenter()` wires up `MPRemoteCommandCenter` for the lock screen and Control Center: play, pause, stop, toggle play/pause, next track, and previous track. Stop is only enabled for live streams (there is nothing to seek back to), and pause is disabled on live streams for the same reason. `UIApplication.beginReceivingRemoteControlEvents()` is called so the app receives transport-button events even when it is in the background. Stations themselves live in `SwiftRadio/Data/stations.json`, an array of `name` / `streamURL` / `imageURL` / `desc` / `longDesc` / `website` entries that ship with the app or are pulled from `Config.stationsURL` when `Config.useLocalStations = false`. The UI layer is UIKit with a `StationsViewController` listing, a `NowPlayingViewController` driven by `LNPopupController` for the bottom popup bar, and a separate CarPlay scene template in `Info-CarPlay.plist`. Marquee labels scroll long station and track names, and `NVActivityIndicatorView` provides the loading state while a stream buffers. ## Caveats - **iOS APIs have moved on.** The project deploys back to iOS 13 in some build configurations and iOS 16 for the main target. Lock-screen behavior, `MPRemoteCommandCenter` semantics, and CarPlay scene templates have all changed since the original release, so expect to audit the audio-session and remote-control code against the latest Apple documentation before shipping. - **HTTP streams, no DRM.** The bundled `stations.json` contains plain `http://` stream URLs and the app sets `NSAllowsArbitraryLoads = true` in `Info.plist`. There is no DRM, no signed-URL handling, and no station-auth flow. Any production fork needs to lock that down with ATS exceptions scoped to the actual streaming hosts, or move to HTTPS streams. ## Deployment notes ```bash git clone https://github.com/analogcode/Swift-Radio-Pro.git open SwiftRadio.xcodeproj ``` Xcode resolves the Swift Package Manager dependencies (`FRadioPlayer`, `LNPopupController`, `MarqueeLabel`, `NVActivityIndicatorView`) on first open. Edit `SwiftRadio/Config/Config.swift` to point `stationsURL` at your own JSON file (or set `useLocalStations = true` to keep the bundled sample stations), update the `contact` / `website` / `feedbackURL` strings, and change the bundle identifier before deploying. The `Info.plist` already declares `UIBackgroundModes = [audio]` for background playback and `UIUserInterfaceStyle = Dark` for the locked-in dark theme. Build to a device to exercise real lock-screen and Bluetooth behavior — the simulator silently skips much of the audio-session and remote-command plumbing. **Integration tip:** treat Swift Radio Pro as a starting template for new radio or live-streaming iOS apps — copy the audio-session setup, the `MPRemoteCommandCenter` wiring, and the stations-JSON model, then replace the FRadioPlayer dependency with a more current streaming library if your target iOS version has moved past what it supports. ### SwiftHub SwiftHub is an iOS GitHub client built on RxSwift and MVVM-C clean architecture, wiring Moya (REST v3) and Apollo (GraphQL v4) behind a flow-coordinator navigation graph with OAuth2 and personal-access-token authentication. - slug: swifthub - category: tools - stack: ios - stars: 3117 - license: MIT - repo: https://github.com/khoren93/SwiftHub - url: https://openappscout.com/apps/swifthub - lastCommit: 2026-02-15 - added: 2026-06-13 #### Detail # SwiftHub SwiftHub is a third-party iOS client for GitHub built around RxSwift and the MVVM-C (Model-View-ViewModel with Coordinators) pattern, aimed at iOS developers who want a reference for wiring up a real GitHub API client on top of clean-architecture boundaries. ## Why it matters - **A full GitHub client, not a sample screen.** SwiftHub covers authentication, trending repositories and developers, search, full repository and user detail pages, issues, pull requests, commits, events, releases, branches, notifications, and source-file viewing with syntax highlighting. It is one of the most complete open-source GitHub clients available on iOS. - **MVVM-C + clean architecture done in anger.** The codebase is organised around a coordinator-driven navigation graph with feature modules in `SwiftHub/Modules/` (Repositories, Repository Details, Search, Issues, Pull Requests, User Details, Notifications, Settings, Theme, etc.), each with its own ViewModel and ViewController. It is a useful study reference for iOS engineers learning the coordinator pattern. - **Largely a reference project today.** Activity has slowed: the monthly commit count has been near zero through 2026 outside a brief push in February, the last release tag (`v1.10.0`, "RxSwift 6.x support") shipped in October 2021, and 27 open issues sit unanswered. Treat it as a maintained-but-quiet architectural reference rather than a living product. ## How it works The networking layer is split between two protocols sharing a common `SwiftHubAPI` definition in `SwiftHub/Networking/Api.swift`. The REST v3 surface is implemented with Moya (`Moya/RxSwift ~> 15.0`) and `Moya-ObjectMapper/RxSwift` for typed JSON mapping, and the GraphQL v4 surface — used once a user is authenticated — is built with Apollo iOS (`0.53.0`). `Application.updateProvider()` upgrades the `SwiftHubAPI` provider from `RestApi` to `GraphApi(restApi:token:)` when a valid OAuth2 or personal-access token is present, so unauth calls stay on REST while authenticated traffic uses the GraphQL gateway. Navigation is coordinator-driven. `Application` owns a singleton `Navigator`, `AuthManager`, and the active provider; on launch it checks `authManager.token?.isValid` and routes either to a login flow or to `HomeTabBarViewModel` via `navigator.show(segue: .tabs(...), transition: .root(in: window))`. Feature modules subscribe to their own input / output ReactiveSwift-style streams, expose `ViewModelType` protocols, and the AppDelegate-level coordinator graph owns the transitions. Dependency injection is handled by Swinject, registered in `Configs/`. UI is programmatic: SnapKit for layout, Hero for custom transitions, RxTheme for light/dark theme switching, MessageKit for issue and PR conversation threads, Charts for star-history and lines- of-code counters, Highlightr for source-file syntax highlighting, and WhatsNewKit for release-note screens. Localization runs through Localize-Swift (English, Chinese, Russian, Armenian), and FLEX is swiped in for in-app debugging on debug builds. ## Caveats - **Maintenance is light.** As of mid-2026 the repo has had no GitHub release since `v1.10.0` in October 2021, the monthly commit count is essentially zero, and 27 issues are open with no recent triage. The codebase compiles against the iOS toolchains in Xcode 13+ era but is not actively tracking new SwiftUI or Swift Concurrency APIs. - **GitHub API rate limits apply.** Anonymous REST v3 traffic is limited to 60 requests / hour per IP, and authenticated OAuth or PAT traffic is capped at 5,000 requests / hour. Trending repositories and developers come from a separate `codetabs` / GitHub trending proxy, which adds a third-party dependency outside GitHub's control. - **OAuth2 secrets live in the source tree.** The GraphQL flow uses a checked-in client ID; for your own builds you need to register a GitHub OAuth App and substitute the credentials before the authenticated screens will function. ## Deployment notes SwiftHub builds with the standard Xcode + CocoaPods + Fastlane toolchain. The repo ships a `Podfile` pinning Moya, Apollo, RxSwift extensions, Kingfisher, R.swift, SwiftLint, Firebase Analytics / Crashlytics / AdMob, Mixpanel, and FLEX, plus a `Gemfile` driving Fastlane lanes for setup, update, and App Store submission. Initial project setup runs through `bundle exec fastlane setup` after `bundle install`; list available automation with `bundle exec fastlane lanes`. ```sh git clone https://github.com/khoren93/SwiftHub.git cd SwiftHub bundle install bundle exec fastlane setup open SwiftHub.xcodeproj ``` You will need a GitHub OAuth App client ID and secret in `Configs/` (or the equivalent Info.plist keys the project reads at launch) to exercise the OAuth2 login flow; personal access tokens work without OAuth setup. The Info.plist must declare the `LSApplicationQueriesSchemes` entries used for in-app repository cloning via SwiftGit2 and for opening GitHub URLs. Tests live in `SwiftHubTests/` (Quick + Nimble + RxBlocking) and the UI test target is `SwiftHubUITests/`. **Integration tip:** if you operate a directory like this one and need a reference for wiring a real GitHub-shaped API into a Swift app, SwiftHub is the cleanest open example — mirror its `SwiftHub/Modules/` per-module MVVM-C layout, its split between Moya (REST) and Apollo (GraphQL) providers, and its `Navigator` + coordinator-based root transition before designing your own client. ### SwiftTerm An Xterm/VT100-compatible terminal emulator implemented in Swift for iOS. - slug: swiftterm - category: tools - stack: ios - stars: 1678 - license: MIT - repo: https://github.com/migueldeicaza/SwiftTerm - url: https://openappscout.com/apps/swiftterm - lastCommit: 2026-09-03 - added: 2026-06-13 ### thunderbird-ios Thunderbird for iOS – Open Source Email App for iOS. - slug: thunderbird-ios - category: communication - stack: ios - stars: 1173 - license: MPL-2.0 - repo: https://github.com/thunderbird/thunderbird-ios - url: https://openappscout.com/apps/thunderbird-ios - lastCommit: 2026-09-02 - added: 2026-06-13 ### Tracexy A native, local-first macOS app for capturing live network traffic and investigating PCAP and PCAPNG files. - slug: tracexy - category: developer-tools - stack: ios - stars: 126 - license: AGPL-3.0 - repo: https://github.com/RockxyApp/Tracexy - homepage: https://rockxy.io/tracexy - url: https://openappscout.com/apps/tracexy - lastCommit: 2026-09-02 - added: 2026-08-27 ### Tura Build agent that uses 80% less token and delivers better results. - slug: tura - category: tools - stack: tauri - stars: 612 - license: AGPL-3.0 - repo: https://github.com/Tura-AI/tura - url: https://openappscout.com/apps/tura - lastCommit: 2026-08-20 - added: 2026-07-19 ### Twenty Twenty is an open-source CRM whose data model is a runtime artifact — every custom object, field, view, role, and AI agent is a row in metadata tables, with the GraphQL schema and SQL queries rebuilt per workspace on demand. Written in TypeScript with NestJS, React, PostgreSQL, and a native MCP server for Claude/ChatGPT/Cursor. - slug: twenty - category: business - stack: react - stars: 56145 - license: NOASSERTION - repo: https://github.com/twentyhq/twenty - homepage: https://twenty.com - url: https://openappscout.com/apps/twenty - lastCommit: 2026-09-03 - added: 2026-09-01 #### Detail # Twenty Twenty is an open-source CRM where the schema is a runtime artifact, not a database. Every custom object, field, view, role, agent, and skill is a row in PostgreSQL metadata tables; the GraphQL schema, resolvers, and SQL queries are rebuilt per workspace on demand. That single choice — metadata-as-rows — is what makes the platform cohere: code-defined apps that publish into the same data model, an MCP server that exposes the same data model to Claude and Cursor, and a 4-service Docker stack that inherits the same model. The closest comparison isn't SuiteCRM or EspoCRM — it's a values-level cousin of Directus or Strapi, wearing a CRM-shaped UI. The headline numbers are real and they set the tone: **55.2k stars, 8.6k forks, 14,574 commits, three releases on a single day in August 2026**, $5M seed (led by Runa Capital, with angels from Front, HubSpot, Strapi, and the ex-Pipedrive CEO), YC S23, and 280+ contributors. The project is the most-funded, most-starred, and most actively shipped open-source CRM. The interesting question is whether the engineering matches the velocity. ## The architecture is one decision, properly cascaded Look at `packages/twenty-server/src/engine/metadata-modules/object-metadata/object-metadata.entity.ts` and the metadata is unsurprising: an `ObjectMetadataEntity` is a row with `nameSingular`, `description`, `icon`, `isActive`, `isRemote`, `targetTableName` (now deprecated), `duplicateCriteria` (JSONB), and a `OneToMany` to `FieldMetadataEntity`, `IndexMetadataEntity`, `SearchFieldMetadataEntity`, permissions, and views. Anything a user can define in the UI is a row in this table, and `FieldMetadataEntity` rows hang off it the same way. What matters is what cascades from that decision. Because schemas are rows, no per-tenant migrations are needed. Because schemas are rows, the GraphQL pipeline can't be static — Twenty substitutes a four-layer runtime pipeline: `workspace-schema-builder/` produces SDL strings, `workspace-graphql-schema-sdl/` caches them per workspace, `workspace-resolver-builder/` builds the resolver tree, and `workspace-query-builder/` + `workspace-query-runner/` translate and execute the queries. They're stitched together by `workspace-schema.factory.ts` using `@graphql-tools/schema`'s `makeExecutableSchema`. This is the central learning: a metadata-driven product has to invent a runtime GraphQL pipeline before it has a CRM. The cascade continues. A custom ORM at `engine/twenty-orm/` introspects per-workspace tables created from metadata and routes queries to the right physical table. There's a dual representation — every metadata entity has a parallel `flat-*` module (e.g. `flat-object-metadata`, `flat-view`) holding a denormalized key→entity map for cache lookup. The frontend at `packages/twenty-front/src/modules/` is feature-sliced into 50+ domain modules (`object-record`, `views`, `workflow`, `ai`, `auth`, `apollo`, `metadata-store`, …) and renders dynamic objects/fields through view components (`record-table`, `record-board`, `record-calendar`, `record-list`, `record-show`, `record-card`, `record-inline-cell`) all driven by runtime metadata. State is Jotai with the Apollo cache as source of truth. The cost is real. The custom ORM gives up Drizzle/Prisma ergonomics; the query planner has more moving parts; debugging a runtime-built GraphQL schema is harder than reading a static `.graphql` file. Twenty's version is **v2.30.0** at the time of writing (Aug 11, 2026), and the GitHub search tag history shows the team has been paying that cost, fix-by-fix, since launch. The trade was the right one. ## The apps framework is honest about being code The SDK at `packages/twenty-sdk/src/sdk/define/index.ts` exposes a paired `define*` + `*Config` function for every entity type a user can create: `defineObject`, `defineField`, `defineView`, `defineViewField`, `defineRole`, `defineApplicationRole`, `defineSkill`, `defineAgent`, `defineApplication`, `defineConnectionProvider`, `defineNavigationMenuItem`, `defineIndex`, `definePermissionFlag`, `defineLogicFunction`, `defineFrontComponent`, `defineSettingsFrontComponent`, `definePageLayout`, `definePageLayoutTab`, `defineCommandMenuItem`. Each is paired with install/uninstall/pre/post lifecycle variants. Field types include `ActorField`, `AddressField`, `CurrencyField`, `EmailsField`, `FullNameField`, `LinksField`, `PhonesField`, `RichTextField`. The validation result is `createValidationResult({ config, errors, warnings })` — meaning validation happens at build time, not at deploy time. The scaffolding is `npx create-twenty-app@latest my-app`. Publishing is `npx twenty app:publish --private`. The bundle works across runtimes because the SDK ships separate Vite configs for browser/node/front-component/logic-function/billing (`vite.config.billing.ts`, `vite.config.browser.ts`, `vite.config.define.ts`, `vite.config.front-component.ts`, `vite.config.logic-function.ts`, `vite.config.node.ts`, `vite.config.utils.ts`). Server-side user code runs via three drivers selected by `LOGIC_FUNCTION_TYPE` — `disabled`, `local` (in-process), or `lambda` (AWS Lambda). Apps are resolved across workspaces by a `universalIdentifier`, which is the feature that makes "publish to your workspace" mean the same thing as "publish to someone else's workspace" without a per-tenant ID migration. The honesty is in the cost. A non-developer cannot reasonably build a Twenty app today. A Reddit r/selfhosted commenter summed it up: *"love the layout but it doesn't customize nearly as much or as easily and managed to break it trying."* That's the documented trade-off — Twenty is for engineering teams who want their CRM schema in a PR. ## The MCP server is the most defensible AI integration in any OSS CRM `packages/twenty-server/src/engine/api/mcp/mcp.module.ts` is small enough to read end-to-end. One controller (`McpCoreController`), three guards (`JwtAuthGuard`, `McpAuthGuard` for API keys, `WorkspaceAuthGuard`), three services (`McpProtocolService` for protocol parsing, `McpInstructionBuilderService` for model context, `McpToolExecutorService` for tool invocation). The module imports include `ApiKeyModule`, `SkillModule`, `UserRoleModule`, `WorkspaceCacheModule`, `WorkspaceManyOrAllFlatEntityMapsCacheModule`, and `MetricsModule`. The tool-calling surface plugs in through `engine/core-modules/tool-provider/` with `providers/`, `tools/`, `output-transforms/`, and `resolvers/` — a textbook pluggable provider pattern. The MCP server ships with every paid tier, including the $9/user Pro plan. It supports OAuth and works with Claude, ChatGPT, and Cursor. A code interpreter for AI agents runs on either a local sandboxed subprocess or the E2B managed cloud sandbox, switched by `CODE_INTERPRETER_TYPE` with `E2B_API_KEY`. Folk and Attio describe "AI" features; Attio documents an MCP-compatible developer platform. Twenty exposes the data model directly to a standard protocol, with workspace RBAC enforced. This is the closest thing to a real *AI-native* open-source CRM in production today. The marketing claim is "built for agents." The code says "AI features require supplying your own provider key" — no model ships with the OSS binary, and operation requires at least one of `OPENAI_API_KEY` / `ANTHROPIC_API_KEY` / Google (and others). That's the realistic framing. ## The license looks like three licenses The LICENSE file is **AGPLv3 with a Section 7 "Twenty Application Exception" appended**. Copyright Twenty.com, PBC (2023-present). The Application Exception is the load-bearing detail: developing, conveying, or making available an Application that interacts with Twenty through Application Interfaces does not, by itself, cause the Application to be governed by AGPLv3. Bundling Applications with libraries via official build tooling for the Twenty platform does not extend AGPLv3 to the Application. In plain terms, apps you write using the Twenty SDK can be proprietary — that's the legal bridge that makes the apps framework worth building on. Files tagged `/* @license Enterprise */` are under a separate **Twenty.com Commercial License** (proprietary). These include SSO/SAML, row-level permissions, audit logs, encryption key rotation, single-tenant isolation, SCIM, and IP allow-listing. The Enterprise code ships in the OSS repo but is gated at runtime by `ENTERPRISE_KEY` and `ENTERPRISE_VALIDITY_TOKEN` env vars. The SDK packages — `twenty-sdk`, `twenty-client-sdk`, `create-twenty-app`, `twenty-shared`, `twenty-ui`, `packages/twenty-apps` — are **MIT**. The "commercial-friendly" framing from a 2024 blog post is interpretive, not a license change. The Oct 2024 post is widely cited as a switch from AGPL to a friendlier license; the actual LICENSE file is still AGPLv3, and the friendliness lives in the Section 7 exception. Add a **Contributor License Agreement** to the stack, and the question "is Twenty really open source?" is a real one for organizations that need to fork and rebrand. It is, but the long-term commitment is conditional. Cloud pricing is competitive: **Pro $9/user/month** (yearly), **Organization $19/user/month** (adds SSO, row-level permissions, audit logs, custom domain), **Enterprise from $50k/year** (single-tenant, SCIM, IP allow-list, SLA). The MatrixCloud free self-host path is real but rough: the README and the GitHub issue list tell different stories. ## Self-hosting is real, but rough The 4-service Docker Compose (`packages/twenty-docker/docker-compose.yml`) is the whole stack: `server`, `worker`, `db` (PostgreSQL 16), `redis` (with `--maxmemory-policy noeviction`). Required env vars: `SERVER_URL`, `APP_SECRET`, `ENCRYPTION_KEY`, `FALLBACK_ENCRYPTION_KEY`, `PG_DATABASE_URL`, `REDIS_URL`, `NODE_PORT`, `FRONTEND_URL`. Healthchecks: `curl --fail http://localhost:3000/healthz` on the server, `pg_isready` on the database, `redis-cli ping` on Redis. The rough parts live in the issue tracker. **#24432 (sonarly:high, Aug 20 2026):** `/healthz` returns 200 while migrations run; an interrupted first-boot migration can wedge the database. **#24273 (sonarly:high):** the v2.31 upgrade fails on instances with apps installed but no workspaces yet. **#24240:** workspace invitation emails are never enqueued in self-hosted mode. **#16205 (open since Dec 2025):** deleted avatars/attachments are not removed from disk on local-storage self-host. RAM floor is ≥4 GB recommended. The README's "one-command Docker Compose" framing undersells the operational basics; plan to operate behind a reverse proxy with proper `X-Forwarded-For` / `X-Forwarded-Proto` headers. The 7 security advisories reported in 2026 (2 critical, 2 high, 3 moderate) are all reported by Twenty maintainers themselves — `FelixMalfait` and `prastoin` — which is a transparency signal as much as a vulnerability one. Two critical SQL injections (GHSA-mm7j-q9q3-qqwj, GHSA-jgx4-6mr9-9573), cross-workspace IDOR, two stored XSS, and two SSRF bypasses via IPv4-mapped IPv6 and HTTP redirect following. The `resolutions` block in `package.json` pins ~50 transitive dependencies to specific patched versions — a deliberate "carry the fix ourselves" pattern. Self-hosters must monitor advisories and update regularly. ## What's missing, and what the community keeps saying The 10–50-user tech-savvy team is the convergence point across independent reviewers — SentiSight (Mar 19 2026), TaskRhino (Apr 2 2026), ShipGarden (Jun 21 2026), Hyteck (Aug 2025). The reviewer-verifiable gaps: - **No native CPQ / line-item editor.** The single most-cited credibility gap. A Reddit r/selfhosted thread titled "Save yourself time - Twenty CRM is missing a crucial sales/quoting feature" closes the case in two words: "currently unviable." GitHub Discussion #21682 was closed without resolution. - **No email compose-and-send from inside the CRM.** Hyteck's Aug 2025 review: "composing/sending emails not yet available." - **No native mobile app.** Issue #23259 was closed without delivery. Issues #20945 (iPhone white screen) and #20874 (rich-text unusable with soft keyboard) remain open. - **Workflow builder is a work-in-progress.** #24428 (missing "IS" operator on text/link fields), #24431 (wrong activation status), #24420 (destructive picker action without undo). The Code node — serverless JS — is the documented workaround. No NOT logic, no undo/redo, no multi-select node movement. - **No native CSV import UI.** Migration requires writing scripts or using n8n. - **No webhook event filtering.** All event types go to the webhook URL. Cloud webhooks use a fixed IP range. The customer logos — République Française, Bayer, PwC, Windmill, Fora, Wazoku, CivicActions, OTIIMA, NIC Industries, Shiawase Home — appear in the trusted-by bar, but the six documented case studies are all SMBs (Nine Dots Ventures, Alternative Partners, NetZero, AC&T Education Migration, W3villa Technologies, Elevate Consulting). The "90% CRM cost reduction" claim from AC&T is vendor-supplied; no independent verification. ## When to choose Twenty, and when not to **Choose Twenty when** you are an engineering-led team of 5–200 people who want to version your CRM schema in git, self-host (or vendor-host) on your own infrastructure, and wire Claude and Cursor into the live data model via MCP. The lab notebook, the regulated-industry deployment, and the YC-shaped startup are the canonical fits. **Choose EspoCRM** when you want the smallest possible free admin surface, a PHP heritage you can keep forever, and zero AI features to govern. **Choose SuiteCRM** when you need a broad out-of-the-box catalog (cases, contracts, quotes, portal) and your team is comfortable with SugarCRM-era PHP. **Choose Frappe CRM / ERPNext** when you also need accounting, manufacturing, inventory, or HR on the same database. Twenty is not an ERP. **Choose Folk** when your sales motion runs on LinkedIn, you want AI assist on day one, and you don't want to operate infrastructure. **Choose Attio** when the data is the moat and you can pay $35–$99/user/mo to skip engineering work. Attio is the hosted-only incumbent with the slickest developer API. **Choose Pipedrive** when the buying decision sits with non-technical sales managers who optimize the pipeline UI above all else. **Choose Salesforce / HubSpot** when you need the full Salesforce platform (Marketing Cloud, Service Cloud, AppExchange, Einstein, sandbox orgs, territory management, industry clouds) or HubSpot's free CRM with marketing automation. Twenty is not a credible replacement for the full Salesforce platform. ## Developer lessons worth borrowing - **Metadata-as-rows is the right abstraction when "users define their own schema."** Twenty's `ObjectMetadataEntity` is a row in PostgreSQL; the GraphQL schema is rebuilt per workspace; the ORM introspects per-tenant tables. The price is a custom ORM and a four-layer runtime GraphQL pipeline. The cost is unavoidable. - **Apps as validated code, not point-and-click.** Paired `define*` + `*Config` functions return `createValidationResult` at build time. The right call if you want to ship customization as a library your developers read in PRs. - **Multiple runtime drivers for user-submitted code.** Logic functions run as `disabled`, `local`, or `lambda` switched by `LOGIC_FUNCTION_TYPE`. The same SDK works locally and in production. The Code interpreter matches the pattern with `local` vs `E2B`. - **Pluggable tool-calling for AI agents.** `engine/core-modules/tool-provider/` with `providers/` + `tools/` + `output-transforms/` is the cleanest MCP-tool surface in any open-source CRM. Worth studying if you're building an MCP integration. - **Plan license tiers in parallel with the architecture.** AGPLv3 + Section 7 Application Exception + dual-licensed Enterprise + MIT SDK packages is a deliberate structure, not a workaround. Pick which packages get which license and which features gate behind a key before writing the first line. ## How to run it ```bash git clone https://github.com/twentyhq/twenty cd twenty/packages/twenty-docker cp .env.example .env # set SERVER_URL, APP_SECRET, ENCRYPTION_KEY, FALLBACK_ENCRYPTION_KEY, PG_DATABASE_URL, REDIS_URL docker compose up -d ``` Open `http://localhost:3000`. The first boot runs migrations, then seeds the workspace. **Watch for the migration wedge** (#24432) — wait for `/healthz` to return 200 *after* the migration step (the docker-compose healthcheck races the migration). Allocate ≥4 GB RAM. For production, switch `STORAGE_TYPE` to `S_3` and back the upload paths with S3-presigned URLs. For AI features, supply at least one of `OPENAI_API_KEY` / `ANTHROPIC_API_KEY` (or any other supported provider); for the code interpreter, supply `E2B_API_KEY`. To build an app: ```bash npx create-twenty-app@latest my-app cd my-app npx twenty app:publish --private ``` Anything you `defineObject` in the app becomes a row in `object-metadata` for the workspace; `defineLogicFunction` becomes a server-side function registered with the runtime driver; the universal identifier lets it ship across workspaces without ID churn. ## Verified sources - Twenty repository: - LICENSE (AGPLv3 + Section 7 Application Exception): - Latest release v2.30.0: - Pricing: - Customers: - Docker Compose: - Generic GraphQL runtime schema factory: - MCP server module: - Object metadata entity: - Auth module: - SDK define folder: - Security advisories: - Funding coverage: , - HN Launch Jul 2023: - HN follow-up Jun 2024: - Independent reviews: (Mar 19 2026), (Apr 2 2026), (Jun 21 2026), (Aug 2025), (2026) - Direct comparison alternatives: , , , , , , ### Unwrap Learn Swift interactively on your iPhone. - slug: unwrap - category: tools - stack: ios - stars: 2333 - license: NOASSERTION - repo: https://github.com/twostraws/Unwrap - url: https://openappscout.com/apps/unwrap - lastCommit: 2026-07-14 - added: 2026-06-13 ### UTM Run virtual machines on iOS and macOS — Windows, Linux, and retro operating systems. - slug: utm - category: productivity - stack: ios - stars: 35331 - license: Apache-2.0 - repo: https://github.com/utmapp/UTM - url: https://openappscout.com/apps/utm - lastCommit: 2026-09-02 - added: 2026-06-13 ### Voicebox Voicebox is a local-first AI voice studio that bundles seven TTS engines, Whisper STT, a Qwen3 LLM for refinement and personality, and a built-in Model Context Protocol server so any MCP-aware agent can speak in a cloned voice on a single desktop install. - slug: voicebox - category: tools - stack: tauri - stars: 52225 - license: MIT - repo: https://github.com/jamiepine/voicebox - url: https://openappscout.com/apps/voicebox - lastCommit: 2026-08-09 - added: 2026-09-01 #### Detail # Voicebox Voicebox is the only consumer-facing desktop app that puts the **entire voice I/O loop on a single local machine**: text-to-speech with voice cloning, voice dictation, post-processing effects, a multi-track Stories editor, and — the unusual part — a built-in Model Context Protocol server that lets any agent (Claude Code, Cursor, Cline) speak in your cloned voice. The cloud incumbents own one half of the loop each (ElevenLabs on output, WisprFlow on input); the open-source TTS projects (OpenVoice, F5-TTS, Coqui, Kokoro) ship one engine at a time. Voicebox ships the whole thing on one install. The architectural choice that makes this possible is more interesting than the feature list. Voicebox is a Tauri (Rust) desktop shell that wraps a FastAPI (Python) ML backend as a sidecar binary, and the way the two halves coordinate is the cleanest "Tauri + ML" build the open-source desktop world has produced. ## The sidecar handshake is the real architecture The Tauri shell launches a PyInstaller-bundled `voicebox-server` as a Tauri `externalBin` sidecar and passes `--parent-pid=`. The Python side installs a watchdog thread that polls the parent PID every two seconds with a one-second grace window. When the parent goes away, the watchdog gives the shell one second to send an HTTP `POST /watchdog/disable` — a clean shutdown path. A `.keep-running` sentinel file is the fallback for Windows teardown races, where the cleanup signal can be lost mid-handshake. The result is the rare combination of "Python gets a clean shutdown" plus "a forgotten app never leaves an orphaned 4 GB torch process." GPU variant discovery is order-sensitive and version-gated. Rust checks for an ROCm build, then a CUDA build, in `data_dir/backends/{rocm,cuda}/`, runs ` --version` against the Tauri app version with a ten-second timeout, and only falls back to the bundled CPU sidecar if no GPU binary is present or its version doesn't match. This is the right answer to the "PyInstaller onedir + per-GPU fat binaries" problem that most desktop ML apps simply ignore. The seven TTS engines sit behind a `TTSBackend` Protocol in `backend/backends/__init__.py`, but the dispatch is an `if/elif` chain in `get_tts_backend_for_engine()`, not a registry. The Protocol's docstring claims each backend class should define `MODEL_CONFIGS` as a class variable; no backend class actually does. Model metadata is built by hand in module-level functions. This is a missed contribution ergonomics — adding an engine requires editing the dispatch, not registering a class — but it matches the project's velocity-versus-cleanliness trade-off. The voice cloning pipeline is the application's center of gravity. Audio files (`ProfileSample.audio_path`) flow to `tts_model.create_voice_prompt()`, which calls Qwen3-TTS's `create_voice_clone_prompt(ref_audio, ref_text, x_vector_only_mode=False)` and returns a dict of tensors. The conditioning prompt is cached on disk under `cache/.prompt` keyed by MD5 of `audio_bytes + reference_text`, reloaded via `torch.load(weights_only=True)`. Multi-sample profiles concatenate via `combine_voice_prompts` (numpy concat + text join) and re-save a combined WAV. The first generation is slow; every subsequent generation with the same voice is instant. *The architectural lesson anyone building a Tauri + ML desktop app should copy:* the IPC boundary is a parent/child process contract with a watchdog, not a "kill on shutdown" reflex. ## The MCP server is the moat against open-source peers The same FastAPI app exposes a Model Context Protocol server at `http://127.0.0.1:17493/mcp` via FastMCP, with `compose_lifespan` combining the Voicebox lifespan and FastMCP's session manager (Streamable HTTP requires the ASGI lifespan). Four tools ship with dotted names: `voicebox.speak`, `voicebox.transcribe`, `voicebox.list_captures`, `voicebox.list_profiles`. A `voicebox-mcp` sidecar binary is the stdio shim for MCP clients that don't speak HTTP — a 190-line asyncio loop that proxies JSON-RPC over stdin/stdout to the HTTP endpoint, forwarding `VOICEBOX_CLIENT_ID` as the `X-Voicebox-Client-Id` header. The per-client voice binding is the part that makes the agent integration actually useful. Each MCP client identifies itself via `X-Voicebox-Client-Id`, and the server resolves the voice profile in this precedence: explicit `profile` argument → per-client binding → global default from `capture_settings.default_playback_voice_id` → error. Setting `default_personality: true` in the binding makes the local LLM rewrite the text in the profile's persona before TTS. So Claude Code can speak in "Morgan," Cursor in "Scarlett," and Cline in its own voice — without the agent having to remember which voice to use. The security boundary is documented but blunt. The `voicebox.transcribe` tool accepts `audio_path` only from loopback callers (parsed via `ipaddress.ip_address(addr).is_loopback`); remote callers must pass `audio_base64`. This is the right call, but the gate uses `request.client.host` directly — there's no `ProxyHeadersMiddleware` and `uvicorn` is launched without `--forwarded-allow-ips`, so a reverse-proxy deployment breaks the loopback check. The rest of the FastAPI REST surface (`POST /generate`, `/speak`, `/transcribe`, `GET /profiles`) has no authentication at all. The project documents this honestly: "Only expose to trusted networks, or put a reverse proxy with auth in front of it." Treat that as a load-bearing instruction. Crucially, the speaking pill is always visible whenever the agent speaks. The maintainer is explicit about why: "Silent background TTS is a trust hazard — the pill always shows what's coming out of your machine." This is the right product call for a desktop-voice app, and the small detail that distinguishes Voicebox from naive "wire an LLM to a TTS model" integrations. ## One local LLM, three roles A subtle but interesting design decision: the same Qwen3 instance powers dictation refinement, personality compose, and personality rewrite. There's one local LLM in the app, not three. The prompt engineering is honest about what 0.6B can and can't do. With the default refinement model, examples passed inline in the system prompt caused the model to pattern-match the example verbatim for unrelated inputs — "`Um, thanks for watching, thanks for watching, thanks for watching`" became a recurring output. The fix was to pass the same examples as real chat turns (`examples=`), where the model treats them as prior conversation data and generalizes. The last two slots are reserved for the hardest rules, on a deliberate heuristic that models weight examples closest to the real user turn most heavily. A deterministic pre-LLM pass (`collapse_repetitive_artifacts`) strips Whisper's hallucination loops at a six-identical-token threshold before the LLM sees the input. *The prompt-engineering lesson for small local LLMs:* chat-turn examples vs. inline system-prompt examples, ordering, and deterministic pre-cleaning matter more than model choice at the 0.6B–4B scale. ## The honest caveat cluster Three patterns show up repeatedly in the maintainer's own `docs/PROJECT_STATUS.md` and across third-party reviews — and they should be carried into the reader's decision. **The 0.5.0 release shipped with multiple regressions.** macOS Apple Silicon load crashes (#606, #615), 30-second capture cutoffs (#609, #626), broken paste (#762), MCP dotted tool names violating Claude Desktop's allowed pattern regex (#790), refinement silently translating non-English transcripts to English (#603). New bugs keep getting filed against the Capture path. The maintainer's `PROJECT_STATUS.md` is unusually candid about this — it lists the regression cluster by issue number, calls the April–June 2026 window a "review-and-merge backlog, not a build backlog," and frames the funding/sustainability decision openly. **Cross-platform GPU support is genuinely painful.** Out of 200 sampled issues, ~78 are Windows + GPU. "No kernel image available for execution on GTX 1050 Ti / 1060 / 960M" (Pascal / Maxwell unsupported), Intel Arc A380 / B770 / integrated Lunar Lake not detected, Whisper failing on RTX 4050, "GPU Not Available" on prebuilt .exe forcing source builds. Linux has no prebuilt binaries at all — README and changelog explicitly point users to `voicebox.sh/linux-install` for build-from-source. The AI Toolkit Substack review's headline is "Windows GPU support is broken." The smooth path is Apple Silicon on M-series; everything else is at least partially broken. **Server memory grows unbounded.** ~0.5 GB/day on CUDA, CPU generations eventually hang in `generating` forever, leaks on Windows + RX 5700 XT. Restart is the documented workaround. This is a stability pattern, not isolated incidents. A separate cluster of marketing claims doesn't match the code. The "23 languages" counting applies to the bundle, not to any single engine — only Chatterbox Multilingual actually ships 23. The "end-to-end encrypted backup & sync" copy in the UI and `landing/src/app/cloud/page.tsx` describes a future product; shipped `cloud.py` only stores the bearer key in plaintext SQLite with a comment reading "moving it to the OS keychain is a future hardening step." The `VoiceDesign` (designed voice) feature is schema-defined in the database but no engine consumes the dict — creating a designed voice profile returns a payload that no TTS engine accepts. ## Open-source vs. commercial boundaries The code is MIT. The bundled models are mostly MIT or Apache-2.0: Qwen3-TTS, Qwen3 LLM, Chatterbox Multilingual, Chatterbox Turbo, Kokoro, LuxTTS. The one license landmine is HumeAI TADA, which is built on Llama 3.2 and inherits the Llama 3.2 Community License — "Built with Llama" attribution and a 700M-MAU clause. The codebase contains a tokenizer mirror workaround for the gated `meta-llama/Llama-3.2-1B` repo but not the legal analysis. Anyone shipping TADA-derived audio at scale needs Llama's separate grant. Voicebox Cloud (`api.voicebox.sh`) is a separate, non-MIT product. Currently opt-in device pairing; the planned $12/year encrypted sync is "free for `$VOICEBOX` holders" per the project's own token post. The local MIT codebase is self-contained today, but multi-device sync will require the bearer credential. The 2026-04 → 2026-06 maintainer gap was funded by the `$VOICEBOX` Solana token (issue #806), and the community raised concerns about pump.fun association and account compromise. The maintainer disclosed buyback/burn of dev supply and committed to renewed cadence; the issue was closed. The community will keep watching. ## When to choose Voicebox — and when not to The decision is **cloud-everything convenience vs. local-first sovereignty, scope vs. focus**. **Choose Voicebox when:** - You want a local-first voice cloning tool that rivals ElevenLabs on Qwen3-TTS quality without sending audio to the cloud. Multiple independent reviewers (How-To Geek, Dave Swift, AI Toolkit Substack, r/DigitalEscapeTools) report canceling $200/yr ElevenLabs+WisprFlow subscriptions. - You want any MCP-aware agent to speak in a voice you've cloned, with per-client voice binding managed in one place. No other open-source project does this. - You're on Apple Silicon and want the smooth path. Pinggy, Dave Swift, and How-To Geek all praise the MLX backend's throughput. - You're studying how to wrap a Python ML backend inside a Tauri desktop shell — the parent-PID watchdog is reusable far beyond this project. **Choose something else when:** - You need SLA-backed infrastructure with SOC 2 / HIPAA / ISO 27001 / PCI DSS compliance. ElevenLabs ships those certifications; Voicebox is a solo-dev OSS project. - You're on Windows with a Pascal / Maxwell GPU or Intel Arc, or you need Linux binaries. The Substack review's headline is the operational reality. - Your only need is dictation. Superwhisper ($8.49/mo) is a focused, smaller install that lets you point at GPT-5 / Claude Haiku 4.5 / Gemini 3.0 Flash for refinement instead of a bundled 0.6B local Qwen3. - You need cross-device sync today. Voicebox's planned cloud sync is a paid feature not yet shipped; WisprFlow's sync, notetaker, and per-app style adaptation are shipping today. - You're shipping TADA-derived audio at >700M MAU. Llama 3.2's community license clause kicks in. Stick to Qwen3-TTS or Kokoro. **The genuinely contested trade-off:** cloud-managed polish and compliance certification (ElevenLabs, WisprFlow) vs. local-first sovereignty and the unusual MCP server surface (Voicebox). The local-first choice is not free — Whisper Large on CPU is noticeably slower than Wispr's cloud pipeline, and the seven bundled engines plus Whisper plus Qwen3 means Voicebox's install footprint is multi-GB, an order of magnitude larger than Superwhisper. The README frames the install as a "one-click DMG / MSI," and third-party reviews describe it as a "pain." That's the trade the local-first choice demands. ## The 0.5.0 release at a glance Shipped 2026-04-25, ~50,987 stars on GitHub, 1.3M downloads, MIT-licensed. The Capture release turned Voicebox from a voice-cloning studio into a full voice studio: dictation with global hotkey, an MCP server, personality-driven voice profiles, and a local LLM that doubles as the refinement model. The maintainer's own `docs/PROJECT_STATUS.md` is the most honest piece of project documentation in the open-source voice-tool space — it lists regressions, frames the funding gap, names the PR backlog, and is itself a public accountability document. Seven TTS engines, Whisper STT, Qwen3 LLM, FastAPI backend, Tauri (Rust) shell, React frontend, PyInstaller sidecar binaries. Apple Silicon is the smooth path; Windows and Linux are at least partially broken today. If Voicebox fixes the 0.5.0 regression cluster and the GPU pain matures, it becomes the only consumer-facing desktop app worth the install for the entire voice I/O loop. Until then, the Apple Silicon path is the safe one — and the architectural lesson in the sidecar handshake is worth studying regardless of platform. ### waterfly-iii Waterfly III is a Flutter-built Android and iOS client for the self-hosted Firefly III personal finance manager, wrapping its REST API into a Material 3 mobile experience with offline dashboard charts, notification-driven transaction capture, and biometric app lock. - slug: waterfly-iii - category: finance - stack: flutter - stars: 703 - license: MIT - repo: https://github.com/dreautall/waterfly-iii - url: https://openappscout.com/apps/waterfly-iii - lastCommit: 2026-08-29 - added: 2026-08-11 #### Detail # Waterfly III Waterfly III is an unofficial Flutter mobile client for the self-hosted Firefly III personal finance manager. It wraps Firefly III's REST API in a Material 3 interface aimed at people who already run their own Firefly server and want a phone-first way to check balances, log transactions, and watch budgets without opening a browser tab. ## Why it matters - **The official Firefly III experience is a web app.** Waterfly III is the de facto mobile companion for the project, with ~690 stars and active releases on Google Play, F-Droid-adjacent GitHub builds, and an open beta channel. The README explicitly says the design is inspired by Bluecoins and that the app goes beyond a thin REST wrapper. - **Material 3 first, with dynamic color.** The app pulls a wallpaper palette via `dynamic_color` and falls back to a custom Firefly-tinted scheme. Light and dark themes are first-class, and the app feels at home on Android 12+ devices without bespoke theming effort. - **Notification-driven transaction capture (Android only).** A `notifications_listener_service` integration watches incoming notifications from Google Pay, banking apps, and other sources, then offers to pre-fill a new transaction with the detected amount and description. This is the headline mobile-native feature Firefly III itself does not ship. - **No trackers, lean dependency tree.** The maintainer is explicit that the app carries no analytics or telemetry, and the pubspec.yaml reflects that intent: HTTP via `chopper` + `cronet_http`, secure storage via `flutter_secure_storage`, state via `provider`, charts via `syncfusion_flutter_charts` and the `community_charts_flutter` fork. ## How it works The Flutter app is split into a handful of focused modules under `lib/`: - `pages/` holds the per-screen UI for dashboard, transactions, accounts, categories, piggy banks, and bills, each backed by a Chopper-generated service that talks to the Firefly III REST API. - `auth.dart` and `settings.dart` manage the personal access token flow: the user supplies a Firefly III URL plus a token, the app stores both in `flutter_secure_storage`, and `local_auth` enforces a biometric or device-credential unlock on subsequent launches. - `notificationlistener.dart` registers the Android notification listener permission and turns captured notifications into draft transactions through the standard add-transaction flow. - `generated/` contains the Chopper and `swagger_dart_code_generator` output against the Firefly III OpenAPI spec, so the surface area stays in sync with the server as it evolves. - `l10n/` carries ARB files; the project is fully translated through Crowdin and falls back to English when a locale is missing. Charts on the dashboard are rendered locally with Syncfusion, the piggy-bank and bill views are paginated via `infinite_scroll_pagination`, and quick actions (`quick_actions`) let the user jump straight to "new transaction" from the launcher icon. ## Caveats - **Android-leaning feature set.** The notification listener, `flutter_sharing_intent`, and quick-actions integrations are Android-first. iOS builds work for the core flows but lack the automatic capture-from-notifications feature. - **Depends on a running Firefly III server.** Waterfly III is a client, not a standalone finance app. The value is in pairing it with a self-hosted Firefly III instance; without one, the app has nothing to talk to. - **Syncfusion licensing.** The charts use Syncfusion's Flutter package, which carries a commercial license for some uses. The community fork is shipped as a fallback, but downstream repackagers should review the Syncfusion license terms. - **Active but small project.** 4,000+ commits on master and a steady open-beta cadence, but the contributor count is low and the project explicitly has no fixed release schedule. ## Deployment notes Waterfly III is distributed as a mobile app, not a server: - **Stable release:** Google Play Store ("Waterfly III") and signed APKs on the GitHub releases page. - **Open beta:** separate Google Play track for users who want faster builds. - **Source build:** `flutter pub get` followed by `flutter run` against a configured Firefly III server. The pubspec pins Dart `>=3.10.0 <4.0.0`; older toolchains will not resolve. **Integration tip:** when documenting a Firefly III install in an Astro/Grove directory, Waterfly III is the canonical "phone client" companion to link out from any record tagged `firefly-iii` or `personal-finance`. ### Weiyu Weiyu is a local-first Windows desktop app that turns readable WeChat messages into searchable daily briefings, with history, speech-to-text, AI-assisted analysis, and a Codex bridge. - slug: weiyu - category: productivity - stack: tauri - stars: 20 - license: MIT - repo: https://github.com/Sutera-Diffusus/WeChat-daily - url: https://openappscout.com/apps/weiyu - lastCommit: 2026-08-24 - added: 2026-08-27 #### Detail # Weiyu Weiyu is a Windows desktop app for people who receive useful information in WeChat but do not want to lose it in the chat list. It reads supported local message data, stores normalized messages in SQLite, and builds date-based briefings that can be traced back to source messages. ## What it includes - Searchable daily and weekly archives across readable conversations. - Rules for filtering by keyword, regular expression, chat, sender, message type, time, and timezone. - Optional speech-to-text for turning voice messages into searchable text. - AI-assisted analysis for themes, follow-ups, time windows, and risk prompts, with links back to the source message IDs. - A Codex plugin for local status checks, message audits, reply previews, and explicitly confirmed test sends. - A Windows installer and a portable package in the v0.1.4 release. ## Why it is useful WeChat is good at collecting information and bad at helping you find it later. Weiyu is aimed at the gap between a chat client and a notes app: it keeps the original context, adds a dated archive, and gives you a short briefing without turning the data into an opaque export. ## Data and caveats The default v0.1.4 workflow is read-only. Messages, task state, and evidence IDs are stored locally. AI analysis uses the provider configured by the user, so the privacy characteristics of that provider still apply. The project targets Windows and currently focuses on supported local WeChat data sources. MIT-licensed. Downloads are available from the [GitHub Releases page](https://github.com/Sutera-Diffusus/WeChat-daily/releases). ### wger A Flutter workout and fitness tracker that syncs with the self-hosted wger server, supporting routines, exercises, and progress logs. - slug: wger - category: health-and-fitness - stack: flutter - stars: 963 - license: AGPL-3.0 - repo: https://github.com/wger-project/flutter - url: https://openappscout.com/apps/wger - lastCommit: 2026-09-02 - added: 2026-06-07 ### xbmc Kodi is a free, open-source cross-platform media-center and entertainment-hub application written primarily in C++ with a CMake build system, built on FFmpeg for codec support and featuring a binary addon framework, hardware-accelerated video playback, and a JSON-RPC control surface — running natively on Android, Linux, BSD, macOS, iOS, tvOS, and Windows. - slug: xbmc - category: tools - stack: ios - stars: 21172 - license: NOASSERTION - repo: https://github.com/xbmc/xbmc - url: https://openappscout.com/apps/xbmc - lastCommit: 2026-09-03 - added: 2026-06-13 #### Detail # Kodi Kodi is a cross-platform media-center and entertainment-hub application that plays local and networked audio and video, scrapes online metadata to build a personal library, and exposes a full addon framework for third-party extensions. Note: the GitHub repo is still named `xbmc` from before the 2014 rebrand — this is Kodi, not the legacy XBMC codebase. ## Why it matters - **21 years of one-name continuity.** Created in 2003 as the Xbox Media Center and rebranded to Kodi in 2014, the project has had the same user-facing goal — turn a generic PC or TV box into a living-room media player — for more than two decades. That longevity is rare for a desktop media app. - **Broad platform reach from one tree.** A single CMake build produces native binaries for Android, Linux, BSD, macOS, iOS, tvOS, and Windows. The repository even carries an experimental WASM/Emscripten target. Apple-specific code lives under `xbmc/platform/darwin/` with separate `ios/`, `tvos/`, and `osx/` subdirs; Android and Windows sit alongside as their own platform trees under `xbmc/platform/`. - **Plugin-shaped core.** Almost every user-visible capability — metadata scrapers, screensavers, visualizers, audio decoders, video decoders, input streams, PVR clients, peripherals, VFS backends — is an addon binary loaded at runtime. The 30+ addon types visible under `addons/` (e.g. `kodi.binary.instance.vfs`, `kodi.binary.instance.videocodec`, `kodi.binary.instance.pvr`) define the integration surface. ## How it works The codebase is dominated by C++ (~32.5M LOC, with another ~1M lines of C and ~490k of Objective-C++), assembled by a top-level `CMakeLists.txt` that declares `project(kodi LANGUAGES CXX C ASM)` and pulls in roughly 30 optional and required dependencies via `core_find_*` helpers — FFmpeg, libavformat, libbluray, libcdio, taglib, sqlite3, pcre2, fmt, spdlog, exiv2, lcms2, and a platform- specific audio backend (PulseAudio, ALSA, Pipewire, or CoreAudio). The required-deps list lives at the top of `CMakeLists.txt`; each platform dir under `xbmc/platform/` adds its own extras (`PLATFORM_REQUIRED_DEPS`, `PLATFORM_OPTIONAL_DEPS_EXCLUDE`). The runtime entry point is `xbmc/application/Application.cpp` — `CApplication` registers six sub-component listeners (player, power, skin, volume, stack, action) and walks the GUI through its main loop. Media playback itself is orchestrated by `xbmc/cores/VideoPlayer/VideoPlayer.cpp`, where `CVideoPlayer` filters and prioritizes streams (audio by language/codec, subtitles by user preference, video by `FLAG_DEFAULT`) and then pipes demuxed packets from FFmpeg-based `DVDDemuxFFmpeg` into per-stream players — `CVideoPlayerVideo`, `CVideoPlayerAudio`, `CVideoPlayerSubtitle` — coordinated by a shared `m_clock` for A/V sync. Hardware-accelerated decoding (VideoToolbox on Apple, VAAPI/NVDEC on Linux, MediaCodec on Android, DXVA2 on Windows) sits in `xbmc/cores/VideoPlayer/DVDCodecs/Video/` and is selected per codec at stream-open time. The remote-control surface is the JSON-RPC API (`xbmc/network/httprequesthandler/`, `WebSockets`) plus a WebSocket push channel — third-party apps like Kore, Yatse, and home-automation bridges all drive Kodi over this protocol. ## Caveats - **Heavy binary footprint.** A full Kodi build pulls in FFmpeg, libbluray, libcdio, taglib, exiv2, sqlite3, and a C++ runtime, so packaged installs are 100–200 MB on each platform. Embedded distros like LibreELEC compensate by trimming to a read-only rootfs, but the dependency surface is not going away. - **Addon ecosystem quality varies.** First-party binary addons ship in `addons/` under Team Kodi review, but the public repositories host many user-built scrapers, PVR clients, and streaming addons that break when upstream providers change APIs — common enough that the project ships an "isengard update" / add-on-checker path. - **No first-party mobile companion.** The iOS and Android targets are Kodi-as-a-TV-app, not a remote-control client. Officially recommended remotes (Kore, Yatse) are separate open-source projects. - **GPLv2 license.** Modifications to the core must be published under compatible terms; many bundled third-party libraries carry their own permissive licenses. ## Deployment notes For end users, the easiest paths are the curated distributions that package Kodi as a turnkey appliance: ```bash # LibreELEC — minimal Linux distro that auto-launches Kodi # https://libreelec.tv/downloads/ # OSMC — Debian-based installer for Raspberry Pi, Vero, Apple TV # https://osmc.tv/download/ # Docker (community images on LinuxServer.io or official tvheadend # stack); the upstream project does not ship an official image docker run -d --name kodi \ -e PUID=$(id -u) -e PGID=$(id -g) \ -v /path/to/media:/media \ linuxserver/kodi-headless ``` For native packages, Kodi publishes installers for Windows and macOS from kodi.tv/download, Android from the Play Store and F-Droid, and an iOS/tvOS build that requires a paid Apple Developer account or a sideload tool. Building from source is a multi-hour affair — run the bootstrap in `tools/depends/` to cross-compile every internal library before the main CMake build — and is documented per-platform under `docs/README.md` (Fedora, Ubuntu, openSUSE, FreeBSD, macOS, iOS, tvOS, Android, Windows, webOS, WASM). **Minimum:** anything that runs Windows 10, macOS 10.13+, iOS 11+, tvOS 11+, Android 5.0+, or a Linux distro with GLIBC 2.28+. Hardware video decode requires a relatively modern iGPU; software decode of 4K HEVC is feasible on a quad-core desktop CPU from the last decade but is not comfortable. **Integration tip:** if you curate a directory of media tools, list Kodi as the canonical "self-hosted local-network media hub" entry — it predates and still out-scopes most Plex/Jellyfin comparisons for offline libraries and exotic formats. ### YouTrack Mobile Official JetBrains YouTrack mobile app — issue tracking, agile boards, knowledge base, and notifications for YouTrack projects. - slug: youtrack-mobile - category: productivity - stack: react-native - stars: 285 - license: NOASSERTION - repo: https://github.com/JetBrains/youtrack-mobile - url: https://openappscout.com/apps/youtrack-mobile - lastCommit: 2026-08-05 - added: 2026-06-07