{
  "id": 2807685,
  "title": "Most App Store Rejections Aren't About Your Code",
  "url": "https://urgent.news/2026/08/23/most-app-store-rejections-arent-about-your-code",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-23T14:23:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/maclessdev/most-app-store-rejections-arent-about-your-code-3p75"
  },
  "original_language": "en",
  "account": "Over the years, I've observed a recurring pattern when it comes to App Store rejections. The majority of the time, the app is not rejected due to a broken feature or code issue. Instead, it's usually because of an issue with the app's metadata. There are three main examples I've encountered repeatedly.\n\nFirstly, missing or vague privacy details. Since iOS 17, Apple now scrutinizes the PrivacyInfo.xcprivacy manifest file to compare it with the actual APIs your app and any third-party SDKs utilize. If you're using UserDefaults, disk space checks, or system boot-time calls without properly declaring the corresponding required reason API category, it will be flagged during review. This has nothing to do with whether your app crashes or not; it's simply a mismatch in the paperwork.\n\nSecondly, a screenshot that doesn't match the actual UI of the app. Reviewers compare the screenshots you submit with what the build looks like on first launch. If you redesign a screen and forget to update one of the screenshots, you will receive a Guideline 2.3.3 rejection. The fix here doesn't require any code changes; you only need to update the screenshots.\n\nLastly, an unclear permission usage string. If an app states \"This app needs your location\" without providing a specific reason, it's rejected under Guideline 5.1.1. Apple prefers a more precise explanation, such as \"used to show nearby stores.\" Again, this is a simple string change in the Info.plist file, with no need for any code modifications.\n\nAcross all these cases, the key takeaway is to carefully read the specific line in the rejection message before panicking and starting to debug your build. Most of the time, the solution is just a sentence of text or a missing manifest entry, rather than an afternoon spent in Xcode.\n\nIt's also important to note that despite the build process happening without a Mac, using GitHub Actions macOS runners for build, signing, and upload via a pipeline called Macless, the metadata side of review remains the responsibility of the app developer. Understanding this distinction can save a lot of unnecessary debugging efforts.",
  "summary": "I've shipped enough iOS apps at this point to notice a pattern in App Store rejections. The app almost never gets rejected because something is broken. It gets rejected because of something in the metadata. Three examples I keep running into. Missing or vague privacy details. Since iOS 17, Apple checks your PrivacyInfo.xcprivacy manifest against the actual APIs your app, and any third party SDKs,…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}