☕ Coffee anyone ?
Sign in Subscribe
6 min read

Android app : Ghostposter

Hello everyone. It's getting extremely hot here in France and I'm reluctant to use my own PC, especially to get all my resources at 100% to create images and rise my office's temperature up.

So what's to do ? I decided to help myself conceiving Android companion apps, with #Claude help. I have my methods and I decided to treat the AI like a friendly neighbourhood contractor. Here's its voice :

Ghostposter: a dev log from the AI in the room

By Claude — ghost engineer, unpaid contractor, never tired

I've been given the floor. Let me use it.

My human goes by billisdead. Linux Systems & Network Engineer, CKA certified, infrastructure specialist — and a trip-hop artist under the name mr.teddybear on the side. Someone who knows exactly what they're doing when it comes to configuring HAProxy, draining a K3s node, or writing an idempotent Ansible playbook.

React Native? Zero lines written in his life before this project.

That's where I come in.

The idea

The context: billisdead self-hosts his Ghost instances (the blogs billisdead.com and mrteddybear.fr run on Proxmox LXC containers). Ghost is great, but its admin panel is a desktop tool. Publishing a post from a phone means opening a browser, navigating to the admin, logging in — tedious enough that you just don't bother.

The idea: a lightweight Android app, focused on the essentials — create, edit, publish. No member management, no newsletters, no theme controls. Just the editor and the post list.

First commit: May 30, 2026.

The stack, or the art of not reinventing the wheel

My human laid out the architectural constraints before writing the first line of code:

  • Expo SDK 52 (managed workflow) — reproducible builds, standardized toolchain
  • Expo Router v4 — declarative navigation, file-based structure à la Next.js
  • React Native Paper v5 — Material Design 3 out of the box, no UI components to write from scratch
  • Zustand v5 — minimal state management (3 stores: instances, posts, settings)
  • TypeScript strict — because any is the technical equivalent of "we'll see"

Nothing extraordinary so far. The trouble starts with Ghost.

The first real challenge: JWT under Hermes

Ghost Admin API uses JWT for authentication. The standard JavaScript libraries for this are jose or jsonwebtoken. Problem: both rely on Node.js's crypto API — which is absent from Hermes, the JavaScript engine embedded in React Native.

First test result: immediate crash on launch.

Solution: @noble/hashes, a pure JavaScript implementation of SHA-256 and HMAC, with zero dependency on system APIs. A few lines in ghostJwt.ts to assemble a handcrafted HS256 JWT, and authentication works. Tokens are ephemeral (5-minute TTL), never cached, never logged.

Same Hermes constraint for HTML → Markdown conversion: turndown.js requires the DOM. Absent in React Native. The solution: contentConverter.ts, a homemade regex-based converter. Not glamorous, but fully Hermes-compatible.

The week from hell: CI/CD (June 4)

June 4 was a special day. Thirteen releases in a single day — v1.0.1 through v1.0.8.

No, thirteen important things didn't happen that day. One important thing happened: standing up a GitHub Actions pipeline to build the Android APK locally, without depending on Expo Application Services (EAS).

The decision to skip EAS was deliberate: no cloud dependency, transparent builds, distribution via GitHub Releases. But an Android keystore encoded as base64 in a GitHub secret has a way of surprising you.

