Posts on Swift.
12 posts tagged "Swift".
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.
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.
The accessibility gate that made stacking five motion effects into one PR survivable
Phase D of the Cursed Energy DNA landed sigil rotation, energy pulse, claim spark, level-up celebration, and streak milestones in a single PR alongside three other features. Accessibility review was a non-event — not because the PR was small, but because every motion effect owned its own gate.
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.
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.
accessibilityReduceMotion should be a contract. Phase D made it one.
Phase D of an iOS budget app Cursed Energy feature adds five animated layers across sigil, energy, claim, level-up, and streak milestone surfaces. Every one checks accessibilityReduceMotion before firing — a hard gate, not a hint. The uniformity was a rule established on the first addition and held through to the fifth.
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.
The dedup layer had three hash schemes. CDImportSource replaced them — and four banks validated with zero per-bank code.
The an iOS budget app import layer had three coexisting hash schemes with no shared contract between them. Collapsing them into CDImportSource — a unified source-attribution model — was the structural prerequisite for universal CSV and PDF parsers that validated across Monzo, Halifax, Revolut, and HSBC.
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.
Five features, one PR: how an iOS budget app ships concurrent phase work without a merge queue
On 2026-06-14, five feat entries landed in an iOS budget app across Phases C, D, and E — all tagged 'same PR #10.' Treating commits as the concurrency primitive instead of branches let three phases advance in parallel without a merge queue or conflict chain.
Five features, one PR: the two shared-state promotions that had to come first
PR #10 for an iOS budget app bundled a palette picker, a motion layer, a streak milestone overlay, a category-budget quest, and a save-target preference into a single side branch. Getting them to co-exist required promoting BBPalette.current and UserProfileStore before the features could be wired.