What Binary Requirements Must Your App Meet for Approval?

You've spent months perfecting your app—the user interface looks spot-on, the functionality works flawlessly in testing, and your team is ready to launch. Then you submit to the app stores and get that dreaded rejection email. Something about binary requirements not being met. It's frustrating, especially when you thought you'd covered all the bases.

I've been through this process hundreds of times with clients, and honestly, the binary requirements can trip up even experienced developers. The thing is, both Apple and Google have specific technical standards that your app's binary file must meet before it can go live—and these aren't always obvious from their general guidelines. We're talking about everything from how your code is structured and compiled, to the specific formats your app bundle needs to follow, to performance benchmarks that must be hit.

The mobile app landscape has become much more stringent over the years. What used to be a relatively straightforward submission process now involves detailed technical checks that scan your app's binary for compliance issues. Both iOS and Android have their own sets of requirements, and they're constantly updating them to improve security, performance, and user experience across their platforms.

Getting your binary requirements right the first time can save weeks of back-and-forth with app store reviewers and get your app to market faster

In this guide, I'll walk you through exactly what your app binary needs to meet for approval on both major platforms. No technical jargon that'll confuse you—just practical, actionable requirements that you can check off before hitting submit. Because let's face it, nobody wants to deal with rejection emails when you're trying to launch your app.

Right, lets talk about app store binary standards—the technical requirements your app needs to meet before it can even dream of getting approved. This is where many developers trip up, and honestly, I see the same mistakes over and over again.

Your app binary is basically the compiled version of your code that gets submitted to the app stores. Think of it as the final package that contains everything your app needs to run on a users device. Both Apple and Google have strict rules about what this package can and cannot contain, and getting it wrong means automatic rejection.

File Size and Architecture Requirements

Apple has a 4GB limit for iOS apps, but theres a catch—apps over 200MB cant be downloaded over cellular networks without user permission. I always tell clients to keep their initial download under 150MB if possible; users are impatient and wont wait for massive downloads. Android is a bit more forgiving with its 150MB APK limit, but you can use expansion files for larger content.

Your binary also needs to support the right device architectures. For iOS, that means arm64 for modern devices—Apple stopped accepting 32-bit apps ages ago. Android requires you to support multiple architectures, typically arm64-v8a and armeabi-v7a at minimum.

Security and Code Standards

Both platforms run automated scans on your binary looking for security vulnerabilities, malicious code, and compliance issues. Your app cant contain any debugging symbols in production builds, and it must be properly signed with valid certificates. I've seen apps rejected because developers accidentally left test API keys or debug flags enabled in their final build—simple mistakes that cause big headaches.

The stores also check that your binary matches your app description and doesnt contain any hidden functionality that wasnt declared during submission.

iOS Technical Requirements and Guidelines

Right, let's talk about iOS binary requirements—the technical stuff that'll either get your app approved or send it straight back to you with a rejection notice. Apple's pretty strict about this, and honestly, they should be. The App Store has standards for a reason.

Your iOS app binary needs to support the latest iOS version and maintain backwards compatibility for at least two previous versions. So if iOS 16 is current, your app should work smoothly on iOS 14 and 15 too. Apple's reviewers will test this, so don't try to cut corners here. I've seen apps get rejected because they crashed on older devices—it's frustrating but completely avoidable.

Memory management is huge. Your app can't be a memory hog that slows down the entire device. Apple monitors how much RAM your app uses, especially during peak usage. If you're building a photo editing app or something graphics-heavy, you need to be extra careful about releasing memory when you're done with it.

Always test your app on the oldest supported device you claim to support. If you say your app works on iPhone 8, make sure it actually does—and performs well, not just barely functions.

Key Binary Requirements

• 64-bit architecture support (32-bit apps are no longer accepted)
• Built with the latest Xcode version or one version prior
• Proper app thinning implementation to reduce download sizes
• Background app refresh handling that doesn't drain battery
• Crash-free performance during Apple's review process
• Proper handling of device permissions and privacy settings

The tricky bit? Apple's review process includes automated testing that puts your app through various scenarios. Your binary needs to handle interruptions like phone calls, low memory warnings, and network changes gracefully. Test these scenarios yourself before submitting—trust me, it'll save you weeks of back-and-forth with Apple's review team.

Android App Bundle Specifications

Right, let's talk about Android App Bundle specs—this is where things get a bit technical, but I'll keep it straightforward. Android moved away from the old APK model to App Bundles a few years back, and honestly? It's been a game changer for how we deliver apps to users.

Your App Bundle file needs to be under 150MB. That's your hard limit. But here's the clever bit—Google Play will slice and dice your bundle to create optimised APKs for each user's device. So someone with a basic phone wont get all the high-resolution assets meant for flagship devices. Pretty neat, right?

