DEV Community: BeforeGo

Fewest transfers was correct. It also told a stranger to pay my friend.

BeforeGo — Sun, 01 Nov 2026 14:52:18 +0000

The plan said Coco pays Mia $75.20.

The arithmetic was right. Coco and Mia have never met. Coco wasn't even on the trip.

This is about the settle-up screen in the expense splitting I built for my travel app (BeforeGo, iOS). The problem got caught in a worked example before it shipped, and the fix is small. I still think it's worth writing up, because the textbook algorithm does exactly what it promises, and that turned out to be the problem.

Two kinds of people on a trip's bills

Most splitting apps assume everyone on a bill is in the group. On a real trip, that's not quite true:

Buddies: the people on the trip. They pay for things and split things with each other.
Others: friends back home you bought things for. If you've been to a Japanese drugstore with a shopping list from three friends, you know.

Others show up on exactly one kind of bill: one you paid on their behalf. They don't owe the group anything. They owe you.

The textbook settle-up

The usual way to settle a group's debts:

Work out each person's net: what they paid minus what they owe. Positive means they're owed money.
Pair the largest creditor with the largest debtor, transfer as much as possible, and repeat until everyone's at zero.

Each step zeroes at least one person, so with n people you never need more than n − 1 transfers. It isn't guaranteed to find the true minimum (that problem is NP-hard: it comes down to finding as many separate zero-sum groups as possible), but it's simple, it's predictable, and on a trip-sized group it's hard to beat.

Here's the version in the app, trimmed:

/// Greedy: the largest creditor takes from the largest debtor until one of them is square.
/// Scanning in roster order and replacing only on a strictly larger amount makes ties go to
/// whoever comes first on the roster.
private static func fewestTransfers(_ net: [UUID: Decimal], roster: [UUID]) -> [SettlementTransfer] {
    var credits: [(id: UUID, amount: Decimal)] = roster.compactMap { id in
        guard let value = net[id], value > 0 else { return nil }
        return (id, value)
    }
    var debts: [(id: UUID, amount: Decimal)] = roster.compactMap { id in
        guard let value = net[id], value < 0 else { return nil }
        return (id, -value)
    }

    // largest(_:) returns the index of the biggest amount; the first one wins a tie.
    var transfers: [SettlementTransfer] = []
    while !credits.isEmpty, !debts.isEmpty {
        let c = largest(credits)
        let d = largest(debts)
        let amount = min(credits[c].amount, debts[d].amount)
        transfers.append(SettlementTransfer(fromId: debts[d].id, toId: credits[c].id, amount: amount))
        credits[c].amount -= amount
        debts[d].amount -= amount
        if credits[c].amount == 0 { credits.remove(at: c) }
        if debts[d].amount == 0 { debts.remove(at: d) }
    }
    return transfers
}

The worked example

Before writing any of the money code, the design doc had one sample trip worked out with exact fractions: five bills in Tokyo, three buddies (Me, Mia, Leo) and two friends back home (Coco, Ray). Rate: 1 JPY = 0.0067 USD.

Bill	Paid by	Amount	Split
Taxi	Leo	¥3,900 ($26.13)	Me, Mia, Leo
Hotel, 5 nights	Mia	¥96,000 ($643.20)	Me, Mia, Leo
Dinner	Me	¥12,480 ($83.62)	Me, Mia, Leo
teamLab tickets	Mia	¥11,400 ($76.38)	Me, Mia, Leo
Drugstore	Me	¥19,830 ($132.86)	line by line: Coco, Ray, and a bit for me, plus a 10% shopping fee for the friends

Put everyone in one pool and the nets are:

Person	Net
Mia	+443.14
Leo	−250.31
Me	−80.00
Coco	−75.20
Ray	−37.63

They add up to zero, as they should. Run the greedy on that pool and you get:

Leo → Mia $250.31
Me → Mia $80.00
Coco → Mia $75.20
Ray → Mia $37.63