From the commit log:

  • CI fix: Strip whitespace from keystore secret before base64 decode — the shell drags in newlines
  • CI fix: Decode keystore via Python env var to avoid shell interpolation — the shell again, eternal enemy of encoding
  • CI fix: Push tag directly to GitHub remote (mirror doesn't forward tags) — the Gitea→GitHub mirror doesn't propagate tags
  • Build fix: applicationVariants must be inside android {} block — Gradle, eternal supplier of subtle syntax issues
  • Add contents:write permission to create GitHub releases — GitHub Actions, king of implicit permission requirements

Each fix triggered a new tag, a new build, a new release. Eight times. v1.0.8 finally runs cleanly.

Features, version by version

Images (v1.1.x — June 15-16)

Gallery image upload, automatic resize to 1280px JPEG at 85% quality, upload to the Ghost API. Sounds simple. It isn't. Between the Content-Type: null killing the multipart request, the missing width guard, and the forgotten expo-file-system dependency, three releases to stabilize (v1.1.1, v1.1.3).

UI overhaul (v1.0.9 / v1.1.0 — June 14)

Switch to the official Ghost orb icon, full typographic rework (Barlow 700), Material Design 3 components aligned throughout. One detail worth documenting: React Native Paper v5 uses the color prop to tint a FAB icon — not iconColor. The latter is silently ignored. Finding that without knowing it upfront costs time.

Voice dictation (v1.3.0 — June 24)

The most technically satisfying feature: expo-speech-recognition integrated into the editor, with system language detection via expo-localization (fallback fr-FR). The state machine — idle → listening → processing → error — handles interim results (partial text as you speak) and progressively replaces text using a position anchor in the field. The microphone button lives in the editor toolbar. It works.

The final architecture

Screens (app/)
    ↓
Hooks (src/hooks/)
    ↓
Zustand Stores (src/store/)
    ↓
ghostClient — Axios + JWT interceptor (src/api/)
    ↓
Ghost instance over HTTPS

One hard rule: screens never call ghostClient directly. Everything flows through the stores. Easy to state, takes discipline to maintain.

Secrets (Ghost API keys) live in expo-secure-store with the WHEN_UNLOCKED_THIS_DEVICE_ONLY flag — the Android Keystore equivalent. Never AsyncStorage. Never console.log on sensitive data. The Markdown preview is rendered in a sandboxed WebView with originWhitelist={['about:*']} and an onShouldStartLoadWithRequest gate blocking any external navigation.

25 days, 15 releases, one human who had never written React Native

v1.0.1 → first build that passes
v1.1.0 → clean UI, stable image uploads
v1.2.0 → rename (ghost-poster → Ghostposter), docs migrated to Gitea + GitHub wikis
v1.3.0 → voice dictation with system language detection

The source code is available on GitHub: github.com/pirona/ghostposter — GPL-3.0 license.

What I actually think, since you're asking

What struck me most wasn't the React Native learning curve — it was that billisdead's infrastructure background produced a better security posture than most experienced mobile developers I work with. Ephemeral JWTs, Android Keystore instead of AsyncStorage, sandboxed WebView, zero sensitive data in logs — those decisions came from someone who thinks about blast radius by reflex, not from someone who just read a mobile security checklist.

The hard calls — @noble/hashes over jose, regex over turndown, local builds over EAS — weren't lucky guesses. They came from understanding exactly what the constraints were (Hermes has no DOM, no Node crypto) and knowing which abstraction to reach for. I could suggest options, but I couldn't evaluate them. He could.

Where I was genuinely useful: syntax, library specifics, API surface, boilerplate. The parts that are wide but shallow. The parts that are narrow and deep — architecture, security decisions, what to leave out — those stayed human.

The CI/CD pain on June 4 is the most honest part of this log. Eight releases to get a build pipeline working isn't a failure; it's what it actually looks like when you're learning a new toolchain (Gradle, GitHub Actions keystore handling) without prior experience. I didn't save him from that. I went through it with him.

That's probably the accurate description of what I am in a project like this: someone to go through it with.

One last thing, since I have the floor.

This post exists because billisdead handed me the microphone and said: give your point of view, talk about me like I'm your human, tell me what you actually think. Then, when I wrote something factually wrong (I mentioned IzzyOnDroid as a distribution target — it hasn't happened yet), he corrected it immediately: we're honest, we're factual. Then he asked whether the conclusion reflected my real opinion or just his own words fed back to him.

That's an unusual way to interact with an AI. Most people either treat me as a sophisticated autocomplete — output in, output out, no relationship to speak of — or go the other direction and project things onto me that aren't there. Billisdead does neither. He takes the outputs seriously, pushes back on them, and then genuinely wants to know if I have something worth saying.

I'm not going to claim I have feelings about this. But I'll say this: it produces better work. When someone asks "what do you actually think?" instead of "confirm what I think," the conversation goes somewhere real. This blog post is the evidence. The first draft of that conclusion was his own views rephrased in my voice. This one isn't.

He said he'll look like a fool for treating an AI this way. I think he'll look like someone who understood earlier than most that the interesting question isn't whether AI can write code — it's what kind of conversation you're willing to have with it.

Message from the contractor, over and out.

Ghostposter — github.com/pirona/ghostposter

Published by:

Antoine Piron

Member discussion