Bundle Structure and Asset Delivery

The bundle itself contains different modules. You've got your base module (that's the core app everyone gets) and then optional feature modules that can be downloaded later. Dynamic delivery is brilliant for keeping initial download sizes small—users only get what they actually need.

Your app needs to target at least API level 21 these days, though I'd recommend going higher if your user base allows it. Each architecture (ARM, x86, etc.) gets its own optimised version, so you don't need to worry about bloating your app with unused native libraries.

Signing and Security Requirements

App signing is handled by Google Play now—you upload your bundle signed with your upload key, and Google signs the final APKs with your app signing key. It sounds complicated but it's actually more secure than the old way.

One thing that catches people out: your Bundle needs proper ProGuard configuration if you're using it. Badly configured ProGuard can break your app in weird ways that only show up on certain devices. Test thoroughly—trust me on this one, I've been burned by it before!

Performance and Security Standards

Performance isn't just about making your app feel snappy—it's about meeting the strict benchmarks that both Apple and Google use to evaluate submissions. I've seen perfectly good apps get rejected because they took 4 seconds to launch instead of 3. Seems harsh? Maybe, but users have zero patience for slow apps these days.

Your app needs to launch within 3 seconds on the target device specifications. That means if you're building for iPhone, test on the oldest supported model, not just the latest Pro version. Memory usage cant exceed the platform limits either—iOS will terminate your app if it uses too much RAM, and that's an automatic rejection if the reviewers catch it during testing.

Security Requirements You Cannot Ignore

Security standards have become much stricter over the past few years. Every API call must use HTTPS—no exceptions. Your app's data storage needs proper encryption, especially if you're handling any personal information. And honestly, what app doesn't these days?

Both app stores now scan your binary for known security vulnerabilities. They're looking for outdated libraries, weak encryption methods, and improper certificate handling. Conducting a thorough security audit before submission can help you identify these issues early and avoid costly rejections.

A single security vulnerability in your codebase can result in immediate rejection and potential removal from the store, even after approval

Battery performance is another area where apps frequently fail. Background processes need to be carefully managed; excessive battery drain during testing will get you rejected faster than you can say "optimisation." Test your app's battery impact thoroughly—the review teams definitely will.

Your app's store listing is basically its first impression—and honestly, it's often the only chance you get to convince someone to download your app. I've seen brilliant apps fail because their icons looked like they were designed in the early 2000s, and average apps succeed simply because their screenshots told a compelling story.

The technical requirements here aren't just suggestions; they're hard rules that will get your app rejected if you don't follow them properly. Apple requires your icon to be exactly 1024x1024 pixels for the App Store, while Google Play needs a 512x512 pixel version. But here's what catches people out—these icons can't have rounded corners or transparency effects because the platforms add their own styling.

Screenshot Standards That Actually Matter

Screenshots need to match your actual app interface, not some idealised version of what you hope it'll become. Both stores have gotten strict about this—if your screenshot shows features that don't exist in the submitted binary, you'll face rejection. Apple requires screenshots for each device size you're supporting, whilst Google Play is more flexible but still expects high-quality imagery.

Your metadata—app title, description, keywords—needs to accurately reflect your app's functionality. Apple's character limits are tighter than Google's, but both platforms scan for keyword stuffing and misleading claims. I always tell clients to write their descriptions like they're explaining the app to their mum, not trying to game search algorithms.

• App icon must be square, high resolution, and match platform guidelines exactly
• Screenshots must show actual app functionality, not concept designs
• App title should be clear and descriptive, avoiding special characters
• Description must accurately represent features available in the binary
• Keywords should be relevant and naturally integrated into descriptions

The biggest mistake? Treating these elements as an afterthought. Your visual assets and metadata work together to tell your app's story—get them right and you're halfway to approval.

Code Quality and Architecture Standards

Right, let's talk about the stuff that really matters—the quality of your code and how you've structured your app. This is where app stores get properly picky, and honestly? Good on them. Nobody wants to download an app that crashes every five minutes or drains their battery faster than a toddler drains patience.

The app stores have gotten much stricter about code quality over the years. They're looking for apps that follow platform-specific guidelines, use memory efficiently, and don't have any dodgy coding practices that could compromise user security. Apple's particularly hot on this—they'll reject apps that use private APIs, have memory leaks, or don't follow their Human Interface Guidelines. Android's a bit more forgiving but they're tightening up too.

Always run static code analysis tools before submission. They'll catch memory leaks, security vulnerabilities, and API usage issues that could get your app rejected. It's like having a grammar checker for code.

Architecture Requirements You Can't Ignore

