Posts on BB Finance.
14 posts tagged "BB Finance".
The back-nav went to Accounts. It should have gone to the calendar.
Weeks of Accounts build work passed SwiftUI preview on every check. The first hands-on device install found gaps the simulator had never reported. Round two found a navigation bug — Back from Day view landed in Accounts, not the calendar — that the simulator had never seen.
The check-in button opened a transaction form: how three device-QA bugs made bb-finance's Home gamification navigable
The three Home gamification blocks in bb-finance — Quests, Level, Streak — were pulling live data and doing nothing else. Tapping the Streak check-in opened the transaction form instead. Three bugs from the AnF device-QA round forced Phase N, which built the detail screens and routing that turned the blocks from decoration into navigation.
Back from the day view landed on Accounts — the simulator had nothing to say about it
Phase O added a full-screen month calendar inside the Accounts tab, taking the navigation to three levels. Round-2 device QA found A8: tapping Back from a day view vaulted over the calendar entirely and returned to the Accounts screen. The simulator had approved the same flow without complaint.
Calendar → Day → Back Landed on Accounts. The Stack Was Correct; the Model Wasn't.
A8 in the round-2 device QA pass: tapping Back from the day view skipped the full-screen calendar and landed on Accounts. The NavigationStack had done nothing wrong. The navigation model had no concept of levels.
One PR, three game systems: why pure generators kept the ledger honest
Shipping streaks, quests, and levels as a single PR forced a specific architecture: pure generators with no side effects, persisted targets decoupled from quest logic, and celebration overlays computed after state transitions. This is the constraint that produced those decisions.
Real quests, broken buttons: how Phase C and N closed bb finance's behaviour loop
Phase C replaced mockQuests with a generator that reads real transaction history. Phase N found that the quest blocks were non-interactive labels and the streak's Check In button opened the wrong screen. Both sprints were necessary. Only together did they close the loop.
Five animations, five accessibility gates: what Cursed Energy Phase D cost to ship correctly
Phase D of the Cursed Energy design system added five animated effects to bb finance: sigil rotation, energy pulse, claim spark, level-up celebration, and streak milestone overlays. Every one is gated by the SwiftUI Reduce Motion environment key. Gating from the start rather than retrofitting later cost extra environment reads on every animated view. What it bought was a WCAG 2.1 AA clean bill before any user encountered the animations.
I had the Accounts calendar scoped as one level. Mid-design I deepened it to three.
Phase K shipped a horizontally-scrollable daily-activity strip on the Accounts screen. Phase O was meant to replace it with a calendar — I had a compact, single-level surface already scoped. Mid-design I deepened the ask to full-screen plus day mode, and a back-nav regression in round-2 device QA explains why that was the right call.
The Accounts screen took four iterations. Each one bought fidelity by spending scope.
Sprint 2 shipped a SwiftUI list with CRUD. Phase K rebuilt it into a module stack with a trend chart and activity strip. Phase O turned the strip into a three-level calendar flow. Round-2 device QA on AnF found the back-nav bug that came with it.
Four quest types. None of them read your transactions.
An iOS budget app shipped a gamification layer backed by a hardcoded mock array. Phase C replaced it with QuestGenerator — a pure function that derives up to four quests per day from real transaction history. What changed wasn’t the number of quests. It was whether the quests knew anything about the user.
The Accounts calendar strip passed every preview check. On my test iPhone, it answered the wrong question.
The Phase K Accounts screen shipped with a horizontally-scrollable calendar strip. Device QA on my test iPhone showed it was answering the wrong question, so mid-design I deepened Phase O to a three-level navigation flow: inline calendar, full-screen month view, day mode. SwiftUI preview had nothing to say about any of it — the back-nav regression that followed only surfaced under a real thumb.
Five sprints inside one PR: what an iOS budget app's side-branch pattern reveals about tracking
PR #10 on an iOS budget app landed five complete features in a single merge. Each devlog entry reads as a self-contained sprint brief with its own type, its own boundary, its own completion signal. PR-level granularity and feature-level granularity are not the same number.
Cursed Energy Phase C: wiring an iOS budget app's quest system to real transaction history
The an iOS budget app gamification layer had quest cards, a claim button, and a streak counter. None of it read from actual spending. Replacing a hardcoded array with a transaction-aware QuestGenerator turned decorative chrome into a feedback loop that surfaces real patterns.
Device QA found three regressions. The simulator had approved them all.
Round-2 device QA on bb finance flagged a navigation stack popping two levels instead of one, ProMotion locked at 60Hz on a 120Hz panel, and category rules over-reaching on shared word fragments. None of them showed in the simulator.