DEV Community: Bryan

I shipped my first iOS app, got rejected twice, and built a tool so it never happens again

Bryan — Fri, 12 Jun 2026 17:36:02 +0000

The code was never the hard part. The App Store review was.

I shipped my first iOS app — a small baby tracker — and got rejected twice. Not for bugs. Not for crashes. For things I literally couldn’t see: a privacy-label mismatch I didn’t know existed, and EULA/paywall wording that wasn’t where Apple wanted it. Each rejection meant a 24–48h wait, a fix, a resubmit, and another wait.

The frustrating part wasn’t the rejection. It was that every reason was already sitting in my build and my App Store Connect metadata the whole time. Nothing just cross-references them and tells you “hey, this will bounce.”

So I started pulling my own builds apart to understand what Apple actually looks at. Here’s what I learned — and the Swift to do it yourself.

An .ipa is just a ZIP

That’s the first thing that clicks. Rename it, unzip it, and you get:

Payload/
YourApp.app/
Info.plist
PrivacyInfo.xcprivacy
embedded.mobileprovision
Frameworks/
SomeSDK.framework/
PrivacyInfo.xcprivacy

Everything Apple’s automated checks care about is in there. If you build with Xcode, the .xcarchive in ~/Library/Developer/Xcode/Archives has the same .app bundle under Products/Applications/ — and it exists before you export an .ipa, so you can inspect it earlier.

Reading Info.plist (it’s binary)

A common gotcha: the Info.plist inside a shipped build is usually in binary format, not XML. In Swift, PropertyListSerialization handles both transparently:

let plistURL = appURL.appendingPathComponent("Info.plist")
let data = try Data(contentsOf: plistURL)
let info = try PropertyListSerialization
.propertyList(from: data, format: nil) as? [String: Any] ?? [:]

Now you can check the things that quietly get apps rejected. The classic one is empty or placeholder usage strings (Guideline 5.1.1):

for (key, value) in info where key.hasSuffix("UsageDescription") {
let text = (value as? String ?? "").trimmingCharacters(in: .whitespaces)
if text.count < 10 || ["todo", "test", "xxx"].contains(text.lowercased()) {
flag(.error, "5.1.1", "(key) is empty or placeholder")
}
}

I shipped a NSCameraUsageDescription that literally said “TODO” once. Don’t be me.

Another cheap win: ITSAppUsesNonExemptEncryption. If it’s missing, you get the export-compliance question on every submission, which slows you down.

The privacy manifests (the modern rejection magnet)

Since May 2024, third-party SDKs that use “required reason APIs” must ship a privacy manifest (PrivacyInfo.xcprivacy). Missing ones are a top rejection reason now. They live at the app root and inside each .framework, so you walk them recursively:

let frameworksURL = appURL.appendingPathComponent("Frameworks")
let frameworks = (try? FileManager.default.contentsOfDirectory(
at: frameworksURL, includingPropertiesForKeys: nil)) ?? []

for framework in frameworks where framework.pathExtension == "framework" {
let manifest = framework.appendingPathComponent("PrivacyInfo.xcprivacy")
if !FileManager.default.fileExists(atPath: manifest.path) {
flag(.error, "privacy", "(framework.lastPathComponent): no privacy manifest")
}
}

The part that actually matters: the cross-check

Here’s the insight that turned this from “a checklist” into something useful.

A static checklist can tell you “you should declare your data collection.” It can’t tell you that your specific build contains an SDK that collects data you forgot to declare. That requires crossing your build with your App Store Connect metadata.

Concrete example: RevenueCat’s privacy manifest declares it collects Purchase History:

let manifestData = try Data(contentsOf: manifest)
let m = try PropertyListSerialization
.propertyList(from: manifestData, format: nil) as? [String: Any] ?? [:]

