What do Apple and Google look for when approving an app?

Let's start with something that can catch businesses off guard. Having an app that works doesn't automatically mean it will be approved for publication.

Apple and Google review submissions against their respective requirements, looking at areas such as functionality, technical quality, security, privacy and the experience offered to users. An app might work perfectly well in a development environment but still fall short of what a platform expects from a product available to the public.

There's a good reason these checks matter. According to Apple's 2025 App Store Transparency Report, Apple reviewed more than 9.1 million app submissions during 2025 and rejected 2,093,244 of them. That's approximately 23% of submissions reviewed, although the figure relates to submissions rather than unique apps, as developers can submit an app more than once.

The report also records more than 1.35 million rejections under performance-related guidelines, alongside over 415,000 under design guidelines. These categories can overlap with other reasons for rejection, but they demonstrate that getting an app ready for publication involves more than checking whether its features work.

This doesn't mean you should expect your app to be rejected, or that the process needs to be complicated. It means that understanding the requirements early gives you a better opportunity to make the right decisions, identify potential issues and prepare a product that meets the standards expected of it.

You can explore the requirements directly in Apple's App Store Review Guidelines and Google Play's Developer Programme Policies.

One of the conversations we regularly need to have with prospective partners is around how much of an app can be built using existing components or a standard template.

Reusable technology has a valuable role in app development. It can help development teams work more efficiently, reduce the amount of duplicated work and give businesses a more cost-effective starting point. The important distinction is between reusing technology to build a product and reusing a product without giving users anything meaningful or distinctive.

Apple's minimum functionality guideline explains that apps should offer features, content and interfaces that go beyond a repackaged website. It also places restrictions on apps that primarily serve as marketing material, advertisements or collections of links rather than providing an adequate level of utility or entertainment. Google Play has its own policies covering repetitive content and apps that provide limited functionality or content.

In practical terms, imagine a business that already has a website containing information about its services. Turning every page into a mobile screen doesn't necessarily give users a compelling reason to download an app. If they can do exactly the same things through their mobile browser, without any additional convenience or useful functionality, the product may struggle to meet the expectations of the app stores.

Now consider a different approach. The business identifies what its customers need to do regularly and builds an app around those activities. Users might be able to manage bookings, receive relevant notifications, access personalised information or complete tasks while they're away from their desks. These features have a clear purpose because they support the way people interact with the business.

That doesn't mean every app needs an entirely original concept or a long list of complicated features. A relatively simple product can still provide considerable value if it solves a specific problem well. What matters is that the functionality makes sense for the intended audience and gives the product a clear reason to exist.

This is also why we don't see reusable technology and bespoke development as opposing approaches. The right foundations can help us build more efficiently, but the product itself still needs to be designed around its users, objectives and requirements.

Another question worth asking is what your app will do that makes sense on a mobile device, rather than simply on a website.

Modern smartphones give developers access to a range of capabilities, including cameras, GPS, biometric authentication, Bluetooth and push notifications. Depending on the product, these features can make everyday tasks easier, provide information at the right moment or allow users to interact with a service in ways that wouldn't be possible through a standard website alone.

For example, a travel app might use location services to help someone find nearby facilities, while a field operations app could allow employees to capture photographs, record information, and update job details while working on site. A healthcare app might use notifications to remind users about an activity or appointment, while biometric authentication could make signing in more convenient for a product handling sensitive information.

In each case, the functionality supports a particular user need. It isn't there simply to demonstrate that the app can access the device's capabilities.

It's important to understand that Apple and Google don't require every app to use every available device feature. A product shouldn't request access to someone's camera, location or contacts unless that access is necessary for its intended functionality. Instead, the question is whether the app makes appropriate use of the capabilities that genuinely benefit its users.

This is particularly relevant when businesses ask whether they should build a mobile app or a mobile-friendly website. Both can be valuable, but the right choice depends on what people need to accomplish, how frequently they'll use the product and whether access to device capabilities would improve the experience.

If users primarily need to read information or browse a small collection of pages, a responsive website might be all they need. If they're regularly completing tasks, interacting with other users, receiving updates or using features that benefit from integration with their device, a mobile app could be a better fit.

Thinking about this distinction at the beginning of a project helps you decide what you're actually building and why. It also makes it easier to prioritise features that provide value rather than adding functionality simply to make the app appear more sophisticated.

Once you've established what your app needs to do, the next consideration is how reliably it does it. It's easy to concentrate on the features that will make your product stand out, particularly when you're working towards a launch date. However, the quality of the experience depends just as much on whether those features work as expected and whether users can navigate the app without running into problems.

Imagine downloading an app to manage an important booking, only to find that the confirmation screen doesn't load. Perhaps the app crashes when you try to upload a photograph, or you can create an account but can't complete the next step. Even if the product looks great, these problems make it difficult for users to achieve what they came to do.

Apple's review guidelines cover performance, completeness and other aspects of app quality. Google Play also sets expectations around functionality, stability and the experience offered to users. Both platforms can reject submissions that fail to meet their requirements.

This is why testing needs to be part of the development process rather than something left until the final few days before launch. Teams need to check that the main user journeys work correctly, that features behave as expected and that the app performs appropriately across the devices and operating system versions it intends to support.

Testing should also account for what happens when things don't go to plan. What happens if someone loses their internet connection halfway through a task? Can they recover from an error without losing their progress? Does the app explain what they need to do next if a service is temporarily unavailable?

These details might not be the first things you think about when planning a new product, but they can make a real difference to how useful and dependable it feels.

