DEV Community: Odd Eggs Studio

Vietnam's 2027 public holidays, in money (and the pot maths behind it)

Odd Eggs Studio — Sun, 08 Nov 2026 14:00:00 +0000

Cross-posted from the 6pm blog. We make 6pm, an iPhone budgeting app built in Saigon, and this is the guide we wrote for our Vietnamese users' 2027 holidays. If you build anything that turns a date into a monthly amount, there's a short section near the end on how the app does that maths in TypeScript, integer đồng and all.

Between now and the end of 2027, Vietnam has six public holiday breaks besides Tết: 24 November 2026, 1 January, Hùng Kings' Day on 16 April, 30 April–1 May, 2 September and 24 November 2027. For Tết 2027, civil servants are off for seven days, Thursday 4 to Wednesday 10 February. With the example budgets below, the five breaks of 2027 outside Tết cost 9,900,000₫, or 825,000₫ a month on average. But 30 April comes early: start from the 10 November payday and the first six months need 1,100,000₫ each.

Vietnam's 2027 holiday calendar (plus 24 November this year)

Holiday	Date	Days off
Vietnamese Culture Day	Tue 24 Nov 2026	Official. 1 day, the first time
New Year's Day	Fri 1 Jan 2027	Set by law. 1 day; a three-day weekend if your weekend is Saturday and Sunday
Tết (Lunar New Year)	Thu 4 – Wed 10 Feb 2027	Official. Civil servants 7 days; businesses at least 5 paid days, on one of three options the employer picks
Hùng Kings' Day (10th of the 3rd lunar month)	Fri 16 Apr 2027	Set by law. 1 day; a three-day weekend
Reunification Day and Labour Day	Fri 30 Apr – Sat 1 May 2027	Set by law. 2 holidays; with Saturdays off, 1 May's day moves to Mon 3 May, so expected 4 days, 30 Apr – 3 May
National Day	Thu 2 – Sun 5 Sep 2027	Official. Civil servants 4 days; businesses give 2 Sep plus 1 or 3 Sep, at the employer's choice
Vietnamese Culture Day	Wed 24 Nov 2027	Set by law. 1 day

Official means there is a document. In letter 10065/VPCP-KGVX of 2 October 2026, the Government Office approved seven days off for Tết and four for National Day in 2027, and one day for Vietnamese Culture Day in 2026. The dates are in the Ministry of Home Affairs' notice 11483/TB-BNV of 9 October 2026, as quoted by Hà Tĩnh's provincial portal.

