How I Built a macOS App in 2 Weeks with Claude Code

I built NotchWise, a macOS app that puts flashcards in the MacBook notch, in about two weeks as a solo developer. Here's how.

This isn't a tidy "everything went to plan" story. There were four App Store rejections, a complete rethink of the payment system halfway through, and a moment where I realised I'd been building keyboard shortcuts using APIs Apple considers accessibility features. But the app shipped and the tests pass.

Why the MacBook Notch?

The notch on modern MacBooks is dead space. It sits there, eating into your screen real estate, doing absolutely nothing. Meanwhile, anyone who's used Anki knows the consistency problem: you have a deck of 200 cards, you know spaced repetition works, but you keep skipping days because opening a dedicated study app feels like a commitment.

The insight was simple. You don't need dedicated study time. You need reviews woven into your existing workflow. What if every time you glanced at the top of your screen, there was a flashcard waiting? Not a full study session. Just one card, taking five seconds to review, then it disappears back into the notch.

The best spaced repetition system is the one you actually use. And the easiest one to use is the one that's already in your line of sight.

That's the core idea behind NotchWise. Ambient spaced repetition. The notch expands on hover, shows you a card, you rate your recall, and it collapses. Five seconds. No context switching. No "I'll do my reviews later." The card comes to you.

The Stack

I wanted to keep the dependency count low. macOS doesn't have the same ecosystem as iOS. Fewer packages are actively maintained, and you pay for every dependency in binary size and maintenance burden.

• Swift + SwiftUI: The obvious choice for a modern macOS app. SwiftUI's declarative model made the notch UI straightforward to build, especially the expand/collapse animations.
• DynamicNotchKit: An open-source library by MrKai77 for managing notch-anchored windows. This saved weeks of reverse-engineering Apple's notch geometry. It handles the window positioning, the rounded corners, and the transition between compact and expanded states.
• GRDB.swift: SQLite via a Swift wrapper. I needed a local database for flashcards, scheduling data, and review history. Core Data felt like overkill. GRDB gives you raw SQL when you want it and type-safe queries when you don't.
• SM-2 and FSRS: Two spaced repetition algorithms. SM-2 is the classic (it's what Anki uses under the hood). FSRS is the newer one that adapts to individual learning patterns. NotchWise implements both: SM-2 for free users, FSRS for Pro.

The target was macOS 14 (Sonoma) and later. This let me use the Observation framework (@Observable instead of ObservableObject) and modern Swift concurrency features throughout.

The Orchestration System

I used Claude Code as my development partner. The main challenge with AI-assisted development is context. A coding agent doesn't remember what it did yesterday. It doesn't know which features are done, which are blocked, or what decisions were made three sessions ago.

My solution was a set of four plain-text files that act as the project's memory:

• CLAUDE.md: The instruction manual. Defines an 8-step session protocol (orient, verify, identify, implement, validate, commit, update context, final commit). Every session follows the same sequence.
• REGISTRY.md: A component registry mapping every Swift file to its purpose and dependencies. The agent reads this instead of guessing how things connect.
• PROGRESS.md: A session log. After each session, the agent writes what it did and what decisions it made. This is the project's memory.
• HANDOFF.md: A structured handover note. It tells the next session what's working, what's broken, and what to do next.

The most important file was notchwise-progress.json: a JSON file listing all 40 features with acceptance criteria and a simple passes: true/false status. The rule was strict. You can only change false to true. You can't edit descriptions, reorder features, or remove anything. This prevented the kind of scope drift where an AI agent "simplifies" the project by quietly dropping features.

The one-feature-per-session discipline was critical. Each Claude Code session picked up exactly one feature, implemented it, tested it, committed it, and updated all context files. No multi-feature sessions, no "let me just quickly refactor this other thing." Atomic progress.

The Numbers

By the time NotchWise was ready for submission:

• 40 features across 4 phases (Foundation, SRS Engine, Workflow, AI + Sync)
• 781 tests: unit tests for the scheduling algorithms, integration tests for the database layer, UI tests for the notch interaction
• ~15 Claude Code sessions spread across about two weeks
• 4 phases: each phase gated behind all features passing before merging to main

The session protocol (orient, identify, implement, validate, commit, update context) meant that every session started productive within minutes. No "where was I?" fumbling. The agent reads the handoff, checks the progress tracker, picks the next feature, and goes.

The App Store Saga

Building the app was the straightforward part. Getting it past App Store Review? That was humbling. Four rejections. Each one a lesson I could've learned by reading more carefully, but apparently I needed to learn the hard way.

Rejection 1: External payment links. I'd originally integrated LemonSqueezy for payments, a simple checkout link for the Pro upgrade. Apple's Guideline 3.1.1 says no. If your app sells digital content, you use StoreKit. No exceptions, no external links, no "buy on our website" buttons. I ripped out LemonSqueezy and implemented StoreKit 2. Lesson learned.

Rejection 2: Apple trademark in subtitle. My subtitle said something like "Flashcards in your MacBook notch." Turns out Guideline 5.2.4(iv) prohibits using Apple trademarks (including "MacBook") in your app's metadata. A one-line fix, but it cost me another review cycle, about 48 hours of waiting.

Rejection 3: Accessibility API misuse. This one stung. I'd used NSEvent.addGlobalMonitor for keyboard shortcuts, which requires the Accessibility permission. Guideline 2.4.5 says you can't use Accessibility APIs for non-accessibility purposes. The fix was switching to NSEvent.addLocalMonitor, which works within the app's own windows without system-wide permissions. Functionally identical for my use case. The review team was right. I didn't need global monitoring.

Rejection 4: Paid Apps Agreement not set up. This one was embarrassing. I hadn't completed the banking and tax forms in App Store Connect before submitting a paid app. Apple can't sell your app if they don't know where to send the money. A 10-minute form I should've filled out before the first submission.

Each rejection came with a roughly 48-hour review cycle. Four rejections meant about 8 extra days from first submission to approval. If you're about to submit your first app: read the guidelines cover to cover, set up your App Store Connect account completely, and don't assume anything about what APIs you're allowed to use.

What I'd Do Differently

If I were starting NotchWise from scratch, here's what I'd change:

• Design feature gating from day one. I added the free/Pro split late in development, which meant retrofitting access controls into code that assumed everything was unlocked. If you're planning a freemium model, build the gate before you build the features behind it.
• Set up Paid Apps Agreement before first submission. Don't lose a review cycle to paperwork. Fill out every form in App Store Connect the day you create your app record.
• Don't use Accessibility APIs for non-accessibility purposes. Even if it works, even if it seems harmless, Apple will catch it and reject you. Find the non-privileged API that does what you need.
• Test on both notch and non-notch Macs early. DynamicNotchKit behaves differently on hardware with a physical notch versus a virtual notch. I discovered some edge cases late that would have been trivial to fix earlier.

The Methodology as a Reusable Workflow

The most transferable part of this project isn't the code. It's the context management approach. The 4-file system (instructions, registry, progress log, handoff) works for any AI-assisted development project. The key principles:

• Make the feature list immutable. The AI can mark things done but can't change what "done" means.
• One feature per session. Atomic progress prevents the drift where you end up with five half-finished features.
• Every session starts by reading context. Orientation before implementation.
• Every session ends by writing context. The next session shouldn't have to guess what happened.

It's project management for solo developers working with AI. Simple enough to follow every time, structured enough to prevent the chaos that kills side projects.

Try It