Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.swiftaiboilerplate.com/llms.txt

Use this file to discover all available pages before exploring further.

Apple reviews change. This page reduces the patterns reviewers cite most under Guideline 4.3; it does not guarantee approval. Treat it as a checklist, not a legal opinion.

​
What 4.3 actually says

Apple’s Guideline 4.3 (Spam) has two parts. 4.3(a) says don’t ship multiple Bundle IDs of the same app. 4.3(b) says don’t pile into a saturated category without a unique, high-quality experience. There’s a related rule, 4.2.6, about apps “created from a commercialized template or app generation service.” Reviewers don’t always cite the sub-letter. When they say “4.3,” they usually mean one of three things they noticed:
  1. Your binary, listing, and screenshots look too similar to another app already on the store.
  2. Your product is functionally identical to a known template (same screens, same flows, same strings).
  3. The category is saturated and your app doesn’t show a clear reason to exist.

​
Shared architecture is fine. Undifferentiated product is not.

Thousands of apps share UIKit, SwiftUI, RevenueCat, Supabase, and OpenAI. Apple knows this. What gets flagged is when the product, listing, and binary fingerprint all look like a copy of something else. Your job before submitting:
  • Keep the architecture (it’s yours now anyway).
  • Replace every user-visible string, asset, and flow that screams “boilerplate.”
  • Lead your App Store listing with your hero feature, not a generic chat screen.
  • Strip dead code that ships in the binary and exposes the boilerplate’s name.

​
The five things to do before you hit “Submit”

1

Run a Release `strings` audit on the .ipa

Reviewers don’t run strings, but their automated checks compare binary fingerprints. Anything that ships in your Release .ipa can match boilerplate fingerprints.
# Build a Release archive in Xcode, then export the .ipa
unzip -o YourApp.ipa -d /tmp/yourapp
strings /tmp/yourapp/Payload/YourApp.app/YourApp \
  | grep -i -E "swiftai|boilerplate|swiftaiboilerplate|featurechat|placeholder|TODO" \
  | sort -u
If the output contains the boilerplate’s product name, package names you didn’t rename, or stub strings, fix the source and rebuild. Don’t ship an .ipa whose strings give away its origin.
2

Remove dead Swift files from the app target

Files that aren’t referenced by your app’s UI but are still in the app target still compile into the binary. That includes example views, sample data, and demo flows you replaced.Open Xcode → Project navigator → check Target Membership for every file in Features/, Examples/, and any *Sample*.swift. Anything you don’t use, remove from the app target (you can keep the file on disk if you want it for reference).See the per-module removal notes in docs/checklists/APP_STORE_4_3_HARDENING.md in your distribution repo. There are coupling rules: removing FeatureChat without also pruning AI module entry points leaves orphaned code paths that show up in the binary.
3

Rebrand every user-visible string

Search the codebase for the boilerplate’s product name and replace it everywhere a user can see it: launch screen, onboarding, settings, paywall, push copy, error toasts, support email, About screen, legal pages.
# In your project root
rg -i "swiftai|boilerplate" \
  --type swift --type strings --type plist \
  --glob '!**/Tests/**' --glob '!**/.build/**'
Build your branding map before you start: old name → new name, old bundle ID → new bundle ID, old support URL → new support URL. Apply it once. Don’t leave half-renamed files.
4

Lead App Store screenshots with your hero, not the chat tab

The boilerplate ships a chat-first home. If your app is a parking helper, a meal planner, or a study tool, chat is not your hero. Reviewers see five other AI-chat apps a day; if your first screenshot is “AI chat with bubbles,” you’re invisible.First screenshot: the screen that shows what your app actually does (parking spot map, meal of the day, flashcard review). Second screenshot: the differentiated outcome. Chat, if it appears at all, comes after.
5

Read the module removal notes before you delete anything

If you remove FeatureChat, you also need to prune AI entry points (the chat view model is the largest consumer of the AI client). If you remove Payments, you need to remove paywall presentation hooks from FeatureSettings. Removing one module without its couplings leaves dangling symbols in the binary, which reviewers’ tooling can fingerprint.The full per-module table, including which symbols to grep for and what to delete, is in docs/checklists/APP_STORE_4_3_HARDENING.md. Pair it with the buyer-facing prompts in docs/prompts/AppStore4_3Hardening.prompts.md.

