DEV Community: Odd Eggs Studio

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.