It's also worth distinguishing between an app that's technically complete and one that's ready to launch. A feature might work in isolation but still create problems when it interacts with another part of the product. Reviewing the app as a whole helps identify these issues before they affect users.

A thorough quality assurance process gives the team time to find and resolve problems before submission, although no amount of testing can guarantee that an app will never encounter an issue after release. The aim is to launch with confidence that the product has been tested against its intended use and the requirements of the platforms it will run on.

Not every app store requirement is visible to the person using the product. Some of the most important decisions happen behind the scenes, in the technology used to build the app and the way it interacts with the operating system.

Apple and Google regularly update their technical requirements to reflect changes in their platforms, including improvements to security, privacy and performance. Developers need to keep up with these changes when building new apps and maintaining existing ones.

For Android, one important example is the target API level. This determines the version of Android an app is designed to target and influences how it interacts with the operating system. Google Play uses target API requirements to encourage developers to adopt newer platform behaviour and security improvements.

As of 31st August 2026, new apps and app updates submitted to Google Play generally need to target Android 16 (API level 36) or higher. Existing apps generally need to target Android 15 (API level 35) or higher to remain available to new users on newer Android versions. There are exceptions for certain device categories and circumstances, so the specific requirements should always be checked before submission. You can find the latest details in Google Play's target API level requirements.

Third-party software development kits, commonly known as SDKs, are another consideration. These are collections of tools and functionality that developers can integrate into an app rather than building everything from scratch. An app might use an SDK for analytics, payments, maps, notifications or other services.

Using an SDK doesn't automatically create a problem, but developers need to understand what it does, what permissions it requires and how it handles information. A third-party library can affect the app's privacy disclosures, security and compatibility, so it's important to assess these dependencies rather than treating them as a minor implementation detail.

The same principle applies to the wider architecture of the product. The technology needs to support the features you're planning to deliver, work with the relevant platform requirements and allow for ongoing maintenance as those requirements change.

This is particularly important for businesses planning to keep their app for several years. Launching is only one stage of a product's life, and the decisions made during development can influence how straightforward it is to update, improve and support the app in the future.

Technical compliance is only part of the picture. If your app collects personal information or accesses sensitive device features, you also need to consider how that information is handled and what users are told about it.

Depending on the product, this could include account details, location data, photographs, contact information, payment information or information about someone's activity. The requirements will vary according to what the app does, the information it processes and the relevant platform policies and laws.

Both Apple and Google have rules covering privacy disclosures, permissions and data handling. Google Play, for example, requires developers to provide appropriate disclosures and obtain consent where its policies require them, particularly when an app accesses personal or sensitive information in ways users might not reasonably expect. Apple's guidelines also cover data collection, privacy practices and the use of sensitive information.

The important thing is to make these decisions while the product is being designed, rather than waiting until the app is ready to submit.

Let's say your app needs access to a user's location. The team should establish why that access is needed, when it should be requested and how the information will be used. If location access is only required for a particular feature, there may be no reason to request it as soon as someone opens the app. Explaining the purpose clearly and requesting permission at an appropriate point can help users understand what's happening and make an informed decision.

The same applies to third-party SDKs. If a library collects information or accesses device functionality, the app's wider privacy approach needs to account for that behaviour. Choosing a library without understanding its data practices can create problems later, particularly if the app's disclosures don't accurately reflect what happens behind the scenes.

Getting privacy right isn't simply a matter of satisfying a review checklist. It's part of building a product that people can trust, especially when they're sharing information or relying on the app to manage something important.

By this point, you might be wondering what all of this means for your own idea. Do you need to understand every technical requirement before approaching a development team? Not necessarily, but there are a few questions worth exploring before you commit to a particular approach.

Start with the people who will use it and what they need to achieve. A clear understanding of the problem helps you decide which features are essential and which can wait. It also gives you a stronger basis for explaining why an app is the right solution.

Think about how people will use the product and whether mobile-specific functionality would make a meaningful difference. You don't need to include every possible feature, but you should understand the value an app offers compared with a website or another digital service.

It's tempting to include everything you can imagine, particularly when you're investing in a new product. However, identifying the features that support the core purpose of the app helps you focus your budget and development time on what matters most. An MVP should still provide a useful, complete experience for its intended purpose.

The answer will depend on your product. An app that uses location services, handles sensitive information or integrates with external systems may have different considerations from a straightforward content-based product. Identifying these requirements early gives the team time to assess the right technology and plan the work properly.

Platform requirements change, operating systems evolve and users' expectations develop over time. It's worth considering how the app will be monitored, updated and supported once it's live, including who will be responsible for addressing issues and keeping its technology up to date.

These questions don't need to be answered in isolation. Working through them with an experienced product and development team can help you understand the options, identify potential challenges and make informed decisions before development gets under way.

That's where discovery becomes particularly valuable. By exploring the objectives, audience, requirements and technical considerations before committing to a build, you can establish a clearer direction for the product and reduce the likelihood of discovering major issues later in the process.

Apple and Google have their own requirements, and meeting them involves more than getting the code to work. Your app needs to offer meaningful functionality, provide a reliable experience, handle information appropriately and use technology that meets the relevant platform standards.

The good news is that these considerations don't need to stand in the way of a good idea. When they're understood early, they can help shape a better product by encouraging you to focus on what users actually need and how the app will work in practice.

At The Distance, we believe the strongest apps start with a clear understanding of the problem they're solving. From discovery and product design through to development, testing and ongoing support, our approach considers the product as a whole, including what it needs to achieve and the requirements it needs to meet.

If you're planning a mobile app and want to understand what's involved before committing to development, we'd be happy to talk through your idea and help you work out the right next steps.