◉RORK LABJP
●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SDK 58 — Beta since 09/15 with no stable date yet; running projects in Expo Go has required login since 09/03●WIDGET — A write-up traces an iOS widget that renders black only in production builds●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SDK 58 — Beta since 09/15 with no stable date yet; running projects in Expo Go has required login since 09/03●WIDGET — A write-up traces an iOS widget that renders black only in production builds●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Articles/Dev Tools
⬡ Dev Tools/2026-05-12Intermediate

Rork App Rejected for Incomplete Data Safety Section on Google Play: How to Fix It

Step-by-step guide to correctly filling out Google Play's Data Safety section for Rork apps. Covers AdMob, Firebase, RevenueCat, and common declaration mistakes that cause rejections.

troubleshooting69Google Play38data safetyAndroid55AdMob73Firebase10privacyapp review3

If you've received a message from Google Play Console saying your app violates policy because the Data Safety section is incomplete or inaccurate — you're in good company.

Having built and shipped apps since 2014 with a cumulative total of over 50 million downloads across my portfolio, this particular rejection has caught me off guard more than once. It's especially tricky for Rork developers, because Rork automatically includes several SDKs (AdMob, Firebase, Expo modules) that collect data behind the scenes — data you may not even realize you need to declare.

This guide breaks down exactly which SDKs collect what data, and how to fill out the Data Safety form accurately to get your app approved.

Why Rork Apps Are Prone to Data Safety Rejections

Google mandated the Data Safety section in 2022. It requires developers to disclose what user data their app collects, how it's used, and whether it's shared with third parties.

The catch for Rork developers is this: even if you didn't write code to collect data yourself, any SDK bundled in your app counts. If AdMob is collecting advertising IDs and you didn't declare it, that's a violation — regardless of whether you added that code intentionally.

The three most common failure patterns are:

  • Missing AdMob advertising ID declaration: Ad SDKs always collect device identifiers. Not declaring this is one of the fastest ways to get rejected
  • Overlooking Firebase Crashlytics: Crashlytics sends diagnostic data (crash logs, device info) to Firebase servers. This falls under "App Performance" in the Data Safety form
  • Vague user content handling: Apps with chat features or photo uploads need to declare "User Content" data collection

SDK Data Collection Reference for Rork Apps

Here's a practical reference for the SDKs commonly bundled in Rork-generated apps.

AdMob (Google Mobile Ads SDK)

If your app uses AdMob, these declarations are required:

  • Data type: Device or other IDs (advertising ID)
  • Purpose: Advertising or marketing
  • Shared with third parties: Yes (Google)
  • User control: Optional (users can reset advertising ID)
AdMob Declaration Checklist:
✅ Device or other IDs → Collected: Yes
✅ Advertising or marketing → Purpose: Yes
✅ Data shared with third party → Yes (Google)
✅ User can request data deletion → Yes (advertising ID reset)

Firebase Crashlytics / Analytics

  • Crashlytics: Collects crash logs and diagnostic data → declare under "App Performance"
  • Analytics: Collects in-app behavior and device info → declare under "App Activity"
  • Authentication: Collects email addresses or phone numbers → declare under "Personal Info"

Expo / React Native (Base Framework)

Expo itself doesn't collect data independently, but specific Expo libraries may require declarations. For example, if your app uses expo-notifications, you need to declare device token (identifier) collection.

How to Correctly Fill Out the Data Safety Form

Step 1: Identify All SDKs in Your App

Open your Rork project's package.json and search for relevant packages:

cat package.json | grep -E "(google|firebase|expo|revenuecat|analytics|admob)"

Sample output:

"expo-ads-admob": "^3.0.0",
"@react-native-firebase/crashlytics": "^18.0.0",
"expo-notifications": "^0.27.0",
"react-native-purchases": "^7.0.0"

Use this list as your starting point for the Data Safety declarations.

Step 2: Check Each SDK's Official Data Safety Guidance

Most major SDKs publish guidance specifically for Google Play's Data Safety form:

  • AdMob: Google publishes a sample Data Safety form for AdMob at the Google Mobile Ads Help Center
  • Firebase: Firebase Console offers a downloadable CSV file with pre-filled Data Safety responses for each Firebase product