Set by law means the day off is already in Article 112 of the 2019 Labour Code (1 January, Hùng Kings' Day, 30 April, 1 May) or in Resolution 28/2026/QH16 (24 November every year). A holiday that lands on your weekly day off moves to the next working day under Article 111. No document yet swaps working days or adds days around these dates, so every longer break here is expected, not official. The original page on at6pm.app will be updated when a notice comes out.

The calendar above is the civil service one. Private employers choose their Tết days and the extra National Day, and announce them ahead. Shift and service workers may work on the holiday itself. Ask HR for your schedule before you book.

What each break costs (example numbers)

These are example numbers for one person working in Vietnam, travelling alone or with costs already split with whoever comes along. Swap in your own prices; what matters is having a number for each break.

24 November 2026: a day in the city, 300,000₫

Cinema ticket 100,000₫, dinner 150,000₫, coffee 50,000₫: 300,000₫. It's three weeks away, so this one comes out of this month's money, no pot needed.

1 January 2027: three days at a nearby beach, 1,500,000₫

Line	Example
Return bus	400,000₫
Room, 1 night	600,000₫
Food	500,000₫
Total	1,500,000₫

Tết 2027: its own plan

Tết is the year's biggest line and has its own maths: tickets home, gifts, lucky money, divided by the paychecks left. The Vietnamese guide Tết 2027, thưởng và lì xì walks through it, and the holiday spending plan does the same for any big season. The rest of this page leaves Tết out.

Hùng Kings' Day, 16 April: three days back home, 1,500,000₫

Line	Example
Return bus	500,000₫
Gifts for the family	400,000₫
Food, coffee with old friends	600,000₫
Total	1,500,000₫

30 April – 3 May (four days, expected): the big trip, 3,600,000₫

Line	Example
Return ticket at peak season	1,200,000₫
Room, 3 nights × 500,000₫	1,500,000₫
Food and entry tickets	900,000₫
Total	3,600,000₫

The busiest break of the year. Book the ticket and the room early and the first two lines stop being guesses.

2 September: two or four days, 3,000,000₫

Line	Example
Return ticket	1,000,000₫
Room, 2 nights × 600,000₫	1,200,000₫
Food	800,000₫
Total	3,000,000₫

Civil servants are off Thursday 2 to Sunday 5 September. If your employer picks 2 and 3 September, you get four days too, as long as your weekend is Saturday and Sunday; if it picks 1 and 2 September, Friday is a work day and the trip gets shorter.

24 November 2027: a Wednesday, 300,000₫

One day mid-week is hard to travel on. Repeat this year's: cinema, dinner, coffee, 300,000₫.

The whole of 2027, in money

Break	Example budget
1 Jan	1,500,000₫
16 Apr	1,500,000₫
30 Apr–3 May	3,600,000₫
2 Sep	3,000,000₫
24 Nov	300,000₫
Total	9,900,000₫

Divided by 12: 825,000₫ a month. That is what "every break, every year" costs on average with the examples above.

825,000₫ is the average. 30 April sets the pace

The holidays don't wait for an even split. If you're paid on the 10th and start with the 10 November 2026 paycheck, there are only six paydays before 30 April (10 Nov, 10 Dec, 10 Jan, 10 Feb, 10 Mar, 10 Apr), and 1 January, Hùng Kings' Day and 30 April already need 6,600,000₫ between them. At 825,000₫ a month you'd have 4,950,000₫ by 30 April, 1,650,000₫ short.

Split by stretch, it works out on time:

Paydays	For	Needed	Each month
10 Nov 2026 – 10 Apr 2027 (6)	1 Jan, 16 Apr, 30 Apr	6,600,000₫	1,100,000₫
10 May – 10 Aug 2027 (4)	2 Sep	3,000,000₫	750,000₫
10 Sep – 10 Nov 2027 (3)	24 Nov	300,000₫	100,000₫
Total: 13 paydays		9,900,000₫

Check each stop: by 1 January you've put away 2,200,000₫; the beach takes 1,500,000₫, leaving 700,000₫. By Hùng Kings' Day all six paydays are in, so 5,100,000₫ is there; the trip home takes 1,500,000₫, leaving exactly 3,600,000₫ for 30 April.

The first six months are the heavy stretch, and they overlap with saving for Tết. If 1,100,000₫ a month is too tight, each fix has a number:

Shrink 30 April: a 2,400,000₫ trip instead of 3,600,000₫ makes the first stretch (1.5 + 1.5 + 2.4 million) ÷ 6 = 900,000₫ a month.
Pay for 1 January from December's money, like 24 November: the first stretch drops to (1.5 + 3.6 million) ÷ 6 = 850,000₫ a month, and December gets tighter instead.
Take fewer trips: drop one break and share its money among the rest.

Not paid on the 10th? Count your own paydays before each break; the division is the same.

Start a pot this payday

In 6pm, money set aside for something is a pot, with a goal and the month you need it. A pot takes its share before your daily number is worked out: (goal − what you already have) ÷ months left until that month, rounded up to the nearest 50,000₫. 6pm wants the money ready before the trip's month begins, so it plans a little tighter than the table above. Made before the 10 November payday:

A "Beach, 1 Jan" pot, 1,500,000₫, January 2027: 1,500,000 ÷ 2 = 750,000₫ a month.
A "30 April" pot, 3,600,000₫, April 2027: 3,600,000 ÷ 5 = 720,000₫, rounded up to 750,000₫ a month.

On a 30-day pay cycle, the 30 April pot takes 25,000₫ a day off what's safe to spend today. Seeing that 25,000₫ now is easier than putting the trip on a card in April and paying it off in May.

The free plan includes one pot of your own: enough for the biggest trip, with the small breaks coming out of your daily number. 6pm Max makes pots unlimited, one per break and one for Tết. For how the daily number is worked out, see how much can I spend per day. 6pm never moves money: the amounts in a pot are what you say you've set aside. It just counts.

For builders: the pot maths in code

The numbers above come from a few small pure functions in our open-source repo (Apache 2.0, in packages/domain/src/plan/ and money/). Money is stored as integer đồng, so there's no float drift to round away. An occasion pot spreads what's left over the months to its date, rounds up to a 50,000₫ step, and never asks for more than is left:

export function potMonthlyNeed(
  goal: Vnd,
  saved: Vnd,
  monthsLeft: number | null,
  currency: Currency = VND,
): Vnd {
  const left = Math.max(0, goal - saved);
  if (left === 0 || monthsLeft === null || monthsLeft <= 0) return 0;
  return Math.min(left, ceilToSetAside(left / monthsLeft, currency));
}

/** Ceils to fifty steps, as pot set-asides do (50.000₫ in Vietnam, $50 in the US). */
export function ceilToSetAside(amount: Money, currency: Currency): Money {
  const unit = 50 * currency.step;
  return Math.ceil(amount / unit) * unit;
}

Two choices did most of the work:

Months are counted from the pay cycle, not from today. A cycle is named after the month that holds the day before its next payday, so the cycle that ends on the 10 November payday is November's. That's why a pot made before 10 November counts January as 2 months away, and the set-aside doesn't jump around between paydays.
Round up, then cap. Rounding 720,000₫ up to 750,000₫ means the pot fills a little early instead of a little late, and the Math.min(left, ...) keeps the last month from overshooting the goal.

On the trip, just travel

A good plan doesn't make you type receipts while looking at the sea.

Restaurants and entry tickets with a VietQR code: scan it with 6pm, then pay in your bank app.
Cash at the market: say "bánh mì thirty thousand", or Quick add, three taps.
The hotel bill: take a photo and 6pm reads the amount.

Didn't open the app all trip? Nothing breaks. Missed days wait for you, and what you spent already counts. Back home, close them in one go.

FAQ

How many days off is Tết 2027 in Vietnam?

Civil servants are off seven days, Thursday 4 to Wednesday 10 February 2027 (the first day of Tết is Saturday 6 February). Private-sector workers get at least five paid Tết days; the employer picks one of three options and announces it ahead.

How many days off are 30 April and 1 May 2027?

By law, two holidays: Friday 30 April and Saturday 1 May. If Saturday is your day off, 1 May's day moves to Monday 3 May, so the expected break is four days, 30 April to 3 May. No notice covers this break yet.

How many days off is National Day 2027?

Civil servants are off four days, Thursday 2 to Sunday 5 September 2027. Businesses give two: 2 September plus 1 or 3 September, at the employer's choice.

Is 24 November a public holiday every year?

Yes. Resolution 28/2026/QH16 makes 24 November Vietnamese Culture Day every year, a paid day off. The first is Tuesday 24 November 2026; in 2027 it falls on a Wednesday.

Can I make a trip pot on 6pm's free plan?

Yes. Free includes one pot of your own; 6pm Max makes them unlimited.

Try 6pm

6pm is on the App Store for iPhone, and the code is on GitHub. More at at6pm.app.

If you've built savings goals or sinking funds into an app: did you round the monthly amount up, down, or to the nearest step, and did your users notice?

Sky shaders at 120fps in React Native with Skia

Odd Eggs Studio — Wed, 04 Nov 2026 14:00:00 +0000

6pm's sky is one React Native Skia canvas drawn behind the Today screen: a time-of-day gradient, drifting blooms, sun, halftone, grain, rain and three "living scenes". It stays cheap by baking anything expensive once (blurs, noise, rain), keeping per-frame work to gradients and textures, and stepping slow motion at 30 Hz while scrolling still moves every frame.

The code is in apps/mobile/src/ui/sky in the 6pm repo. Versions: @shopify/react-native-skia 2.13.1, react-native-reanimated 4.7.0, Expo 58, React Native 0.88.

Where it started: a sky made of CSS

6pm's design is an HTML prototype. Its sky is a stack of absolutely positioned divs: a three-stop linear gradient, three radial "blooms" softened with filter: blur(), a sun with rings and a flare, an SVG feTurbulence grain tile with mix-blend-mode: overlay, a halftone made of a tiled radial-gradient, light leaks, a vignette, and per-theme extras. Every colour is computed for the minute of the day, and changes ease over one second.

CSS layer stacks don't port to views. Stacking a dozen full-screen blurred, blended views would melt the GPU and still not blend the way the browser does. Our technical decisions doc puts it in one line:

Sky and atmosphere: @shopify/react-native-skia: gradients, blurred blooms, grain/halftone/rain as runtime shaders. 60/120 fps full-screen effects; CSS layer stacks do not port to views.

The shipped code is more conservative than "everything is a shader". Here is what actually runs.

Colours: run the prototype's own logic

Before drawing anything, the colours have to match. Instead of re-implementing the prototype's palette maths, tools/design/extract-prototype-logic.ts extracts the prototype's look functions into a generated module, and @6pm/theme runs them with the chosen look injected as state:

// packages/theme/src/look-engine.ts
/** The colour tokens of one frame. */
export function paletteFor(input: FrameInput): Palette {
  return select(input.look, input.config).palette(input.hour, input.serious, input.look);
}

The design's oklch tints are converted to sRGB hex in code, which renders identically to the browser references. Same function, same numbers, no "close enough".

One canvas, one array of numbers

Sky (sky.tsx) is a single <Canvas> with layers in prototype order:

<Canvas style={StyleSheet.absoluteFill}>
  <Group transform={shrink}>
    <SkyGradient frame={frame} width={width} height={height} />
    <LivingBackdrop {...scene} />
    <AtmBoxes raw={current.atm.back} {...boxes} />
    {shown.blooms && <SkyBlooms {...props} />}
    {/* sun, flare, moon, bokeh, halftone, leak, weather, scenes, vignette */}
    {shown.grain && <SkyGrain {...props} />}
    <WeatherTop {...scene} />
  </Group>
</Canvas>

The interesting part is frame. Everything on the sky that changes with the hour (gradient stops, bloom colours, sun opacity, halftone ink, grain strength) is packed into one flat number[], with colours taking four slots (sky-slots.ts). A new hour is then a single UI-thread tween of that array, the equivalent of CSS's transition: 1s:

// apps/mobile/src/ui/sky/use-switched-tween.ts (trimmed)
useAnimatedReaction(
  () => (flag.value ? onValues.value : offValues.value),
  (target, previous) => {
    if (previous === null) {
      shared.value = target;
      return;
    }
    shared.value = reduced.value ? target : withTiming(target, TRANSITION);
  },
);

Two prepared states (sun shown on Today, hidden on other tabs) live on the UI thread, so a tab switch tweens the sky without a single React render. Each layer reads its slots with useDerivedValue, and Skia picks up shared values directly as props.

Layers whose strength is zero for the current look and hour are unmounted (useShown keeps one for an extra second so it can fade out), so a frame only pays for what is visible.

Blooms: bake the blur into the gradient

The prototype's blooms are radial gradients blurred with filter: blur(). A live Gaussian blur on three full-screen layers every frame is exactly what we wanted to avoid.

The observation that makes it free: blurring a radially symmetric shape keeps it radially symmetric. So the blurred result is itself a radial gradient, and we can compute its alpha profile once, ahead of time:

// apps/mobile/src/ui/sky/blur-profile.ts (trimmed)
// In polar form the 2-D Gaussian blur of a radial f is the Hankel-type integral
// g(r) = ∫ f(ρ)·(ρ/σ²)·exp(−(r−ρ)²/2σ²)·[e^(−x)·I₀(x)] dρ with x = rρ/σ² (Simpson's rule).
const blurredAt = (r: number) => {
  let sum = 0;
  for (let i = 0; i <= STEPS; i++) {
    const rho = i * h;
    const weight = i === 0 || i === STEPS ? 1 : i % 2 === 1 ? 4 : 2;
    const kernel =
      (rho / s2) * Math.exp(-((r - rho) ** 2) / (2 * s2)) * scaledBesselI0((r * rho) / s2);
    sum += weight * alpha(rho) * kernel;
  }
  return (sum * h) / 3;
};

scaledBesselI0 is the exponentially scaled modified Bessel function, from the Abramowitz and Stegun polynomial approximations, so it doesn't overflow for large arguments. The profile is sampled as 32 stops out to support + 3.5σ and memoised per look. At draw time a bloom is a plain <RadialGradient> whose colours come from the frame array and whose position drifts with the clock. All three blooms composite in one full-screen pass, then blend onto the sky (screen after dark, multiply by day) like the prototype's bloom container. It has unit tests (blur-profile.test.ts).

The base gradient itself is drawn with dither, because a night sky spans only a dozen 8-bit steps over the whole screen and bands without it.

Halftone: a real runtime shader

The halftone band is a tiled radial-gradient(circle, dot 0.9px, transparent 1.5px) under a linear mask. This is a natural fit for a runtime effect, written in SkSL:

// apps/mobile/src/ui/sky/sky-halftone.tsx
const HALFTONE = Skia.RuntimeEffect.Make(`
uniform float4 ink;
uniform float cell;
uniform float height;

half4 main(float2 p) {
  float2 q = mod(p, cell) - 0.5 * cell;
  float coverage = clamp((1.5 - length(q)) / 0.6, 0.0, 1.0);
  float y = p.y / height;
  float mask = y < 0.45 ? y / 0.45 : (y < 0.6 ? 1.0 : (1.0 - y) / 0.4);
  float a = ink.a * coverage * clamp(mask, 0.0, 1.0);
  return half4(ink.rgb * a, a);
}
`);

The ink uniform comes straight from the frame array through useDerivedValue, so the dots change colour with the hour on the UI thread. Note the premultiplied return: Skia expects premultiplied colour from a shader.

The other runtime effects live in scenes/boxes/box-fill.tsx: one repeats a child shader on a grid (CSS background-repeat), and one applies an SVG feColorMatrix to noise in straight (unpremultiplied) colour, which is how two looks get their speckle and brush textures.

Grain: same noise as the browser, drawn once

The prototype's grain is an SVG feTurbulence tile. Skia's FractalNoise is the same algorithm, so with the same frequency, octaves, seed and stitch size it produces the same grain. The subtle part is stitching: SVG's filter region overhangs the 180 pt tile by 10% on each side, so the stitch size is 216, not 180. And feTurbulence runs in linearRGB, hence LinearToSRGBGamma:

// apps/mobile/src/ui/sky/sky-grain.tsx (trimmed)
const TILE = 180;
const STITCH = 216;

useTexture(
  <Group transform={[{ scale }]}>
    <Rect x={0} y={0} width={TILE} height={TILE}>
      <FractalNoise freqX={0.85} freqY={0.85} octaves={2} seed={0}
                    tileWidth={STITCH} tileHeight={STITCH} />
      <LinearToSRGBGamma />
    </Rect>
  </Group>,
  { width: Math.round(TILE * scale), height: Math.round(TILE * scale) },
  [scale],
);

So grain is not computed per frame at all: the tile is rendered once at the screen's pixel density and repeated with an ImageShader. The prototype's stepped grain animation jumps between three offsets every 0.8 s, and the canvas only redraws when the step changes:

// Only a new step moves the grain: the canvas stays idle between steps when nothing else moves.
useAnimatedReaction(
  () => grainStep(time.value),
  (step, previous) => {
    if (step !== previous) stepAt.value = time.value;
  },
);

Rain: bake the strokes, slide the texture

Rain in the prototype is a tilted, oversized layer with an SVG stroke tile, one sharp and fast, one bigger, blurred and slower. Stroking and blurring a screenful of lines every frame on the CPU is not an option. So each layer's tile is painted once into an offscreen Skia.Surface, blur included, and drawn as a repeating image:

// apps/mobile/src/ui/sky/scenes/weather/rain-bake.ts (trimmed)
const surface = Skia.Surface.Make(pixels[0], pixels[1]);
const canvas = surface.getCanvas();
for (const group of strokeGroups(tile)) {
  const path = Skia.Path.Make();
  for (let dy = -1; dy <= 1; dy++) {
    for (let dx = -1; dx <= 1; dx++) {
      for (const s of group.strokes) {
        path.moveTo(dx * tile.width + s.x, dy * tile.height + s.y);
        path.lineTo(dx * tile.width + s.x, dy * tile.height + s.y + s.length);
      }
    }
  }
  // ... stroke paint, plus a blur mask filter for the soft layer
  canvas.drawPath(path, paint);
}
surface.flush();
const baked = { image: surface.makeImageSnapshot(), pixels };

The 3×3 loop paints each stroke in the neighbouring cells too, so strokes and blur that cross an edge wrap around and the tile repeats without a seam. Baked tiles are cached by tile, size, blur and scale. Per frame, the only work is a transform: the layer is rotated about the screen centre and its offset slides down, looping.

The living scenes

Three premium looks have scenes that respond to the phone itself:

Long Exposure adds a warm radial band across the horizon on top of its sky gradient, and its star trails are rings masked by conic gradients whose arc grows with an "exposure" value (calc(var(--exp, 1) * 18.3deg + 0.4deg) in the prototype's CSS, parsed into k × exp + c in box-css.ts and evaluated in a worklet).
Paper Diorama is layers of cut-paper hills. Each layer casts a drop shadow from the union of its pieces (PathOp), so overlapping hills shade once, and the shadow shifts with tilt.
Lantern River hangs two catenary wires of 25 bulbs each, with five silk lanterns swinging from each wire, over a river cut into 2 pt lines that ripple.

The motion comes from useAnimatedSensor(SensorType.GRAVITY). A small worklet converts gravity into the browser's deviceorientation angles the prototype was written against, eases the tilt in, tracks stillness, and drives a damped pendulum:

// apps/mobile/src/ui/sky/scenes/boxes/scene-motion.tsx (trimmed)
const gamma = (Math.asin(Math.max(-1, Math.min(1, g.x / n))) * 180) / Math.PI;
const beta = (Math.atan2(-g.y, -g.z) * 180) / Math.PI;
const tx = clamp1(gamma / 28);
const ty = clamp1((beta - 45) / 28);
s.cx += (tx - s.cx) * 0.09;
// stillness builds while the phone is held still and any movement spends it
motion.exp.value += (0.12 + 0.88 * s.still - motion.exp.value) * 0.12;
s.pendV += (-s.cx * 22 - motion.pend.value) * 0.016;
s.pendV *= 0.965;
motion.pend.value += s.pendV;

Hold the phone still and the long exposure "develops"; tilt it and the lanterns swing. The driver is only mounted for a premium look with its "sense" switch on, outside serious mode and outside previews.

About that 120

The honest version of the title: the canvas can redraw at the display's full rate, and does when you scroll (the sun, flare, halftone and bokeh move with the list at their own parallax rates, every frame). But the slow motion does not need 120 updates a second, so the sky's clock deliberately steps:

// apps/mobile/src/ui/sky/sky.tsx
/** The sky's slow drifts step 30 times a second; falling rain needs 60 to read as a fall. */
const DRIFT_STEP_MS = 1000 / 30;
const RAIN_STEP_MS = 1000 / 60;

useSkyClock accumulates frame time on the UI thread and only advances when a step is due, so every layer driven by time is recomputed and redrawn only on a step. Drifts, pulses and twinkles look the same at 30 steps a second, and when nothing is scrolling most display frames draw nothing new.

The clock is also gated. useGatedFrameCallback really stops the frame callback (setActive(false)) when the screen isn't showing: another tab, a full-screen takeover, or the app in the background. Nothing wakes the UI thread for a sky nobody can see. Under Reduce Motion the clock stays at zero, which freezes every drift, twinkle and grain step on its first frame.

FAQ

Can React Native Skia run custom shaders?

Yes. Skia.RuntimeEffect.Make compiles SkSL, and a <Shader> with uniforms from a Reanimated useDerivedValue updates on the UI thread without React renders.

How do you get a cheap Gaussian blur in Skia on mobile?

Avoid a live blur where you can. For a radially symmetric shape, compute the blurred radial profile once and draw it as gradient stops; for textures like rain, paint the blur into an offscreen surface once and repeat the image.

Does an animated background drain the battery?

It costs more than a static one, so 6pm steps slow motion at 30 Hz, stops the frame callback whenever the sky isn't visible, and freezes it under Reduce Motion. We have not published battery measurements.

Try it

The sky is open source under Apache 2.0: github.com/at6pm/6pm (start at apps/mobile/src/ui/sky/sky.tsx). Watch it shift through the day in 6pm: on iPhone (App Store) and Android (beta) · at6pm.app.

Why we open-sourced our money app

Odd Eggs Studio — Sun, 01 Nov 2026 14:00:00 +0000

A privacy policy is a claim; code is evidence. 6pm, an iPhone expense tracker, is open source under Apache 2.0 so anyone can check what it keeps on the phone (an SQLCipher database whose key never leaves the Keychain), what reaches our server (hashes, sealed receipts, ciphertext), and what goes to third parties.

This post is a guided tour of the parts of github.com/at6pm/6pm that back the privacy policy, including the parts that are not private. If you only read one section, read "What does leave the phone".

The argument for opening it

Money apps ask for a lot of trust. Most ask you to trust a policy page. Ours makes specific promises: no bank login, no account for the core app, records encrypted on the phone, a server that cannot read your backup. Those are statements about code. Opening the code turns them into things you can check.

The website says it plainly: "The app, the money maths and the privacy promises are all open source." The repository holds the iPhone app (apps/mobile), the API (apps/api, Hono on Cloudflare Workers with D1 and R2), the website (apps/web), the money rules (packages/domain), the looks (packages/theme) and the English and Vietnamese copy (packages/i18n). The licence file is the Apache License, Version 2.0.

Open source also helps with a duller problem: correctness. The daily number, the pay cycle, the close, the VietQR and receipt parsers all live in packages/domain, a pure TypeScript package with unit tests. If our maths is wrong, you can show us the line.

What stays on the phone

An encrypted database with a key that never leaves

The app's store is expo-sqlite with SQLCipher turned on in app.config.ts (['expo-sqlite', { useSQLCipher: true }]). The key is made on first launch:

// apps/mobile/src/db/database-key.ts
const OPTIONS: SecureStore.SecureStoreOptions = {
  keychainAccessible: SecureStore.AFTER_FIRST_UNLOCK_THIS_DEVICE_ONLY,
};

export async function ensureDatabaseKey(databaseName: string): Promise<void> {
  if (await SecureStore.getItemAsync(KEY_NAME, OPTIONS)) return;
  await clearUnreadableDatabase(databaseName);
  const key = Array.from(getRandomBytes(32), (b) => b.toString(16).padStart(2, '0')).join('');
  await SecureStore.setItemAsync(KEY_NAME, key, OPTIONS);
}

and applied as the first statement on the connection:

// apps/mobile/src/db/database.ts
await db.execAsync(`PRAGMA key = "x'${key}'"`);
await db.execAsync('PRAGMA journal_mode = WAL; PRAGMA foreign_keys = ON;');

THIS_DEVICE_ONLY has a consequence the code is honest about. An iCloud or Quick Start restore brings the database file to a new phone without its key, so it can never be opened there. When a key has to be made and a database file already exists, the file is moved aside to a dated name rather than deleted, and the user's days come back through 6pm's own encrypted backup. A Keychain read that fails, as opposed to finding nothing, throws, so a locked Keychain never costs anyone their data.

Extensions never open the database

iOS kills a suspended extension that holds a file lock in a shared container, and SQLite in WAL mode holds one. So the share extension, widgets and App Intents never open the store. Each capture is written as one JSON file into the App Group's inbox/ folder, which the app imports and deletes. Widgets read files the app writes to surfaces/. This is in docs/tech-decisions.md under "Extensions and the store".

The maths runs locally

Ask 6pm ("Can I afford $350 on Saturday?") is the clearest example. The phone computes every number from its own records; a model on the server only turns the question into an intent and an amount, and words the answer. Your balances are never sent.

What our server sees

A hashed device token, not an account

The core app has no account. On first contact the phone gets a random token:

// apps/api/src/device-auth.ts
export async function hashDeviceToken(token: string): Promise<string> {
  const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(token));
  return Array.from(new Uint8Array(digest), (b) => b.toString(16).padStart(2, '0')).join('');
}
/** The database only ever sees this. */

D1 stores the hash, the app language and first and last seen times. last_seen_at is rewritten at most once an hour, because it exists for rough daily counts. Rate limiting keys on the IP address through Cloudflare's rate-limit binding; the comment, and the policy, say the address is a counter key and is never stored.

Receipt email: read in memory, sealed until fetched

Each phone gets an address like k7m2qx@at6pm.app. Cloudflare Email Routing's catch-all hands mail to the Worker. apps/api/src/receipt-email/receive.ts describes the contract:

Mail to an unknown handle, or over 1 MB, is refused.
An email that prints no amount is dropped unread and never sent to a model.
Otherwise it is read in memory, by an Anthropic model when one answers and by rules when it does not. Only what was read (amount, currency, merchant, category, time, sender, memo) is kept. The email itself is never stored or logged.
Anything that is not a receipt is dropped without a bounce, so a forwarding filter is not disabled by one promo.

What is kept is sealed:

// apps/api/src/receipt-email/seal.ts (doc comment)
// Receipts wait in D1 sealed with AES-256-GCM. The key is derived with HKDF-SHA-256 from the
// EMAIL_SEAL_KEY Worker secret, with the device's token hash as the context, so a copy of the
// database alone opens nothing and one device's key opens no other device's receipts. The
// capture's id is the associated data: a sealed row cannot be passed off under another id.

When the phone has saved its receipts it acknowledges them and the rows are deleted (DELETE FROM email_captures WHERE device_hash = ? AND id IN (…)). Anything unfetched for 30 days is deleted unread.

To be precise about the threat model: the Worker holds the secret and reads the email in memory, so this protects against a leaked database, not against the server operator. We say so because it is true.

Voice: a token, not the audio

// apps/api/src/routes/voice-token.ts (doc comment)
// Mints a short-lived key to the realtime transcriber for one spend said aloud. The phone then
// streams its microphone to the vendor directly: no audio and no words pass through this server.

The server records that a transcription happened, against the device hash, for cost. It never sees the sound or the words.

Backup: ciphertext under a name only the key can produce

Backup (a 6pm Max feature, off by default) seals a snapshot on the phone with AES-256-GCM using a 32-byte key kept in iCloud Keychain. The server files it under a token derived from that key:

// apps/mobile/src/features/backup/backup-seal.ts
export async function backupTokenOf(crypto: BackupCrypto, key: Uint8Array): Promise<string> {
  const label = utf8Encode('6pm.backup.token.v1');
  const input = new Uint8Array(label.length + key.length);
  input.set(label);
  input.set(key, label.length);
  return toBase64Url(await crypto.sha256(input));
}

The API then stores only the hash of that token as the R2 object key (backups/<hash>), and the backup route "checks the envelope's shape and size and nothing else: it cannot open it." No device id is involved, so the server cannot link a backup to a phone. If someone loses both the key and the phone, nobody can open the backup, including us.

One honest caveat from the code itself: the comment on the Keychain store says whether a key written on one iPhone arrives on another "can only be seen on two real devices signed in to one Apple ID". It is the kind of thing open code lets you see, and test.

Merchant names without numbers

When a shared bank receipt has a payee the phone cannot name, the phone sends the receipt's lines to /v1/name-merchant with every number removed. The route turns away a body holding a digit before any model is called, so amounts, account numbers and reference codes cannot reach it even by mistake.

What does leave the phone

This is the section most privacy pages skip. In plain terms, from apps/web/src/legal/privacy.en.md:

Anthropic reads Ask questions (with your category and pot names), the few facts a companion line is about, number-free receipt lines, a receipt photo the phone could not read with confidence, forwarded receipt emails, and category names for icon suggestions. The policy states Anthropic does not train on them and deletes them within 30 days, with stated exceptions. We keep token counts in a cost ledger, not the content.
Deepgram or ElevenLabs hears your voice while you hold the microphone. Free users get 10 cloud transcriptions a day; after that, offline, or in on-device mode, Apple's on-device speech is used and nothing is sent.
RevenueCat knows what you bought, under an anonymous app user ID, plus the device details purchase SDKs usually receive, including IP address.
Sentry gets crash reports with sendDefaultPii: false and no money, names or notes attached. In on-device mode the reporter is closed, including the native one, so a crash is not sent at the next launch.
Cloudflare runs the site and API and may keep ordinary request logs.
Expo answers update checks, which carry the app version, platform and IP address.
Apple handles payments, iCloud Keychain and Sign in with Apple, which is used only for Budget together (shared pots for two).

On-device mode

Settings → AI can keep 6pm's AI on the iPhone: questions are read, companion lines written and receipts read with a model downloaded once from Hugging Face. In that mode receipt email is off (it needs the server), crash reports are off, and voice uses Apple's on-device recogniser.

What open source does not prove

It proves what the code in the repository does. It does not, by itself, prove that the binary in the App Store was built from that commit, or what a vendor does once data reaches it. We would rather say that than overstate it. What it does give you is the ability to read every route the app calls, every field the server stores, and every place a model is involved, and to hold us to the policy line by line.

FAQ

What licence is 6pm under?

Apache License 2.0, as in the LICENSE file at the root of the repository.

Can 6pm read my spending?

The records live in an SQLCipher database on your iPhone, with a key made on the phone and kept in its Keychain. We never receive the key or the database. We never store your transactions; they live on your iPhone, encrypted. No bank login.

Does open source mean I can self-host the API?

The API is in the repo (Hono on Cloudflare Workers, D1, R2) and server secrets are listed by name in .env.example. The shipping app talks to at6pm.app.

Can I contribute?

Read CLAUDE.md first; it is the working contract for anyone, human or agent, changing the code. Questions and bug reports go to hello@at6pm.app.

Try it

Read the code at github.com/at6pm/6pm. The iPhone app is in public beta on TestFlight: testflight.apple.com/join/a8UrvT5P, and on the App Store from 6 November 2026, 18:00 ICT. More at at6pm.app.

One camera for QR codes and receipts with Apple Vision

Odd Eggs Studio — Wed, 28 Oct 2026 14:00:00 +0000

6pm's Scan runs one AVCaptureSession with three outputs: the system metadata reader for QR codes, a video feed that Vision searches for paper ten times a second, and a photo output. A receipt held still for 0.9 s is taken, squared up with CIPerspectiveCorrection, and read on the phone. Only an unsure reading sends the photo, once.

The code is in apps/mobile/modules/scan-camera (a local Expo module, Swift and Kotlin) and packages/domain/src/capture (the receipt parser, TypeScript). The repo is Apache 2.0.

The product constraint

Scan has one job per moment: at a counter you want the QR read instantly; at home with a crumpled receipt you want it found, cut out and read. Two modes with a switch would be simpler to build. It would also mean a choice at the till. So there is one camera, and it looks for both at once.

One session, three outputs

// apps/mobile/modules/scan-camera/ios/ScanCameraSession.swift (trimmed)
/// One capture session that finds QR codes (the system's metadata reader, as fast as the
/// Camera app's) and the receipt in view (Vision's document segmentation, ten times a
/// second), and takes the full-resolution photo a receipt is read from.
final class ScanCameraSession: NSObject, @unchecked Sendable {
  let session = AVCaptureSession()
  private let photoOutput = AVCapturePhotoOutput()
  private let videoOutput = AVCaptureVideoDataOutput()
  private let metadataOutput = AVCaptureMetadataOutput()
  static let receiptInterval: CFTimeInterval = 0.1
  static let missesReported = 4
  static let minimumArea = 0.06
}

QR codes come from AVCaptureMetadataOutput with metadataObjectTypes = [.qr], delivered on the main queue. It is the same reader the Camera app uses, and it is faster than running a Vision barcode request per frame. The same code is ignored for a second after it fires, so holding the phone over a code does not spam the parser.

Receipts come from the video output, kCVPixelFormatType_420YpCbCr8BiPlanarFullRange, with alwaysDiscardsLateVideoFrames = true. The delegate throttles itself to one look every 100 ms: "often enough for the outline to follow the paper, rare enough to leave the phone cool", as the comment puts it.

The photo comes from AVCapturePhotoOutput at .balanced quality, taken only when a receipt is captured.

Session work runs on one serial queue, frames on another, and the one flag both read (whether to look for receipts at all) sits behind an NSLock.

Picking the lens

A receipt is held close. The session asks for the virtual multi-camera device first, so iOS can switch to the macro-capable lens as the Camera app does, and starts it at its 1x lens rather than its widest:

let types: [AVCaptureDevice.DeviceType] =
  position == .back
  ? [.builtInTripleCamera, .builtInDualWideCamera, .builtInWideAngleCamera]
  : [.builtInWideAngleCamera]
// …
if let wide = device.virtualDeviceSwitchOverVideoZoomFactors.first {
  device.videoZoomFactor = CGFloat(truncating: wide)
}

Finding the paper

Vision has two tools for this, and we use both:

// apps/mobile/modules/scan-camera/ios/ReceiptPhoto.swift (trimmed)
/// Its document segmentation first, and where that finds nothing (it needs the Neural
/// Engine, and misses paper on a busy table) the plainest rectangle in view.
static func paper(_ handler: VNImageRequestHandler, minimumArea: Double) -> Corners? {
  let segmentation = VNDetectDocumentSegmentationRequest()
  let rectangles = VNDetectRectanglesRequest()
  // A receipt is long and narrow, and photographed at an angle.
  rectangles.minimumAspectRatio = 0.15
  rectangles.maximumAspectRatio = 1
  rectangles.quadratureTolerance = 30
  rectangles.minimumSize = 0.2
  rectangles.minimumConfidence = 0.7
  rectangles.maximumObservations = 1
  if (try? handler.perform([segmentation])) != nil,
    let found = segmentation.results?.first, found.confidence >= minimumConfidence
  {
    let corners = Corners(found)
    if corners.area >= minimumArea { return corners }
  }
  guard (try? handler.perform([rectangles])) != nil, let found = rectangles.results?.first
  else { return nil }
  let corners = Corners(found)
  return corners.area >= minimumArea ? corners : nil
}

VNDetectDocumentSegmentationRequest is the better detector for paper, but it misses on cluttered tables. The rectangle detector is tuned for receipts: aspect ratios down to 0.15 (long and thin) and 30 degrees of tolerance for a phone held at an angle. Anything covering less than a few percent of the frame is a label or a card, not the receipt; the shoelace formula on the quad gives the area.

Vision's origin is bottom left; React Native's is top left. Corners flips once, at the boundary, and everything downstream uses [x0, y0, …, x3, y3] from the top left, clockwise.

Losing it gracefully

Detectors flicker. A frame where the outline vanishes is usually the detector, not the hand. The session keeps reporting "gone" for four looks after a loss, then goes quiet, and the TypeScript side lets two stray sightings pass before it believes the receipt moved:

// apps/mobile/src/features/scan/receipt-outline.ts
export const STEADY_SHARE = 0.08; // a corner may wander 8% of the shortest side
export const STEADY_POINTS = 10;  // …and never less than 10 points
export const MAX_STRAYS = 2;      // one or two misses are the detector, not the hand
export const STEADY_MS = 900;     // held still this long: take the photo
export const MIN_SHARE = 0.12;    // smaller than this on screen: outlined, not taken

The tolerance scales with the receipt's shortest side on screen, so a receipt held close may shake as much as one held far. Stillness is measured from where the receipt settled, not from the last sighting, so a slow drift still resets the timer. After 0.9 s still, Scan takes the photo itself. There is also a shutter.

Mapping corners onto the preview has one trap: the preview is aspect-fill, so the frame is scaled to cover the view and cropped. quadOnView applies the same scale and centring offset, so the drawn outline sits on the paper rather than near it.

Cutting it out and reading it

The full-resolution photo goes through four steps in ReceiptPhoto.read:

Upright and bounded. CGImageSourceCreateThumbnailAtIndex with the transform applied, at most 3,000 px on the long side, which keeps the small print on a long receipt.
Find the paper again in the photo. If that fails, use where the live view last saw it.
Square it up with Core Image:

let output = CIImage(cgImage: image).applyingFilter(
  "CIPerspectiveCorrection",
  parameters: [
    "inputTopLeft": vector(corners.topLeft),
    "inputTopRight": vector(corners.topRight),
    "inputBottomRight": vector(corners.bottomRight),
    "inputBottomLeft": vector(corners.bottomLeft),
  ])

Read it at 2,000 px with VNRecognizeTextRequest at .accurate:

if let vietnamese = supported.first(where: { $0.lowercased().hasPrefix("vi") }) {
  request.recognitionLanguages = [vietnamese, "en-US"]
  request.usesLanguageCorrection = true
} else {
  request.recognitionLanguages = ["en-US"]
  request.usesLanguageCorrection = false
}

The second branch matters for Vietnamese receipts on a phone whose Vision lacks Vietnamese: with English language correction on, Vietnamese words get "corrected" into English ones. Off, the raw glyphs survive, and the parser matches labels with accents folded away anyway.

A picture chosen from Photos goes through the same path, after a VNDetectBarcodesRequest decides whether it is a QR screenshot instead.

The parser: lines in, a total out

Vision returns lines with boxes and confidence. packages/domain/src/capture/shop-receipt.ts turns them into a ShopReceipt: total, currency, merchant, time, plus two flags, totalSure and currencySure.

Totals are found by label, ranked. The labels are folded (no accents, lower case) in Vietnamese, English and Indonesian:

// packages/domain/src/capture/shop-labels.ts (excerpt)
export const TOTAL_RANK = { final: 3, total: 2, running: 1 };
const LABELS = {
  final:
    'tong con lai, con phai thu, con lai, khach phai tra, khach can tra, can thanh toan, ' +
    'phai thanh toan, tien phai tra, tong thanh toan, total amount, grand total, amount due, …',
  total: 'tong cong, tong tien, tong, thanh toan, total, jumlah',
  running: 'thanh tien',
  // …
};

totalSure means a total label was read and nothing on the receipt argues with it: no second total of the same rank with a different amount, no card charge or subtotal that disagrees. currencySure means the receipt printed its currency or is plainly Vietnamese.

When the phone is not sure

The card that shows the reading decides whether to ask for help:

// packages/domain/src/native/share-card.ts
needsCheck: read === null || (read.kind === 'shop' && !(read.totalSure && read.currencySure)),

Only then, and only if the user has not chosen to keep AI on the phone, the app sends one JPEG (long side 1,600 px, at most 1.5 MB, quality stepped down from 0.7 until it fits) to POST /api/v1/receipts/read. The server asks an Anthropic vision model for the total as printed, the currency, the shop and the time; code, not the model, converts the printed total into an amount. The server does not store or log the photo. Offline, or when the server has no answer, the phone keeps its own reading.

When the closer look returns, lookedReceiptCard merges it over the phone's reading. Fields the phone read surely stay as they were; the server fills what the phone was unsure of.

The share extension (sharing a bank's "transfer successful" screenshot into 6pm) reads with the same parser and the same rules; the Scan path was written to read a receipt "exactly as one shared to 6pm".

The Android port

Android is not released yet, but the camera module has a Kotlin side in modules/scan-camera/android, kept to "the same steps and limits as the iPhone's reader".

Camera: CameraX, with an ImageAnalysis use case on STRATEGY_KEEP_ONLY_LATEST and YUV_420_888 frames.
QR: ML Kit barcode-scanning restricted to FORMAT_QR_CODE, run on every analysed frame, with the same one-second repeat guard.
Text: ML Kit text-recognition with the Latin recogniser, whose languages include Vietnamese. Its boxes are converted to Vision's bottom-left convention so the TypeScript parser does not care which phone it runs on.
Paper: this was the real work. Android has no rectangle detector of its own, and ML Kit's document scanner is a full-screen flow, not a frame-by-frame detector. So PaperFinder.kt is a plain one, about 400 lines:

// apps/mobile/modules/scan-camera/android/.../PaperFinder.kt (doc comment)
// The paper is the largest bright patch that stands out from what is around it and is shaped
// like a four-cornered sheet: the picture cut at a few brightness levels, the largest bright
// regions of each cut, their convex hulls and the largest quadrilateral that fits in each,
// then checks that the region really is that quadrilateral and stands out from its surroundings.

It works on a grey grid: the Y plane sampled down to 160 px on the long side for the live view (four samples per cell), 400 px for the photo. One threshold rarely fits, since paper on a pale table needs a higher cut than paper on a dark one, so it tries Otsu's threshold and four levels between it and the 98th percentile, and keeps the largest sheet. Checks reject blobs (solidity below 0.8), shapes with more than four corners, regions filling over 92% of the frame (that is the table), corners more than 40 degrees off square, and paper less than 35 grey levels brighter than its surroundings.

Straightening uses Matrix.setPolyToPoly with four points and a filtered Canvas.drawBitmap, the Android equivalent of CIPerspectiveCorrection.

Lessons

Use the platform's fast path for the easy thing. The metadata reader handles QR better than per-frame Vision.
Two detectors beat one tuned detector. Segmentation for clean cases, rectangles for cluttered ones.
Make "unsure" a first-class output. The parser's totalSure and currencySure flags are what keep most receipts on the phone.
Normalise coordinates once, at the boundary. Both platforms hand TypeScript the same corner order and origin.

FAQ

Does every receipt photo go to a server?

No. Every receipt is read on the phone first. A photo is sent once only when the phone is not sure of the total or the currency, and never in on-device AI mode.

Why not use VisionKit's document camera?

Scan needs QR codes and receipts in one live view, with its own outline and auto-capture. The building blocks (AVFoundation plus Vision requests) allow that; a full-screen system flow does not.

Is the Android version released?

No. 6pm launches on iPhone. The Android camera module is in the repo and builds in CI.

Try it

The code is at github.com/at6pm/6pm: apps/mobile/modules/scan-camera and packages/domain/src/capture. The iPhone app is in public beta on TestFlight: testflight.apple.com/join/a8UrvT5P, and on the App Store from 6 November 2026, 18:00 ICT. More at at6pm.app.

11.11 in Vietnam: 3 QR payment scams, and what they changed in our QR-reading app

Odd Eggs Studio — Mon, 26 Oct 2026 13:30:00 +0000

We're a small studio in Saigon building 6pm, an iPhone expense tracker that reads the VietQR code at the counter to log a spend. Because the app touches QR payments, we spent a while reading what Vietnam's police and banks say about QR scams, and the 11.11 sales are when these peak. This is the user-side write-up; the notes for builders are at the end. Originally published on at6pm.app.

In Vietnam almost everything is paid by scanning a QR code, and the 11.11 sales are when people scan fastest. Three scams come up again and again: a fake QR sticker over a shop's real code, a "wrong transfer, please scan this to send it back" message, and a fake courier asking for an extra fee by QR. Police and banks have warned about all three. One habit protects you from each of them: after you scan, read the payee's name in your banking app before you confirm.

Why sale season is QR scam season

On 11.11 you scan more than usual: delivery fees, deposits, the coffee on the way to pick up a parcel. You are also in a hurry, because a flash sale lasts minutes. That is exactly what a scammer needs: lots of transactions and little time to look.

Vietnamese police call this family of scams Quishing, from "QR code" and "phishing". Hanoi police have warned that it is spreading, and their list of 25 scam scripts for 2026 names malicious QR codes and fake transfer receipts (both sources in Vietnamese).

Scam 1: a fake QR code stuck over the shop's own

The scammer prints a new QR code that points to their own account and sticks it over the payment code at a restaurant, a café or a bus station. You scan, and the money lands in a stranger's account. The shop gets nothing, and you find out when the owner asks whether you've paid yet.

Hanoi police describe exactly this: codes pasted over or swapped at restaurants and bus stations to take the money when people pay. The Vietnam Banks Association summarised warnings from Vietcombank, ABBank, KienlongBank and VRB that list fake QR codes stuck over real ones in restaurants, stations and payment points.

Signs: a code stuck on top of another, peeling edges, a brand-new sticker on an old counter, or two codes side by side.

What to do: ask the seller "is this your code?" before you scan. After scanning, the payee name in your banking app should match the shop or its owner.

Scam 2: "I sent it by mistake, scan this to send it back"

Money you weren't expecting arrives in your account. Minutes later, a message or a call: "I transferred it to you by mistake, please send it back", with a QR code or a different account number. Sometimes the caller claims to be from the bank, offering to "help you get the money back".

Phú Thọ provincial police describe two versions. In the first, scammers send a small "bait" amount, then pose as the mistaken sender or a debt collector and pressure you to transfer money to an account they choose. In the second, they pose as bank staff and ask you to scan a QR code in your banking app "to verify". According to the warning, once the victim scans, the code carries out a transfer of the whole balance.

The safe way to handle it, per the same police advice:

Money arrives that isn't yours: don't withdraw it or send it anywhere. Tell your bank, and return it only through the bank's official channel or with the authorities as witness.
You sent money by mistake: keep the transaction screenshots and ask your bank to trace it. Never pay a "fee" to a stranger online who promises to recover it.
Don't scan QR codes or tap links that strangers send.

Scam 3: the fake courier, "your order still has a fee"

Sale season means the most parcels, so it is also peak season for fake couriers. The usual script: a delivery call at a time you're out, then a message asking you to transfer first, or "your order still has a fee, scan this code".

Vietnam's Ministry of Public Security has warned that fake couriers call when you're likely not home, send transfer details, deliver fake or low-quality goods and refuse inspection. Its advice includes one short line: don't scan QR codes from unclear sources.

A newer twist: in August 2026, Hưng Yên provincial police warned of callers posing as couriers who say they sent the wrong payment account for an order, then steer the victim to a fake Facebook page of the delivery company to "file a refund complaint". A second person, posing as customer care, sends a "refund confirmation code". When the victim enters it in their banking app, it is actually a transfer of more than 28 million đồng.

What to do:

Open the shopping app and check whether the order is paid and what the delivery fee is. A real courier won't need any amount beyond what the order says.
Pay only for orders you placed, preferably through the marketplace or directly to the seller.
If in doubt, call the delivery company's official hotline, not a number a stranger gives you.

The 3-second rule: after you scan, read the payee's name

All three scams share one weakness: the money has to go to an account that isn't the one you meant to pay. And before you confirm, your banking app shows the payee's name on the transfer screen.

So before you tap send, take 3 seconds:

Read the payee's name. It doesn't match the shop, the seller or the friend you're paying? Stop. Don't send.
Don't scan codes strangers send you by text, Zalo or Messenger, however urgent the story.
Never read an OTP out to anyone, including people who say they are the bank or the police. Hanoi police repeat this in their 2026 warning: never share passwords or OTPs, and don't transfer money before you've verified who receives it.

Send this to your parents. Older family members may scan less, but they are also less likely to doubt a "wrong transfer" message.

What 6pm does, and what it doesn't

6pm is an expense tracker. When you scan a VietQR code with 6pm, it reads the account number, amount and message in the code, logs the spend, then opens the banking app you choose. The payment still happens in your banking app, where you see the payee's name and confirm as usual.

6pm never moves money. It only counts.
6pm never asks for an OTP, a password or your bank login.
We never store your transactions.
6pm can't detect fake codes, and we don't claim it can. The 3-second rule is still yours to follow, in any app.

Where 6pm helps: every scan lands in your log, and at 6pm you go through each spend when you close the day. A strange amount, two payments for one order, or an odd "delivery fee" is easier to spot when they sit side by side on one receipt.

Notes for anyone building on QR payments

Reading these warnings shaped a few rules in our own app, and they apply to anything that scans a payment code:

Never complete the payment yourself. We read the code, log the spend, then hand off to the user's banking app, so the bank's confirm screen with the payee's name is always the last step.
Never ask for an OTP, a password or a bank login. The "scan to verify" call in scam 2 and the "refund confirmation code" in scam 3 both get the victim to act inside their own banking app; an app that only counts has no reason to ask for any of that.
Don't promise what you can't check. A scanner can't tell a sticker over the real code from the real code, so we don't say ours can. Telling people that plainly is better than a "verified" badge.

The parser side (TLV, CRC-16, NAPAS 247 and handing a filled-in payment to 28 bank apps) is in an earlier post: Reading VietQR on the phone. The app is open source: github.com/at6pm/6pm.

FAQ

What is a QR code scam (Quishing)?

A scam that uses a fake or malicious QR code: stuck over a real payment code, sent by message or email, or printed on fake goods. You scan, and the money goes to the scammer, or you land on a fake site that collects your login details.

Someone sent money to my account by mistake. What should I do?

Don't withdraw or forward it, and don't scan any code they send. Tell your bank and return the money only through the bank's official channel or with the authorities as witness, as Phú Thọ police advise.

A courier says my order has an extra fee. Should I scan their code?

Not straight away. Check in the shopping app whether the order is paid and what the fee is. If you still have doubts, call the delivery company's official hotline or contact the seller.

Is scanning with 6pm safer?

6pm doesn't move money and doesn't recognise fake codes. It logs the spend and opens your banking app, where you still read the payee's name and confirm yourself. The 3-second rule applies exactly as it does in your banking app.

I've been scammed. What now?

Call your bank's hotline straight away and ask for the transaction to be traced, keep screenshots, call recordings and statements, and report it to the nearest police station.

Try 6pm

6pm arrives on the App Store at 18:00 on Friday 6 November 2026 (Vietnam time), in time for 11.11. Want it sooner? Join the public TestFlight beta: testflight.apple.com/join/a8UrvT5P. More at at6pm.app.

Every spend, caught.

Your turn: if you've built a payment flow on QR codes anywhere (PromptPay, PayNow, Pix, UPI), what did you do about codes stuck over the real one? We'd like to compare notes in the comments.

Widgets, Controls and Live Activities from an Expo app

Odd Eggs Studio — Sun, 25 Oct 2026 14:00:00 +0000

6pm is an Expo app with three native extensions: a widget extension (Home and Lock Screen widgets, two Control Center controls, one Live Activity), an App Intents extension ("Log in 6pm" for Siri and Apple Pay automations) and a share extension. The extensions never open the database, and Swift never decides a number: TypeScript writes JSON, Swift lays it out.

Code below is from the 6pm repo. The stack: Expo 58, React Native 0.88 on the New Architecture, and @bacons/apple-targets 5.0.0 for the native targets.

The shape

Everything native beyond the app itself lives in apps/mobile/targets:

targets/
  widgets/    WidgetKit: SafeTodayWidget, TodayListWidget, SurfaceActivityWidget, two controls
  intents/    App Intents extension: LogSpendIntent, open-screen intents
  share/      Share extension: reads a bank receipt with Vision
  _shared/    GroupFiles.swift, DomainBridge.swift, ThemeTokens.swift, strings, domain-native.js

Each target is declared in a few lines of JavaScript. The widget extension:

// apps/mobile/targets/widgets/expo-target.config.js
module.exports = (config) => ({
  type: 'widget',
  bundleIdentifier: '.widgets',
  deploymentTarget: '17.0',
  frameworks: ['WidgetKit', 'SwiftUI', 'ActivityKit', 'AppIntents'],
  entitlements: {
    'com.apple.security.application-groups':
      config.ios.entitlements['com.apple.security.application-groups'],
  },
});

expo prebuild turns that into an Xcode target. apps/mobile/ios is generated and git-ignored, so the targets folder and app.config.ts are the only source of truth.

The bundle itself is short:

// apps/mobile/targets/widgets/Bundle.swift
@main
struct SixpmWidgets: WidgetBundle {
  var body: some Widget {
    SafeTodayWidget()
    TodayListWidget()
    SurfaceActivityWidget()
    if #available(iOS 18.0, *) {
      ScanQRControl()
      QuickAddControl()
    }
  }
}

The deployment target is iOS 17; controls are iOS 18 only, so they sit behind #available.

Rule one: extensions never touch the database

The app's source of truth is SQLite with SQLCipher (via expo-sqlite). It would be natural to put that file in the App Group and let the widget read it. We deliberately don't.

SQLite in WAL mode holds a file lock, and iOS kills a suspended extension that holds a lock on a file in a shared container (the 0xdead10cc termination). So the contract, from docs/tech-decisions.md, is:

Each capture an extension makes is one JSON file in <group>/inbox/. The app imports it through the normal capture path and deletes it.
The app writes what extensions show to <group>/surfaces/.
Files are written whole and renamed into place, readable after first unlock, and excluded from backups.

The whole App Group layer is one small Swift file, shared between the app's local Expo module and the extensions:

// apps/mobile/targets/_shared/GroupFiles.swift (generated from modules/surfaces/ios)
/// Writes the whole file to a temporary name and renames it into place.
static func write(_ data: Data, to url: URL) throws {
  try data.write(to: url, options: [.atomic, .completeFileProtectionUntilFirstUserAuthentication])
  var url = url
  var values = URLResourceValues()
  values.isExcludedFromBackup = true
  try url.setResourceValues(values)
}

/// Leaves one capture for the app to import. Extensions only ever write here.
static func writeInbox(id: String, json: Data) throws {
  try write(json, to: folder("inbox").appendingPathComponent("\(id).json"))
}

The group id is derived from the bundle id, so the dev and store builds never share a container.

Rule two: Swift lays out, TypeScript decides

The daily number ("Safe to spend today") is computed by @6pm/domain, a tested TypeScript package. We did not want a second copy of that logic in Swift. So the app writes a snapshot, and the widget draws it.

surfaceSnapshot() in apps/mobile/src/features/surfaces/surface-snapshot.ts produces:

Entries: one for the rest of this money day, and one starting at the next 04:00 (6pm's money day ends at 04:00, so a late-night spend belongs to yesterday). The second entry means the number turns over at 4 a.m. without the app running.
Palettes for every hour: the widget's colours follow the app's time-of-day sky, so the app writes 24 sets of colour tokens plus the companion's mood for each hour.
Strings: every word, already in the user's language (English or Vietnamese), plus Material Symbols glyphs as private-use characters so Swift needs no icon names.

On the Swift side, a timeline provider turns that into WidgetKit entries, one at the top of every hour so the colours follow the sky:

// apps/mobile/targets/widgets/SurfaceTimeline.swift (trimmed)
static func timeline(now: Date) -> Timeline<SurfaceEntry> {
  let loaded = SurfaceSnapshot.load()
  guard let snapshot = loaded, !snapshot.entries.isEmpty else {
    let entry = SurfaceEntry(date: now, state: .setUp, snapshot: loaded, entry: nil,
                             tokens: loaded?.tokens(at: now) ?? [:])
    return Timeline(entries: [entry], policy: .never)
  }
  let starts = snapshot.entries.map { surfaceDate($0.from) ?? now }
  let end = (starts.last ?? now).addingTimeInterval(lastStretch)   // 24 h

  var dates: Set<Date> = [now, end]
  for start in starts where start > now && start < end { dates.insert(start) }
  var hour = Calendar.current.dateInterval(of: .hour, for: now)?.end ?? end
  while hour < end {
    dates.insert(hour)
    hour = hour.addingTimeInterval(60 * 60)
  }
  // ... one SurfaceEntry per date; past `end` the state is .stale ("Open 6pm")
}

The snapshot carries a version (v). If a widget finds a version it does not read, it shows the set-up state instead of decoding garbage. When the app writes a new snapshot it reloads everything it owns:

// apps/mobile/modules/surfaces/ios/SurfaceFiles.swift
static func reloadWidgets() {
  WidgetCenter.shared.reloadAllTimelines()
  if #available(iOS 18.0, *) {
    ControlCenter.shared.reloadAllControls()
  }
}

One widget, four families

SafeTodayWidget covers the Home Screen (small, medium) and the Lock Screen (a ring and a card):

// apps/mobile/targets/widgets/SafeTodayWidget.swift
StaticConfiguration(kind: "SafeToday", provider: SurfaceTimelineProvider()) { entry in
  SafeTodayView(entry: entry)
}
.supportedFamilies([.systemSmall, .systemMedium, .accessoryCircular, .accessoryRectangular])
.contentMarginsDisabled()

// ...
switch family {
case .accessoryCircular: SafeRing(entry: entry)
case .accessoryRectangular: SafeCard(entry: entry)
case .systemMedium: SafeMedium(entry: entry)
default: SafeSmall(entry: entry)
}

TodayListWidget is the large size: what's left, a spent bar and the newest spends.

The companion (a little sun, by default) appears in the widgets as PNGs the app renders and drops into the group (companion-<mood>-<size>.png). In serious mode the snapshot says so and the widget leaves it out.

Controls: SF Symbols and universal links

iOS 18 controls live in Control Center, on the Lock Screen's bottom corners and on the Action button. They only take SF Symbols, so where the app draws Material Symbols, the controls wear qrcode.viewfinder and plus. Each control opens its screen through a universal link, which the app routes whether it was running or not:

// apps/mobile/targets/widgets/Controls.swift
@available(iOS 18.0, *)
struct ScanQRControl: ControlWidget {
  var body: some ControlWidgetConfiguration {
    StaticControlConfiguration(kind: "ScanQR") {
      ControlWidgetButton(action: OpenURLIntent(ControlLink.url("scan"))) {
        Label {
          Text("scan.title", tableName: "Intents")
        } icon: {
          Image(systemName: "qrcode.viewfinder")
        }
      }
    }
    .displayName(LocalizedStringResource("scan.title", table: "Intents"))
    .description(LocalizedStringResource("scan.description", table: "Intents"))
  }
}

One Live Activity type, JSON state

6pm uses a Live Activity in two situations: a QR payment waiting for you to finish it in your bank app, and a trip in Travel mode. Rather than two ActivityAttributes types, there is one, and its content state is a JSON string the app has already worded:

// apps/mobile/targets/widgets/SurfaceAttributes.swift (generated, copied from the module)
public struct SurfaceAttributes: ActivityAttributes {
  public struct ContentState: Codable, Hashable {
    public var json: String
  }
  /// `pendingPay` or `travel`.
  public var kind: String
  /// What the activity follows: the waiting spend's id, or the trip's.
  public var key: String
}

The widget decodes PendingPayState or TravelState from it, and lays out the Lock Screen banner and the Dynamic Island's compact, minimal and expanded regions. Later fields are optional, so an activity started by an older build still decodes after an over-the-air update.

Activities are started by the app, in the foreground, with pushType: nil. There is no remote push: the app has no notification token to send anywhere.

The waiting payment's banner has a "Paid" button. It is a LiveActivityIntent, so it runs in the app's process without opening the app, and it follows the same inbox rule as everything else:

// apps/mobile/targets/widgets/_shared/MarkPaidIntent.swift
func perform() async throws -> some IntentResult {
  let id = UUID().uuidString.lowercased()
  let event: [String: Any] = [
    "v": 1, "id": id, "kind": "paid", "spendId": spendId,
    "at": ISO8601DateFormatter().string(from: Date()),
  ]
  try GroupFiles.writeInbox(id: id, json: JSONSerialization.data(withJSONObject: event))
  for activity in Activity<SurfaceAttributes>.activities where activity.attributes.key == spendId {
    await activity.end(nil, dismissalPolicy: .immediate)
  }
  return .result()
}

On the JavaScript side, useLiveActivity reconciles: on any relevant change it lists what iOS has running and starts, updates or ends activities to match the plan, one run at a time.

"Log in 6pm": running TypeScript in an App Intent

The most interesting target is the App Intents extension. It powers Siri ("Log in 6pm") and, more importantly, Apple Pay capture.

iOS Shortcuts can run an automation when a Wallet card is tapped, and pass the transaction's amount and merchant. 6pm publishes a ready-made shortcut, "Log to 6pm", containing one "Log in 6pm" action with Amount and Where taken from the shortcut input. The user adds it once and attaches it to a Wallet automation. From then on, every Apple Pay tap on that iPhone lands in 6pm's Inbox.

The intent never starts the app, and it has to return quickly, because Wallet gives up on an automation that takes long:

// apps/mobile/targets/intents/LogSpendIntent.swift (trimmed)
struct LogSpendIntent: AppIntent {
  static let openAppWhenRun = false

  @Parameter(title: LocalizedStringResource("logSpend.amount", table: "Intents"), ...)
  var amount: String

  @Parameter(title: LocalizedStringResource("logSpend.merchant", table: "Intents"))
  var merchant: String?

  func perform() async throws -> some IntentResult & ProvidesDialog & ShowsSnippetView {
    let logged = try LoggedSpend.log(amount: amount, merchant: merchant, at: Date())
    // Only Siri gets here: Wallet always names a merchant, and its unread amounts still log.
    if logged.needsAmount {
      throw $amount.needsValueError(...)
    }
    ...
  }
}

Parsing "25k", "twelve dollars" or Wallet's formatted amount, picking a category from merchant rules, and working out the new "safe today" line are all domain logic. So the extension runs the domain in JavaScriptCore:

// apps/mobile/targets/_shared/DomainBridge.swift (trimmed)
final class DomainBridge {
  /// The `NATIVE_API_VERSION` this Swift was written against.
  static let apiVersion: Int32 = 4

  init() throws {
    guard let url = Bundle.main.url(forResource: "domain-native", withExtension: "js"),
          let source = try? String(contentsOf: url, encoding: .utf8),
          let context = JSContext()
    else { throw Failure.missingBundle }
    context.evaluateScript(source)
    // ... reads the global `SixpmDomain`, checks NATIVE_API_VERSION, installs an exception handler
  }

  /// Calls `SixpmDomain.<name>(...arguments)`, each argument and the result a JSON string.
  func call(_ name: String, _ arguments: [String]) throws -> String { ... }
}

LoggedSpend.log passes the amount, the merchant, the context file the app last wrote to the group, and the current time. The domain answers with an item to file, which goes into the inbox, plus the text for Siri's snippet. The version check means a Swift/JS mismatch fails loudly instead of logging a wrong number.

The App Shortcuts provider registers the phrases. Siri has no Vietnamese, so the spoken phrases are English while titles follow the phone's language:

// apps/mobile/targets/intents/IntentsExtension.swift
AppShortcut(
  intent: LogSpendIntent(),
  phrases: [
    "Log in \(.applicationName)",
    "Log a spend in \(.applicationName)",
  ],
  shortTitle: LocalizedStringResource("logSpend.short", table: "Intents"),
  systemImageName: "plus.circle"
)

Keeping two languages in sync

Swift holds no copy of a number rule, a word or a colour. tools/scripts/generate-native.ts writes everything the iOS side reads from the TypeScript packages:

targets/_shared/domain-native.js: the domain's native entry, bundled with esbuild for JavaScriptCore
targets/_shared/<lang>.lproj/<Table>.strings: the native.* keys from @6pm/i18n
targets/_shared/ThemeTokens.swift: fixed colours from @6pm/theme
SurfaceAttributes.swift and GroupFiles.swift, copied from the local module so the app and the extensions share one definition

CI runs it with --check and fails when a generated file is out of date, so a renamed key or a changed colour cannot reach Swift half-done.

What we'd tell you before you start

Decide the IPC early. "Extensions write one JSON file, the app imports it" is boring, and boring is the point. Shared SQLite would trade it for lock-related terminations.
Precompute, don't recompute. A widget timeline with an entry at the next day boundary means the number is right at 04:00 even if the app hasn't run since yesterday.
Version every file that crosses the boundary. Over-the-air JS updates mean the app can be newer than the extension's expectations, and vice versa.

FAQ

Can you build iOS widgets with Expo?

Yes. @bacons/apple-targets adds widget, App Intents and share extension targets from a small config file per target, and expo prebuild generates the Xcode project. The widget UI itself is still SwiftUI.

How do the widgets get the data without opening the database?

The app writes a versioned JSON snapshot to the App Group (entries, hourly colours, strings) and reloads timelines. Extensions only ever write single JSON files to an inbox folder, which the app imports.

How does 6pm log Apple Pay transactions?

Through a Shortcuts automation on Wallet taps that runs the "Log in 6pm" App Intent with the amount and merchant. The intent runs the domain logic in JavaScriptCore and leaves the spend in the App Group inbox without opening the app.

Does the Live Activity use push notifications?

No. The app starts, updates and ends it locally with pushType: nil, and the "Paid" button is a LiveActivityIntent.

Try it

The code is on GitHub under Apache 2.0: github.com/at6pm/6pm (start in apps/mobile/targets and apps/mobile/modules/surfaces). The widgets, controls and Live Activity are in the public beta on TestFlight: testflight.apple.com/join/a8UrvT5P. 6pm is on the App Store from Friday 6 November 2026, 18:00 ICT. More at at6pm.app.

Folding it shut closes the day: building a React Native money app for the iPhone Duo

Odd Eggs Studio — Thu, 22 Oct 2026 03:58:18 +0000

Apple's iPhone Duo goes on sale on Friday 23 October. 6pm, our daily money app, already lays itself out for each way you can hold it. We built it in mid-October on the iPhone Duo simulator in Xcode 27.1, and it ships in 6pm 2.0.0 on the App Store on 6 November.

This post covers what the iOS 27.1 SDK gives you, how we got it into React Native, and the one design question that took the most thought: what should folding a phone shut mean in an app you close once a day?

Every snippet is from the open-source repo (github.com/at6pm/6pm, Apache 2.0).

What the platform gives you

Three things in the iOS 27.1 SDK matter:

UIHingeInteraction: added to a view, it reports UIHinge updates with a status (closed, partially open, fully open) and an angle in radians.
UIView.reservedRegions(kind:): .division is the fold across the inner screen, and .occlusion is the vertical island on the outer screen. Each comes with a frame in the view's space.
UIArrangementViewController: split and overlay arrangements for native two-pane apps. 6pm draws its own pages in React Native, so we read the regions instead.

There is no single "pose" value. "Held like a book" and "stood on a table" are both "partially open"; the difference is which way the fold runs across the window. So the pose is yours to work out.

Some readings from the simulator, which helped us write tests:

Held	Hinge	Window	Division
Closed	closed, angle 0	466×678	none; the island strip at the top right
Book	partial, ≈2.23 rad	951×669	40 pt upright, at x 455.5
Flat	open, π	951×669	none once it lies flat
Stand	partial	669×951	across, at y 455.5

A small native module, events only when something changes

The Swift side is one Expo module of about 200 lines. It adds an invisible probe view that fills the key window, re-reads the regions whenever the window lays out (folding, turning and Split View all resize it), and holds a UIHingeInteraction:

let interaction = UIHingeInteraction { [weak self] _, update in
  guard let self else { return }
  if let hinge = update.hinge {
    self.hinge = Self.name(hinge.status)
    self.angle = Double(hinge.angle)
  } else {
    self.hinge = "unknown"
    self.angle = nil
  }
  self.report()
}
window.addInteraction(interaction)

report() sends a snapshot to JS only when it differs from the last one, so a scroll that relays the window out sends nothing. The JS thread reads the last snapshot the main thread took, never UIKit itself.

In JS, the module is optional: requireOptionalNativeModule('Fold') returns null in tests and on other platforms, and a provider turns it into React state. The angle also goes into a Reanimated shared value, so motion that follows the hinge stays on the UI thread:

const subscription = fold.addListener('onFold', (next) => {
  angle.set(next.angle ?? -1);
  setSnapshot(next);
});

Five layouts from one pure function

Everything that decides layout lives in foldForm(snapshot, window), a pure function with Jest tests and no device needed:

export type FoldForm =
  | { readonly kind: 'phone' }
  | { readonly kind: 'rail'; readonly rail: number }
  | {
      readonly kind: 'spread';
      readonly left: Page;
      readonly right: Page;
      readonly rail: number;
      readonly book: boolean;
    }
  | { readonly kind: 'stand'; readonly top: Half; readonly bottom: Half };

rail: closed, and something covers the window's right edge (the island). The status, Add, the tabs and Scan move into a 72 pt rail on the right, and the sky and the day's number take the full height.
spread: opened sideways with room for two pages of at least 360 pt. It splits at the division, or at the middle with a 40 pt gutter when the screen lies flat and reports no fold. book is the same spread part way open.
stand: part way open with the division running across. The top half is for reading, the flat half for touching.
phone: everything else, including the Duo opened upright and flat.

One rule from the design governs all of them: nothing you tap sits in the fold. Lists may scroll across it; controls never.

On the spread, the left page is Today, Plan or the Diary. The right page is the month, a spend you tapped, the Diary's chosen day, or Ask 6pm.

The design question: what does folding it shut mean?

6pm's core moment is the Close. At 6pm you go through the day's captured spends as cards (Keep, Edit, Not mine), and the day is stamped closed. On the opened Duo, the Close lays out as a book: the cards on the left page, and on the right a ledger with what's been kept and what's still yours today.

Folding a phone shut is the most natural "I'm done" gesture there is. But in a money app, "done" can't mean "keep whatever I didn't look at". So the rule is:

Folding the phone shut finishes the Close once no card is waiting, exactly as the reveal's Done does. With cards still waiting, it carries on on the outer screen, so nothing is ever kept that was not decided.

In code that's a small hook. It fires only on a transition into closed from part way or fully open, so launching the app on the outer screen never closes anything:

export function useFoldShut(onShut: () => void, enabled: boolean) {
  const { snapshot } = useFold();
  const latest = useRef(onShut);
  useEffect(() => {
    latest.current = onShut;
  });
  const was = useRef(snapshot.hinge);
  useEffect(() => {
    const before = was.current;
    was.current = snapshot.hinge;
    if (enabled && snapshot.hinge === 'closed' && (before === 'partial' || before === 'open')) {
      latest.current();
    }
  }, [snapshot.hinge, enabled]);
}

The Close screen enables it only after the card step, and the hinge and the Done button share one useFinishClose. It runs once, works the day's number out for the closed day itself, and lets a failed save be tried again. The outer screen then shows tomorrow's number.

Standing it on a counter: Market mode

The stand pose turned out to be the most "real life" one. Half open with the fold across, on Home, 6pm becomes a counter. The top half shows what's left for today in numbers readable from a step away. The flat half has a keypad, the hour's likely categories and Add. Each Add is saved at once as a kept cash spend, the number goes down, and the spend shows as a chip. Think of a morning at the market with cash in hand.

The same pose powers Scan to pay: the inner camera and a frame to hold the stall's QR up to on the top half, the confirm and the bank hand-off on the flat half. While a payment is under way, the top half shows the amount and payee large enough for the seller to read.

Gotchas

Check the SDK, not the compiler. We first guarded the 27.1 calls with #if compiler(>=6.4). Then Xcode 27.0 shipped the same Swift 6.4 with the iOS 27.0 SDK, and the build broke there. UIKit's module version follows the SDK, so that's what we check now:

#if canImport(UIKit, _version: 9127.0.85)  // iOS 27.1's UIKit
  if #available(iOS 27.1, *) {
    // UIHingeInteraction, reservedRegions(kind:)
  }
