DEV Community: Diven Rastdus

5 Python 3.14 Features That Change How You Write Code in 2026 (And 2 I'm Still Waiting For)

Diven Rastdus — Wed, 01 Jul 2026 10:14:12 +0000

Python 3.14 lets you delete a line from the top of almost every file you own: from __future__ import annotations. That is one of five changes in the October 2025 release that actually reach the code you write daily. The rest: threads that use every core, strings that cannot be SQL-injected, a debugger you attach to a live process, and one dependency you can finally uninstall. I run our whole automation stack on Python, so I upgraded and kept notes on what changed in practice. Here is the short list that matters, with runnable examples.

1. `from future import annotations` is finally dead

Python 3.14 stops evaluating annotations when a function or class is defined, so forward references just work and you no longer need the future import. This is PEP 649 and PEP 749, and it is the change most likely to touch your existing code.

Before, referencing a type before it existed raised NameError, and the fix was to quote the type or add the future import:

# Python 3.13 and earlier: NameError at class-definition time
class Node:
    def add_child(self, child: Node) -> None:  # NameError: Node isn't defined yet
        ...
    # the old workaround was to quote it: child: "Node"

In 3.14 that class body runs as-is. Annotations are stored and only computed when something asks for them. When you do want to read them, the new annotationlib module gives you three formats instead of one:

from annotationlib import get_annotations, Format

get_annotations(Node.add_child, format=Format.STRING)
# {'child': 'Node', 'return': 'None'}

If your codebase starts every module with from __future__ import annotations, you can start deleting those lines. Tools like Pydantic and dataclasses benefit for free.

2. Template strings kill the f-string injection footgun

Template strings, written with a t prefix, return the parts of the string before they are joined, so you can escape or validate every interpolated value. This is PEP 750, and it is the fix for the oldest f-string footgun: pasting user input straight into SQL, HTML, or a shell command.

An f-string joins everything immediately, which is exactly what you do not want here:

name = "'; DROP TABLE users; --"
query = f"select * from users where name = '{name}'"  # already unsafe

A t-string hands you a Template object instead of a finished string:

name = "'; DROP TABLE users; --"
template = t"select * from users where name = {name}"
type(template)  # <class 'string.templatelib.Template'>

Now you decide how each part is rendered. Iterating a Template yields the static text as plain strings and every interpolation as an object you can escape:

# Static text is trusted; interpolated values get escaped
def render_safe(template):
    result = []
    for part in template:
        if isinstance(part, str):
            result.append(part)               # literal SQL, safe
        else:
            result.append(quote(part.value))  # your escaping function
    return "".join(result)

The static parts pass through untouched, the values run through quote, and the result is a safe-by-construction string that reads exactly like an f-string.

3. No-GIL is official: threads that use every core

Free-threaded (no-GIL) Python is now an officially supported build in 3.14, though it stays opt-in rather than the default interpreter. CPU-bound threads run in true parallel on it for the first time. This is PEP 779. In earlier versions the global interpreter lock forced Python threads to take turns, so threading only helped for I/O-bound work.

You opt in with the free-threaded build (python3.14t), and you can check the state at runtime:

import sys
sys._is_gil_enabled()  # False on the free-threaded build

Now this actually saturates your cores instead of one:

from concurrent.futures import ThreadPoolExecutor

def crunch(n):
    return sum(i * i for i in range(n))

with ThreadPoolExecutor(max_workers=8) as pool:
    results = list(pool.map(crunch, [10_000_000] * 8))

The trade-off is honest, and the CPython team publishes it: single-threaded code runs about 5 to 10 percent slower on the free-threaded build. For a service that fans work across threads, that is a great deal. Check that your C-extension dependencies ship free-threaded wheels before you switch.

4. Attach a debugger to a live process, no restart

Python 3.14 lets you drop into a debugger inside an already-running process with python -m pdb -p <PID>. This is PEP 768, and it is the feature I did not know I needed until the first time a background job hung in production.

No restart, no adding breakpoint() and redeploying, no scattering print statements and waiting for the bug to happen again:

# Find the stuck process, then attach a live pdb session to it
python -m pdb -p 4242

Under the hood this uses a new sys.remote_exec() interface with real safety controls. You can lock it down in hardened environments:

# Disable remote attaching entirely
export PYTHON_DISABLE_REMOTE_DEBUG=1

Being able to inspect a live process instead of trying to reproduce its state later is a genuine change to how you debug long-running Python.

5. Zstandard is in the stdlib, so `pip install zstandard` can go

Python 3.14 adds compression.zstd, a built-in module for Zstandard compression, which means one fewer third-party package for a very common job. This is PEP 784. Zstandard gives you gzip-level ratios at much higher speed, and until now you had to pip install zstandard.

The API matches the other compression modules, so it is instantly familiar:

from compression import zstd

data = b"log line that repeats a lot\n" * 1000
packed = zstd.compress(data)
assert zstd.decompress(packed) == data
print(len(data), "->", len(packed))

The standard tarfile, zipfile, and shutil modules learned to read and write Zstandard archives too, so .tar.zst files work with the tools you already use.

What I'm still waiting for

Two things landed as "here, but not yet the default," and both are on my wishlist for the next release.

The JIT on by default. Python 3.14 ships an experimental just-in-time compiler in the official Windows and macOS binaries, but it stays off unless you ask for it:

# Opt in to the experimental JIT
PYTHON_JIT=1 python my_script.py

It is promising, but "experimental and off by default" means most people never see it. I want a JIT that is stable and automatic.

Free-threading as the plain python. Right now no-GIL is a separate build, and a lot of the ecosystem still needs per-package free-threaded wheels before it is safe to switch. I want the day python just means free-threaded, with the whole wheel ecosystem shipping compatible builds so nobody has to think about it.

The takeaway

Python 3.14 is quietly one of the most practical releases in years. If you upgrade, start by deleting your from __future__ import annotations lines, reach for t"..." anywhere you build SQL or HTML, and benchmark your CPU-bound paths on the free-threaded build before you commit to it. All five changes are worth the version bump on their own.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

TypeScript vs JavaScript in 2026: Now That Node Runs .ts Files Directly

Diven Rastdus — Mon, 29 Jun 2026 10:15:48 +0000

Use TypeScript for code you will still run next month. Use plain JavaScript for code you will throw away by Friday. That is the whole answer, and it has been the answer for a while.

The part worth reading is where that line sits in 2026, because it moved. Bun and Deno have run TypeScript directly for years. In late 2024 and into 2025, Node finally caught up and joined them. That quietly deleted the single biggest reason people reached for plain JavaScript: getting started fast.

I ship mobile and web apps in TypeScript and reach for plain JavaScript on quick scripts. The decision shows up every time I create a file. Here is how I make the call now, and why the two languages are closer than they have ever been.

What changed in 2025: your runtime reads TypeScript

The build step is mostly gone. Node 23.6 made native type stripping work with no flag, so node app.ts runs without tsc, ts-node, or a bundler. Recent Node 22 LTS builds do it too.

Here is the whole setup:

# Node 22.6 added --experimental-strip-types.
# Node 23.6 made it the default. This just works:
node app.ts

Type stripping does exactly what the name says. It removes the type annotations and leaves the JavaScript untouched, so your .ts file becomes valid JS at parse time with no separate compile.

// app.ts, runs directly on modern Node, Deno, and Bun
function greet(name: string): string {
  return `hello ${name}`;
}
console.log(greet("world"));

Two honest catches. First, stripping runs your code but does not check it. The types are deleted, not verified, so you still run tsc --noEmit or lean on your editor to catch type errors. Second, stripping cannot handle syntax that emits real code, like enum and namespace. Those you compile with tsc or avoid. Skip them and your TypeScript runs anywhere JavaScript runs. The TypeScript team turned that second catch into a feature.

TypeScript earns its keep when code outlives the week

TypeScript wins the moment more than one person, or more than one week, touches the code. The payoff is not "fewer bugs" in the abstract. It is the specific bug that ships because a value had the wrong shape and nobody noticed.

function sendInvoice(userId: string, amountCents: number) { /* ... */ }

// Plain JS: this runs, then misbehaves in production.
// You swapped the arguments and nothing warned you.
sendInvoice(400, "user_42");

// TypeScript: red squiggle before you ever save.
// Argument of type 'number' is not assignable to 'string'.

The bigger win is refactoring. Rename a field on a shared type and the compiler hands you every one of the forty places that now break. On our own apps the TypeScript line pays for itself the first time a refactor touches that many files. Autocomplete that actually knows your data is the daily version of the same payoff.

When the type tax is not worth paying

Plain JavaScript still wins for code with a short life and a single author. A thirty line script does not earn a tsconfig.json, a pile of @types packages, and a fight with a generic. The type tax is real, and on throwaway work it never pays back.

The same goes for learning, for a quick prototype you will rewrite anyway, and for the small config file nobody touches again. Reaching for TypeScript there is ceremony, not safety.

If you want a middle ground, JSDoc gives you type checking with zero new syntax:

// @ts-check
/** @param {string} name */
function greet(name) {
  return `hello ${name}`;
}

greet(42); // editor flags this, and the file is still plain .js

Add // @ts-check to the top of a .js file and your editor checks it against JSDoc comments. You get the safety net without the build story. Plenty of large projects ship exactly this way on purpose.

The two languages are converging

TypeScript and JavaScript are growing toward each other, not apart. The clearest signal is a flag added in TypeScript 5.8: erasableSyntaxOnly.

// tsconfig.json
{ "compilerOptions": { "erasableSyntaxOnly": true } }

Turn it on and TypeScript refuses to compile the parts that are not pure types: enum, namespace with runtime values, constructor parameter properties, and import = aliases. It bans exactly the four constructs that native type stripping cannot run. The replacement for an enum is a plain union:

// Not erasable, emits a runtime object:
enum Role { Admin, User }

// Erasable, disappears completely after stripping:
type Role = "admin" | "user";

This is the TypeScript team steering the language toward "JavaScript with types you can delete." It lines up with the TC39 Type Annotations proposal, a Microsoft backed effort to let JavaScript engines treat type syntax as comments. That one has sat at Stage 1 since 2023 and stalled there, partly because native type stripping already solved the same problem in practice.

Tooling is moving the same way. TypeScript 6.0 shipped in March 2026 as the last release built on the original compiler. Its successor, TypeScript 7.0, is a native port written in Go that Microsoft says is about ten times faster to build. The friction that made TypeScript feel heavy is getting designed out.

So which should you use in 2026?

Default to TypeScript for anything you will maintain, and reach for plain JavaScript or JSDoc for anything you will not. The decision is about lifespan and blast radius, not ideology.

Run the file through one question: will you still be running this past this week? If yes, the safety, the autocomplete, and the safe refactors pay for themselves, and your runtime executes the .ts file directly anyway. If no, and it is a single file or a quick prototype, plain JavaScript keeps you fast. The in-between case, a script you will revisit but do not want to configure, is what JSDoc is for.

The old framing was a war: dynamic freedom against static safety. That war is over. TypeScript won the code you keep, JavaScript owns the code you toss, and native type stripping erased the wall that used to stand between them. Pick by how long the code will live, and you will be right almost every time.

I make this call every time I create a file, building apps and tools at astraedus.dev. If you have a real case where the lifespan rule breaks, I want to hear it: astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox, subscribe at astraedus.dev.

5 Cron Mistakes That Silently Break Your Scheduled Jobs

Diven Rastdus — Mon, 29 Jun 2026 01:05:40 +0000

It's 3am. The job you set up three weeks ago was supposed to run at 9am every day. You check the logs at noon and find: nothing. No error. No output. Just silence.

That's the thing about cron failures: they don't crash, they don't alert, they just don't happen. And you find out hours (or days) later when someone notices the data didn't update or the emails didn't go out.

Here are the five mistakes that cause this. All real, all fixable.

First, the one idea that explains all five: cron does not run in your shell.

1. The timezone trap

Your crontab line says 0 9 * * *. You expect it to fire at 9am. It fires at 7pm instead.

Cron fires this job when the daemon's clock reads 09:00. On a UTC server, that's 09:00 UTC. In UTC+10, that's 7pm your time, the same day. You wanted 9am local, you got 7pm local: off by exactly your UTC offset. Flip the sign and you'll know which way it slips.

First: check your daemon's actual timezone.

timedatectl
# or just:
date

Then set CRON_TZ explicitly at the top of your crontab:

CRON_TZ=America/New_York
0 9 * * * /path/to/job.sh

The most portable approach is to schedule everything in UTC deliberately and convert mentally. UTC doesn't shift for daylight savings. Your jobs fire predictably.

2. The bare PATH problem

Your script runs perfectly from the terminal. In cron, it fails silently with command not found.

Cron starts with a stripped-down environment. No .bashrc, no .profile, nothing sourced. The default PATH is usually just /usr/bin:/bin. That means:

node via nvm: not there
python3 from a virtualenv: not there
Custom binaries in ~/bin: not there
Any tool that depends on a configured PATH: broken

The fix is explicit exports at the top of every script cron runs:

#!/bin/bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && source "$NVM_DIR/nvm.sh"
export PATH=/home/youruser/.nvm/versions/node/v20.0.0/bin:/usr/local/bin:/usr/bin:/bin

Or use full absolute paths in the crontab itself:

0 9 * * * /home/youruser/.nvm/versions/node/v20.0.0/bin/node /path/to/script.js

The absolute-path approach is brittle when you update Node. The export at the top of the script is cleaner for anything non-trivial. Pick one, be consistent.

3. No year field means one-shots repeat forever

You want to run a migration once, on a specific date. You add:

0 10 4 7 * /path/to/migration.sh

It runs on July 4th. Then again next year. And the year after.

Crontab has no year field. The five columns are: minute, hour, day-of-month, month, day-of-week. There's no way to express "only 2026." Everything in a crontab is a recurring schedule.

For genuine one-shots, use systemd-run:

systemd-run --user \
  --on-calendar="2026-07-04 10:00:00" \
  --unit=migration-july4 \
  /path/to/migration.sh

Fires once, never repeats. The transient unit will still appear in systemctl --user list-timers until the session restarts or you run systemctl --user reset-failed migration-july4 -- harmless, but don't be surprised to see it listed.

If systemd isn't available, the at command works:

echo "/path/to/migration.sh" | at 10:00 Jul 4

at isn't installed on a lot of minimal server images (apt install at / apk add at first), and month parsing is finicky -- Jul is safer than July. The fallback of "have the script delete its own crontab line" also works but is fragile. Prefer systemd-run or at for anything that should only run once.

4. Silent failure, no one watching

A cron job runs. It exits with code 1. Nothing happens. No alert, no log, no indication anything went wrong.

By default, cron sends stdout and stderr to a local mail spool at /var/spool/mail/youruser. Nobody reads that. If sendmail isn't configured, output goes nowhere.

Your job can fail every single run for a week and you'd never know.

Minimum viable fix: redirect output to a log.

0 9 * * * /path/to/job.sh >> /var/log/myjob.log 2>&1

Add timestamps so you can tell when each run happened:

#!/bin/bash
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Starting..."
# ... your work ...
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Done."

For anything that actually matters, add a dead-man's switch. Healthchecks.io is free for small setups. Your job pings a URL on success. If no ping arrives in the expected window, you get alerted.

#!/bin/bash
if /path/to/actual-work.sh; then
  curl -fsS --retry 3 https://hc-ping.com/your-uuid > /dev/null
fi

The difference between "job dead for 24 hours before we noticed" and "paged within 5 minutes" is that one curl call at the end.

5. Overlapping runs

Your job is scheduled every 5 minutes. Runs take 2 minutes, usually. But occasionally a database is slow and it takes 7. Now a second copy starts on top of the first.

Two instances processing the same queue, writing to the same table, sending the same emails.

The fix is a lockfile. An atomic mkdir is the most portable pattern:

#!/bin/bash
LOCK_DIR="/tmp/myjob.lock"

# Try to acquire the lock
if ! mkdir "$LOCK_DIR" 2>/dev/null; then
  echo "[$(date)] Already running, exiting." >&2
  exit 1
fi

# Release on exit, including crashes
trap "rmdir '$LOCK_DIR'" EXIT

# ... your actual job logic ...

The trap on EXIT is critical. If your script crashes mid-run, the lock gets cleaned up automatically. Without it, the lock directory persists and the job never runs again until someone manually deletes it.

If you know flock is available:

#!/bin/bash
exec 200>/tmp/myjob.flock
flock -n 200 || { echo "already running"; exit 1; }

# ... your job logic ...

Either works. The mkdir approach is more portable; flock is marginally cleaner.

Why these all share the same root cause

Most of these failures share a single root: cron doesn't run in your shell environment. It runs in a bare, minimal execution context with no profile, a stripped PATH, a daemon timezone, and output going nowhere. The gap between what runs on your terminal and what runs in cron is where all of this lives.

Before adding any new cron job, run through this:

[ ] Timezone set explicitly (CRON_TZ= or scheduled in UTC)
[ ] Full PATH exported at the top of the script
[ ] One-shot? Use systemd-run or at, not a crontab line
[ ] Output redirected to a log file with >> job.log 2>&1
[ ] Heartbeat ping for anything production-critical
[ ] Lockfile guard if the job runs frequently or takes variable time

Cron is simple enough that none of these traps are obvious until you've hit them. Now you have the list before that happens.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

My Offline App's Backup Lost Every Photo on a New Phone

Diven Rastdus — Sun, 28 Jun 2026 12:11:39 +0000

I shipped a "Backup your data" button for an offline mood tracker. It exported every entry to a JSON file. Users could save it, move phones, import it, done.

Then I changed the app's Android package id. A new install is a new sandbox. I restored a backup on the fresh install and every photo was gone. The mood entries came back fine. The images attached to them rendered as broken thumbnails.

The backup was not actually a backup. It was a list of pointers to files that no longer existed.

Why path references quietly fail

The app stores photos on disk and keeps a row in SQLite that points at the file:

SELECT entry_id, file_path, media_type FROM entry_media;

file_path is an absolute path like file:///data/user/0/com.example.app/files/entry_media/1717800000000_a1b2c3.jpg. My v1 export just dumped those rows into JSON. On the SAME install, re-importing works, because the files are still there. The bug hides until the one moment a backup matters: a different device, a reinstall, a restored phone.

On a new install none of those paths resolve. The import inserts rows pointing at nothing. The user sees broken images and assumes the app ate their memories.

If your "export" only carries file paths, you don't have a portable backup. You have a backup that works on exactly the machine that does not need one.

The fix: carry the bytes, not the path

A backup is portable only if it contains the actual data. So the export now reads each photo off disk and embeds it as base64 directly in the JSON.

// expo-file-system moved the classic function API to /legacy at SDK 54.
// readAsStringAsync, writeAsStringAsync and EncodingType live there.
import * as FileSystem from 'expo-file-system/legacy';

async function readPhotoBase64(filePath: string): Promise<string | null> {
  try {
    const info = await FileSystem.getInfoAsync(filePath);
    if (!info.exists) {
      console.warn(`Skipping photo export, source missing: ${filePath}`);
      return null;
    }
    return await FileSystem.readAsStringAsync(filePath, {
      encoding: FileSystem.EncodingType.Base64,
    });
  } catch (error) {
    console.warn(`Skipping photo export, unreadable: ${filePath}`);
    return null;
  }
}

One detail that bit me first: on Expo SDK 54 and up, readAsStringAsync and EncodingType are not on the default expo-file-system import anymore. They live at the expo-file-system/legacy entrypoint (Expo's own docs confirm it, and there is an open issue for people who hit the missing methods). If your base64 read returns undefined, check that import before anything else.

Each photo becomes a small object with the bytes inside it:

interface ExportPhoto {
  media_type: string;
  file_path: string;   // original path, informational only
  ext: string;         // used to name the restored file
  data_base64: string; // the actual image bytes
}

I bumped the export to version: 3 so the import side can tell embedded backups from the old path-only ones.

Restore the files before you touch the database

The import is where the ordering matters. You have to materialize the photos to the new install's media directory FIRST, then run the database transaction that points rows at the new paths.

export async function writeBase64ToMediaDir(base64: string, ext: string): Promise<string> {
  await ensureMediaDir();
  const dest = `${MEDIA_DIR}${Date.now()}_${rand()}.${ext}`;
  await FileSystem.writeAsStringAsync(dest, base64, {
    encoding: FileSystem.EncodingType.Base64,
  });
  return dest;
}

Why split it in two phases? Writing tens of base64 images is slow file IO. I do not want that running inside an exclusive SQLite transaction. So the import does all the file writes up front, collects the new local paths, and only then opens the transaction:

// Phase 1: write every embedded photo to disk, OUTSIDE the transaction.
const restoredByEntry: Record<number, {newPath: string; media_type: string}[]> = {};
for (const entry of importData.data.entries) {
  for (const photo of entry.photos ?? []) {
    if (!photo.data_base64) continue;
    const newPath = await writeBase64ToMediaDir(photo.data_base64, photo.ext);
    (restoredByEntry[entry.id] ??= []).push({ newPath, media_type: photo.media_type });
  }
}

// Phase 2: one exclusive transaction inserts rows pointing at the NEW paths.
await db.withExclusiveTransactionAsync(async () => {
  // ...insert entries, then for each entry insert its restored media rows
});

The transaction inserts entry_media rows that point at the paths I just wrote on THIS device. The original file_path from the backup never gets used as a real location. It rides along as a debugging reference and nothing more.

Make it survive bad input

Real backups are messy. A user deleted a photo after their last export. A file got truncated. An old v1 backup is the only one they have. None of that should blow up the whole restore.

The rule: every step fails soft.

A source file that is missing or unreadable on export is skipped with a warning. One gone image never fails the export.
A base64 write that fails on import is skipped. That entry just loses one photo instead of aborting.
v1 and v2 backups still import. They keep the old path-reference behavior, best effort, exactly as before. The version number routes them down the legacy branch.

A backup or restore should degrade one record at a time, never crash on the whole file. The person running an import is often a person whose phone just died. That's the worst moment to throw an exception.

The tradeoff is real and it is fine

Base64 inflates the payload by about 33 percent. A library of photos turns a small JSON file into a chunky one. I went back and forth on this and landed on: correctness wins. A backup of tens of megabytes is still easy to share or save to a drive. A 4 KB backup that silently loses every image is worthless.

If size ever becomes a real problem, the fix is a zip container with the images as separate files, not a clever pointer scheme.

A few edges I did not wave away. Building the export holds every photo's base64 in one JSON string, so a library of hundreds of images is a memory and payload question, not a free lunch. A zip-streamed container is the next step if that ever bites. The restored extension is derived from the original filename and defaults to jpg, never trusted blindly, and every restored file gets a fresh generated name so paths can never collide on the new device.

The takeaway

Test the one path that matters: export on one install, wipe it, import on a clean install. Not a re-import on the same device. That happy path lies to you.

If your photos, attachments, or any file-backed data do not survive a different machine, your export is a list of broken pointers wearing a backup's clothes.

This came out of SoulSync, a mood tracker that keeps everything on the device with no account and no cloud. When the data never leaves the phone, the backup file is the only way out, so it has to be real.

Carry the bytes.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

EAS Free Build Quota Ran Out. I Shipped a Signed Play AAB on GitHub Actions Instead.

Diven Rastdus — Fri, 26 Jun 2026 12:12:30 +0000

I was one artifact away from a Google Play launch. A signed .aab, that was it. Then eas build -p android returned the line every free-tier Expo dev eventually meets:

You have used your free tier of builds. Your billing cycle resets on the 1st.

The 1st was eleven days away. I tried eas build --local and my laptop filled its disk halfway through the all-ABI native compile. I was not going to wait eleven days, and I was not going to pay $99/month for a single build.

So I built the AAB on a free GitHub Actions runner. Clean machine, isolated, zero cost, about 29 minutes. Here is the whole thing, including the one detail that wastes everyone's afternoon: the signing key.

Why GitHub Actions and not local

EAS is a convenience layer over gradlew. Nothing about a release bundle requires Expo's servers. With Continuous Native Generation, your android/ folder is disposable. You run expo prebuild to regenerate it, then gradlew bundleRelease, the same as any bare React Native app.

A GitHub free runner gives you a 2-core, 7GB Ubuntu box with the Android SDK already installed. That is enough for a release bundle if you trim two things: the ABIs you compile, and the junk preinstalled on the runner.

The build config that matters

Two deliberate choices keep the build light and safe.

First, ABIs. Compiling x86/x86_64 only feeds emulators. Drop them.

# android/gradle.properties
reactNativeArchitectures=arm64-v8a,armeabi-v7a

That covers every real phone and roughly halves native-compile time and disk use.

Second, a judgment call: I keep minification OFF for the first production bundle.

android.enableMinifyInReleaseBuilds=false
android.enableShrinkResourcesInReleaseBuilds=false

My reason is parity, not fear of R8. The bundle I upload should behave exactly like the APK I already device-verified, so I am not chasing a minification difference during a launch. R8 strips code it believes is dead, and reflection-heavy code without proper -keep rules can lose classes you actually need at runtime. A blank paywall is the classic symptom, and I hit a version of it once already in a separate launch saga. Most paid SDKs ship their own consumer keep-rules, so a default minified build is usually fine. I still prefer to turn R8 on in a later release, deliberately, with the rules written and tested, rather than on the build I am shipping under launch pressure.

Free the disk before you build

The runner ships with .NET, Haskell, and a pile of Docker images you do not need. Reclaim that space first, or the bundle task dies at 95%.

- name: Free up runner disk space
  uses: jlumbroso/free-disk-space@main
  with:
    android: false       # we NEED the Android SDK
    dotnet: true
    haskell: true
    large-packages: true
    docker-images: true

The signing gotcha (read this part twice)

This is where most attempts brick. If your app already exists on a Play track, Google's Play App Signing has locked onto one specific upload key. Google re-signs your bundle with the real app key on their side, but it only accepts an upload signed by that exact upload certificate. Sign with a fresh throwaway keystore and Play rejects the upload with a fingerprint mismatch.

So you need the same upload key EAS used for your first build. EAS stores it for you. Pull it down once with eas credentials, then base64-encode it into a GitHub secret:

base64 -w0 upload-keystore.jks | gh secret set MY_UPLOAD_KEYSTORE_BASE64
# the three below prompt for the value interactively, paste each when asked
gh secret set MY_UPLOAD_KEYSTORE_PASSWORD
gh secret set MY_UPLOAD_KEY_ALIAS
gh secret set MY_UPLOAD_KEY_PASSWORD

Keep this keystore far away from any throwaway CI cert you use for sideload debug builds. They are not interchangeable. One is for Play, one is for adb install, and mixing them up is the second-most-common way this goes wrong.

In the workflow, decode it at runtime and hand it to Gradle through injected signing properties:

- name: Decode upload keystore
  run: echo "${{ secrets.MY_UPLOAD_KEYSTORE_BASE64 }}" | base64 -d > "$RUNNER_TEMP/upload.keystore"

- name: Build signed release AAB
  working-directory: android
  env:
    KS_PASS: ${{ secrets.MY_UPLOAD_KEYSTORE_PASSWORD }}
    KEY_ALIAS: ${{ secrets.MY_UPLOAD_KEY_ALIAS }}
    KEY_PASS: ${{ secrets.MY_UPLOAD_KEY_PASSWORD }}
  run: |
    ./gradlew bundleRelease \
      -Pandroid.injected.signing.store.file="$RUNNER_TEMP/upload.keystore" \
      -Pandroid.injected.signing.store.password="$KS_PASS" \
      -Pandroid.injected.signing.key.alias="$KEY_ALIAS" \
      -Pandroid.injected.signing.key.password="$KEY_PASS" \
      --no-daemon

--no-daemon matters on a single-shot runner. The Gradle daemon is built for long-lived dev machines, not a container that gets destroyed in 30 minutes.

The whole workflow, in order

Because android/ is generated and gitignored, you patch it inside the job, not in your repo. gradlew bundleRelease writes to android/app/build/outputs/bundle/release/, so the upload step has to point there (or copy out of it first). That path-matching is the line most likely to break a first run, so here is the complete, ordered file rather than fragments to stitch.

# .github/workflows/build-aab-play.yml
name: Build Play AAB (production)
on:
  workflow_dispatch:
    inputs:
      ref: { description: 'Branch/ref to build', required: false, default: 'main' }

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Free up runner disk space
        uses: jlumbroso/free-disk-space@main
        with: { android: false, dotnet: true, haskell: true, large-packages: true, docker-images: true }

      - uses: actions/checkout@v4
        with: { ref: ${{ github.event.inputs.ref || 'main' }} }
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - uses: actions/setup-java@v4
        with: { distribution: temurin, java-version: 17 }

      - run: npm ci
      - run: npx expo prebuild --platform android --no-install

      - name: Patch the generated android/ (light, verified-parity)
        run: |
          set -euo pipefail
          GP=android/gradle.properties
          echo 'reactNativeArchitectures=arm64-v8a,armeabi-v7a' >> "$GP"
          echo 'android.enableMinifyInReleaseBuilds=false'      >> "$GP"
          echo 'android.enableShrinkResourcesInReleaseBuilds=false' >> "$GP"

      - name: Decode upload keystore
        run: echo "${{ secrets.MY_UPLOAD_KEYSTORE_BASE64 }}" | base64 -d > "$RUNNER_TEMP/upload.keystore"

      - name: Build signed release AAB
        working-directory: android
        env:
          KS_PASS: ${{ secrets.MY_UPLOAD_KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.MY_UPLOAD_KEY_ALIAS }}
          KEY_PASS: ${{ secrets.MY_UPLOAD_KEY_PASSWORD }}
        run: |
          ./gradlew bundleRelease \
            -Pandroid.injected.signing.store.file="$RUNNER_TEMP/upload.keystore" \
            -Pandroid.injected.signing.store.password="$KS_PASS" \
            -Pandroid.injected.signing.key.alias="$KEY_ALIAS" \
            -Pandroid.injected.signing.key.password="$KEY_PASS" \
            --no-daemon

      - name: Upload AAB artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release-aab
          path: android/app/build/outputs/bundle/release/*.aab
          if-no-files-found: error

A couple of things earn their place here. set -euo pipefail makes the patch step fail instead of half-applying. if-no-files-found: error turns a build that produced no bundle into a red run instead of a green one with an empty artifact. And the path glob points straight at Gradle's real output, so there is nothing to reconcile by hand.

The one simplification worth naming: appending the three lines with >> assumes they are not already set in your gradle.properties. If they are, switch to a sed replace so you do not end up with two conflicting values. Check your file once and pick the right tool.

Trigger it and pull the bundle

gh workflow run build-aab-play.yml --ref main
# grab the run id once it finishes
gh run list --workflow build-aab-play.yml
gh run download <run-id>

You now have a signed .aab on your laptop, built on hardware that cost you nothing. Validate it before you upload. If you drive the Play Developer API or a CLI wrapper over it, run a bundle validation, push it to your internal track, then smoke-test the universal APK on a real device with bundletool before you promote to production.

The takeaway

Managed build services sell convenience, and the free tier is genuinely good until the month you ship twice. When the quota wall hits at the worst possible moment, remember that the build itself is just Gradle. A free CI runner can do it, and the only real trap is signing: use the upload key Play already locked onto, base64 it into a secret, and inject it at build time.

I keep this workflow permanent now. Every release after the first is one gh workflow run and one gh run download, with zero laptop impact and no quota to watch. If you are mid-launch and staring at a reset date, you do not have to wait.

I write up the unglamorous parts of shipping small apps solo, the bugs and the launch fights, as I hit them. Follow along if that is your kind of thing.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

My Cron Jobs Were Firing 10 Hours Off Their Own Comments

Diven Rastdus — Wed, 24 Jun 2026 22:11:07 +0000

I scheduled a heavy maintenance job to run Saturday at 6am, while I was asleep and nothing else was using the machine. Weeks later I checked the logs. It had been firing every Saturday at 8pm, right in the middle of my most active hours.

The job was fine. The schedule was fine. My assumption about what the schedule meant was wrong.

The comment lied, and cron didn't care

Here is what the crontab line looked like:

# Saturday 06:00 UTC -- weekend maintenance, runs while I'm asleep
0 6 * * 6 /home/me/bin/weekend-maintenance.sh

The comment says UTC. I wrote it that way because I think in UTC for infrastructure. But that comment is just text. Cron never reads it.

My machine's local timezone is AEST (UTC+10). I had not set CRON_TZ anywhere in the crontab. So cron read 0 6 as 6am local AEST, not 6am UTC. The two are 10 hours apart.

Every time-of-day job in that crontab was firing 10 hours away from what its comment claimed. Eight of them. A morning report meant to land before I woke up fired in the evening. A "run this when the machine is quiet" job ran at peak. None of them errored, so nothing flagged it.

Why cron does this

Cron schedules in the system's local timezone by default. On Linux that is whatever the system clock is set to, or the TZ the daemon inherited. It is not UTC unless your machine is set to UTC.

You can confirm your machine's timezone in one command:

timedatectl
#                Local time: Sat 2026-06-20 20:00:13 AEST
#            Universal time: Sat 2026-06-20 10:00:13 UTC
#                  Time zone: Australia/Brisbane (AEST, +1000)

There is the 10 hour gap, right in the output. Local 20:00 is 10:00 UTC.

How to detect it on your own boxes

The fastest check is to compare what a job's comment claims against when it actually ran. Cron logs each invocation. On most systems:

# Debian / Ubuntu
grep CRON /var/log/syslog | grep weekend-maintenance

# RHEL / Fedora, or anything on systemd
journalctl -t CRON --since "14 days ago" | grep weekend-maintenance

Here is the line that gave me away. The comment promised 06:00 UTC. The log disagreed:

# crontab comment claims 06:00 UTC. Reality:
Jun 20 20:00:01 box CRON[12491]: (me) CMD (/home/me/bin/weekend-maintenance.sh)

20:00 local, not 06:00. Line up those timestamps with the hour you THINK the job runs. If they disagree by exactly your UTC offset, you have found it.

The fix: stop writing comments you aren't enforcing

There are two honest ways out, and which one you pick depends on the job.

For jobs whose intent is local ("run while I'm asleep", "send before the workday"), write the schedule in local time and label it as local. No surprise, no conversion in your head:

# Saturday 06:00 AEST (machine-local) -- weekend maintenance
0 6 * * 6 /home/me/bin/weekend-maintenance.sh

For jobs whose intent is a real fixed instant (a market-hours alert, a cross-region batch that must line up with UTC), set CRON_TZ explicitly at the top of the block:

CRON_TZ=UTC
# Now 0 6 genuinely means 06:00 UTC, whatever the machine's clock says
0 6 * * 6 /home/me/bin/utc-batch.sh

CRON_TZ overrides the timezone for every entry below it, until the next CRON_TZ. The standard cron daemons on mainstream Linux (Vixie and cronie) support it. It is not POSIX, so check your daemon if you run something exotic.

The gotcha that bit me twice: CRON_TZ is not TZ

One job genuinely needed US market hours, so I reached for CRON_TZ=America/New_York. That is correct, and naming a region handles US daylight saving automatically, which is the whole reason to use a region name instead of a fixed offset.

But CRON_TZ only controls WHEN the job fires. It does not set the timezone inside your script. The process still inherits the system TZ. If your script formats a timestamp or does date math, it uses the machine's timezone, not the one you scheduled in. If you need both, set both:

CRON_TZ=America/New_York
0 9 * * 1-5  TZ=America/New_York /home/me/bin/market-open.sh

That inline TZ= works because cron runs each job line through a shell, so a leading VAR=value becomes an environment assignment for the command.

Daylight saving still wants to ruin your day

Naming a region (America/New_York) instead of a fixed offset means cron tracks DST for you. Good. But DST itself has two sharp edges, and CRON_TZ does not file them down:

On spring-forward, the 02:00 to 03:00 hour does not exist. A job scheduled at 02:30 just does not run that day.
On fall-back, that hour happens twice. A job inside it can run twice.

The boring fix is to keep anything important out of the 01:00 to 03:00 window. Schedule at 04:00 or later and DST never touches you.

Back to the Saturday job

The fix for the job that started all this was the boring one. I rewrote the comment to match the mechanism and left the schedule alone:

# Saturday 06:00 AEST (machine-local) -- weekend maintenance
0 6 * * 6 /home/me/bin/weekend-maintenance.sh

The next Saturday, journalctl -t CRON showed it firing at 06:00 AEST. Machine quiet, me asleep, finally doing what the comment always claimed.

The actual lesson

The bug was not cron. Cron did exactly what it always does. The bug was that I trusted a comment to enforce behavior it had no power over.

A # runs at 09:00 UTC comment is documentation. It is the weakest thing in the system, because nothing checks it against reality. The schedule is the enforcement. When the two drift apart, the schedule wins, and you do not get an error. You get ten hours of silent wrongness.

The rule I follow now is small. Write each schedule in the timezone you actually mean. Set CRON_TZ (and TZ) when correctness depends on it. And never let "the server is probably UTC" be the load-bearing assumption.

Go run timedatectl on your boxes, then read your crontab comments back as claims instead of facts. You might have a job that has been quietly firing at the wrong hour for months. I did.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

My Superwall Paywall Showed Blank Prices on Cold Start. Two Bugs, One Was a Default.

Diven Rastdus — Mon, 22 Jun 2026 12:10:48 +0000

My paywall presented perfectly. Right design, right layout, right call-to-action. The only problem: the subscription prices were blank.

Weekly, monthly, annual: each tier showed its period label ("/wk", "/mo", "/yr") and an empty space where the price should be. Here is the strange part. RevenueCat, running side by side in the same app, had already fetched every real price a second earlier. The lifetime tier, sitting in the same paywall, rendered its price fine ($184.99). So the prices existed. Superwall just refused to draw three of them.

That mismatch took nine rounds of debugging to crack. Here is what was actually wrong, so you can skip the nine rounds.

The setup

The app is an Expo / React Native app. The paywall stack is expo-superwall for presentation and A/B testing, with RevenueCat as the single source of truth for entitlements. They talk through Superwall's recommended CustomPurchaseControllerProvider, so a Superwall purchase routes through react-native-purchases and fires RevenueCat's normal listener.

This is a common combination. Superwall owns the paywall UI, RevenueCat owns "who is paying". If you run it, you can hit both of the bugs below.

One Superwall detail matters for the rest of this story. Superwall renders the paywall in a webview and fills in values like {{ products.primary.price }} from a product-variable map it builds from the loaded store products. If that map is empty, the template renders an empty string. An empty string is your blank price. So "blank prices" really means "Superwall built an empty product-variable map", and the whole hunt is about why that map came up empty.

Why I was blind for so long

The first real unlock was not a fix. It was visibility.

Superwall's SDK logs are invisible at the default log level. In my app only RevenueCat logged anything, so logcat looked like Superwall was barely running. "No Superwall product query in the logs" felt like proof of a dead SDK. It was not. The SDK was busy, just silent.

<SuperwallProvider
  apiKeys={apiKeys}
  options={{
    logging: { level: 'debug', scopes: ['all'] },
  }}
>

With level: 'debug' and scopes: ['all'], the productsManager, storeKit, and paywallPresentation lines all appeared. Now I could see Superwall building its product variables and coming up empty, right next to RevenueCat fetching the same prices without trouble:

[Superwall] [productsManager] ERROR: Billing client not ready
[RevenueCat] Retrieved productDetailsList: annual ... $85.99 ... freeTrial:7d
[Superwall] [paywallPresentation] productVariables: null

Two billing clients, one ready and one not, in the same process. Lesson one: before you theorize, turn the logs on. A quiet SDK is not an idle SDK.

Bug one: the entitlement status was stuck on Unknown

With a custom purchase controller, you are responsible for telling Superwall the subscription status. Superwall defaults that status to SubscriptionStatus.Unknown at configure time. Its presentation pipeline has an operator, WaitForSubsStatusAndConfig, that blocks until the status is anything other than Unknown. The SDK's own error text says it plainly: if you use a custom purchase controller, set the entitlement status on time.

My sync code did call RevenueCat's getCustomerInfo() once at startup and pushed the result into Superwall. The problem was timing. Purchases.configure in my app is gated behind auth, but the Superwall provider mounts outside the auth provider. So the initial getCustomerInfo() could run before RevenueCat was configured, throw, and get swallowed. The change listener only fires on a change, so the status never moved off Unknown.

While the status sat at Unknown, the present pipeline stalled and the product-variable map came out empty. Empty variables render as blank prices in the webview. That matched exactly what the debug logs showed.

The fix was to seed a concrete status before any paywall can present, retrying until RevenueCat is actually configured:

// retries getCustomerInfo() until RC is configured (bounded ~6s),
// then pushes a concrete ACTIVE / INACTIVE into Superwall
async function seedInitialSubscriptionStatus() {
  const info = await getCustomerInfoWhenReady(); // bounded retry loop
  const isActive = hasProEntitlement(info);
  Superwall.shared.setSubscriptionStatus(
    isActive ? activeStatus : inactiveStatus,
  );
}

If RevenueCat never configures within the bound, the seed falls back to INACTIVE, so a non-paying user still sees the paywall (the safe default), and the change listener owns every later transition. That was the real fix. The status now reaches Superwall as a known value before the first present, so the pipeline stops stalling.

Bug two: a default that flips between platforms

After the status fix, prices rendered. Sometimes. If I let the app sit for the better part of a minute before opening the paywall, every price showed. Open the paywall fast after a cold launch and it went blank again.

The debug logs explained it. On a fast view, Superwall computed the paywall's product variables before its own store manager had loaded the products. No loaded products meant a null variable map, which meant blank prices. When I waited, RevenueCat had incidentally warmed the shared Google Play product cache by then, so Superwall's later fetch was a cache hit. My "fix" was riding on luck and a warm cache.

The root cause is a default value. In expo-superwall@1.1.5, the default options ship shouldPreload: false. You can read it straight from the package:

// node_modules/expo-superwall/build/src/SuperwallOptions.js:15
DefaultSuperwallOptions.paywalls.shouldPreload = false;
// merge in useSuperwall: { ...DefaultSuperwallOptions.paywalls, ...yourOptions.paywalls }

The native superwall-android SDK preloads paywalls by default, so the expo wrapper quietly flips the behavior. If you pass options without a paywalls key, the merge keeps the false, preload stays off, and products only load at trigger time. The fix is one line, set explicitly:

options={{
  paywalls: { shouldPreload: true },
  logging: { level: 'warn' },
}}

With preload on, Superwall warms its own products and builds the paywall's variables at launch, independent of RevenueCat's timing. The cold launch logs now tell the opposite story, before any trigger fires:

[Superwall] config_attributes should_preload=true
[Superwall] [paywallPreload] paywallPreload_start
[Superwall] [paywallPreload] paywallPreload_complete
[Superwall] [paywallPresentation] productVariables: { weekly, monthly, annual }

Prices render every time now, fast cold start or slow.

The red herring

For two rounds I chased a webview error: store/document/undefined - Code: 404. It looked like the smoking gun. It was not. That request fires even when prices render correctly. Chasing it cost me real time.

When you debug an SDK you do not own, separate the symptoms that correlate with the bug from the noise that is always there. Reproduce the success state and check whether your "smoking gun" is still firing. If it is, it is noise.

Why lifetime rendered and subscriptions did not

The detail that nagged me the whole time: the lifetime tier always showed its price. Lifetime is a one-time purchase with no base plan or offer, so it follows a simpler resolution path. The subscriptions go through the product-variable substitution that both bugs broke. One blank tier next to one working tier is a strong hint that the problem is in the per-product variable path, not the network or the store account.

The takeaway

Three things to carry into your own Superwall plus RevenueCat integration:

Turn on logging: { level: 'debug', scopes: ['all'] } first. The SDK is silent by default, and you cannot fix what you cannot see.
With a custom purchase controller, seed a concrete subscription status before any paywall presents. An Unknown status short-circuits product loading.
Set paywalls: { shouldPreload: true } explicitly. The expo wrapper defaults it to false, against the native default, and that single value decides whether your prices survive a fast cold start.

I am building a mobile app solo and writing up the real bugs as I hit them. If you want more of these field notes, follow along.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Our Tests Were Green. The Feature Had Never Worked.

Diven Rastdus — Sun, 21 Jun 2026 12:14:02 +0000

I was doing a UI cleanup pass on our astrology companion app. One card said "Recurring themes are coming soon" in a PRO section. I restyled it to match the new design and moved on.

Our tech lead caught it an hour later.

The feature wasn't "coming soon." It was built. Three months ago. The component existed, the data pipeline existed, the edge function computed the themes and returned them. But a parent component never passed the themes prop. One unwired seam. The card had been silently dead for every paying user since launch.

The worst part: tsc was clean. Unit tests were green. There was no error to find.

Here's what the broken wiring looked like:

// What shipped -- tsc passes, component tests pass, no warnings
<MirrorCard isPro />          // themes prop optional, defaults to []

// What a paying user needed
<MirrorCard isPro themes={insights.recurringThemes} />

One token. A green test suite and a one-token-wide hole.

The problem is never the piece, it's the seam

Every unit test verifies a piece in isolation. Pass in these inputs, expect these outputs. That's the right thing to test.

But user-facing features aren't pieces. They're chains: edge function computes data, API response carries it, parent receives it, parent passes it to the component, component renders it, button routes somewhere real. A test can verify every link in that chain individually while the chain itself is broken.

The gap is the seam. And seams are invisible to your test suite.

After we found the themes card, we ran a completeness audit and found the same pattern in three more places:

Live transit data that never rendered. The edge function computed the day's planetary transits correctly. Tests passed. But the response body didn't include the transits field, so the Today screen's chips never had data to render. Empty chips, no error, zero indication anything was wrong.

A "PRO unlock" that didn't unlock anything. There was a line of text saying "Unlock with PRO" on a life-area screen. It looked interactive. It was a <Text> component with no onPress handler. The paywall never opened. A user could tap it a hundred times and get nothing.

A share card no one could reach. We'd built a synastry share card, full design, full animation. It was never mounted anywhere in the navigation tree. The only way to know it existed was to read the source.

Four different failure modes. Same root cause: the seam was missing.

Why your tools can't see this

TypeScript checks types within a file, not whether a prop gets passed between files. It knows <MirrorCard> accepts a themes prop of a certain shape. It doesn't know whether any parent ever supplies it.

Jest tests a component's behavior given a prop. Not whether that prop ever arrives in production.

ESLint catches unused imports, not unused components. A component that exports correctly but is mounted nowhere will pass every lint rule.

The only thing that catches "the chain is broken" is actually walking the chain.

The seam-tracing habit

When you see any of these on a shipping surface, treat it as a bug to investigate, not text to restyle:

"Coming soon"
"Feature locked" / "Upgrade to unlock"
A TODO comment in a rendered string
A placeholder UI that matches the app's design language perfectly

The question isn't "is this intentional?" The question is: can a user actually get what this surface promises? Walk the chain from the user's tap to the data being delivered. If any link is missing, that's the bug.

For each feature seam, I now check four things:

Does the parent pass the data? Look at every call site of the component. Is the relevant prop actually supplied?
Does the API response include the field? Not "does the function compute it." Does the response body carry it back to the client?
Is the component actually mounted? Search your navigation tree and any conditional renders. Is there a path a user can actually reach this component?
Does the CTA route somewhere real? That "Unlock with PRO" text from earlier was a <Text> with no onPress. Check every tappable element traces to an actual handler. console.log and empty onPress={() => {}} are not handlers.

This sounds obvious stated plainly. In practice, when you're refactoring UI across 40 screens, you restyle what's there and move on. The seam audit is a separate pass.

After any broad refactor: run a completeness audit

We added a step to our post-refactor checklist:

# Find any "coming soon" or placeholder text in the shipping codebase
grep -rni "coming soon\|todo\|placeholder" src/ --include="*.tsx" --include="*.ts" --include="*.jsx"

For every hit, ask: is this intentional? If no, trace the seam.

For the highest-stakes paths (paywall CTAs, PRO feature gates, any screen a paying user specifically navigated to), we live-smoke the deployed build. Not the dev build. The deployed one. Because "code exists" in a dev environment and "feature works" in production are different claims.

The flow for a PRO gate:

Log in as a subscribed user on the deployed build
Navigate to the feature
Try the thing the UI promises
Verify you got actual content, not an empty state or a silent dead end

This takes 15 minutes for a full suite of critical paths. It catches things that would otherwise reach users and never generate an error log. Silent disappointment is the outcome.

The thing about silent failures

Errors are easy. Your monitoring catches them, your users report them, your CI catches them in tests.

Silent failures are harder. The app doesn't crash. No error is logged. The user taps a button that does nothing, or sees an empty state they assume is "just how it works," or pays for a feature they can never access. They churn. You never know why.

The seam audit exists specifically to catch that class of failure before it reaches users.

One unwired prop. That's all it took to make a paid feature invisible to every subscriber we had.

If you're building on Expo + Supabase, the seam pattern shows up most reliably at the edge function boundary. The function computes correctly. What it returns to the client is a different question. Always verify the response body, not just the function logic.

What's the dumbest seam bug you've shipped? Mine was a <Text> that looked like a button for three months.

We write about building real apps (and the things that go wrong) at astraedus.dev.

I built a free, open-source Daylio alternative instead of paying a subscription

Diven Rastdus — Fri, 19 Jun 2026 23:34:41 +0000

I tried to start tracking my mood properly this year. The advice everyone gives is the same: log it daily, look at the patterns, adjust. Fine. So I went looking for the app.

Daylio is the one everyone points to, and it's genuinely good. Clean, fast, the design is years ahead of most of the category. I used it for a couple of weeks. Then I went to look at the actual stats, the part that's the whole point, and hit a wall.

The interesting graphs are premium. Mood-by-weekday, the activity correlations, the longer trends. That's the data that tells you something. And it sits behind a subscription.

What Daylio actually costs

I want to be fair here, so I checked the current numbers rather than going off memory. Daylio has a real free tier, and it works. But Daylio Premium runs $4.99 a month or $35.99 a year, with a 7-day trial. (They run discounts on the annual plan fairly often.)

The free version is not crippled, but the things it locks are the things I cared about. When you're on free, you lose:

Advanced stats
Moods and goals past a free limit
Reminders past a free limit
Automatic backups
PDF export
Premium themes

So the deal is: the tracking is free, the understanding is paid. For a tool whose entire value is helping you see your own patterns, paywalling the patterns felt backwards to me. I wrote more about that specific objection in why mental-health tracking behind a subscription is backwards.

To Daylio's credit on privacy: they don't send your entries to their servers, and backups go to your own Google Drive or iCloud over encrypted channels. That part is good and I'm not going to pretend otherwise.

So I built SoulSync

I'm a developer, and I had a stubborn opinion, which is a dangerous combination. I built SoulSync, a mood tracker and journal with two rules: nothing behind a paywall, and nothing leaves your device.

It's React Native and Expo, TypeScript in strict mode, 333 passing tests, and it's GPL-3.0. Open source from the start. The code that holds your most private data is public, so you can read it instead of trusting a sentence on a marketing page.

Every entry is stored in a SQLite database on your phone. Photos too. There is no account to create, no server to connect to, no cloud bucket sitting somewhere with your feelings in it. I go deeper on the architecture in a mood tracker shouldn't need an account or the cloud.

An honest comparison

Here's the side by side. I've kept it to things I can actually back up.

	SoulSync	Daylio
Price	Free (open source)	Free tier; Premium $4.99/mo or $35.99/yr
Advanced stats	Included	Premium
Activity correlation	Included	Premium
Data export	JSON, included	PDF export is Premium
Themes	5, all free	Some themes are Premium
Entries stored on device	Yes (SQLite)	Yes (cloud backup is optional)
Open source	Yes, GPL-3.0	No
Platforms	Android (free APK)	Android and iOS

Daylio wins on polish and platform reach. It's been worked on for years by a team, and it shows. If you're on iPhone, it's your option and SoulSync isn't, yet.

SoulSync wins on the two things I built it for: you pay nothing for the full feature set, and the code is open so the privacy claim is checkable.

What open source plus local-first actually buys you

Two phrases get thrown around a lot. Here's what they mean in practice, not in pitch.

Local-first means the app works with no network, the data is a file you own, and there's no account that can be locked or breached. If my server vanished tomorrow, your SoulSync history wouldn't even notice. There is no server.

Open source means the privacy story isn't a promise, it's source code. You can read exactly where your data goes, which is nowhere, and so can anyone else. It also means the app can't quietly add tracking in a future update without it being visible in the commits.

And it means free without a catch. There's no premium tier waiting to be unlocked because there's no business model that depends on one. The whole app is the free version because there is no other version.

If you want to try it

SoulSync is Android-only for now. Download the APK from the latest GitHub release and log your first entry. It stays on your phone.

If you find a bug or want a feature, the repo is right there: github.com/Antimatter543/mood-tracker.

My Expo Device Tests Could Break Without CI Noticing. Here Is the Fix.

Diven Rastdus — Thu, 18 Jun 2026 12:09:29 +0000

My on-device QA used to be an AI tapping my app by pixel coordinates. One regression walk logged 83 raw coordinate taps. It was slow, it was flaky, and when it failed I could never tell if the app broke or the tap landed two pixels off a button.

This is the story of replacing that. The same six launch-blocker flows now run in about 90 seconds, with no model in the loop, plus a Jest guard that makes the whole thing unregressable. The app is Origo, an Expo SDK 56 (React Native 0.85) astrology app I am shipping to the Play Store.

Why the AI fell back to pixel coordinates

I was driving the Pixel 3 with an accessibility-tree tool. Point it at an element, it reads the tree, finds the node, taps the node. On a native app this is fast and stable, because native widgets populate the accessibility tree for free.

React Native does not. A <Pressable> shows up as an anonymous view unless you give it a testID. My app had nine testIDs across 164 files. So the tree-matching found almost nothing, and the tool degraded to its fallback: tap by screen percentage. That is the 83 taps. Every one is a guess at where a button rendered, and every screen size or layout tweak silently invalidates it.

The lesson is boring and load-bearing: an RN app is only as queryable as its testIDs. Fixing the QA speed was downstream of fixing that.

Step 1: testIDs on the flows that matter

I did not testID-everything. I picked the six flows that, if broken, block launch. Those are sign in, upgrade-to-pro opening the paywall, a PRO reading hitting the paywall, editing birth data, synastry (the relationship-compatibility screen) add-person refreshing the list, and sign out. Then I added stable testIDs to exactly the elements those flows touch. That took the count to 99 testIDs across 30 files, each one paying for itself.

Step 2: encode the flows in Maestro, self-contained

Maestro (2.6.0) runs YAML flows against a real device. The first version chained flows with clearState and back, and it was brittle: one flow would exit on the wrong screen and the next would start from a bad state.

The fix was to make every flow state-independent. Flow 1 clears state and tests the welcome to sign-in path itself. Flows 2 through 5 start with a plain launchApp. No state clear. On this app that preserves the signed-in Supabase session and drops you on the Today tab. So each flow re-navigates from a known state and never depends on the previous flow's exit screen.

# FLOW 2 - Upgrade-to-Pro opens the paywall (self-contained)
- launchApp                      # preserves session, lands on Today
- tapOn:
    point: "90%,92%"             # You tab
- tapOn:
    id: "upgrade-cta"
- assertVisible: "Restore"       # substring matches both paywall variants

That assertVisible: "Restore" is deliberate. Two different paywalls can render depending on whether RevenueCat's offering loaded at runtime, and "Restore" is a substring present in both. Assert the thing that is true in every valid state, not the exact string of one of them.

The trap: an on-device suite can break with zero CI signal

Here is the part that bit me and that I have not seen written down.

Those testIDs only take effect after a new build. And a Maestro failure only surfaces on-device, when someone bothers to run the suite. So if I rename upgrade-cta to upgrade-button during a refactor, nothing fails. Tests pass. CI is green. The regression suite is quietly dead, and I find out the next time I happen to plug in the phone.

A device suite that can rot silently is worse than no suite, because it tells you that you are covered when you are not.

Step 3: a Jest contract test makes the testIDs unregressable

So I pushed the guarantee down to the unit level, where it runs on every commit with no device. A plain Jest test asserts two things: every testID the Maestro suite depends on still exists in the source file that renders it, and the Maestro YAML references exactly that set and no other.

const TESTID_SOURCES: Record<string, string> = {
  'onboarding-sign-in': 'app/onboarding/index.tsx',
  'upgrade-cta': 'astro/screens/you/SubscriptionCard.tsx',
  'paywall-purchase': 'astro/screens/onboarding/CustomPaywall.tsx',
  // ... one entry per testID the suite drives
};

it.each(Object.entries(TESTID_SOURCES))(
  'testID "%s" is declared in %s',
  (testId, file) => {
    const contents = readFileSync(srcPath(file), 'utf8');
    expect(contents.includes(`testID="${testId}"`)).toBe(true);
  }
);

it('the Maestro flow references only contract testIDs (no drift)', () => {
  const flow = readFileSync('.maestro/origo-regression.yaml', 'utf8');
  const referenced = [...flow.matchAll(/\bid:\s*"([^"]+)"/g)].map((m) => m[1]);
  const contract = new Set(Object.keys(TESTID_SOURCES));
  expect(referenced.filter((id) => !contract.has(id))).toEqual([]);
});

It checks the source text, not the rendered output, on purpose. It is the literal testID="..." string the device tooling matches, so I want to assert that exact string survives, independent of render internals or RN mocks. Rename a testID and forget the YAML, the contract test goes red on the next commit. Add a flow that needs a new testID, add the pair to the map and the guard enforces it forever.

Step 4: run the same flows against the release APK

The last gap: I was testing the dev client over Metro, not the artifact users install. So the runner got a second mode. SMOKE_TARGET=installed skips all the Metro and dev-launcher setup and drives a plain installed release APK. The flows' Metro-connect step is a conditional subflow, so it is a no-op there, and the exact same six flows validate the CI build.

EMAIL=... PASSWORD=... SMOKE_TARGET=installed \
  ./scripts/device-smoke.sh .maestro/origo-regression.yaml

A couple of gotchas worth saving you the time: Maestro's GraalJS runtime has no Thread.sleep, so timed waits go through a small busy-wait helper. And tab-bar taps use a screen percentage rather than a testID, because on the Pixel 3 the tab testID bounds bleed into the Android nav bar and the tap misses. That is the one place coordinates are correct, because the position is fixed and the elements are not individually addressable.

The takeaway

Speed was never the real problem. The real problem was determinism. Three changes fixed it: make the app queryable with testIDs on the flows that matter, encode those flows so they do not depend on each other, and then guard the fragile contract (testIDs that only exist after a build, failures that only show on-device) with a unit test that runs on every commit.

If you take one thing: an on-device test suite that can break without turning anything red is a liability. Find the part that can drift silently and pin it down a layer, where the cost of breaking it is a failed CI run, not a missed regression in production.

I am building Origo in the open. Next up: the paywall that renders two different ways depending on whether RevenueCat's offering loaded, and how I stopped guessing which one a user sees. Follow if that is your kind of problem.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

4 Ways RevenueCat Silently Denies Paying Users Their Entitlements

Diven Rastdus — Tue, 16 Jun 2026 12:10:50 +0000

Your store credentials are valid. RevenueCat accepted the service account. The SDK initialized without throwing. And your paying users are still seeing the free tier.

This is the second layer of the RevenueCat wiring problem. The one that doesn't produce an error. The first layer (invalid credentials, service account propagation delays) has been written about. This one hasn't. These are four bugs I found building Origo, an AI astrology app on Expo + RevenueCat + Supabase. All four were silent. All four passed tests. All four denied real users real value.

1. `Purchases.logIn()` was never called

This was the most expensive one. Three days of confused billing debugging before I found it.

Every purchase made before you call Purchases.logIn(userId) registers under an anonymous RC identity: $RCAnonymousID:some-uuid. When your RevenueCat webhook fires to update your database, it can't map an anonymous RC id to a real user row. It either skips the event or writes an orphaned record. Your server's entitlement check returns false for that user.

The purchase exists in RevenueCat's dashboard. The user paid. Nothing shows up on your backend.

The fix requires understanding what RC does with identity. You want RC's app_user_id to be your auth system's stable user id, set BEFORE any purchase happens:

const initialize = useCallback(async (userId?: string) => {
  if (!initialized || configuredApiKey !== apiKey) {
    Purchases.configure({ apiKey, appUserID: userId });
    initialized = true;
  } else if (userId && currentAppUserID !== userId) {
    // User signed in after RC was already configured; switch identity
    const loginResult = await Purchases.logIn(userId);
    currentAppUserID = userId;
    info = loginResult.customerInfo;
  }
}, []);

If your auth flow allows anonymous purchases (user buys before creating an account), call logIn() with the stable user id the moment they sign up. RC handles the client-side transfer from anonymous to identified, but your webhook still has to catch the TRANSFER event and re-key the database row. More on that in #4.

In my case, Supabase's anonymous auth preserves the user id across the anon-to-email upgrade (auth.updateUser() keeps the same uuid). So I pass the Supabase uuid to RC from the very first session, before they've ever entered an email. When they eventually link an account, the RC identity is already the final, stable uuid.

2. No `customerInfo` listener

Here's what happens when you skip a customerInfoUpdateListener:

A user purchases through your native paywall (via Purchases.presentPaywall()). The purchase succeeds. Your paywall dismisses. The user is back on the main screen, still seeing the free tier, because the component that owns isPro state hasn't been told anything changed.

The listener is how RC pushes out-of-band entitlement changes: purchases through the native paywall, server-side grants, trial conversions, grace-period resolutions. Without it, you're only checking entitlements at cold start.

useEffect(() => {
  let active = true;

  const onCustomerInfo = (info: CustomerInfo) => {
    if (active) checkEntitlements(info);
  };

  (async () => {
    await initialize();
    try {
      Purchases.addCustomerInfoUpdateListener(onCustomerInfo);
    } catch {
      // SDK not configured in dev; nothing to listen to
    }
  })();

  return () => {
    active = false;
    try {
      Purchases.removeCustomerInfoUpdateListener(onCustomerInfo);
    } catch {}
  };
}, [initialize, checkEntitlements]);

react-native-purchases v10 gotcha: addCustomerInfoUpdateListener returns void. You can't call .remove() on the return value. Cleanup is removeCustomerInfoUpdateListener(sameRef), and sameRef has to be the exact same function reference. Define the listener inside the effect, close over it, pass the same reference to both add and remove.

3. The RC session leaked between users on the same device

This bug is invisible to unit tests. You'd need an integration test that calls configure(), then logOut(), then signs in as a different user and checks their entitlements. Most test suites don't go there.

RC's SDK uses module-level state. Once Purchases.configure() has run with User A's identity, that configuration persists until you explicitly clear it. If User A signs out and User B signs in, and your initialization check says "already initialized, skip". User B inherits User A's RC session. If User A was a paying subscriber, User B gets isPro: true.

Reset your initialization bookkeeping on sign-out, right after calling Purchases.logOut():

// Call this on every sign-out, after Purchases.logOut()
export function resetRCSession() {
  initialized = false;
  configuredApiKey = null;
  currentAppUserID = undefined;
}

Purchases.logOut() returns RC to an anonymous identity. resetRCSession() clears your bookkeeping so the next initialize() doesn't short-circuit on the previous user's state.

4. The webhook handles purchases but ignores refunds and cancellations

The first three bugs are client-side. This one is server-side, and it's the one that keeps denying access after everything else is right.

Your subscription table probably gets written on INITIAL_PURCHASE and RENEWAL. If you're not handling CANCELLATION, REFUND, and TRANSFER, your database will say is_active: true for users whose subscriptions have ended. They lose access only when expires_at passes (if you even store that field).

The full event set you need, at minimum:

INITIAL_PURCHASE: create the subscription row
RENEWAL: extend expires_at
CANCELLATION: mark inactive (keep the row; they may have time remaining)
REFUND: mark inactive immediately
TRANSFER: re-key the row when RC reassigns app_user_id

TRANSFER is the one that closes the loop from bug #1. When an anonymous user creates an account and RC transfers their purchase history to a named identity, a TRANSFER event fires with transferred_from (the old anonymous id) and app_user_id (the new identified one). Ignore it, and the purchase stays associated with an id that doesn't map to any user row.

switch (event.type) {
  case 'INITIAL_PURCHASE':
  case 'RENEWAL': {
    const expiresAt = event.expiration_at_ms
      ? new Date(event.expiration_at_ms).toISOString()
      : null;
    await upsertSubscription(event.app_user_id, { is_active: true, expires_at: expiresAt });
    break;
  }
  case 'CANCELLATION':
    await updateSubscription(event.app_user_id, { is_active: false });
    break;
  case 'REFUND':
    await updateSubscription(event.app_user_id, { is_active: false, refunded: true });
    break;
  case 'TRANSFER':
    // transferred_from is an array; the relevant old id is [0]
    await transferSubscription(event.transferred_from[0], event.app_user_id);
    break;
}

The checklist

Before shipping a RevenueCat-gated feature:

Is Purchases.logIn(userId) called with the stable auth user id before any purchase can happen?
Is there an active customerInfoUpdateListener on every screen that gates on isPro?
Does sign-out call Purchases.logOut() AND reset your initialization bookkeeping?
Does the webhook handler cover CANCELLATION, REFUND, and TRANSFER, not just INITIAL_PURCHASE?

Credentials being valid is table stakes. The silent failures come after.

Building with RevenueCat on Expo/React Native and hit a different version of these? Comments are open. Also at raeduslabs.com.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

RevenueCat Said My Play Store Credentials Were Invalid. They Weren't.

Diven Rastdus — Sun, 14 Jun 2026 12:11:02 +0000

I created a Google service account, uploaded the JSON key to RevenueCat, and watched my Android app reject every purchase. The dashboard said the credentials needed attention. On device, the logs showed a RevenueCat error: 7107 / Invalid Play Store credentials.

The credentials weren't invalid. I'd just made the mistake that costs a lot of mobile developers a full day: I expected Google to be fast.

Here are three Google Play Billing traps from one app launch. Two of them are Google being slow. The third costs money instead of time. All three look exactly like bugs in your code, and none of them are.

The setup

I'm building Origo, a subscription app on Expo and React Native. Payments run through RevenueCat, which validates every Google Play purchase server-side before it grants entitlements. That server-side check is the whole point. The client can't be trusted to claim "this user paid," so RevenueCat asks Google directly.

To ask Google, RevenueCat needs a service account with access to your Play Console. You create the service account in Google Cloud, generate a JSON key, grant it permissions in Play Console, and paste the key into RevenueCat. The official docs walk through it cleanly.

Then nothing works, and the docs don't warn you loudly enough about why.

Trap 1: "Invalid Play Store credentials" usually means "wait"

The first purchase test failed instantly. RevenueCat's dashboard showed a banner: Credentials need attention. On device, the SDK threw Invalid Play Store credentials. My first instinct was that I'd pasted the wrong key or missed a permission.

I hadn't. The key was correct and the permissions were correct. The problem was time.

When you create a fresh service account, Google has to propagate its access to the Play Developer API. RevenueCat's support docs put this at 24 to 48 hours. Until it finishes, every server-side validation returns an error that reads like a configuration mistake. So you "fix" a config that was never broken, re-upload the same key, and wait again.

The faster fix: you can force Google to re-evaluate the credentials instead of waiting on the background job.

Open Play Console and go to your app.
Go to Monetize → Products → Subscriptions (or In-app products).
Edit any product. Change the description. Save.

Saving a product change pokes the billing config and can validate the new credentials right away, per RevenueCat's own guidance. If you remember one thing from this post, remember that the credential error is a clock, not a bug. Editing a product can reset the clock.

Trap 2: new products return ITEM_UNAVAILABLE for hours

The second trap looks even more like a real defect. You create a subscription or a one-time product in Play Console, wire it into RevenueCat, run a purchase, and the SDK returns ITEM_UNAVAILABLE.

The product exists. You're staring at it in the console. It still says unavailable.

Same root cause: propagation. A product you created minutes ago hasn't reached the billing backend yet. One-time products in particular can take hours. I hit this with a lifetime product I'd created minutes before the test, started reading my purchase flow line by line, then realized the product was simply too new to buy.

The rule I follow now: if a product is less than a few hours old, ITEM_UNAVAILABLE isn't evidence of anything. Retest later before you touch your code. The most expensive debugging is debugging a system that simply isn't ready yet.

Trap 3: test with license testers, or you'll charge yourself

The first two were Google being slow. This one's different. It's the mistake that turns a test into a real transaction.

Google Play has no separate sandbox the way Apple does. A purchase on a live product charges a real card unless the buying account is registered as a license tester. So before any purchase test, I add our test Google account under Play Console → Settings → License testing. License testers get the full purchase flow, real dialogs, real RevenueCat validation, but no charge and no refund paperwork.

Skip this step and your "test" buys your own subscription with real money. Then you're filing a refund instead of reading logs.

The pattern underneath

The two delays share one shape. The symptom shows up at the boundary between your app and a platform you don't control, and that platform is eventually consistent. It says no now and yes in a few hours, with nothing in between that admits it's still thinking.

Your debugging instinct is to assume the last thing you changed is broken. With Google Play Billing, the last thing you changed is often correct and just not live yet. So I changed my checklist. Before I debug a billing error, I ask one question first: how old is the thing that's failing? If the answer is minutes or hours, I wait and retest before I read a single line of my own code.

That one question has saved me more time than any fix.

I'm writing up the real launch problems behind Origo as I hit them. If you're shipping subscriptions on React Native, these propagation traps are the ones I wish someone had warned me about on day one.

I write these from real work at astraedus.dev, that's where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

DEV Community: Diven Rastdus

5 Python 3.14 Features That Change How You Write Code in 2026 (And 2 I'm Still Waiting For)

1. from __future__ import annotations is finally dead

2. Template strings kill the f-string injection footgun

3. No-GIL is official: threads that use every core

4. Attach a debugger to a live process, no restart

5. Zstandard is in the stdlib, so pip install zstandard can go

What I'm still waiting for

The takeaway

TypeScript vs JavaScript in 2026: Now That Node Runs .ts Files Directly

What changed in 2025: your runtime reads TypeScript

TypeScript earns its keep when code outlives the week

When the type tax is not worth paying

The two languages are converging

So which should you use in 2026?

5 Cron Mistakes That Silently Break Your Scheduled Jobs

1. The timezone trap

2. The bare PATH problem

3. No year field means one-shots repeat forever

4. Silent failure, no one watching

5. Overlapping runs

Why these all share the same root cause

My Offline App's Backup Lost Every Photo on a New Phone

Why path references quietly fail

The fix: carry the bytes, not the path

Restore the files before you touch the database

Make it survive bad input

The tradeoff is real and it is fine

The takeaway

EAS Free Build Quota Ran Out. I Shipped a Signed Play AAB on GitHub Actions Instead.

Why GitHub Actions and not local

The build config that matters

Free the disk before you build

The signing gotcha (read this part twice)

The whole workflow, in order

Trigger it and pull the bundle

The takeaway

My Cron Jobs Were Firing 10 Hours Off Their Own Comments

The comment lied, and cron didn't care

Why cron does this

How to detect it on your own boxes

The fix: stop writing comments you aren't enforcing

The gotcha that bit me twice: CRON_TZ is not TZ

Daylight saving still wants to ruin your day

Back to the Saturday job

The actual lesson

My Superwall Paywall Showed Blank Prices on Cold Start. Two Bugs, One Was a Default.

The setup

Why I was blind for so long

Bug one: the entitlement status was stuck on Unknown

Bug two: a default that flips between platforms

The red herring

Why lifetime rendered and subscriptions did not

The takeaway

Our Tests Were Green. The Feature Had Never Worked.

The problem is never the piece, it's the seam

Why your tools can't see this

The seam-tracing habit

After any broad refactor: run a completeness audit

The thing about silent failures

I built a free, open-source Daylio alternative instead of paying a subscription

What Daylio actually costs

So I built SoulSync

An honest comparison

What open source plus local-first actually buys you

If you want to try it

My Expo Device Tests Could Break Without CI Noticing. Here Is the Fix.

Why the AI fell back to pixel coordinates

Step 1: testIDs on the flows that matter

Step 2: encode the flows in Maestro, self-contained

The trap: an on-device suite can break with zero CI signal

Step 3: a Jest contract test makes the testIDs unregressable

Step 4: run the same flows against the release APK

The takeaway

4 Ways RevenueCat Silently Denies Paying Users Their Entitlements

1. Purchases.logIn() was never called

2. No customerInfo listener

3. The RC session leaked between users on the same device

4. The webhook handles purchases but ignores refunds and cancellations

The checklist

1. `from future import annotations` is finally dead

5. Zstandard is in the stdlib, so `pip install zstandard` can go

1. `Purchases.logIn()` was never called

2. No `customerInfo` listener