Done in 5 Days for iOS, Took 5 Weeks for macOS — AI Is so Bad at Visual UI Development

Five days for iOS. Five weeks for macOS. Same app. Same AI. Same developer.

That disparity isn’t a story about platform complexity or codebase size. It’s a story about why AI is bad at visual UI development. Because the iOS app and the macOS app share 66% of their code — the services, the models, the sync layer, the business logic. The part that’s different is the part you look at. And visual design, it turns out, is exactly what AI can’t do.

iOS: Five Days, No Drama

The Clarity.Do iOS app was built in five days. One hundred and one commits, averaging twenty per day. Each day had a clear shape: build the next feature, wire it up, move on.

The first day established the foundation — project setup, networking, authentication. The second built the core tabs: Upcoming, Priority, Plan. The third was the busiest — forty-two commits covering search, task creation, WebSocket integration, and swipe-to-delete. By day five, the app was complete.

The commit history reads like a checklist. Feature after feature, assembled and working. Almost no reverts. Almost no rework. A steady, linear march from empty project to finished app.

Why was it this fast? Because iOS doesn’t ask you to make layout decisions. Apple already made them.

A tab bar goes at the bottom. A navigation stack handles drilling into content. Safe areas are calculated automatically. List rows have standard heights. Sheet presentations slide up from the bottom. The design vocabulary is so constrained that there are almost no spatial decisions to make — where things go, how wide they are, how they sit next to each other. Apple decided, and SwiftUI enforces it.

For an AI generating code, this is ideal. The design space is narrow. The patterns are well-documented. The framework is opinionated. When you tell an AI “build a tab view with five sections, each containing a filtered list of tasks,” there’s essentially one right answer. The AI writes it, and it works.

Twelve files. 3,300 lines. Fully SwiftUI, zero platform bridging. Five days.

The macOS Reality Check

When the macOS app first launched, it looked terrible. The AI had generated visuals that looked natural on iOS — but the UI it produced for macOS looked completely wrong in a desktop window. Whatever it generated just didn’t work for a desktop app. The iOS version was eye-pleasing because Apple’s design system carried it. The macOS version was not.

The Clarity.Do macOS app needed a sidebar, a content area, and a detail panel. It needed floating windows for date pickers and parent task selectors. It needed a menu bar icon with a quick-capture popover. It needed keyboard shortcuts, window frame restoration, column width management, and a toolbar that changes based on context. Every single one of these is a spatial decision — where does it go, how wide is it, how does it behave when the window resizes, what happens when the sidebar collapses. All of these had to be figured out by a human, not AI.

AI is remarkably poor at macOS UI development. The open canvas of a desktop window — resizable, multi-panel, with no framework-imposed layout constraints — exposes every weakness in AI’s inability to reason about visual positioning. iOS hides the problem. macOS makes it unavoidable.

macOS: Five Weeks of Fixes

Over the next five weeks, the macOS app accumulated over 400 commits. Not a steady twenty per day like iOS. Volatile. Explosive. One single day produced 151 commits. Most of them were one- or two-point padding adjustments.

The pattern was always the same. The AI would generate a layout. The layout would be structurally correct — the right components in the right hierarchy, the right data flowing to the right views. But something would be off. A panel header four points too low. A sidebar icon not vertically centered. A detail view that jumped two pixels when switching from read mode to edit mode. Text baselines that didn’t align across columns.

And here’s the thing about those problems: the AI didn’t know they existed. It has no ability to evaluate visual output. It could write a .frame(width: 200) or a .padding(.leading, 8) with perfect syntax, but it had no way to judge whether 200 was the right width or 8 was the right padding. It was generating spatial relationships without any understanding of how they’d actually look on screen.

The Padding Crisis

The worst stretch lasted about a week. Over 400 commits in seven days, almost entirely focused on alignment and spacing.

The AI would fix section header padding in the Upcoming view. Then the same padding would need adjusting in the Priority view, but differently, because the content structure was different. Then the fix in Priority would reveal that the spacing convention established in Upcoming was inconsistent with the Plan view. Fixing all three would surface a mismatch in the shared TaskRowView component, which was used by all of them with platform conditionals. Fixing the shared component would break the iOS spacing that was already correct.

One file — TaskDetailsPanel.swift — accumulated 261 commits over the course of the project. That’s one-sixth of the entire codebase history, concentrated in a single file. The problem was deceptively simple: the detail panel had both a read-only mode and an edit mode. When switching between them, the content had to stay perfectly still — same font sizes, same line heights, same padding. Any mismatch caused a visible “jump.” The AI fixed it dozens of times. Each fix addressed one field while subtly misaligning another.

This wasn’t a bug the AI could reason about. It was a visual artifact that required looking at two states side by side and noticing that a label shifted three points downward. No amount of code analysis reveals that. A human has to see it.

On the busiest single day, the sidebar alone went through eleven revisions. The commit messages read like someone arguing with themselves:

Add expandable sidebar with text labels
Sidebar: bigger centered text, hide label
Sidebar: revert to left-aligned text
Refine sidebar expand with snappy animation
Fix sidebar expand: keep icon sizes

The AI was cycling through options — centered text, left-aligned text, animated expansion, static expansion — without being able to evaluate which one looked and felt right. It could implement any of them flawlessly. It just couldn’t tell which one to keep.