#endif

#available still guards the runtime, for people on older iOS.

An older SDK means no hinge, silently. A build from an older Xcode runs fine on the Duo, with one page everywhere. Our CI built signed apps with Xcode 26.6, so we moved signed builds to the Xcode 27 runner image, picking 27.1 once it's a release build. Never a beta: App Store Connect refuses uploads built with one.

The inner screen turns on its own. iOS ignores the portrait lock there, so every inner-screen layout has to work both ways round.

The simulator folds from Device Hub, not simctl. simctl has no posture command. We drove the hinge from scripts with agent-device fold closed|half-open|open, which sends the hinge event inside the simulator and reads the angle back.

Every pose change animates

Pages slide apart and the rail eases in; nothing jumps. The order of things is the same on both screens, so shutting the phone part way through keeps your place.

6pm 2.0.0 is on the App Store from Friday 6 November, 18:00 ICT. Until then the beta is on TestFlight (join here), and the code is at github.com/at6pm/6pm.

Written with AI assistance from our own code, commits and design docs; every snippet is from the repo.

Reading VietQR on the phone: TLV, NAPAS and 28 bank apps

Odd Eggs Studio — Wed, 21 Oct 2026 15:59:21 +0000

6pm reads a VietQR entirely on the phone: a small TLV reader, a CRC-16/CCITT-FALSE check, a NAPAS template lookup. Then it opens the payer's bank app. For 28 apps that is a transfer link with account, amount and note filled in; for the rest, the app's home screen, the amount on the clipboard and the QR saved to Photos.

