Privacy Policy

1. About this policy

This policy covers information handled by the Pim Will Fall game for iPhone and iPad. The game displays the credit “Created by Peiju Lin.” The legal developer or responsible entity and privacy contact have not yet been confirmed.

The descriptions below are based on a source and dependency audit of the production app. A release archive, live network traffic, actual consent screens, and AdMob dashboard settings were not verified. Google SDK disclosures describe possible processing; they do not establish that every category is collected from every player.

2. Gameplay and local information

The game processes touch movement, player position, score, in-game health, platform encounters, effects, and run state to operate gameplay. In-game health is a fictional game value. The reviewed code does not access HealthKit or collect human health information.

Current run state is primarily held in memory. The app saves your personal best floor, tutorial preferences and completed-lesson flags, music and sound-effect volumes and mute choices, and the last displayed-ad timestamp in local device preferences.

The reviewed app-owned code does not upload these gameplay values to a developer server or explicitly send them as analytics events or advertising targeting parameters. No player accounts, login, developer-operated backend, multiplayer, chat, online leaderboards, or custom cloud saves were found.

No app-owned collection of names, email addresses, postal addresses, or phone numbers was found, nor access to contacts, photos, camera, microphone recording, or precise location. Audio playback uses bundled sound files. These findings do not describe Google’s separate SDK processing.

3. Google advertising and data

The production app integrates Google AdMob interstitial advertising. The app is configured to request non-personalized ads, disable publisher privacy personalization, and disable Google’s optional publisher first-party ID feature.

Non-personalized advertising still involves data processing. Google explains that identifiers and storage may be used for frequency capping and aggregated ad reporting. See Google’s explanation of non-personalized ads.

According to Google’s Mobile Ads data disclosure and the SDK manifests inspected in the audit, Google’s services may process:

• Device identifiers and advertising information.
• Coarse location, including location inferred from an IP address.
• Product and advertising interactions.
• Crash information, performance information, and other diagnostics.

Google’s SDK declarations associate this information with advertising, analytics, or consent-related app functionality, depending on the SDK and category. Actual processing depends on the release configuration, device permissions, consent choices, and Google’s services. Disabling personalization does not establish that all identification, measurement, diagnostics, or fraud-prevention processing is disabled.

In the reviewed implementation, every third accepted Game Over → Retry action is eligible for an ad, subject to a cooldown of at least 180 seconds since the last recorded impression and ad availability. Pause-menu restarts and returning to the main menu do not use this presentation path. Consent updates and ad preloading may contact Google earlier, including after the app returns to the foreground.

4. Consent and privacy choices

The app uses Google User Messaging Platform (UMP) to update consent information and present a consent form when the SDK requires it. Ad SDK startup and ad loading are gated by UMP’s indication that ads can be requested. Previously obtained consent state may govern fallback behavior if an update fails.

When Google UMP reports that a privacy-options entry point is required, you can open Credits → Ad privacy choices in the game to revisit the SDK’s choices. Starting that flow discards cached or in-flight ad results associated with the previous choices.

Which messages, regions, vendors, and options apply depends on the published AdMob settings; these were not verified in the audit. Permission to request ads does not mean you agreed to every processing purpose, and a choice against personalized advertising does not guarantee that every Google connection stops. See Google’s UMP guidance.

5. Identifiers and attribution

No direct app-owned request for Apple App Tracking Transparency authorization, direct IDFA or IDFV access, or persistent player or device identifier creation was found. A temporary retry-attempt identifier is used in memory to prevent duplicate callbacks; app-owned code does not save or transmit it.

These source findings are not a guarantee of no identification or tracking by Google. The inspected Google Mobile Ads privacy manifest declares device identifiers with a tracking flag. Actual access and use depend on operating-system authorization, SDK behavior, consent, and configuration. Whether an SDK-managed ATT explanation or prompt can appear still requires release and dashboard verification.

The app includes SKAdNetwork attribution configuration. Its presence does not mean that every listed advertising network receives player information.

6. Analytics and diagnostics

No independently integrated analytics or crash-reporting service beyond Google’s advertising and consent services was found. Google’s SDKs can process advertising analytics and diagnostic information, and app code does not explicitly disable Google SDK crash reporting.

App-owned diagnostics primarily use local console or system logging in debug builds; no remote log uploader was found. Developer access to Apple, TestFlight, and AdMob reports and any optional reporting features still requires confirmation.

7. Storage, resets, and retention

The app stores its persistent settings in device preferences. No scheduled expiration or automatic retention period for those preferences was found. Google UMP can maintain its own consent records, whose exact storage lifecycle was not established by this audit.

• Reset high score sets your saved personal best to zero.
• Reset tutorial progress clears completed-lesson flags, rather than all app preferences.
• Neither reset clears audio settings, the ad cooldown, or Google-managed consent records.

No comprehensive delete-all-data control or third-party deletion-request interface was found. Resetting scores or tutorials does not delete information held by Google. Uninstalling the app is not a promise that all information is erased; device backup, restoration, offloading, and third-party retention require separate consideration.

A developer retention policy and request-handling process have not yet been confirmed. Google describes its own retention and privacy controls in the Google Privacy Policy; those practices are not a developer retention promise.

8. External links and this website

The game opens the developer website and this privacy-policy URL in response to player actions. Ads may also lead to external destinations. Those websites and services have their own data practices.

This website’s root layout loads Google Analytics. Website browsing is separate from the game’s local gameplay processing. Hosting logs, analytics configuration, cookies, contact flows, processors, and retention for the website require a separate review and are not established by the app audit.

9. Details awaiting developer confirmation

The following information must be resolved before this draft becomes a final published policy:

• Identity and contact: the legal developer or responsible entity, jurisdiction, privacy contact, and any required address. No contact address is assigned by this draft.
• Audience and age-related practices: intended audience, store age rating, geographic availability, and appropriate advertising and consent treatment. No age gate or explicit age-treatment configuration was found; no minimum age or child-directed status is asserted here.
• Release and advertising configuration: final archive and SDK manifests, actual requests and identifier behavior, regional consent outcomes, published messages, ad partners, mediation, IDFA messaging, and restricted-processing settings.
• Retention and requests: actual developer retention practices and a working process and contact for applicable privacy requests. This draft does not promise deletion of Google-held data through game controls.
• Other business practices: access to Apple and AdMob reports, optional analytics features, recipients, and international processing arrangements.
• Website and store disclosures: website data practices and final App Store Connect privacy answers reconciled with the shipped app.
• Publication: the final policy wording, effective date, and any policy-update procedure.

10. Google privacy resources

These official resources describe Google’s services and controls. They supplement the app-specific information above.

• Google Privacy Policy
• Google advertising technologies
• How Google uses information from partner sites and apps
• Google Mobile Ads: iOS data disclosure
• Personalized and non-personalized ads
• Google UMP: consent and privacy-options guidance