Inform SDK Mobile App Launch & Store Submission Checklist

⚠️
Reminder: This is only a starting point. Clients must review and adapt the language to reflect their actual data practices, legal jurisdiction(s), third-party integrations, and store-submission metadata.
Because store policies on Apple App Store, Google Play Store, and relevant privacy/data-protection regulations evolve over time, this guidance may become out-of-date. It is your responsibility to ensure that your app, including all third-party SDKs or libraries you integrate, fully complies with the most current version of the store policies, privacy regulations, and review guidelines at the time of your submission.

This checklist is intended as a pre-submission readiness guide for mobile apps that integrate a Validic Inform SDK or wrapper. Its goal is to help you systematically review and validate the app build, metadata, permissions, privacy disclosures, and dependencies so you enter the App Store or Play Store submission process with a higher likelihood of a smooth review and approval.

Because review policies (on iOS, Android, and for health-sensitive data) are complex, evolve over time, and often include nuanced requirements around privacy, consent and technical completeness, this checklist helps prevent common pitfalls (crashes, missing privacy disclosures, missing permissions justification, broken links, incomplete features, etc.).

Official Store Policy References

Apple

App Store Review Guidelines (Apple): for content, design, metadata, IAP, health-app rules.

Apple Developer “Guidelines” index: full set of rules including UI, business, legal, IAP, artwork.

Google

Google Play Policies (Android): all current Play Store rules.

Android Developers “Declare your app’s data use” guide: to correctly complete Play Console Data Safety declarations.

Android Developers “Publish your health app on Google Play” (Health Connect / sensitive data): for apps that access health, fitness, or medical data.

Pre-Submission Checklist

📄 Metadata & Build Readiness

App is stable and complete. No placeholder UI/text, no obvious crashes, all navigation paths work, login/back-end services live if needed.
All metadata and assets are final. Store listing text/description, screenshots, previews, app icons, launch images, etc. reflect the real, intended app (not demo or test state).
If app depends on external hardware or devices (e.g. Bluetooth devices, sensors), ensure those dependencies are clearly documented internally; ensure reviewers (or test accounts) can access or simulate device functionality if needed.
If using in-app purchases / premium features / paywall, verify that in-app purchase flows are implemented, visible, functioning, and that store-side configurations (IAP items, pricing, durations, restore flows) are correct.

🔐 Privacy, Permissions & Data Handling

Privacy policy exists and is publicly accessible via HTTPS (not behind login). Must describe what data is collected, how it’s used, whether shared with third parties, data retention/deletion, user rights (access, deletion, portability), and contact info for privacy inquiries.
Privacy policy link included in store metadata (App Store Connect or Play Console) and, where appropriate, accessible from within the app (e.g. Settings or Account screen).
On Android:
- When filling out the Google Play Data Safety form, be careful with the "Location" section.
- If you target Android 12+ and use the neverForLocation flag for your Bluetooth permissions, you generally do not need to declare that you collect "Location" data solely for the purpose of Bluetooth connectivity.
- However, if you support Android 11 or lower (where ACCESS_FINE_LOCATION is required), you may need to declare Location permission usage but can clarify in the "Data collected" section that it is used for "App functionality" (device connectivity) rather than "Physical location tracking," depending on your actual data use.
Data collection and sharing accurately declared in relevant store-submission forms:
On Android: complete the “Data safety” form, declaring all types of user data collected/shared (including third-party SDK behavior) and security practices (e.g. encryption, deletion)
On iOS: provide “App Privacy” / privacy-label disclosures for all data types collected including health/fitness, identifiers, usage data, diagnostics, etc.
Permissions requested in the app are limited to what is strictly necessary (principle of least privilege). Don’t request data/permissions not needed for core functionality.
For sensitive data (health, fitness, medical, sensors, Bluetooth, etc.), ensure user consent is requested clearly; provide context/explanation for why data is being requested; avoid misusing data (e.g. for marketing or tracking) unless explicitly permitted and disclosed.
No false or misleading statements/claims about health, medical capabilities, or what data the app can access. Do not write false data to health frameworks (e.g. HealthKit), and don’t store personal health info in unsecure or disallowed storage (e.g. disallowed iCloud backup for health data).