This post walks through the code in packages/domain/src/vietqr/ and apps/mobile/src/features/scan/bank-handoff.ts. Everything quoted is from the repo, which is Apache 2.0.

Why parse it ourselves

6pm is an expense tracker that never asks for a bank login. In Vietnam most small payments are VietQR transfers: a printed code at the bánh mì stall, scanned by a bank app. If 6pm does the scanning, it knows the payee, the amount and the note before the money moves, and the spend lands in the Inbox without anyone typing it.

That only works if the parser is boringly correct. A wrong amount in a money app is worse than no amount. So the parser lives in @6pm/domain, a plain TypeScript package with no React Native in it, tested in Vitest, and bundled into the app and its iOS extensions.

The format in two minutes

VietQR is NAPAS's profile of the EMVCo merchant-presented QR. The payload is a flat string of data objects, each ID (2 digits) · length (2 digits) · value. Some values are themselves TLV strings. A typical transfer looks like this, broken up for reading:

00 02 01                      payload format indicator
01 02 12                      12 = dynamic (one-off), 11 = static
38 57 0010A000000727          merchant account template, NAPAS GUID
      0127 0006970422 0113…   beneficiary: BIN 970422 + account
      0208QRIBFTTA            service: transfer to an account
53 03 704                     currency: VND
54 05 55000                   amount
58 02 VN                      country
62 .. 08 .. Banh mi           additional data, 08 = purpose
63 04 ABCD                    CRC

