Most CodeCanyon Flutter apps don't get rejected because of bugs. They get rejected because the submission misses a policy requirement that reviewers check every time. Below are the issues we see most often when publishing 6amMart, 6Valley, Demandium and DriveMond apps, and the fixes that get them approved. Store policies change, so check the current Apple and Google guidelines before you submit.
Before you submit anything
- Developer accounts. Use an organisation account where you can. It shows your company name and avoids some of the extra testing requirements that apply to new personal accounts on Google Play. Apple requires a D-U-N-S number for organisation enrolment.
- Your own package name and bundle ID. Never submit with the demo identifiers. See the rebranding guide.
- A live backend. Reviewers use the app against your real server. If the API is down or has no data in the reviewer's location, the app looks broken.
- A privacy policy URL that actually describes your data use: location, phone number, payments.
Apple App Store: the common rejections
Guideline 4.3: design spam
Apple rejects apps that look like many others built from the same template. This is the biggest risk for any script-based app. What helps:
- A real, distinct brand: name, icon, colours and screenshots, not the demo look.
- A real business behind it, explained in the review notes: your company, your city, your partner stores.
- Real content in the app during review, meaning stores, products or services in the reviewer's view.
- Don't submit multiple near-identical apps from one account.
Guideline 2.1: app completeness and demo accounts
Give reviewers a working demo account for every role: customer, and also store, provider or driver for those apps. Explain in the review notes how to place a test order or request a trip. If reviewers can't log in or see nothing to test, the app is rejected.
Guideline 5.1.1: account deletion and permissions
Apps that let users create an account must let them delete the account from within the app. Recent 6amTech versions include this, so make sure it works against your backend. Every permission prompt (location, camera, photos) needs a clear purpose string that explains why your app needs it.
Guideline 4.2: minimum functionality
This mainly affects web-to-app conversions. An app that's only a website in a frame gets rejected. Native navigation, push notifications and device features help.
Google Play: the common rejections
Testing requirement for new personal accounts
New personal developer accounts must run a closed test with a minimum number of testers for a set period before they can apply for production access. Plan this into your timeline, or use an organisation account.
Background location declaration
Delivery-man and driver apps track location while in the background, which Google treats as sensitive. You'll need:
- A prominent in-app disclosure before the permission prompt, explaining what's collected and why.
- The location permission declaration in Play Console, with a short video showing the feature.
- Correct foreground service declarations for the service types your app uses on recent Android versions.
Customer apps usually don't need background location. Remove the permission if your build includes it unnecessarily.
Target API level
Google requires new apps and updates to target a recent Android API level, and raises the bar every year. Older script versions may need their Android build settings updated before they can be uploaded at all.
Data safety form and account deletion
The data safety form must match what the app actually collects, including data collected by SDKs such as Firebase and Maps. Google also requires an account deletion option in the app and a web link where users can request deletion.
Store listing assets
Prepare these for each app:
- An icon, plus a feature graphic for Google Play.
- Screenshots in the required sizes, showing your brand and real content.
- Short and full descriptions written for your market and language.
- Support email and website.
- Content rating questionnaire and target audience answers.
When you get rejected anyway
Read the rejection message carefully, because it usually names the guideline. Fix the specific issue, reply in Resolution Center (Apple) or update the release (Google), and explain what you changed. If you disagree, Apple lets you reply or appeal. Calm, specific replies get much better results than resubmitting unchanged.
How we help
Store publishing is part of every package we deliver. We submit under your own accounts and handle rejections until the apps are approved. You can see the client apps we've published in our live client apps sections, or go straight to the web-to-app service.
Questions
Why did Apple reject my app under guideline 4.3?
Apple considers it too similar to other apps built from the same template. Use a distinct brand, real content and a clear explanation of your business in the review notes.
Do I need a demo account for the App Store review?
Yes, if your app requires login. Give working credentials for each role and explain how to test the main flow.
Why does Google Play ask for a location declaration?
Delivery and driver apps use location in the background. Google requires a declaration, a prominent in-app disclosure and a video showing the feature.
Should I use a personal or organisation developer account?
An organisation account is better for a business. It shows your company name, and on Google Play it avoids the testing requirement for new personal accounts.