​
Pre-submit checklist

  • strings on the Release .ipa returns no swiftai, boilerplate, placeholder, or stub matches
  • Bundle ID is yours, not the boilerplate’s
  • No demo or sample files are in the app target’s Compile Sources
  • Removed modules have their couplings pruned (see module table)
  • Branding map applied: name, support email, URLs, paywall copy
  • Onboarding pages reflect your product, not generic AI-chat copy
  • Settings → About shows your company, your URLs, your version
  • Push notifications and email templates use your wording
  • First screenshot leads with your hero, not the chat screen
  • App name and subtitle describe your product, not “AI chat”
  • Description’s first line answers “what does this app do for me”
  • Privacy policy and terms hosted at your domain (not boilerplate’s)
  • You explain in plain language what the app does and who it’s for
  • You credit the architecture honestly if asked, while making clear the product, content, and listing are yours
  • Demo account credentials work and have realistic data

​
Example LLM cleanup prompt

Paste this into Claude Code, Cursor, or your editor’s AI chat after you’ve branched off main. It runs the heavy renaming pass and flags couplings before you submit. 
You are auditing an iOS app for App Store Guideline 4.3 (Spam) and 4.2.6
(template apps) before submission. The app is built on SwiftAI Boilerplate
Pro; the architecture is shared with other apps, which is fine. The goal
is to remove undifferentiated product, listing, and binary fingerprints.

Do these passes in order. After each pass, print a short report and wait
for me to confirm before continuing.

Pass 1: Branding map.
- Search the repo (excluding Tests, .build, Pods, DerivedData) for any
  occurrence of: "SwiftAI", "Boilerplate", "SwiftAIBoilerplatePro",
  "swiftaiboilerplate.com", boilerplate support email, boilerplate
  bundle ID prefix.
- Output a table: file path, line, old token, suggested replacement
  using my product name "<MY_APP_NAME>" and bundle ID "<MY_BUNDLE_ID>".
- Do not edit yet. Wait for me to confirm.

Pass 2: User-visible strings.
- Once I confirm, apply the renames from Pass 1 only to user-visible
  strings: .strings files, Localizable, SwiftUI Text(...), accessibility
  labels, push payload templates, email templates.
- Leave Swift type names, package names, and folder names alone unless
  I tell you otherwise.
- Print a diff summary.

Pass 3: Dead app-target code.
- List every file in the **app target's** Compile Sources whose symbols
  aren't referenced from any view that appears in the running app's
  navigation graph. Include sample data, example views, and demo
  flows.
- Output the candidate removal list. Do not delete; I'll review.

Pass 4: Module coupling check.
- If FeatureChat is being removed, list every reference to its public
  types from outside the FeatureChat package, especially in the AI
  module's clients and CompositionRoot.
- Same for Payments → FeatureSettings paywall hooks.
- Output a "blocking removals" list with file:line references.

Pass 5: App Store listing review.
- Read the screenshots referenced in /AppStoreAssets (or wherever I
  point you) and the App Store description draft if I paste one.
- Tell me: does the first screenshot lead with the hero feature?
  Does the description's first sentence answer "what this app does
  for me"? Where does it still sound like a generic AI-chat
  template?

Constraints:
- Don't invent files or symbols. If you can't find something, say so.
- Don't claim the app will pass review. Your job is to reduce the
  patterns reviewers commonly cite under 4.3 / 4.2.6.
- Stop after each pass and print a short summary.

​
If you already got a 4.3 rejection

Don’t panic, and don’t argue with the reviewer in the first reply.
1

Read the rejection literally

Apple’s message usually quotes the guideline number and points at one or two specific things: a screenshot, a string, a flow, or a binary similarity. Treat that as the entire problem statement, not a hint at a wider issue.
2

Run the five passes above

Even if the rejection mentions only one thing, run the full audit. Reviewers compare binaries; if one fingerprint matched, others probably did too.
3

Reply in App Review with what changed

In App Store Connect → Resolution Center, write a short reply: what you changed, why your app is differentiated, and a one-paragraph plain-language description of what users do with it. Resubmit a new build with a bumped build number.
4

If you disagree, request a call

If you’ve done the work and still believe the rejection is wrong, you can request a phone call through App Review. Show up with your branding map, screenshots, and a clear answer to “who is this for and what makes it different.” Don’t argue the guideline; argue the facts.

​
What a boilerplate can’t guarantee

Honest version: a boilerplate can save you weeks of plumbing. It can’t tell Apple your app is differentiated, because that’s a judgment call about your product, your listing, and your category. The patterns above are the ones reviewers cite most often. They don’t cover product-market fit, content quality, or whether your category is genuinely too crowded. If your idea is “a chat app with a different color scheme,” no checklist will save you. If your idea is a real product that happens to use a chat interface, this checklist removes the noise so reviewers can see it.

Building Your App

Branding, backend, and feature customization

Deployment Guide

TestFlight and App Store submission steps

Customization Recipes

Colors, themes, onboarding, and modules

Apple Guideline 4.3

Read Apple’s wording directly