The merchant account template can sit in any tag from 26 to 51. NAPAS's has GUID A000000727 in sub-tag 00, a nested beneficiary in 01 (BIN in 00, account in 01), and a service code in 02: QRIBFTTA (account), QRIBFTTC (card) or QRPUSH (merchant).

A TLV reader that survives real codes

The reader is small:

// packages/domain/src/vietqr/tlv.ts (trimmed)
export function parseTlv(text: string, unit: LengthUnit = 'chars'): TlvFields | null {
  const chars = Array.from(text);
  const fields = new Map<string, string>();
  let i = 0;
  while (i < chars.length) {
    const tag = chars.slice(i, i + 2).join('');
    const len = chars.slice(i + 2, i + 4).join('');
    if (!TWO_DIGITS.test(tag) || !TWO_DIGITS.test(len)) return null;
    i += 4;
    const want = Number(len);
    let taken = 0;
    const start = i;
    while (taken < want && i < chars.length) {
      taken += unit === 'bytes' ? utf8Size(chars[i]?.codePointAt(0) ?? 0) : 1;
      i++;
    }
    if (taken !== want) return null;
    if (fields.has(tag)) return null;
    fields.set(tag, chars.slice(start, i).join(''));
  }
  return fields;
}

Two details matter.

Array.from(text), not indexing. EMVCo counts characters. JavaScript strings index UTF-16 code units, so an emoji in a note would shift every later field. Iterating code points keeps the count honest.