Step 3: Fill Out the Form in Google Play Console

In Google Play Console, navigate to the "Data Safety" section and work through each question:

  1. Does your app collect or share user data? → "Yes" (applies to nearly every app)
  2. Select data types: Check all types that match your SDK usage
  3. Select purposes: Advertising, analytics, app functionality, etc.
  4. Third-party sharing: Select "Yes" if using ad SDKs
  5. Encryption: "Yes" for HTTPS communications
  6. Submit for review: Don't just save — click "Submit for Review"

Common Mistakes and How to Fix Them

Mistake 1: Declaring "User Choice" When There's No Opt-Out

If you declare a data collection as "based on user choice" but your app doesn't actually provide a way for users to opt out, that's a contradiction. AdMob's advertising ID collection is functionally required to serve ads — it should be declared as "required for the app's functionality," not user choice.

Mistake 2: Missing RevenueCat Purchase History

If you've integrated RevenueCat for in-app purchases, purchase history (financial information) must be declared.

RevenueCat Declarations:
✅ Financial Info → Purchase history → Collected: Yes
✅ Purpose: App functionality (processing purchases)
✅ Shared with third parties: Yes (RevenueCat, Apple/Google)

This is one of the most frequently missed items in Rork apps that include subscription or one-time purchase features.

Mistake 3: Wrong Location Precision

If your app uses Google Maps or any location-based feature, you need to distinguish between "Precise location" (GPS, within 10 meters) and "Approximate location" (city or region level). Using the wrong precision category will result in a policy flag.

After Rejection: What to Know Before Resubmitting

Saving is not the same as submitting: After updating the Data Safety form, just clicking "Save" doesn't trigger a review. You must click "Submit for Review" — and typically submit a new APK or AAB alongside the updated form.

You may need a new build: If the rejection is about actual app behavior (unnecessary permissions, SDK misuse), updating your privacy policy URL alone won't be enough. Submit a new build with the behavior corrected.

Review timeline: After resubmission, expect 3–7 business days for Google to review. Submitting multiple times in quick succession doesn't speed things up — it resets the queue.

Align Your Privacy Policy With Your Declarations

The Data Safety form and your privacy policy must be consistent. If you declare data collection that your privacy policy doesn't mention — or vice versa — you risk another rejection.

Here's a template snippet for AdMob-using apps:

This app uses Google AdMob to display advertisements.
Google AdMob may collect your device's advertising identifier
to serve personalized ads. For more information, please refer
to Google's Privacy Policy.

Many Rork apps use the auto-generated Expo privacy policy as a starting point, which is fine — but make sure you've customized it to reflect every SDK you're actually using. For a broader guide on data protection in Rork apps, see Rork App Privacy Policy and Data Protection Guide.

Further Google Play Policy Resources

If you're dealing with other types of Google Play rejections beyond Data Safety — metadata violations, advertising policy issues, permissions policy — see How to Fix Google Play Policy Violations in Your Rork App.

Start with your package.json, write down every SDK you're using, and work through the Data Safety form one SDK at a time. Once you have the full picture of what data flows through your app, the declarations become straightforward.

Share

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

⬡ Dev Tools2026-10-14
My App Open Ad Only Showed When the App Came Back From Background. The 'Returned to Foreground' Signal Fired Before the Ad Had Loaded
On a cold start, the app open ad in my Android app never showed. The foreground signal came before the load began. Here is how I split the signal from the load and rebuilt it as logic you can test ordering by ordering.
⬡ Dev Tools2026-10-07
Japanese Headings Won't Turn Bold on Android: How to Trace and Fix a fontWeight That Does Nothing
A troubleshooting note for Rork apps where headings look bold on iPhone but stay thin on Android. How to tell the symptoms apart, pick weights through fontFamily, and verify the fix.
⬡ Dev Tools2026-08-18
Version code 1 has already been used — who owns that number, app.json or EAS?
When a Play upload stops on versionCode, check where the number actually lives before bumping it. A one-command way to tell whether app.json, EAS, or build.gradle wins.