--- title: How app developers can get their apps into the app store? description: Learn what app store reviewers actually look for, why rejection rates are so high, and how to build and submit your app to pass approval first time. image: https://weareaffective.com/hubfs/learning-centre-images/how-app-developers-can-get-their-apps-into-the-app-store.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-app-developers-can-get-their-apps-into-the-app-store#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # How app developers can get their apps into the app store? Table of Contents Getting an app into the Apple App Store or Google Play is one of those tasks that looks simple from the outside. You build the app, you submit it, and it goes live. That is the mental model most first-time developers carry into the process, and it is why so many of them are still waiting for approval six weeks later, having spent money they did not plan to spend on compliance work they did not know was coming. > The decisions made in the first week of development determine whether the review process is a formality or a battle. The reality is that app store approval is a design and architecture problem as much as a submission one. The decisions made in the [first week of development, how permissions are structured](https://weareaffective.com/app-planning-strategy), how data is handled, what category the app sits in, how onboarding flows are framed, determine whether the review process is a formality or a battle. By the time an app reaches submission, most of those decisions are fixed. This article covers the full arc from early build decisions through to listing preparation and rejection responses. Some of it is process. Some of it is based on what we have seen go wrong on real projects, including one where Apple's review process was used in a way that had nothing to do with compliance at all. Where those experiences are relevant, we will say so plainly. ## What the app stores actually review and why rejection rates are higher than most developers expect Apple reviews every app submission before it reaches users. The scope of that review is broader than most developers assume. Reviewers check functionality, content, design standards, metadata accuracy, privacy practices, and whether the app's stated purpose matches its actual behaviour. Google Play uses a combination of automated and human review, but the criteria are similarly wide. An app that crashes on a specific device size, requests permissions it does not use, or whose App Store description overstates what the product does can be rejected on any of those grounds independently. Apple's stated average review time is under 24 hours for around [90% of submissions, according to Apple's own published data](https://gotechsolutions.co/blog/apple-app-store-submission-guide-2026/), but speed of review is separate from likelihood of approval. First-time submissions from new accounts, apps in regulated categories, and apps requesting sensitive permissions all attract closer scrutiny. Developers building in health, finance, or social categories will typically face more questions regardless of how well the app is built. The most common rejection reasons are not exotic. Missing privacy policy links, screenshots that do not match the actual app, placeholder content left in metadata, and onboarding flows that request permissions without explaining why they are needed all appear regularly. These are design and communication failures that a reviewer picks up in minutes. ## How design decisions made in early development determine approval outcomes App store reviewers are users before they are gatekeepers. They open an app, move through the onboarding, and form an impression of whether it is competently made. That impression is shaped by the [same psychological mechanisms that shape any user's first encounter](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) with a product. Within a few seconds, the brain is making rapid judgements about whether the design suggests care or carelessness, and those judgements influence how the rest of the review proceeds. This matters because design quality is part of Apple's review criteria. Apps that look unfinished, have inconsistent visual hierarchies, or use touch targets that are too small to use reliably can be rejected on those grounds. Apple's Human Interface Guidelines recommend a minimum touch target size of [44x44 points for interactive elements, as documented in Apple's published HIG](https://weareaffective.com/learning-centre/what-spacing-rules-create-better-mobile-app-layouts). That is a baseline the reviewer will test. The deeper issue is that [design decisions made late in a project are expensive to fix](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). We experienced this on a wellness genetics product where a design handoff went through an intermediary designer, adding distance between the intended visual quality and what the development team could implement. When a premium-looking design meets a functional existing codebase, the gap between the two creates rework that was not budgeted for. Building to the right standard from the start is faster and cheaper than rebuilding to pass review. Review Apple's Human Interface Guidelines before writing a line of code, not before submitting. The guidelines shape what reviewers look for and what they flag, so designing to them from the start removes a whole category of rejection risk. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Technical requirements that must be built in from the start, not bolted on at submission A number of technical requirements cannot be added to an app at the end of development without significant rework. Accessibility support, VoiceOver compatibility on iOS, TalkBack on Android, semantic labels on interactive elements, needs to be considered in the component design, not added as a layer once the build is stable. The same is true of localisation. If an app is built with hard-coded strings and fixed-width layouts, adding a second language at submission stage requires structural changes, not just translation. Performance is reviewed as part of the submission process. An app that takes too long to load, freezes during standard flows, or drains battery abnormally will not pass review, and these are not issues that can be patched quickly. [62% of users uninstall apps after experiencing crashes, freezes, or errors, according to Alphabin's research on mobile app testing](https://www.alphabin.co/blog/mobile-app-testing-uninstall-rates), and reviewers are aware that those failure modes damage the platform's reputation as much as the developer's. The technical requirements worth building in from the start include the following. - Accessibility labels on all interactive elements - Dynamic type support so text scales with user settings - Graceful error handling and offline states - Memory management that prevents crashes on older devices - App Transport Security compliance for all network calls Test on the oldest device your minimum OS version supports, not just on current hardware. Reviewers use a range of devices, and an app that performs well on a current model but crashes on a three-year-old one will be rejected. ## Privacy, data handling, and permissions: the compliance work that cannot be retrofitted Apple introduced App Privacy labels in 2020, requiring developers to disclose exactly what data their app collects, how it is used, and whether it is linked to the user's identity. Google followed with similar disclosure requirements on Play. These disclosures are checked against the app's actual behaviour during review, and a mismatch between what a developer declares and what the app does is grounds for rejection. Permissions are reviewed with particular attention. An app that requests access to a user's contacts, location, or camera must explain why within the permission prompt itself. Apple requires a purpose string for every sensitive permission, and a generic explanation such as "we use your location to improve your experience" will not pass. The explanation needs to be specific and honest about what the feature does. The [framing of permission requests also affects user response](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), which in turn affects the data that matters to the review. Rather than presenting permissions as demands, asking for them as a question, can we send you notifications, is it okay if we access your location for this feature, generates higher acceptance rates and reduces the proportion of users who immediately deny access and then report the app as invasive. Privacy compliance work involves three layers that need to be in place before submission. 1. An accurate privacy policy hosted at a live, publicly accessible URL 2. App Privacy label entries that match the app's actual data practices 3. Purpose strings for every permission request, specific to the feature that needs it None of this can be added cleanly after the app is built. If data collection is embedded in the architecture and the declared purpose does not match what the code does, the fix is architectural, not editorial. ## Financial and regulated product apps: when Apple's review process becomes a barrier in itself Apps in regulated categories, finance, healthcare, gambling, and anything that handles payments, face a distinct review path. Apple requires additional documentation, typically proof of regulatory authorisation, and the review team for these categories has more latitude to reject on grounds that are harder to appeal. A well-built, fully compliant app in a regulated category should pass, but the process is slower and more uncertain than for a standard utility or productivity app. We worked on a currency exchange app where the client's product was repeatedly rejected by Apple despite meeting every stated compliance requirement. Each time we addressed Apple's stated objection, a new one was raised. When Apple cited the potential for money laundering and criminal activity, we responded by capping transactions at €150, which should have addressed the concern entirely. Apple rejected the app again. The client ran out of budget and abandoned the product. It later became clear that the rejections coincided with the build-up to Apple Pay's launch, and we believe the two were connected. That experience illustrates a structural problem with the review process in regulated categories. There is no effective mechanism for a developer to challenge an objection that keeps shifting. A well-funded incumbent can, in practice, use iterative rejection as a blocking tool. Developers building in these categories need to know this before they invest in compliance work, not after. If your app sits in a regulated category, establish direct communication with Apple's developer relations team before submission. Understanding which specific regulatory documents they will require, and in what format, prevents rejection on procedural grounds after months of development. ## How to structure your App Store Connect account and testing pipeline before you build App Store Connect account structure is a decision that most developers leave until they are ready to submit, and it causes problems that are much harder to fix at that stage. The account holder role carries the most authority, and whoever holds it controls what can and cannot be done with the account. If that person is not available during the review process, submissions can stall. If it is a client who does not understand the testing pipeline, they can disrupt it. We set up the testing pipeline on a social football product where the client held the Account Holder role because the account was registered in their name. We had admin access to the majority of the account and structured three testing groups: one for our team, one for the client, and one external QA beta group for the client's own testers. The structure was [designed to control which builds went to which groups](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) during deployment. As the project approached launch, the client began bypassing that structure, manually sending uploaded builds to whichever group they chose. Because the account was theirs, we had limited ability to prevent it, and it caused problems with build consistency and test integrity. The structure worth establishing before a single line of code is written looks like this. | Group | Who has access | Purpose | | --- | --- | --- | | Internal alpha | Development team only | Daily builds, unstable features | | Client review | Client stakeholders | Milestone builds, sign-off | | External beta | QA testers, selected users | Pre-launch testing, feedback | Agreeing access controls and build distribution rules in writing before the account is set up removes a category of conflict that otherwise tends to surface at exactly the wrong moment. ## Preparing your App Store listing so the right users self-select before downloading An App Store listing is not marketing copy. Its function is to communicate accurately what the app is and who it is for, so that users who download it already know what they are getting. When that communication fails, users download the app with the wrong expectations, open it, and leave within the first session. That [early abandonment registers in the app's performance data](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one) and, over time, affects how the store ranks and surfaces the product. We worked on a gifting and wishlist platform where the client was reluctant to invest in App Store optimisation, believing that word-of-mouth referral would carry the product. Our position was that the listing still needed to be precise, regardless of how users arrived at it. Someone referred to an app by a friend will still check the store page before downloading, and if the icon, screenshots, and description do not immediately confirm what the product does, a proportion of those referred users will not convert. On [category selection, where a product could plausibly sit in more than one category](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure), we recommend launching in the less competitive one first. Higher rankings in a smaller category generate more organic impressions, more downloads, and more usage data. Once the product has traction and a rating history, moving into the more competitive primary category is a more viable step than launching into it from a standing start with no reviews and no rank. Write the App Store description for the user who has never heard of the product, not for the user who was referred by a friend. The referred user will read it too, and the description that converts the cold visitor will convert the warm one as well. ## What to do when Apple rejects your app and how to respond effectively Apple sends a rejection notice through App Store Connect with a reference to the specific guideline the app failed to meet. The notice includes a link to the relevant section of the App Store Review Guidelines. The first step is to read that section carefully and match it precisely to what the reviewer described. Rejection notices are sometimes brief, and it is easy to address a surface symptom rather than the underlying issue, which leads to a second rejection on the same grounds. The resolution options available after rejection are a revised submission addressing the stated issue, a response to the reviewer through the Resolution Center, or an appeal to the App Review Board. The Resolution Center is underused. Reviewers can clarify what they need, and in cases where the rejection feels disproportionate or the guideline reference seems incorrect, a direct question through the center often produces a more specific explanation than the original notice. Some rejections are genuinely ambiguous. Apple's guidelines are written at a level of generality that leaves room for interpretation, and two reviewers can reach different conclusions about the same app. In those cases, a revised submission that addresses the most plausible interpretation of the objection, combined with a message through the Resolution Center explaining the approach, gives the next reviewer context that the original submission lacked. - Read the referenced guideline section in full before changing anything - Address the specific issue described, not the most obvious thing to fix - Use the Resolution Center to ask for clarification if the rejection is ambiguous - Keep a record of every submission, rejection reason, and response sent ## Conclusion Getting an app into the store is a process that rewards preparation and punishes assumptions. The developers who move through review quickly are the ones who treated compliance, design standards, and privacy architecture as build requirements rather than submission tasks. The currency exchange project we worked on is an extreme case, where the review process was used in a way that had nothing to do with the app's actual quality. But it is a useful reminder that the process has limits, and that building a solid, well-documented, compliant product is the best defence available against rejection, even if it is not always sufficient. The path through review is predictable if the groundwork is done. The listing communicates clearly so the right users self-select. The permissions are framed as requests rather than demands. The design meets the standards that reviewers are trained to look for. The testing pipeline is structured before the build starts, not improvised when the deadline arrives. Consumer apps are long-term investments. The weeks spent getting the foundations right before a first submission save multiples of that time in rework, re-review, and abandoned users who downloaded with the wrong expectations. If you are building an app and want to work through what that preparation looks like for your specific product, [let's talk about your app](https://weareaffective.com/get-started). ## Frequently Asked Questions How long does it take to get an app approved on the App Store or Google Play? Apple reviews around 90% of submissions within 24 hours, according to its own published data. However, speed of review is separate from likelihood of approval, and apps in regulated categories such as health or finance, or those requesting sensitive permissions, will typically face closer scrutiny and longer back-and-forth. What are the most common reasons an app gets rejected? The most frequent rejection reasons include missing privacy policy links, screenshots that do not match the actual app, placeholder content left in metadata, and onboarding flows that request permissions without explaining why they are needed. These are design and communication failures that a reviewer can identify within minutes of opening the app. Does design quality actually affect whether an app gets approved? Yes, design quality is part of Apple's review criteria. Reviewers move through an app as a user would, and an app that looks unfinished, has inconsistent visual hierarchies, or uses touch targets that are too small will raise concerns about whether the product is ready for release. When in the development process should developers start thinking about app store approval? Approval readiness should be considered from the very first week of development. Decisions about how permissions are structured, how data is handled, and how onboarding flows are framed all shape whether the review process is straightforward or problematic, and by the time an app reaches submission, most of those decisions are already fixed. Are there certain app categories that face more scrutiny during review? Apps built in health, finance, or social categories will typically face more questions during review regardless of how well the app is built. First-time submissions from new developer accounts also attract closer scrutiny compared to established accounts with a track record of approved apps. Do Google Play and the Apple App Store review apps in the same way? Not exactly. Apple reviews every submission manually before it reaches users, while Google Play uses a combination of automated and human review. However, the criteria are similarly wide across both platforms, covering functionality, content, privacy practices, and whether the app's stated purpose matches its actual behaviour. What should a developer do if their app is rejected? A rejection should be read carefully to understand whether it relates to functionality, content, metadata, or permissions, as the response strategy differs depending on the cause. Addressing only the stated issue without reviewing the broader submission for similar problems often leads to a second rejection, so it is worth auditing the whole app before resubmitting. Can an app be rejected because its App Store description is inaccurate? Yes, reviewers check whether an app's stated purpose matches its actual behaviour, and overstating what the product does is a valid ground for rejection. Metadata accuracy, including descriptions, screenshots, and category selection, is part of the review scope on both Apple and Google's platforms. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.