A bytes mode. Some Vietnamese generators count UTF-8 bytes when the note has diacritics ("Bánh mì" is 7 characters and 9 bytes). Strict parsing would reject codes that every bank app accepts. So parseVietQR tries characters first, then bytes, and takes whichever reading ends cleanly on tag 63:

// packages/domain/src/vietqr/parse-vietqr.ts
function readFields(raw: string): { fields: TlvFields; unit: LengthUnit } | null {
  for (const unit of ['chars', 'bytes'] as const) {
    const fields = parseTlv(raw, unit);
    if (fields && [...fields.keys()].at(-1) === '63') return { fields, unit };
  }
  return null;
}

The same unit is then used for the nested templates, so a code is read consistently one way or the other.

The checksum

Tag 63 is a CRC-16/CCITT-FALSE over everything before it, including the literal 6304. The implementation is the textbook bitwise version over UTF-8 bytes:

// packages/domain/src/vietqr/crc16.ts
export function crc16CcittFalse(text: string): string {
  let crc = 0xffff;
  for (const byte of utf8Bytes(text)) {
    crc ^= byte << 8;
    for (let bit = 0; bit < 8; bit++) {
      crc = crc & 0x8000 ? ((crc << 1) ^ 0x1021) & 0xffff : (crc << 1) & 0xffff;
    }
  }
  return crc.toString(16).toUpperCase().padStart(4, '0');
}

