Privacy Policy

What Fishing Weather is

Fishing Weather helps you decide whether to fish. For the waters you choose, it gives a simple GO, MAYBE, or SKIP verdict with the main reason, the main risk, and a confidence level, drawn from weather and environmental forecasts. Fishing Weather is available on the web, on iOS, and on Android, and this policy covers all three. You can use it without creating an account or signing in. Some features use persistent identifiers that can link activity from the same app installation or subscription, as described below.

Data we collect

We keep this to a minimum. There is no account, and we never ask for your name, email, or a personal profile. When you look up a water or ask for a fishing read, your device sends that request to Fishing Weather servers so we can return a forecast and verdict. No account requirement does not mean no identifiers are processed: the optional features below rely on random, accountless identifiers. If you turn on a day alert, the app registers an anonymous installation identifier (a random ID — not your name, email, Apple ID, or Google account) so our servers can evaluate and deliver that alert; on iOS the delivery lane uses your device’s push token, and on Android it uses the Firebase Installation ID that Firebase Cloud Messaging provides for message delivery. Our servers keep ordinary operational logs (such as the request and a timestamp) as needed to run and secure the service. An iOS version that enables AppsFlyer also measures installs and app opens for our own campaign performance, as described under iOS attribution below.

On Android, Firebase may generate and collect a Firebase Installation ID and related app and SDK information when the app starts or later syncs, even before you enable a day alert. This Firebase-side processing is separate from registration with Fishing Weather: when you ask to enable a day alert, our app may send that ID to our servers as part of alert registration. It may also refresh the server’s registration if a day-alert entry remains stored on your device, including after that alert date has passed. A registration update already started or queued may still send the ID to our servers after you turn off the last alert. Turning off an alert deletes its watch entry as described below, but does not by itself delete data already held by Firebase.

Location

Fishing Weather requests your device location only when you actively ask for it — for example when you tap “Nearby” to find waters around you, or “Current location” to use your position. It is a one-time reading; Fishing Weather does not request your location at launch and does not track your location in the background. Those statements describe device location access. Separately, an iOS version with AppsFlyer enabled derives approximate location from event IP addresses for attribution, as described below. On Android, the app requests only approximate (coarse) location access: it does not declare or request fine (precise) location access, and the fine-location permission entry contributed by a bundled maps component is explicitly removed from the merged app manifest.

A Nearby lookup sends that one-time coordinate to our servers once, uses it only to rank the waters nearest you, and the results never echo it back. The app does not attach your anonymous installation identifier to this Nearby request, and a Nearby lookup is not saved as a saved location. Ordinary operational logs may be retained only as described under Retention and deletion.

Saving a place is a separate path and happens only when you confirm it — a custom location you pick on the map or in search, or your current position when you choose to save it. Those saved coordinates are rounded to two decimal places (roughly a one-kilometer square) before they are saved, and later forecast or alert requests for that saved place send the rounded coordinate — see the next section.

Saved waters and custom locations

The waters you save and any custom locations are stored on your device — in the app’s local storage on iOS and Android, and in your browser’s local storage on the web. On Android this on-device state also covers your units and appearance settings, the on/off state of your day alerts, the home-screen widget’s copy of your selected water, and the anonymous installation identity used for alerts. A custom location’s coordinate is rounded to two decimal places (roughly a one-kilometer square) before it is saved, and forecast requests send that rounded coordinate so our servers can return weather and a verdict. By default this list is not tied to an account and is not synced to our servers. On Android the app also opts out of cloud backup and device-to-device transfer, so this data is not copied into Android’s backup or transfer services; if you switch devices, clear the app’s data, or uninstall the app, the local data does not carry over and may be deleted.

The one exception is alerts: when you turn on a location alert for a specific day, our servers store that day’s watch — the rounded coordinate, the name you gave the location, the selected date, and its association with your anonymous installation identifier — solely to evaluate that day’s outlook and deliver your alert. The alert on/off state shown in the app is also kept on your device so it displays instantly; that local state is separate from the server’s watch record. Alert data is never used for advertising, profiling, or cross-app or cross-site tracking. Turning a day’s alert off deletes that watch entry, including its stored coordinate and name; alerts you left on for other days keep theirs until you turn them off or they expire.

Weather and fishing reads

To produce a forecast or verdict, the app sends a request to Fishing Weather servers identifying the water or coarse location you are asking about. The servers gather the relevant weather and environmental data, compute the read, and return it. These requests carry only what is needed to answer them.

Community fishing reports

In the collection-only pilot, you may optionally submit a report for a selected water with an observation date, one to three species, an activity rating, a 20–500 character report, up to three photos, and the required ownership, storage and privacy consents. We do not ask for your name, email address, or an account. Information you choose to put in report text or photos still reaches our servers, so please do not include personal or contact information, identifiable people, or exact secret fishing spots.

Photo bytes received with the request are handled transiently in request memory. Before any photo is stored persistently, the server validates and re-encodes accepted JPEG, PNG, or WebP images as WebP, removing embedded metadata such as EXIF and GPS. Re-encoding does not guarantee that a person or place cannot be recognized from the visible image itself.

Community report rows do not store the raw request IP address. To limit abuse, the service uses short-lived hashed rate-limit keys derived from the request IP. The current pilot only collects submissions for review: there is no public community report reader or feed, and submitting does not guarantee public display.

Purchases and subscriptions

Fishing Weather may offer an optional paid tier (Plus). Where that tier is enabled, purchases are made through the Apple App Store on iOS or Google Play on Android, and your purchase and subscription status (your entitlement) is managed by the store together with RevenueCat, a subscription-management provider. The app and our servers use entitlement status to unlock paid features. In an iOS version with AppsFlyer enabled, RevenueCat may also forward subscription events to AppsFlyer for campaign revenue measurement, as described below. Fishing Weather does not receive or store your payment card details.