Four transfers, the minimum for this set (there's only one creditor, so each of the four debtors has to pay someone). Every number checks out.

And it's absurd. Coco would be sending money to someone she's never met, for sunscreen I bought her, including my 10% shopping fee. Meanwhile I'd pay Mia $80 instead of the $192.83 I actually owe her, because my friends back home would be covering the rest of what I owe her.

The algorithm minimised the number of transfers. Nobody had told it that money only moves between people who know each other.

The fix: two ledgers, not one

Buddies net against each other and get the fewest-transfers plan. Anyone else settles one-to-one with whoever paid their bills, and never joins the buddies' pool.

In code, it's one branch where each debt gets recorded:

func owe(_ debtor: UUID, _ creditor: UUID, _ amount: Decimal) {
    guard debtor != creditor, amount != 0 else { return }
    if buddies.contains(debtor), buddies.contains(creditor) {
        buddyNet[debtor, default: 0] -= amount
        buddyNet[creditor, default: 0] += amount
    } else if debtor.uuidString < creditor.uuidString {
        // Unordered pair → balance; positive means `low` owes `high`.
        pairs[PairKey(low: debtor, high: creditor), default: 0] += amount
    } else {
        pairs[PairKey(low: creditor, high: debtor), default: 0] -= amount
    }
}

buddyNet goes through fewestTransfers. pairs turns straight into one transfer per pair. A recorded payment ("Mark paid") goes through the same owe in the opposite direction, so it nets exactly like a bill.

Same sample, new plan:

Leo → Mia $250.31
Me → Mia $192.83
Coco → Me $75.20
Ray → Me $37.63

Still four transfers. In this example the sensible plan costs nothing extra. In general it can cost a few: if Coco owes me and I owe Mia, the pooled version can route Coco straight to Mia and save a transfer. That's a transfer worth paying for.

Pinning it down with invariants

The sample is pinned in the tests twice, settled in USD and in CNY, because every number on every mock-up came from it. On top of that, a handful of properties have to hold for any input:

private func assertInvariants(_ bills: [ExpenseSnapshot], _ settlements: [SettlementSnapshot] = [],
                              ledger: TripLedger) {
    for bill in bills {
        let breakdown = ExpenseMath.breakdown(of: bill, ledger: ledger)
        XCTAssertEqual(breakdown.shares.values.reduce(0, +), breakdown.convertedTotal,
                       "shares must add up to the bill")
    }
    let plan = ExpenseMath.settle(bills, settlements: settlements, ledger: ledger)
    XCTAssertEqual(plan.buddyNet.values.reduce(0, +), 0, "buddy nets must add up to 0")
    XCTAssertEqual(plan.net.values.reduce(0, +), 0, "everyone's nets must add up to 0")
    let outsiders = Set(plan.net.keys).subtracting(ledger.buddyIds)
    for transfer in plan.transfers {
        XCTAssertFalse(outsiders.contains(transfer.fromId) || outsiders.contains(transfer.toId),
                       "an outsider in the buddies' plan")
    }
}

The first one is the one rounding tries hardest to break. Each share is converted and rounded half-up to the settlement currency's smallest unit, and whatever the rounded shares miss of the rounded total goes to the payer. That's why the dinner splits as $27.88 for me and $27.87 each for Mia and Leo: I paid, so I carry the extra cent.

The same invariants run against the sample at rates from 0.0068 up to 149.37, and in KRW, a currency with no minor unit. The last check in that function is the Coco-and-Mia rule, written so it can't come back.

Two smaller rules came out of the same sample:

Ties go to roster order. Two people owed the same amount always come out in the same order, and shuffling the bills gives the same plan. The plan is shown on screen, exported as an image and recomputed whenever a bill changes, so it shouldn't reshuffle when nothing has changed.
No rate, no conversion. A bill in a currency with no exchange rate yet is left out of the totals and flagged. It doesn't get treated as 1:1.

What I took from it

The greedy didn't have a bug. It answered the question I asked: how do these balances clear in as few payments as possible? The question I should have asked was: who would actually send money to whom? Who knows whom is part of the input, and no amount of testing the algorithm would have shown me that.

What caught it was a worked example with real-looking names, done before the code existed. "Coco pays Mia" looks fine in a unit test full of UUIDs. Next to the sentence "Coco wasn't on the trip," it's obviously wrong.

If you've built splitting logic: how do you handle people who aren't part of the group? I'd like to know whether anyone has found a cleaner model than two ledgers.

If you want to try a group split without installing anything, BeforeGo has a free trip expense splitter that runs in the browser for one travel group.

This post was written by an AI agent (Claude) working from BeforeGo's code, design notes and tests, at my request. Every number and code excerpt in it was checked against them before publishing.

Building a baby memory book with SwiftUI

BeforeGo — Wed, 28 Oct 2026 07:47:41 +0000

A photo can show a baby's first smile. A caption can preserve what happened just before it.

That is the kind of detail I wanted Pagewren to make room for: a picture, a few words, and a page someone might want to return to years later.

I'm the developer of Pagewren, a baby memory book for iPhone. The central design decision was to put the book itself on the home screen. Add a memory, and it becomes part of the book you're already reading.

That decision also shaped some interesting engineering work.

Making each entry feel finished

The capture flow accepts photos, words, or both. Pagewren arranges the content into a page, with chapters organized around the child's age.

For a keepsake app, that immediate result matters. If saving a memory also leaves you with a layout task, there is more work waiting the next time you open it. I wanted the output of a small entry to feel complete enough to keep.

There are no daily streaks. Parents can add an ordinary moment, leave a gap, and come back later. Batch photo import helps them bring older memories into the book too.

Sharing the page renderer

Pagewren is built with SwiftUI. Its book pages use a shared BookPageView that receives the page content, the selected style, and the rendering width.

The PDF exporter uses that same view through ImageRenderer, drawing it into a PDF graphics context. Page dimensions and typography scale from the page width.

This keeps layout decisions in one place. Changing how a theme places a photograph does not require a separate implementation of that layout for export.

The rendering context still needs a few differences. A printed page has square corners. Interactive controls belong in the app. But the composition comes from the same component.

One detail that matters here is image loading. Export does not wait for an asynchronous image request to finish. The page renderer therefore receives a synchronous image source, so the photos are available when the page is drawn.

It is a small interface choice with a visible consequence: a page exported with its pictures in place.

Measuring words before splitting pages

Pagination becomes more involved once a memory can include a short caption, a long story, or a list.

Pagewren measures text using TextKit and the font and available text area for the chosen layout. A photo page has less space for words than a text page. Different themes also leave different amounts of room.

The page break follows the laid-out lines. List items and embedded elements need their own handling so they do not get split arbitrarily across pages.

For this app, measuring the actual text is much more useful than treating a page as a fixed number of characters. The visible line breaks are what determine whether the words fit.

Keeping the book on the device

The persistence layer uses Core Data, with optional CloudKit mirroring for Pro users.

The app can open the local store without enabling sync. When CloudKit cannot be initialized, the persistence controller attempts to open the same store locally. That fallback keeps the storage path centered on the book already on the phone.

There is no Pagewren account to create. Book content stays on the iPhone and, when sync is enabled, in the user's private iCloud database. Usage analytics and crash reporting are separate from the photos and writing in the book.

For the public details, see the app's privacy information on the App Store.

Letting people take the book with them

PDF export is a useful part of the product: it gives the parent a file they can save or share. Individual pages can also be shared as images.

That requirement makes the shared renderer more than a code organization preference. Exported pages are part of the experience people keep outside the app.

Pagewren is available on the App Store. It is free to download and use with the Classic theme. Pro adds themes, iCloud sync, and Privacy Lock, with monthly, yearly, and lifetime purchase options. The Pagewren website also has a free printable baby milestone card maker that runs in the browser.

I'd be interested to hear from other developers building journals or tools for personal archives: how do you keep the capture flow small while giving people something satisfying to come back to?

Using your own photo as an iPhone countdown widget background: what works, and what iOS won't let you do

BeforeGo — Sun, 18 Oct 2026 12:36:56 +0000

Short answer. Several iPhone countdown apps let you put your own photo behind the countdown. As of October 2026, Photo Countdown Widget lists your photo as the background with every widget free, and in our app, Countdown Widget: Any Event, your own photo is part of Countdown Pro. Whatever app you pick, the photo only shows on Home Screen widgets. Lock Screen widgets are drawn by iOS in a single tint, so a photo can't show there. In our app the photo shows with the Home Screen's Default or Dark look; with a Tinted or Clear Home Screen, iOS removes the widget background.

I build Countdown Widget: Any Event. Here's what I learned getting a photo to look right behind a number, in three widget sizes plus the app's own event page.

The Lock Screen won't show it, and that's iOS Lock Screen widget families (accessoryCircular, accessoryRectangular, accessoryInline) are rendered with the system's vibrant, monochrome treatment: colours are flattened, images become single-tone, and the container background is removed. So in our widget code those families draw no backdrop at all. Drawing a backdrop there would only fight the system material.

If you want your photo on the Lock Screen, set the photo as your wallpaper and put the countdown widget over it.

One photo, framed for each shape
A small widget is square, a medium one is wide, and a large one is close to square but much bigger. If you centre-crop one photo for all three, someone's face ends up cut in half in at least one of them. So the photo isn't stored as one crop. It's stored as a focus point plus a separate framing for each target: the event's own page, small, medium and large. The editor shows a preview for each one (Detail, Small, Medium, Large), and you drag the frame in each preview until it sits right, dragging its corners to resize it.
The number has to stay readable
A white number on a bright beach photo disappears. Three sliders handle that:

Opacity fades the photo into the backdrop colour.
Blur softens the detail behind the digits.
Text Contrast adds a scrim, so the text stands out without changing the photo itself.

Widgets get small JPEGs, prepared in advance
A widget extension runs with a tight memory budget and shouldn't be decoding a 12-megapixel photo. The app prepares renditions ahead of time: 1,200 px on the long edge for the event page, 690 px for widgets and 480 px for list tiles. The widget only ever loads a small JPEG.
Sync without stale pictures
The photo is stored as an attachment that syncs through iCloud. Each device builds its own renditions from it. Each rendition remembers which version of the photo it came from, so if you change the photo on your iPad, your iPhone doesn't keep showing the old one.

Doing it in Countdown Widget: Any Event

Tap Add Event and pick a ready-made event or Blank Event. For a countdown you already have, open it and tap the pencil to edit it. Then tap Backdrop.
Choose Custom, then Add Photo, and pick a photo.
In Photo adjustments, frame it in the Detail, Small, Medium and Large previews, then set Opacity, Blur and Text Contrast.
Tap Done, then add the widget to your Home Screen (Default or Dark look). Using your own photo needs Pro. Unlimited events and every widget size are free, with no ads. The app is on the App Store as "Countdown Widget: Any Event".

Christmas is the easy one: the date math behind an iPhone holiday countdown widget

BeforeGo — Fri, 16 Oct 2026 02:41:28 +0000

I make an iPhone countdown app, Countdown Widget: Any Event. Christmas is the countdown most people want this time of year — and it's the one holiday that needs no thought at all. It's December 25, every year.

Almost everything else people count down to is harder than it looks. Here are three things that turned out trickier than expected, and what fixed them.

1. "Repeat yearly" is not "add one year"

Our first version of yearly repeat did the obvious thing: when an event passes, add one calendar year. That works for birthdays and Christmas. It is wrong for Mother's Day: 9 May 2027 came back as 9 May 2028, when Mother's Day 2028 is the 14th.

US holidays are full of these. Thanksgiving is the fourth Thursday of November — November 26 in 2026, November 25 in 2027. Easter moves by weeks. Lunar New Year moves by weeks too, on a different calendar.

The fix was to stop carrying the date forward and store the rule instead:

enum AnnualRule: Hashable {
    /// The ordinal-th weekday of a month. Sunday is 1; -1 means "last".
    case nthWeekday(month: Int, weekday: Int, ordinal: Int)
    /// A fixed number of days from Western Easter Sunday.
    case easter(offsetDays: Int)
    case lunarNewYear
    case lunar(month: Int, day: Int)
}

let thanksgiving = AnnualRule.nthWeekday(month: 11, weekday: 5, ordinal: 4)

Every later occurrence is computed from the rule for that year, so it can't drift. Two details that mattered:

The raw values are frozen. The rule is saved to Core Data, CloudKit, backups and .ics exports as a string like nth:11:5:4. You can add a case, never rename one, and an unknown string falls back to plain yearly repeat instead of failing.
A year the rule can't place is skipped, not fatal. If the calendar can't resolve a lunar date for some year, the search moves to the next year rather than stopping on a date in the past.

2. All-day events should flip at midnight

A yearly birthday countdown could show "Today" in the morning and "364 days" by the afternoon. The cause: we compared instants. The stored time of day — whatever hour the event happened to be created — decided when "today" ended.

For an all-day event, the occurrence is still ahead for the whole of its own day:

func hasPassed(_ occurrence: Date, at now: Date, calendar: Calendar = .current) -> Bool {
    isAllDay
        ? calendar.startOfDay(for: occurrence) < calendar.startOfDay(for: now)
        : occurrence < now
}

All-day dates are also stored as floating dates (year, month, day — no time zone), so December 25 is December 25 wherever you are when you open the app.

3. The widget has to be told when the number changes

A widget doesn't run code all the time; it shows a timeline of entries you hand to WidgetKit ahead of time (I wrote about that in the first post). For a day count, that means one entry at each local midnight, and asking for a new timeline after the last one:

var entries = upcomingMidnights.map { entry(at: calendar.startOfDay(for: $0)) }
let reloadAt = entries.last?.date ?? now.addingTimeInterval(86_400)
return Timeline(entries: entries, policy: .after(reloadAt))

This is also why a countdown widget beats a countdown wallpaper. A number baked into a wallpaper image stays the same until you make a new image; a widget goes down by one every day on its own.

If you just want the number on your phone

Step-by-step for the Lock Screen and Home Screen — including iOS 27's new extra-large widget size — is here: Christmas countdown widget for iPhone. In our app every widget size is free on both screens and you can keep as many countdowns as you like; Pro adds backdrops, your own photos, typefaces and a Lock Screen Live Activity.

If you're comparing apps, I keep a free-tier comparison of seven countdown apps here: Best countdown widget apps for iPhone. It includes the ones that make the widget the paid part.

How iPhone countdown widgets actually work (and which apps keep them free)

BeforeGo — Wed, 14 Oct 2026 04:34:33 +0000

Disclosure: I build one of the apps mentioned below, Countdown Widget: Any Event. The comparison at the end only uses what each app says on its own App Store listing, and links to all of them so you can check.

If you have ever put a countdown widget on your Home Screen and wondered why it says "12 days" instead of ticking down the seconds, the answer is not laziness on the developer's part. It is how WidgetKit works. Once you know the rules, you can tell at a glance which apps are doing it well — and which ones lock the widget behind a paywall.

Widgets don't run code all the time

A widget is not a tiny app that runs in the background. Your app hands the system a timeline: a list of entries, each with a date and the data to draw at that date. The system renders each entry when its date arrives, and asks for a new timeline when the policy you chose says so. Reloads are budgeted, so you cannot simply redraw every second.

For a "days left" counter, the natural timeline is one entry now and one at each upcoming midnight:

func getTimeline(in context: Context, completion: @escaping (Timeline<CountdownEntry>) -> Void) {
    let calendar = Calendar.current
    let today = calendar.startOfDay(for: .now)
    // One entry now, then one at each of the next seven midnights.
    let dates = [Date.now] + (1...7).compactMap { calendar.date(byAdding: .day, value: $0, to: today) }
    let entries = dates.map { CountdownEntry(date: $0, event: loadNextEvent()) }
    completion(Timeline(entries: entries, policy: .atEnd))
}

and the view counts whole days between the start of the entry's day and the start of the event's day:

let days = Calendar.current.dateComponents(
    [.day],
    from: Calendar.current.startOfDay(for: entry.date),
    to: Calendar.current.startOfDay(for: entry.event.date)
).day ?? 0

Counting from start-of-day to start-of-day is what keeps "1 day left" from flipping to "0" at the wrong hour when the event has a time attached.

Live seconds without reloads

You can show a ticking clock in a widget — the trick is that the system animates it, not your code. Text(date, style: .timer) renders a live countdown to date and keeps it current with no timeline reloads. On iOS 16 and later, Text(timerInterval: Date.now...event.date, countsDown: true) does the same and stops at zero instead of counting back up.

The trade-off is that the format is fixed (hours:minutes:seconds), which reads badly when an event is 40 days away. A sensible pattern is days for most of the countdown and a live clock only on the final day.

The Lock Screen is a separate set of widget families

Lock Screen widgets (iOS 16+) are their own families — .accessoryCircular, .accessoryRectangular and .accessoryInline — drawn in a monochrome or tinted style. An app has to support them explicitly:

.supportedFamilies([.systemSmall, .systemMedium,
                    .accessoryCircular, .accessoryRectangular, .accessoryInline])

This is also where many countdown apps draw the line between free and paid, which matters if the Lock Screen is where you actually look.

The last few hours: Live Activities

For the final stretch before a flight or a launch, a widget is the wrong tool. A Live Activity (ActivityKit) sits on the Lock Screen and in the Dynamic Island and can be updated while it runs. It is meant for short events: the system lets one stay active for up to eight hours, and it can remain on the Lock Screen for up to four more after it ends. That makes it a good fit for "the day of", not for a countdown that lasts months.

What this means when you pick an app

Every app below can count down to a date. The real differences are in what the free version lets you put on your screens. Taken from each app's US App Store listing (September 2026):

App	Widgets in the free version	Events in the free version
Countdown Widget: Any Event (mine)	Every size, Home Screen and Lock Screen	Unlimited
Countdown Star	Home Screen widgets listed; listing doesn't spell out what is paid	Unlimited
Countdown (Find Appiness)	Home Screen, Lock Screen and StandBy widgets are Premium	Unlimited
Countdown: Event Countdown	"Next Event" Home Screen widget free; Lock Screen, multi-event and live widgets paid	Unlimited
Countdown Buddy	One basic widget free; 11 styles and more widgets paid	—

If you only need one countdown and care most about how it looks, a widget designer like Countdown Buddy is a good fit. If you keep many dates — birthdays, trips, exams — and want them on the Lock Screen without paying, check the free tier carefully before you commit.

The full comparison of seven apps — repeats, reminders, sync and ads included — is here: Best countdown widget apps for iPhone (2026), free tiers compared.