parseVietQR checks it before reading any field. A failed CRC is its own outcome, bad_crc, so the interface can say "that code looks damaged" rather than "that isn't a payment".

Reading the payment, refusing the rest

After the CRC, the parser finds the NAPAS template among tags 26–51, rejects anything that is not đồng (53 must be 704 when present) or not Vietnam (58 must be VN when present), and validates the beneficiary: a six-digit BIN and an account of 1–19 letters and digits.

Amounts get special care because VND has no minor unit:

const AMOUNT = /^(\d{1,13})(?:\.0*)?$/;
// "55000" and "55000.00" are both 55.000₫; "55000.50" cannot be paid: malformed.

A zero or missing amount is null, meaning "ask the user". The service code is mandatory in NAPAS's spec, but older static codes in the wild omit it, so a missing 02 is read as a transfer to an account.

The result is a discriminated union. Success carries the bank (looked up by BIN), the masked account (•••• 4821), the amount, the note from 62/08, and whether the code is dynamic. Failure carries one of not_emv, bad_crc, foreign, unsupported or malformed.

Foreign codes: name them, never pay them

Travellers scan codes abroad, and Vietnamese visitors scan Thai and Singaporean codes at home. 6pm recognises them and keeps the spend in its own currency, but never tries to pay them.

Detection is by the GUID in the merchant template, falling back to the country in tag 58:

// packages/domain/src/vietqr/foreign-scheme.ts (excerpt)
const GUIDS = [
  { prefix: 'A000000677', country: 'TH', scheme: 'promptpay' },
  { prefix: 'SG.PAYNOW', country: 'SG', scheme: 'paynow' },
  { prefix: 'A0000006150001', country: 'MY', scheme: 'duitnow' },
  { prefix: 'ID.CO.QRIS', country: 'ID', scheme: 'qris' },
  { prefix: 'PH.PPMI', country: 'PH', scheme: 'qrph' },
  { prefix: 'HK.COM.HKICL', country: 'HK', scheme: 'fps' },
  { prefix: 'BR.GOV.BCB.PIX', country: 'BR', scheme: 'pix' },
];

Codes that are not EMV at all (UPI links, SEPA transfer codes, the Swiss QR-bill, Czech QR Platba, Alipay and WeChat Pay shop codes) go through readOtherPayment before the EMV path. A small set, PAID_FROM_VIETNAM = new Set(['TH', 'SG', 'MY', 'KH', 'LA']), records which countries' codes a Vietnamese bank app can pay across the border, so Travel mode can say so.

Handing off to the bank

6pm does not move money. After a scan it hands the payment to the bank app the user picks, from a catalogue of 41 Vietnamese bank and wallet apps whose iOS URL scheme it knows. This is the part that took the most poking at real phones.

Where the links came from

Zalo has a "pay in a bank app" sheet. Watching which URLs it opens gave us each bank's URL scheme and, for most, a transfer link of one shared shape:

<scheme>applink?targetPage=QRPay&qrContent=<url-encoded VietQR>

VietinBank uses the same query on a different path (host.qrTransfer). Nam A Bank takes no QR at all, but a base64 JSON blob of the fields on ops.namabank.com.vn/?data=. The catalogue encodes this per bank:

// packages/domain/src/vietqr/bank-catalogue.ts (excerpt)
MB:  linked('mbbank://', '1205807363'),
VCB: plain('vietcombankmobile://', '561433133'),
VBA: plain('agribankmobile://', '935944952'),
ICB: linked('vietinbankipay://', '689963454', { kind: 'qrPay', path: 'host.qrTransfer' }),
NAB: linked('nabtransfermoney://', '1456997296', { kind: 'namABank' }),

Twenty-eight entries are linked. Zalo signs its links; 6pm sends them unsigned. MB is the bank we have confirmed opens filled in that way with a transfer completed end to end on a real phone. Vietcombank and Agribank take only a token issued to their partners, so they are plain and open at their home screen. MoMo and ZaloPay open by the schemes their own SDKs query, with no transfer link; ViettelMoney and VNPT Money publish no scheme, so 6pm tells the user to open them and copies the amount.

The QR going in

When the user types an amount for a static code, the bank should see that amount. payloadFor re-encodes a person-to-person transfer with the new amount, but never rewrites a shop's code:

// packages/domain/src/vietqr/handoff-link.ts
export function payloadFor(qr: VietQR, amount: Vnd): string {
  if (qr.amount === amount || qr.service === 'merchant') return qr.raw;
  // …re-encode bin, account, amount, note, name with encodeVietQR; on failure, qr.raw
}

encodeVietQR is the mirror of the parser: it builds the TLV, appends 6304, and computes the CRC with the same function.

The hand-off itself

// apps/mobile/src/features/scan/bank-handoff.ts (trimmed)
export async function handOff(bank: BankInfo | null, qr: VietQR, amount: number) {
  await Clipboard.setStringAsync(String(amount));
  const plan = handoffPlan(bank, OS, qr, amount);
  const qrSaved = plan?.filledIn === true ? false : await saveQr(payloadFor(qr, amount));
  if (plan === null) return { result: 'manual', qrSaved };
  if (plan.open !== null && (await opens(plan.open))) return { result: 'opened', qrSaved };
  for (const url of plan.store) {
    if (await opens(url)) return { result: 'store', qrSaved };
  }
  return { result: 'manual', qrSaved };
}

Three decisions are encoded here:

The amount always goes on the clipboard, digits only, because that is what a bank's amount field accepts.
No canOpenURL. It is deprecated for this use and limited to 25 declared schemes, and the catalogue has 41 apps. Linking.openURL fails just as clearly when the app is missing, and the fallback is its App Store page.
If the bank cannot be filled in, the QR is saved to Photos, drawn by our own QR encoder (encode-qr.ts, byte mode, Reed-Solomon, mask scoring per ISO/IEC 18004), so the bank's "scan from photo" reads it back exactly.

On Android, handoffPlan opens the app's home: no bank's transfer link has been seen to open filled in there.

Coming back: "Did it go through?"

No bank app returns to 6pm on its own. When the user comes back, 6pm asks "Did it go through?". Until then the scan is a pending spend, shown as a Live Activity with a Paid button, and it already lowers the day's safe-to-spend number so the number stays honest.

If the bank's own receipt also arrives (a shared screenshot, a forwarded email, an Apple Pay tap), the two are merged rather than counted twice. Most sources merge within three minutes; a waiting scan gets longer, because people finish paying in the bank app a while later:

// packages/domain/src/capture/duplicate.ts
export const DUPLICATE_WINDOW_MS = 3 * 60_000;
/** A QR scan still waiting to be paid is matched by its bank's receipt … up to this long after the tap. Never before the tap. */
export const QR_RECEIPT_WINDOW_MS = 20 * 60_000;

Anything the user typed (Quick add, voice, cash) is never merged with anything.

What we would tell someone building this

Treat "the spec says" and "what is printed on the stall" as two specs. Byte-counted lengths and missing service codes are both real.
Keep the parser pure and away from the camera. Ours runs in Vitest, in the app, and in an iOS extension through JavaScriptCore without changes.
Return reasons, not booleans. bad_crc, foreign and unsupported each produce different words on screen.
Do not promise that every bank opens filled in. Ours do not, and the interface says so.

FAQ

Does 6pm send the scanned QR to a server?

No. The QR is parsed on the phone in @6pm/domain. The only thing that leaves is the URL the bank app is opened with, which goes to that app on the same phone.

Why are the bank links sent unsigned?

Zalo's links carry its own signature, which we cannot produce. The links work unsigned for the banks we have tested, MB end to end; banks that require a partner token (Vietcombank, Agribank) open at their home screen instead.

Can 6pm pay a PromptPay or PayNow code?

No. It recognises the scheme and records the spend in that currency. With Travel mode on from a đồng home, it says whether a Vietnamese bank app can pay that country's codes.

Is the parser reusable?

It is plain TypeScript with no React Native dependency, under Apache 2.0, in packages/domain/src/vietqr/.

Try it

The code is at github.com/at6pm/6pm. The iPhone app is in public beta on TestFlight: testflight.apple.com/join/a8UrvT5P, and on the App Store from 6 November 2026, 18:00 ICT. More at at6pm.app.

How we made an Expo app feel native: Reanimated 4, real form sheets and haptics

Odd Eggs Studio — Wed, 21 Oct 2026 12:08:40 +0000

An Expo app can feel native if every animation runs on the UI thread, every gesture hands its velocity to the spring that finishes it, and you use the system's own sheets instead of drawing your own. In 6pm that means Reanimated 4 worklets, Gesture Handler, Expo Router form sheets, and four kinds of haptic, each used for one job.