let collected = (m["NSPrivacyCollectedDataTypes"] as? [[String: Any]] ?? [])
.compactMap { $0["NSPrivacyCollectedDataType"] as? String }
// -> ["NSPrivacyCollectedDataTypePurchaseHistory"]

If that data type is collected by an SDK in your binary but missing from your App Privacy labels in App Store Connect (which you can read via the App Store Connect API, read-only), that’s an instant Guideline 5.1.1 rejection — and one you’d never catch by eye. That mismatch is the whole game.

Deterministic vs subjective

One honest distinction I had to make: not all rejections are catchable from static analysis.

Deterministic (always catchable): missing privacy manifests, undeclared SDK data, empty usage strings, export compliance, metadata mismatches. These never vary by reviewer.
Subjective (reviewer-dependent): design judgments, “spam”, perceived value. No tool can predict these honestly.

Anyone claiming to predict the second bucket is selling you something. The first bucket, though? That’s the stuff that quietly wastes your week, and it’s 100% catchable before you ever hit “Submit.”

I packaged this into a tool

I ended up turning all of this into a small native macOS app called Cleared — you drop in a build, it parses it locally, pulls your App Store Connect metadata read-only, and flags the deterministic rejection reasons before you submit. It runs fully on-device (the AI explanations too — no key, nothing leaves your Mac).

But honestly, the point of this post isn’t the tool. It’s that most App Store rejections are predictable, and you already have everything you need to catch them — it’s sitting in your .ipa right now.

If you ship iOS apps: what’s the rejection that burned you the most? I’m still adding checks based on real ones.

(If you want to try the tool: cleared.sakaax.com — but the parsing above works on its own too.)

I built img-pilot: the first Claude Code plugin that generates AI images from your terminal

Bryan — Thu, 16 Apr 2026 21:26:34 +0000

Every time I ship a side project, I spend 3 hours on brand assets I don't care about. Logo. Favicon 16 and 32. Apple touch icon. OG image. Twitter card. Discord embed. GitHub banner. iOS icon. Android icon. Different sizes, different crops, same logo.

Each one is a browser tab, a prompt I'll throw away, a manual copy-paste, a resize in Figma.

So I built img-pilot — the first Claude Code plugin that generates AI images from your terminal. And because I refuse to pay for eight API calls when I only need the first one, I built a cost optimizer that derives every variant locally.

One API call. Eight assets. Nine providers.

What it actually does

From inside Claude Code:

/img-pilot logo

That triggers four phases:

Claude reads your context — if you have ux-pilot or brand-pilot installed, it parses their brief files. Otherwise it runs a 6-question discovery (ABCD + free text) and writes img-pilot/brief.md for future runs.
Claude builds the prompt — from the brief, your brand vocabulary, your target provider's strengths. Not a generic "make me a logo" — a real production prompt.
The cost optimizer picks the cheapest path — this is the interesting bit. More below.
Dry-run confirmation — you see the plan (provider, exact prompt, cost estimate in USD) and type yes before a single byte goes out.

The cost-optimizer trick

Before every asset request, the optimizer walks a decision tree:

Stop shipping ugly AI apps: I built a CLI to fix brand & SEO issues

Bryan — Wed, 15 Apr 2026 18:35:58 +0000

I kept noticing the same pattern with AI-generated apps.

They work.
But they look... off.

Colors drift
Components are inconsistent
SEO is half-broken
Branding feels random

So I built something to fix that.

Introducing Brand Pilot

Brand Pilot is a CLI tool that scans your project and detects brand and SEO issues directly from your terminal.

No dashboards. No setup. Just run a command.

👉 Check it out: https://brand-pilot.sakaax.com

👉 GitHub repo: https://github.com/Sakaax/brand-pilot

What it does

Audits brand consistency (colors, fonts, components)
Detects SEO issues (meta tags, OG, structure)
Generates README, OG images, and brand kits
Works locally (no API, no telemetry)

Example


bash
/brand-pilot audit

