ByteBunkers Logo
Flutter

Flutter App Production Release Privacy Checklist: How to Prevent Google Play and App Store Rejections

Rajarajan

Publishing a Flutter application to production is more than building an APK or IPA and uploading it to an app store. Before release, developers need to verify permissions, data collection, third-party SDKs, authentication, storage, networking, privacy disclosures, and platform-specific requirements.

A privacy or security issue that goes unnoticed during development can result in additional review, rejection, delayed approval, or problems after the application is published.

This guide provides a practical Flutter production privacy and compliance checklist that developers can use before submitting an application to Google Play or the Apple App Store.

Why Privacy Auditing Is Important for Flutter Apps

A Flutter application may contain significantly more functionality than the Dart code initially suggests.

For example, adding a package such as an analytics SDK, authentication library, camera plugin, location package, advertising SDK, or crash-reporting service can introduce native Android or iOS functionality.

Therefore, developers should not audit only their lib/ directory.

A proper release audit should cover:

  • Flutter source code
  • Dart dependencies
  • Android native configuration
  • iOS native configuration
  • Third-party SDKs
  • Backend APIs
  • Local storage
  • Permissions
  • Analytics
  • Crash reporting
  • Advertising
  • Authentication
  • Release artifacts

The most important principle is:

Your application's actual behavior, privacy policy, and app-store declarations should all describe the same reality.

1. Audit All Flutter Dependencies

Start by inspecting the application's dependencies.

Run:

flutter pub deps

Also inspect:

pubspec.yaml
pubspec.lock

Create an inventory of every dependency.

Pay particular attention to packages related to:

  • Firebase
  • Analytics
  • Advertising
  • Crash reporting
  • Camera
  • Microphone
  • Location
  • Contacts
  • File access
  • WebView
  • Authentication
  • Payments
  • Push notifications
  • Social login
  • Device information
  • Storage

A package should not be included simply because it might be useful in the future.

Remove dependencies that are no longer required.

Why this matters

Third-party packages may introduce native permissions, services, receivers, tracking functionality, or data collection.

Therefore:

Package audit → Native behavior audit → Privacy disclosure

2. Review Android Permissions

Open:

android/app/src/main/AndroidManifest.xml

Search for:

<uses-permission

Common permissions include:

INTERNET
CAMERA
RECORD_AUDIO
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
ACCESS_BACKGROUND_LOCATION
READ_CONTACTS
READ_MEDIA_IMAGES
READ_MEDIA_VIDEO
POST_NOTIFICATIONS
BLUETOOTH_SCAN
BLUETOOTH_CONNECT

For every permission ask:

  1. Why does the application need it?
  2. Which feature uses it?
  3. Is it actually required?
  4. Is it requested only when necessary?
  5. Can the feature work without it?
  6. Does the permission require additional store review?

Remove permissions that are not genuinely required.

Important

Do not assume that a permission is harmless simply because Android allows it.

Some sensitive permissions can trigger additional scrutiny during store review.

3. Check the Merged Android Manifest

Checking only your application's manifest is not enough.

Flutter plugins can introduce permissions and Android components.

After building the application, inspect the merged release manifest.

Look for:

  • Permissions
  • Activities
  • Services
  • Broadcast receivers
  • Content providers
  • Intent filters
  • Deep links
  • Exported components

This helps identify permissions introduced indirectly by dependencies.

A permission that does not appear in your Dart code may still be present in the final application.

4. Audit Personal Data Collection

Create a list of every type of data your application collects.

Typical examples include:

  • Name
  • Email
  • Phone number
  • Address
  • User ID
  • Location
  • Photos
  • Videos
  • Audio
  • Contacts
  • Device information
  • Advertising identifiers
  • Authentication information
  • Payment information
  • Diagnostics
  • Usage information

For each category determine:

Question Answer
Is it collected? Yes/No
Is it stored? Yes/No
Is it transmitted? Yes/No
Is it shared? Yes/No
Why is it collected? Purpose
How long is it retained? Retention
Can the user delete it? Yes/No

This inventory becomes extremely important when completing app-store privacy declarations.

5. Audit Third-Party SDKs

Third-party SDKs are one of the most commonly overlooked areas.

For every SDK determine:

  • What data does it collect?
  • Does it automatically collect data?
  • Does it use device identifiers?
  • Does it use advertising identifiers?
  • Does it collect IP addresses?
  • Does it track users?
  • Does it send crash information?
  • Does it collect analytics?
  • Does it share information with another company?

Examples include:

Firebase Analytics
Firebase Crashlytics
Google Mobile Ads
Sentry
AppsFlyer
Adjust
OneSignal
Social Login SDKs
Payment SDKs
Maps SDKs

You should understand the behavior of these SDKs before completing the privacy declarations.

6. Protect API Keys and Secrets

Never put server-side secrets directly inside a Flutter application.

Search the project for:

API_KEY
SECRET
PASSWORD
PRIVATE_KEY
CLIENT_SECRET
SERVICE_ROLE
ACCESS_TOKEN
REFRESH_TOKEN
JWT_SECRET

Also inspect:

.env
.env.*
.json
.yaml
.yml
.dart
.kt
.java
.swift

A particularly important example is a Supabase service-role key.

A service-role credential should never be shipped inside a Flutter application.

The same principle applies to:

  • Database passwords
  • Private keys
  • Payment secrets
  • OAuth client secrets
  • Cloud service credentials
  • Server-side API keys

Important security principle

Obfuscating a secret does not make it a secret.

Anything included in an APK or IPA should be considered potentially extractable.

7. Audit Local Storage

Flutter applications commonly use:

  • SharedPreferences
  • Hive
  • Isar
  • SQLite
  • Drift
  • Secure Storage

Search for:

SharedPreferences
Hive
Isar
sqflite
Drift
FlutterSecureStorage

Determine what information is being stored.

Sensitive information such as authentication credentials should not be stored in ordinary plaintext storage.

For example, carefully review code that stores:

password
access_token
refresh_token
session
secret

Use platform-appropriate secure storage for sensitive credentials.

8. Remove Sensitive Logging

Search the project for:

print(
debugPrint(

Also search for your logging framework.

Check whether logs contain:

  • Passwords
  • OTPs
  • Authentication tokens
  • Refresh tokens
  • API keys
  • Phone numbers
  • Email addresses
  • Payment information
  • Location
  • API responses

Development logging can easily remain active in production if it is not explicitly controlled.

A production application should use safe logging and redact sensitive information.

9. Check Network Security

Search for:

http://
https://
Dio(
http.get
http.post
baseUrl

Production applications should use secure HTTPS communication.

Pay particular attention to:

badCertificateCallback
HttpOverrides
validateCertificate

These configurations deserve careful review because disabling certificate validation can create serious security problems.

Also verify that:

  • Production APIs are used.
  • Test APIs are not shipped.
  • Authentication tokens are transmitted securely.
  • Sensitive data isn't unnecessarily placed in URLs.
  • Development proxies aren't enabled in release builds.

10. Review WebView Security

If the application uses WebView, inspect:

WebView
WebViewController
NavigationDelegate
javascriptMode

Verify that the application does not unnecessarily allow arbitrary websites or untrusted content.

Review:

  • Allowed domains
  • JavaScript
  • File access
  • External navigation
  • Authentication
  • JavaScript bridges
  • Deep links

WebView functionality should be limited to the application's legitimate requirements.

11. Audit Firebase Configuration

If the Flutter application uses Firebase, review:

  • Firebase Authentication
  • Firestore
  • Storage
  • Realtime Database
  • Analytics
  • Crashlytics
  • Cloud Messaging
  • App Check

Do not expose Firebase Admin credentials or service-account private keys in the application.

Also review database and storage security rules.

For example, verify that one authenticated user cannot access another user's private information simply by changing an ID in a request.

12. Audit Supabase Configuration

For applications using Supabase, inspect:

SUPABASE_URL
SUPABASE_ANON_KEY
service_role

The most important checks are:

  • Row Level Security
  • Storage policies
  • Database policies
  • Authentication rules
  • Edge functions
  • Authorization checks

A client application should not contain the Supabase service-role credential.

Also verify that users cannot read or modify records belonging to other users.

13. Review Authentication

Audit the complete authentication flow:

Registration
    ↓
Login
    ↓
Token/session
    ↓
Authenticated requests
    ↓
Logout
    ↓
Token invalidation

Also test:

  • Password reset
  • OTP
  • Social login
  • Expired sessions
  • Refresh tokens
  • Logout
  • Account deletion

Never log passwords or OTPs.

Authentication tokens should be stored securely.

14. Implement Proper Account Deletion

If users can create accounts, verify that account deletion actually removes or disables the user's account and associated data according to your documented behavior.

Deleting only the local Flutter session is not equivalent to deleting an account.

Check the complete chain:

Flutter
 ↓
Backend API
 ↓
Authentication
 ↓
Database
 ↓
Storage
 ↓
Third-party services

Test the deletion flow using a real test account before release.

15. Review Camera, Photos, Microphone and Location

Sensitive permissions require additional attention.

For each permission:

Feature
 ↓
Permission request
 ↓
Data collection
 ↓
Upload
 ↓
Storage
 ↓
Deletion

Ask whether every step is necessary.

For example, if an image is selected for profile creation, the application should not silently upload unrelated images from the device.

Similarly, if location is required only for a particular feature, avoid collecting it continuously when the feature isn't being used.

16. Audit Analytics

If using analytics, review every event.

Avoid sending sensitive information such as:

password
OTP
access_token
refresh_token
payment information
private documents

Also review:

  • User IDs
  • Custom properties
  • Device identifiers
  • Email addresses
  • Phone numbers
  • Search queries

Only collect what is genuinely necessary.

17. Audit Crash Reporting

Crash reporting services can receive more information than developers expect.

Review:

setUserIdentifier
setCustomKey
setLog
breadcrumbs
network logs

Do not send:

  • Passwords
  • Tokens
  • API keys
  • Payment details
  • Private user information

Crash reports should help diagnose problems without becoming another source of sensitive-data leakage.

18. Review Advertising and Tracking

If the application contains advertisements or tracking SDKs, identify:

  • Advertising identifiers
  • Tracking technologies
  • Analytics
  • Attribution
  • Cross-app tracking
  • Consent requirements

For iOS, check whether App Tracking Transparency requirements apply.

Make sure the actual implementation matches the information submitted to the store.

19. Separate Development and Production

Search for:

localhost
127.0.0.1
10.0.2.2
staging
development
dev-api
test-api
mock
dummy

Also check:

kDebugMode
kReleaseMode

Verify that production builds don't contain:

  • Test API endpoints
  • Test accounts
  • Mock data
  • Debug menus
  • Debug logging
  • Development Firebase projects
  • Development Supabase projects

20. Inspect the Final APK/AAB

Do not stop at source-code inspection.

Build the production application:

flutter clean
flutter pub get
flutter analyze
flutter test
flutter build appbundle --release

Then inspect the resulting application.

Look for:

  • Permissions
  • URLs
  • API endpoints
  • SDKs
  • Debug strings
  • Secrets
  • Firebase configuration
  • Native libraries
  • Unexpected files

The final artifact is what users and app stores actually receive.

21. Google Play Data Safety

Before submitting to Google Play, create a data inventory based on the actual application.

For every data category determine:

  • Collected?
  • Shared?
  • Required?
  • Optional?
  • Purpose?
  • Retention?
  • Deletion?

Do not guess these values.

The declaration should reflect the actual behavior of the application and its third-party SDKs.

22. Apple App Privacy

For iOS, review the application's data practices and determine the applicable categories, including:

  • Contact information
  • Location
  • Contacts
  • User content
  • Identifiers
  • Usage data
  • Diagnostics
  • Purchases
  • Financial information
  • Sensitive information
  • Other data

Also review:

  • App Tracking Transparency
  • Permission descriptions
  • Keychain usage
  • Background capabilities

23. Privacy Policy Consistency

Your privacy policy should match the actual application.

It should accurately explain:

  • What data is collected
  • Why data is collected
  • How data is used
  • Where data is stored
  • Third-party services
  • Analytics
  • Advertising
  • Account deletion
  • Data retention
  • User rights
  • Contact information

A privacy policy that says one thing while the application does something different can create compliance problems.

24. Final Flutter Production Checklist

Before release, verify:

  • All unnecessary permissions removed
  • All dependencies reviewed
  • Third-party SDKs reviewed
  • Data collection documented
  • Analytics reviewed
  • Crash reporting reviewed
  • Advertising reviewed
  • API secrets removed
  • Server credentials removed
  • Sensitive logging removed
  • Local storage reviewed
  • Authentication reviewed
  • Account deletion tested
  • HTTPS verified
  • WebView reviewed
  • Firebase rules reviewed
  • Supabase RLS reviewed
  • Production configuration verified
  • Development endpoints removed
  • Android manifest reviewed
  • Merged manifest reviewed
  • iOS Info.plist reviewed
  • Release APK/AAB inspected
  • Privacy policy reviewed
  • Google Play Data Safety reviewed
  • Apple App Privacy reviewed

25. Recommended AI-Based Pre-Release Audit

For teams using AI coding assistants, the entire audit can be automated as part of the development workflow.

An AI coding agent can inspect:

Flutter Source
       ↓
Dependencies
       ↓
Android Manifest
       ↓
iOS Info.plist
       ↓
Third-party SDKs
       ↓
Storage
       ↓
Networking
       ↓
Backend integration
       ↓
Release configuration
       ↓
APK/AAB
       ↓
Privacy declarations

The audit should classify findings as:

P0 — Blocker

The application should not be released.

P1 — High

Fix before store submission.

P2 — Medium

Fix before production where practical.

P3 — Low

Recommended improvement.

Unknown

Manual verification is required.

Conclusion

A successful Flutter production release requires more than passing flutter build.

The safest approach is to perform a complete privacy and security audit before submission and ensure that the following three areas agree:

Actual Application Behavior
          +
Privacy Policy
          +
Google Play / Apple Store Declarations

When these three are consistent, unnecessary permissions are removed, sensitive data is protected, third-party SDKs are understood, and production artifacts are inspected, the risk of privacy-related store rejection can be significantly reduced.

The goal should not be to "pass" an automated store check.

The goal should be to release an application whose actual behavior is secure, transparent, and accurately disclosed to users and app-store reviewers.

Related Topics

flutterchecklistrelease