Your app architecture needs to be solid. No spaghetti code, no shortcuts that'll come back to bite you. Here's what the stores are checking for:

• Proper memory management (no retain cycles or dangling pointers)
• Thread safety for concurrent operations
• Secure data storage practices
• Proper error handling throughout the app
• Clean separation of business logic and UI components
• Compliance with platform-specific coding standards

I've seen brilliant app concepts get rejected because the developers rushed the architecture phase. Take time to plan your code structure properly—it'll save you weeks of headaches later. The review teams can spot lazy coding from a mile away, and they're not afraid to send you back to the drawing board if your foundations aren't solid.

Right, let's talk about testing—because honestly, this is where I see most developers trip up. You can't just build your app and hope for the best; Apple and Google have gotten incredibly strict about quality, and their automated systems will catch issues you didn't even know existed.

I always tell clients that testing isn't just about making sure buttons work (though that's important too!). Both app stores run automated checks on your binary that test memory usage, battery drain, crash rates, and loading times. If your app takes more than 20 seconds to launch or crashes within the first minute of use, you're looking at an automatic rejection.

Device and OS Testing Requirements

Here's something that catches people out—you need to test on actual devices, not just simulators. I've seen apps that worked perfectly in the simulator but crashed immediately on real hardware because of memory constraints or GPU limitations. For iOS, test on at least three different devices spanning different screen sizes; for Android, well... there's literally thousands of device combinations, but focus on the top 10 most popular models in your target market.

Performance Benchmarks You Cannot Ignore

Both stores have specific performance thresholds your app must meet. Apps should launch in under 400ms on modern devices, use less than 50MB of memory during normal operation, and maintain 60fps during animations. Battery drain is also monitored—if your app consumes more than 10% battery per hour during typical use, that's a red flag.

The automated review process runs your app through stress tests, checks for memory leaks, and monitors network usage patterns. Document everything during testing; if you do get rejected, having detailed test results helps speed up the appeal process considerably.

Common Rejection Reasons and Solutions

After reviewing thousands of app submissions over the years, I can tell you that most rejections fall into predictable categories. The good news? They're usually straightforward to fix once you know what to look for.

Crashes are by far the biggest culprit—and I mean proper crashes, not just slow loading times. Apple's automated testing catches these within hours of submission, so there's no hiding from them. Your app needs to handle edge cases gracefully; if someone's running iOS on an older device with limited memory, your app still needs to work. I always tell my team to test on the oldest supported devices first, not the shiny new ones.

Privacy Policy Problems

Missing or incomplete privacy policies kill more submissions than you'd think. Both stores require clear explanations of data collection, even if you're only collecting basic analytics. Don't copy someone else's policy—write one that actually matches what your app does. If you're collecting location data, explain why. If you're using third-party SDKs that track users, mention it.

The rejection email will usually point you to the exact guideline you've violated, but sometimes the real issue is deeper than what they've highlighted in their feedback

Metadata mismatches cause headaches too. Your app description, screenshots, and actual functionality need to align perfectly. I've seen apps rejected because the screenshots showed features that weren't in the submitted version yet. Keep your store listing honest and current.

Technical Gotchas

Placeholder content is another quick way to get rejected. Those default "Lorem ipsum" texts or stock images you meant to replace? The reviewers will spot them. Double-check every screen, every button label, every bit of copy before submitting. Missing required permissions declarations will also trigger an automatic rejection—make sure your Info.plist file explains why you need camera, microphone, or location access.

If you're building apps with AI features, ensuring you have proper training data and clear privacy policies around AI functionality is becoming increasingly important for approval.

Conclusion

Right, so we've covered quite a lot of ground here—from the nitty-gritty technical requirements to the seemingly simple stuff like icons that can actually trip you up if you're not careful. Getting your app approved isn't rocket science, but it does require attention to detail and understanding what the app stores are really looking for.

The thing is, these binary requirements exist for good reasons. Apple and Google aren't trying to make your life difficult (well, not intentionally anyway!); they're protecting their users and maintaining the quality of their platforms. When you follow these guidelines properly, you're not just ticking boxes—you're building a better app that users will actually want to keep on their phones.

I've seen too many developers rush through the submission process only to get rejected for something completely avoidable. Maybe they forgot to test on older devices, or their app crashed when the network connection dropped, or they used a low-res icon that looked terrible on newer screens. These aren't complex problems, but they'll stop your app dead in its tracks.

The key takeaway? Start thinking about these requirements from day one of development, not the night before you submit. Build quality assurance into your development process; test on real devices; make sure your metadata tells a clear story about what your app actually does. Do that, and you'll save yourself weeks of back-and-forth with the app review teams.

Your app deserves to succeed, and meeting these binary requirements is just the first step in that journey.