I built a UX co-pilot for Claude Code — 376 rules, live preview, zero AI slop

Bryan — Wed, 01 Apr 2026 15:29:41 +0000

The problem

Every time I asked an AI to design a UI, I got the same output:

Inter font
Purple gradient on white background
Centered hero with a subtitle and a button
"Here's V1, V2, and V3"

It looked... fine. But it looked like everything else. No personality, no UX thinking, no understanding of what the product actually needed.

## The idea

What if the AI could ask questions first before generating anything?

What if it understood that a fintech dashboard needs different UX rules than a restaurant landing page? That a dev tool should use monospace fonts and dark mode, not pastel gradients?

That's what I built.

## Meet ux-pilot

ux-pilot is a free, open-source plugin for Claude Code that acts as a senior UX designer inside your terminal.

Instead of generating code directly, it runs a structured discovery flow — asks about your product, users, business model, and design preferences — then applies the right rules from a
library of 376 UX rules.

### The 4 phases

1. Discovery
The plugin asks questions one at a time (ABCD choices + free text). It adapts — if you're building a CLI tool, it skips pricing/funnel questions. If you give detailed answers, it infers
what it can and moves faster.

Output: a structured UX Brief.

2. Audit
Already have code? The plugin scans it. It detects your framework (Next.js, React, Vue, Svelte), checks routes, HTML structure, forms, accessibility, SEO, mobile. Produces a scored report
with findings by severity.

3. Preview
Opens a local server with hot reload (SSE). Generates screens in vanilla HTML/CSS. For each screen, proposes 2-3 named versions — not V1/V2/V3, but descriptive names like "Classic",
"Bold", "Minimal". You approve, reject, or comment.

4. Export
Generates a complete UX spec in markdown. Optionally converts approved screens to React, Svelte, or Vue components.

## 376 rules, loaded on-demand

The rules are organized in 6 categories:

UX Patterns (10 files) — accessibility, forms, navigation, layout, typography
Conversion & Funnel (7 files) — CTA, pricing, signup, 34 landing patterns
SEO & AEO (5 files) — structure, schema.org, AI citation optimization
Psychology (4 files) — social proof, cognitive load, trust, persuasion
Aesthetics (4 files) — anti-AI-slop, typography craft, 67 UI styles
Product Type (1 file) — 30 product-specific recommendations

Key design decision: rules are never loaded all at once. When you're designing a landing page, only landing-patterns, cta, seo, aesthetics, and social-proof rules are loaded. This
saves tokens and improves accuracy.

## The anti "AI slop" feature

This was the main motivation. The plugin has explicit rules against generic AI output:

Banned:

Inter, Roboto, Arial, system fonts
Purple gradients on white backgrounds
Cookie-cutter layouts
V1/V2/V3 version naming

Instead:

Distinctive fonts with weight extremes (200 vs 800)
3x+ size jumps between heading and body
Gradient meshes, noise textures
Descriptive version names

## Built-in data

Beyond rules, the plugin ships with curated design data:

161 color palettes — industry-specific
57 font pairings — Google Fonts with mood tags
67 UI styles — with use cases and CSS hints
30 product types — with landing patterns and anti-patterns

## The meta flex

The landing page for ux-pilot was designed using ux-pilot itself. The plugin ran the discovery, chose the typography (Newsreader + Space Grotesk + JetBrains
Mono), picked the terracotta accent, and generated the structure.

## Try it


bash
  /plugin marketplace add Sakaax/ux-pilot
  /plugin install ux-pilot@ux-pilot
  /ux-pilot

  - Landing: https://ux-pilot.sakaax.com
  - Demo: https://ux-pilot.sakaax.com/demo.html
  - GitHub: https://github.com/Sakaax/ux-pilot
  - Product Hunt: https://www.producthunt.com/products/ux-pilot-2

  Free, MIT licensed, open source. Feedback welcome — especially on the rule set and the discovery flow.