RevenueCat identifies a purchase with an anonymous app user ID — a persistent identifier, not your name, email, Apple ID, or Google account. It can still link subscription records to the same app user. If you have an active Plus subscription and ask for the extended weather-map outlook, the app sends that anonymous identifier with the request so our servers can confirm the subscription before returning the extended outlook; it is not attached to ordinary forecast, search, or Nearby requests.

A subscription bought on the App Store and one bought on Google Play are separate purchases handled by separate stores, and we cannot promise that a purchase on one store can be restored or transferred to the other. If a paid tier is not enabled in your version of the app, none of this applies to you.

iOS attribution and campaign measurement

This section applies to iOS app versions that enable AppsFlyer; it does not apply to a version where AppsFlyer is off, or to the web or Android apps. AppsFlyer measures installs, app opens, and the effectiveness of our own marketing campaigns. Its SDK may process app interactions and device identifiers, such as an AppsFlyer ID or an identifier for the device vendor. AppsFlyer also receives the IP address with SDK events and derives an approximate city or region for attribution. This is separate from a location you choose for a forecast. We do not send your saved waters, alert identity, push token, or selected fishing locations to AppsFlyer as part of this integration.

If you allow tracking through Apple’s App Tracking Transparency prompt, the app permits use of the advertising identifier (IDFA) and supplies the RevenueCat app user ID to AppsFlyer as a customer identifier. It also requests that RevenueCat associate the AppsFlyer ID with that subscription user. These identifiers can link app activity and subscription events for campaign measurement. RevenueCat may forward events such as a purchase or renewal, with transaction details including product, amount, currency, and an order identifier, to AppsFlyer when that association exists.

If you decline or later turn off tracking, iOS does not provide the IDFA for this purpose, and the app requests removal of its customer ID and RevenueCat–AppsFlyer association when it next observes the changed setting. This does not erase events already received by either provider, and a change may take time to reach their servers. It also does not mean the enabled SDK makes no requests or processes no other data; those details depend on the device and SDK behavior.

Third-party services and data sources

Forecasts and reads are built from public weather and environmental data providers (for example, open weather, tide, and river-gauge data sources). On Android, map display, place search, and picking a location on the map use Google’s Maps SDK for Android and Places API: place suggestions are requested from Google to show results and position the map, and only the map coordinate you confirm is saved by Fishing Weather (rounded as described above). Day alerts on Android are delivered through Firebase Cloud Messaging, which provides the Firebase Installation ID described above. Using these features means the app communicates with Google services, whose own data handling is described in Google’s privacy policy.

For weather requests that need provider data, our servers may send a rounded grid coordinate to Open-Meteo. That request does not include the unrounded Nearby coordinate, your alert installation identifier, or the name of a saved place. On Android, Google’s Maps and Places SDKs may process your IP address, device and request information, SDK-specific identifiers, and crash diagnostics; place searches and map interactions may also be processed when you use those features. To name a map-selected point or your current location, Android’s geocoding service may use a network provider. A map-selected point is rounded to two decimal places before that geocoding lookup; a current-location lookup uses the approximate device reading. The geocoding provider can vary by device.

When the paid tier is enabled, the Apple App Store or Google Play handles payment, and RevenueCat manages entitlement status (see Apple’s privacy policy and RevenueCat’s privacy policy). iOS versions with AppsFlyer enabled use it for the campaign measurement described above (see AppsFlyer’s privacy policy). Optional community submissions use Cloudflare Turnstile to help prevent abuse, a database and private object storage for submission records and processed photos, and Upstash for rate limits and short-lived upload grants. These services receive only the data needed for those functions. These providers operate under their own terms and privacy practices; this policy describes Fishing Weather’s own handling of your data and does not make legal guarantees on their behalf.

Retention and deletion

Your saved waters and custom locations live on your device — you can remove them in the app, or clear them by removing the app’s data or uninstalling it (or clearing your browser storage on the web). Day-watch entries on our servers, including a watch’s stored coordinate and name, are deleted when you turn off the alert and cleaned up automatically shortly after their date passes. Installation registration records are separate from day-watch entries: a Firebase Installation ID already sent to Fishing Weather may remain on our servers after a day-watch entry is deleted. Other server-side operational data, such as request logs, is kept only as long as needed for security and reliability and is not used to build a profile of you.

Subscription and attribution providers keep their own records under their privacy policies, linked above. Clearing local app data or changing the iOS tracking setting does not by itself delete records already held by those providers. Contact us using the address below if you want to ask about your data or request deletion; we will handle requests according to the applicable provider processes.

Pending community submissions have a retention window of up to 90 days. An incomplete uploading intent becomes eligible for cleanup after one hour. Cleanup and removal may need to retry if a database or private object-storage operation is temporarily unavailable, so we do not promise an exact physical-deletion time.

A submission receipt includes a one-time removal token that can be used with the submission ID to request deletion. The server stores only a hash of that token, not the plaintext token. The plaintext cannot be recovered or shown again, and there is no account-based recovery path if it is lost.

Your choices

Saved waters and custom locations stay on your device — you can remove them in the app at any time, and settings can be changed on your device whenever you like. Each day’s alert can be turned off on its own. For an iOS version with AppsFlyer enabled, you can change Fishing Weather’s tracking permission in Settings → Privacy & Security → Tracking. This controls the IDFA and the app’s identity-linking requests described above, but is not a retroactive deletion request. You can email hi@fishingweather.com with any data question.

Contact

Questions about this policy or your data? Email hi@fishingweather.com.

Policy updates

We may update this policy as Fishing Weather changes. The date at the top of this page shows the latest revision.