The same day included twenty-plus commits changing the color palette. Weightage level 0 in light mode updated, then level 1, then the two swapped, then level 2 changed to orange, then reverted. The AI was iterating on design decisions that require subjective judgment — does this orange feel too aggressive next to this blue? — without having any subjective experience to draw from.

Where SwiftUI Ends and AppKit Begins

iOS was pure SwiftUI — the AI’s comfort zone. macOS required reaching into AppKit, Apple’s older imperative framework, for things SwiftUI still can’t do: floating panels (NSPanel), menu bar icons (NSStatusItem), custom dropdown controls (NSViewRepresentable), mouse event handling, and window management.

Twenty-nine instances of AppKit bridging in macOS. Zero in iOS.

This was a different kind of struggle. AppKit’s documentation is sparse compared to SwiftUI’s. The patterns are imperative — create a panel, configure its properties, position it relative to the main window, manage its lifecycle manually. This conflicts fundamentally with SwiftUI’s declarative model, where you describe what you want and the framework figures out how. The AI had to hold both paradigms in its head simultaneously, bridging between them with hosting controllers and representable wrappers.

The floating date picker alone required calculating its position relative to the main window, synchronizing its appearance with the system’s light/dark mode, managing its delegate for dismissal, and handling z-order with other floating panels through a dedicated PanelCoordinator. Each of these is a piece of code the AI could write. Getting them all to work together, visually, required iteration that the AI couldn’t self-direct.

The Asymmetry Explained

The Clarity.Do codebase makes the asymmetry concrete:

Shared code (services, models, sync, business logic): 75 files, 13,649 lines — 66% of the codebase. AI built this quickly and accurately, across both platforms, with minimal rework.
iOS-specific code (views, navigation): 12 files, 3,292 lines. Simple, framework-guided, almost no iteration.
macOS-specific code (views, panels, AppKit bridging): 26 files, 7,293 lines. 2.2x more code than iOS for the same feature set, built over 10x the time.

The .frame() modifier — used to manually specify sizes and positions — appears 122 times in macOS code and 20 times in iOS code. Six times more manual layout work, because macOS doesn’t calculate those values for you.

The shared code was the easy part. Pure logic. Data flows in, transformations happen, data flows out. No pixels, no positions, no “does this look right?” The AI excelled here because the correctness of logic can be verified by the AI itself — does the function return the right value? Does the WebSocket message parse correctly? These are questions with deterministic answers.

The platform-specific code was where time multiplied. Not because the code was harder to write — the AI wrote syntactically correct SwiftUI on the first attempt nearly every time. But because the code’s output is visual, and visual correctness can’t be verified by reading the code. You have to run it and look.

What This Reveals About AI

AI coding tools are extraordinary at architecture. Give one a system design — sync protocol, service layer, data model, state management — and it will produce clean, working code with remarkable consistency. This is why the iOS app took five days and the web app took five hours. When the framework provides the spatial constraints and the developer provides the architectural vision, AI fills in the implementation at incredible speed.

But AI is terrible at visual UI development. It operates on tokens, not pixels. It can reason about a .padding(.top, 6) as a syntactic structure, but it has no concept of the six points of space that padding creates. It can generate a color hex value, but it has no ability to judge whether that color clashes with the one next to it. It can write an animation curve, but it cannot tell whether the motion is too fast or too sluggish.

This makes every UI adjustment a guess-and-check loop — but with only a human to do the checking. The AI guesses (.padding(.top, 8)), the developer looks at the result, says “too much,” and the AI guesses again (.padding(.top, 4)). Repeat across every view, every component, every interaction state, every screen size. Multiply by light mode and dark mode. That’s how 151 commits happen in a single day.

iOS compressed this loop to near-zero because Apple’s design system eliminated most visual decisions. macOS expanded it to five weeks because every visual decision was open.

The lesson is that AI is bad at visual UI development. And desktop interfaces — with their flexible windows, manual layouts, and design freedom — demand far more visual design work than mobile interfaces where the platform makes most visual choices for you.

What This Means for Building with AI

The Clarity.Do Apple project produced 113 Swift files, nearly 25,000 lines of code, with a fully functional iOS app, a fully functional macOS app, and real-time sync between them. AI generated the overwhelming majority of it. That’s extraordinary.

But the time distribution tells the real story. The parts AI could verify — logic, architecture, data flow — were fast. The parts only a human could verify — visual alignment, spacing, color, motion — were slow. Not because the AI wrote worse code for those parts. The code was syntactically identical in quality. The difference was entirely in the feedback loop. Architecture has fast feedback: run the test, check the output, confirm it’s correct. Visual design has slow feedback: build, run, look, judge, describe the problem in words, wait for a new attempt, look again.

The fastest path through an AI-assisted project is to maximize what the AI can self-verify and minimize what requires human visual judgment. On iOS, the platform does this for you. On macOS, you’re on your own. And that gap — between a five-day project and a five-week project — is the gap between AI as architect and AI as designer.

AI doesn’t replace the eye. It replaces the hand. And hands are fast; eyes are slow — because eyes require a human in the loop, every single time.

Clarity.Do — Plan intuitively. See clearly. Stay focused. Know what’s next.