🧪 Review Readiness

Demo / test account or mode available if login / backend is required so store reviewers can actually sign in and test functionality.
If using features like persistent background services, sensors, or health data sync (e.g. with Android Health Connect, or iOS HealthKit / Bluetooth), confirm that these features work as expected in a clean/release build, and are obviously surfaced in UI so that reviewers understand what the app does.
Document external dependencies or hardware requirements clearly in submission notes or metadata (if functionality depends on external devices/sensors).
If paywall gating health or sync features, ensure gating behavior is clear to reviewers and users (e.g. that health features are behind “premium,” or that user must opt-in; don’t request health permissions by default if user hasn’t opted in to relevant features).

✅ Legal & Compliance Considerations

Store-provided data-privacy and user-data declarations reflect actual app behavior, including effects of third-party SDKs (analytics, crash-reporting, etc.). Many compliance or privacy-policy mistakes arise because third-party SDKs collect data but are not disclosed.
If the app is intended for minors or collects data from children, ensure compliance with relevant regulations (e.g. COPPA) and that privacy policy reflects children’s privacy handling and consent flow.
Ensure all external links (support, privacy policy, website, terms, contact) are valid and reachable. Broken links are a common rejection reason.

🧰 Feature-Specific Checklist

Confirm that all requested health/fitness data types correspond directly to user-facing, documented features (e.g. step sync, heart-rate, sleep, etc.). Do not request data that isn’t used. Do not indicate data in your store submission that you do not use in your app.
Ensure permission prompts are clear and first-time requests include user-friendly rationale, e.g. explaining why health data sync is necessary, or why Bluetooth or background services are needed.
Handle "Location for Bluetooth" Confusion on Android:
On Android 11 & below: You must request ACCESS_FINE_LOCATION to scan for Bluetooth devices. In your user-facing prompt, explicitly explain this OS requirement (e.g., "Android requires Location permission to detect nearby Bluetooth devices. We do not use this to track your physical location.") to reduce user friction.
On Android 12+: Verify you are using the new BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions.

**Crucial: **If you do not use Bluetooth beacons for geolocation, add the android:usesPermissionFlags="neverForLocation" attribute to your BLUETOOTH_SCAN declaration in the AndroidManifest.xml. This allows you to skip the Location permission request on newer devices, significantly improving conversion rates.
Handle "Location for Bluetooth" Confusion on iOS:
Ensure the NSBluetoothAlwaysUsageDescription key is present in your Info.plist.
Avoid generic text. Apple frequently rejects placeholders like "Bluetooth access." Use a specific description such as: "This app uses Bluetooth to find and sync data from your supported health devices and provide insights in the Dashboard based on that data."
If the app uses background / foreground services to collect data (e.g. continuous sync, background health monitoring, Bluetooth). Test on real devices across multiple OS versions to ensure stability, battery-performance, correct permission behavior.
Ensure collection / sync flows are robust even if user revokes permission. App should fail gracefully, or degrade features clearly (so user experience remains acceptable).
Ensure privacy policy and in-app disclosures mention that health/fitness data may be collected, synced, stored, and possibly shared with backend / third-party services (if relevant), including any data retention or deletion policies.
If the app includes optional features (e.g. premium features, research, analytics) that use health or sensor data, evaluate whether additional disclosure, consent, or gating is needed.

❗️
**Important disclaimer: **This is not a substitute for your own legal review, policy drafting, or full compliance audit.
The checklist does not provide exact wording, policy text, or guarantee approval.
You must craft your own privacy policy, consent language, in-app disclosures, and store-submission metadata, and you remain fully responsible for how you structure permissions, data handling, and the user experience.
Use the checklist as a planning tool, but assume that final responsibility for app behavior, compliance, and approval stays with you and your team.