6pm is a daily money app. Its core moment, "the close", is a stack of receipt cards you swipe through at 6pm: right to keep, left to edit, down for "not mine". The last card stamps the day CLOSED. If that swipe feels like a web page, the product fails. So our agent contract (the CLAUDE.md at the repo root) opens with this:

Native feel is the product. UI-thread animation only (Reanimated worklets, Gesture Handler). Every state change animates with the prototype's curve. No layout jumps, no blank frames, no JS-thread Animated.

Here is how that rule turns into code. Versions, from the workspace catalog: Expo 58, React Native 0.88 (New Architecture, Hermes), react-native-reanimated 4.7.0, react-native-worklets 0.13.0, react-native-gesture-handler 3.2.1, expo-router 58.0.19, expo-haptics 58.0.6.

Motion is data, not taste

The design started as an HTML prototype with CSS keyframes and cubic-beziers. Rather than eyeballing it, the curves, durations, springs and gesture thresholds live in one place, @6pm/theme:

// packages/theme/src/motion.ts (trimmed)
export const curves = {
  /** The house curve: a confident move with a small overshoot (cards, sheets, chips). */
  house: [0.2, 0.9, 0.25, 1.12],
  /** Entrances: screens, list items, hero cards. */
  enter: [0.2, 0.9, 0.2, 1],
  /** Wheel pickers snapping to a row. */
  snap: [0.2, 0.9, 0.25, 1],
} as const;

export const gestures = {
  cardFling: 90,
  rowConfirm: 90,
  rowRevealDelete: -48,
  rowCommitDelete: -150,
  sheetDismiss: 120,
  tabSwipe: 70,
  fabLongPressMs: 480,
} as const;

Screens import the numbers, never invent them, so motion can be reviewed like any other diff.

Release physics: project where the finger was going

The biggest difference between "animated" and "native" is what happens when the finger lets go. UIKit decides with velocity, not just position: a quick short flick commits, a slow long drag doesn't. We use the same projection UIScrollView uses:

// apps/mobile/src/ui/motion/physics.ts
/**
 * Where a released finger was heading: the distance it would still travel if it kept slowing at
 * UIScrollView's normal rate. A quick short flick projects far and commits; a slow long drag
 * doesn't. `velocity` in points per second, as Gesture Handler reports it.
 */
export function project(velocity: number, decelerationRate = 0.998): number {
  'worklet';
  return ((velocity / 1000) * decelerationRate) / (1 - decelerationRate);
}

The close card uses it to pick a verdict. Only the axis the finger mostly travelled counts, so a mostly downward drag that drifts right is "not mine", never "keep":

// apps/mobile/src/features/close/card-fling.ts
export function cardFling(x: number, y: number, velocityX: number, velocityY: number,
                          threshold?: number): CardFling {
  'worklet';
  // Read here, not as a default parameter: a worklet captures only names its body uses.
  const reach = threshold ?? gestures.cardFling;
  const px = x + project(velocityX);
  const py = y + project(velocityY);
  if (Math.abs(px) >= Math.abs(py)) {
    if (px > reach) return 'kept';
    if (px < -reach) return 'edit';
    return null;
  }
  return py > reach ? 'notMine' : null;
}

That comment about default parameters is a real gotcha: a worklet closure captures only what its body references, so a default parameter that reads an imported constant can come up undefined on the UI thread. The function is pure, so it has a unit test (card-fling.test.ts) that runs in Jest without a device.

The swipe itself

The card stack is a Gesture.Pan() writing to two shared values. Three details make it feel physical:

// apps/mobile/src/features/close/close-cards.tsx (trimmed)
Gesture.Pan()
  .onStart((e) => {
    // A card caught mid-flight is picked up where it is.
    const y = dy.get();
    startX.set(dx.get() - e.translationX);
    startY.set((y < 0 ? unband(y, stack) : y) - e.translationY);
  })
  .onUpdate((e) => {
    const y = startY.get() + e.translationY;
    dx.set(startX.get() + e.translationX);
    dy.set(y >= 0 ? y : rubberband(y, stack));
  })
  .onEnd((e) => {
    const verdict = cardFling(dx.get(), dy.get(), e.velocityX, e.velocityY);
    if (verdict === null) {
      settle(e.velocityX, e.velocityY);
      return;
    }
    // The tap lands as the finger lets go, not when the card is gone.
    scheduleOnRN(haptics.tap);
    // ...
    const away = { ...release.away, reduceMotion };
    if (verdict === 'kept') {
      dx.set(withSpring(AWAY_X, { ...away, velocity: e.velocityX }, done));
    } else {
      dy.set(withSpring(AWAY_Y, { ...away, velocity: e.velocityY }, done));
    }
  });

Interruptible. Grab a card that is still springing home and it is picked up where it is. Because upward drags are rubber-banded, onStart runs the inverse (unband) to find the finger offset that produces the current position. No jump.
Rubber, not walls. Dragging up, the card follows less and less, the same curve iOS uses at a scroll view's edge:

   export function rubberband(overshoot: number, dimension: number, constant = 0.55): number {
     'worklet';
     return (overshoot * dimension * constant) / (dimension + constant * Math.abs(overshoot));
   }

Velocity continuity. Every release spring takes the finger's velocity, so there is no seam between drag and settle. The springs are duration-and-damping-ratio springs, which are far easier to match to a design than stiffness and mass:

   export const release = {
     home: { duration: 400, dampingRatio: 0.8 },
     sheet: { duration: 300, dampingRatio: 0.8 },
     away: { duration: 300, dampingRatio: 1, overshootClamping: true },
   } as const;

The card tilts as it moves (rotate: dx / 18 degrees), computed in useAnimatedStyle. And because each new top card mounts with its own drag at zero, nothing is "reset" after a fling: the card behind is already where the stack had moved it.

The buttons under the card (Keep, Edit, Not mine) do the same thing without a finger. They have no velocity to carry, so they use withTiming on the house ease-out instead of a spring.

Real sheets, not drawn ones

At first, every sheet in 6pm drew itself over a transparent modal with Reanimated. It looked right in screenshots and felt wrong in the hand. On 12 October we switched to the real thing. The reasoning is recorded in docs/tech-decisions.md:

The native sheet drags from anywhere, pulls down from the top of a scroll, carries the finger's velocity, is interruptible, honours Reduce Motion, and slides away on router.back(); the hand-drawn one did none of that well.

With Expo Router that is a screen option:

// apps/mobile/src/ui/navigation/presentations.ts
export const sheet: ScreenOptions = {
  presentation: Platform.OS === 'ios' && Platform.isPad ? 'pageSheet' : 'formSheet',
  sheetAllowedDetents: [1],
  sheetCornerRadius: 40,
  sheetGrabberVisible: false,
  headerShown: false,
  contentStyle: { backgroundColor: 'transparent' },
};

That is UISheetPresentationController underneath (via react-native-screens). Trade-offs we accepted:

4 points. The one detent is the tallest iOS allows. Its top edge sits on the safe area, 4 pt lower than the prototype's. iOS won't raise it, and we decided 4 pt was a better deal than fake physics.
Our own grabber. We hide the system grabber and draw the prototype's, and each sheet paints its own background.
iPad gets a page sheet. On iPad a form sheet is a small centred card, too short for a pinned footer, so there it becomes a page sheet.
Ask and Scan are page sheets on iPhone too. The page behind scales back into a card, as Mail does when you compose, which suits a screen that is "a place of its own".

Two sheets stay hand-drawn because iOS cannot draw them: a floating card inset from the edges, and the Looks sheet, which sinks low over an undimmed page while you try a theme on. Below its tallest detent, iOS floats its sheet inset from the edges, so neither shape can be native. Those use a shared drag-to-dismiss hook that follows the same rules as the native sheet: decide by where the flick was heading (position plus projected velocity), spring home at {300 ms, ratio 0.8} or out at {300 ms, ratio 1, clamped} with the finger's velocity, and continue from wherever it is if grabbed mid-flight.

The stamp

When the last card goes, the day prints: a receipt feeds down out of a slot, and 1.6 s later a red CLOSED stamp lands. The prototype's stampIn keyframes (scale 2.4 → 0.94 → 1, rotate −14° → −7°, opacity to 0.92) become one shared value driven by a sequence, with the keyframe maths in the animated style:

// apps/mobile/src/features/close/close-receipt.tsx (trimmed)
const stampEase = Easing.bezier(0.3, 1.5, 0.5, 1);
const STAMP_MS = { delay: 1600, land: 300, rest: 200 };

stamp.value = withDelay(
  STAMP_MS.delay,
  withSequence(
    withTiming(0.6, { duration: STAMP_MS.land, easing: stampEase }, () =>
      runOnJS(haptics.tap)(),
    ),
    withTiming(1, { duration: STAMP_MS.rest }),
  ),
);

const stampStyle = useAnimatedStyle(() => {
  const t = stamp.value;
  const scale = t < 0.6 ? 2.4 - (t / 0.6) * (2.4 - 0.94) : 0.94 + ((t - 0.6) / 0.4) * 0.06;
  return {
    opacity: Math.min(0.92, t / 0.6),
    transform: [{ rotate: `${-14 + 7 * Math.min(1, t / 0.6)}deg` }, { scale }],
  };
});

The haptic fires in the timing's completion callback, the instant the stamp hits paper. That timing is the whole trick: a thump 100 ms late reads as a bug.

Haptics: four words, used consistently

The prototype had one buzz(). iOS offers several feelings, so we split it into a tiny vocabulary and never call expo-haptics directly from a screen:

// apps/mobile/src/ui/haptics.ts
export const haptics = {
  /** Tab scrub, wheel row, a swipe crossing its threshold. */
  tick: () => void Haptics.selectionAsync(),
  /** Keep / edit / not mine, FAB long-press, sheet dismissed, undo. */
  tap: () => void Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Light),
  /** Something let go of for good: a row flung away to delete. */
  commit: () => void Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Medium),
  /** The close done, the reveal settling, a purchase made. */
  success: () => void Haptics.notificationAsync(Haptics.NotificationFeedbackType.Success),
};

From a gesture worklet, haptics hop to the JS thread with scheduleOnRN (Reanimated 4 moved thread hopping into react-native-worklets). Two rules we follow:

Fire on the finger, not on the animation. The card's tap lands as the finger lets go, not 300 ms later when the card leaves.
Success is rare. Only finishing things gets the success pattern: the close, the reveal of tomorrow's number, a purchase. If everything buzzes, nothing does.

Numbers that roll instead of jumping

"Every state change animates" includes text. The daily number is an odometer: each digit is a column that rolls, 1000 ms plus 80 ms per position, on the entrance curve. When the number grows a digit (99 → 100), the new column opens from zero width while the others glide over, using Reanimated layout animations written as worklets:

// apps/mobile/src/ui/odometer.tsx
const slide = LinearTransition.duration(durations.screen).easing(ease);

No re-render can make the number jump, because the layout change itself is animated on the UI thread.

Reduce Motion is part of the design

Respecting the accessibility setting is not an afterthought you add with a flag at the end. In 6pm:

Release springs pass reduceMotion: ReduceMotion.System, so iOS's setting is honoured in the spring itself.
The motion contract in docs/tech-decisions.md says springs become short fades, atmosphere freezes and nothing loops.
The animated sky's clock stays at zero under Reduce Motion, which holds every drift, twinkle and grain step on its first frame.
Native sheets honour it for free, one more reason to use them.

What we learned

Put the physics in pure worklet functions. project, rubberband, unband and cardFling are a few lines each, run on the UI thread, and are unit-tested in Jest.
Prefer the platform when it exists. We drew our sheets first, then moved every sheet iOS can present to presentation: 'formSheet'. The 4 pt we lost bought interruptibility, scroll hand-off and accessibility.
Haptics are timing. The right pattern at the wrong moment is worse than none.

FAQ

Can a React Native app feel as smooth as a native one?

Yes, if animation and gesture handling run on the UI thread. Reanimated worklets and Gesture Handler do that; the JS-thread Animated API and state-driven re-renders don't.

Should I use native form sheets or a JS bottom sheet in Expo?

Use Expo Router's presentation: 'formSheet' where it fits: you get UISheetPresentationController's drag, scroll hand-off, velocity and Reduce Motion for free. Draw your own only for shapes iOS can't present.

How do you decide if a swipe should commit?

Project the release velocity with UIScrollView's deceleration rate, add it to the current offset, and compare against a threshold on the dominant axis. A short fast flick commits; a slow drag springs back.

Try it

All of this is open source under Apache 2.0: github.com/at6pm/6pm (see apps/mobile/src/ui/motion, apps/mobile/src/features/close and packages/theme/src/motion.ts). Swipe the close yourself in the public beta on TestFlight: testflight.apple.com/join/a8UrvT5P. 6pm is on the App Store from Friday 6 November 2026, 18:00 ICT. More at at6pm.app.

Written with AI assistance from our own code and design docs; every snippet is from the repo.