Fallcast Privacy Policy
Effective date: 2026-10-02
"Fallcast," "we," "us," and "our" refer to the Fallcast iOS application (the "App") and the service provided through it by its developer. This Policy describes the App's data practices as of the effective date above.
Contact: fallcastapp@gmail.com
In short
Fallcast has no accounts, no sign-in, no analytics, no advertising, no crash reporting, and no third-party code libraries of any kind — it is built solely on Apple's frameworks. Nearly everything it does happens on your device.
Three things go from your device to us, and you begin every one of them yourself, one at a time: a color rating you save, a photograph you submit for a place, and a photograph you submit to teach Foliage ID. There is a fourth request, which stores nothing: a check on whether a username you are typing is already claimed.
One optional feature works differently, and is off unless you have Season Pass and Live Activities switched on: it sends the plan for the next days of a saved trip ahead of time, so Fallcast can put each morning's card on your Lock Screen without you opening the App. What it sends, why, and how briefly it is kept are set out under "Other network activity."
No reading of where you are is ever sent to us or to anyone else. It leaves your device in one direction only — into your own Apple account, if you use iCloud, as part of a species sighting you saved. The one thing that can reach us is different in kind: the coordinates of a stop you chose for a trip, which are a place on your itinerary and not where you are, and which are sent only for the optional Lock Screen feature described above.
What stays on your device
Location. If you grant "While Using the App" access, your coordinates are used on the device to show your local forecast, suggest a trip starting point, order the Field Guide by what grows near you, and inform Foliage ID. The App asks for coarse, kilometer-level accuracy, asks only when a feature first needs it, and every one of those features also works with a location you pick by hand. Nothing is stored and nothing is sent. (If you start a trip from your current location, the stop that creates is a stop on the trip like any other; see "Trip days on your Lock Screen.")
Nearby Alerts are optional and off by default. Turning them on is what triggers the iOS "Always" location request. iOS then watches regions around your saved places at a radius you choose, and when you enter one, the App decides on the device whether that place is worth telling you about and schedules a local notification. No location data leaves the device for this feature. Turning it off, or revoking the permission in iOS Settings, stops the monitoring.
No widget reads your location. Widgets read a snapshot file the App prepares; they take no position fix, rank nothing, and make no network requests.
Camera and Foliage ID. Camera access is requested only when you tap "Take Photo." Choosing a library photo uses Apple's out-of-process picker, so the App receives the one photo you picked and has no access to your library. Identification runs on the device against a model bundled with the App. For a library photo, embedded location and date are read in memory to inform the result and are not kept unless you save the sighting.
What you create. Sightings, trips, journal notes and photos, favorites, pins, ratings and preferences are stored in the App's own storage on your device. Alerts are local — scheduled on your device, composed on your device. The one exception is the optional trip-day Live Activity described under "Other network activity," which Apple's push service starts on the morning it is due. The counters that decide when to show Apple's rate-this-app prompt stay on the device too.
What you can send us
Each of the three is a deliberate act. Nothing in this section is sent in the background, and there is no setting that sends for you. (The one scheduled upload is separate, and is described under "Other network activity.")
A color rating. Saving a rating submits it — there is no separate send step and no device-only mode. It contains the place you rated, the visit date, the rating on our six-class scale, the App and model versions, the timestamp, and a random identifier. It contains no name, email, device identifier, photo, username, or location.
> Ratings cannot be withdrawn. We keep submitted ratings > indefinitely and offer no deletion-by-request route, because a stored > rating carries no name, email, device or account — there is nothing > that would let us establish which submissions are yours, and nothing > that would let you point at them. You can delete your own copy > (Preferences → "Your Ratings", swipe), which does not recall what was > already sent. If you would rather a rating not be stored by us at > all, the control is not to rate the place.
A photograph for a place. You open one of your own journal photos, read what you are agreeing to, and confirm with a switch that you took it or hold the rights. It travels with the place you chose, the date taken, an optional caption, the acknowledgement version, the App version, an identifier, and — only if you choose to be credited — your username. The image file carries no location: it is stripped when the photo enters your journal, checked again before sending, and rejected by the receiving service if any GPS tag survives.
A submitted photograph is not public. It lands in private storage with no public address and goes to a review queue a person reads. Nothing is displayed unless it is accepted; if it is, it appears as a photograph of that place credited to your username or to "a Fallcast user," and nothing else about you is shown with it. A declined photograph is kept out of the queue so the decision can be reconsidered. Deleting the photo from your journal removes your copy but does not withdraw the submission — to withdraw one, email fallcastapp@gmail.com.
A photograph to teach Foliage ID. When Foliage ID names a species wrongly, you can pick the right name and send the photo with that label. Same acknowledgement, every time. It travels with the species you picked, which model was wrong and what it answered, the date taken, the acknowledgement and App versions, an identifier, and your username only if you choose to be credited. The image is re-encoded so no embedded location survives, and is verified before sending. There is no place identifier and no caption — the receiving service refuses a submission carrying either.
Training photographs are never published in the App. They are kept apart from the place-photo queue as material for training a future model, and retained indefinitely for that purpose. Sending one does not change the model on your phone. To ask for one to be removed, email fallcastapp@gmail.com.
A username is optional, is a credit line for photographs and nothing else, and gates no feature. You are asked once, at your first submission, and declining is a real answer. While you are typing one, the App asks our photo service whether the name is already claimed; that request carries the name and your identifier, writes nothing, and is advisory. For each claimed name we hold one entry: the name, and a one-way hash of the identifier that claimed it.
The identifiers a submission carries
Two, both randomly generated by the App, neither derived from your device, neither displayed anywhere in the App:
an install identifier, which accompanies ratings and Foliage ID training photos. It is per installation, never synced, and reset when you delete and reinstall the App; a person identifier, which accompanies place-photo submissions and the username check. It is kept in your own iCloud account so your credit line is the same on every device you own — which means reinstalling does not reset it, and photos from your phone and iPad are recognisable as one person's. Signing out of iCloud leaves the App with a device-only value again.
Both are replaced by a one-way keyed hash before anything is stored, so the identifier itself is never written down. Stated precisely, because the difference matters: that is pseudonymisation, not mathematical anonymity. We hold the key, so if someone supplied a particular identifier the matching records could be recomputed. Nobody is in a position to supply one — the App never displays it and sends it nowhere else — but the honest claim is that the identifier is not stored, not that the records could never be linked.
The optional trip-day feature has a third random identifier of its own, made for that feature alone and hashed the same way, so what it holds cannot be matched to a rating, a photograph or a username. The same precision applies: it is pseudonymised, not anonymous.
Submissions are stored in our own storage on Cloudflare. Nothing is added to what you sent beyond the time it arrived: no IP address, no device or browser identification, no other request metadata. As with any internet request, your IP address is visible to the hosting provider in transit, subject to Cloudflare's own practices; we do not use such logs to identify anyone.
iCloud sync
If you are signed in to iCloud, the things you save sync across your devices through your own Apple account, which we cannot read. That covers favorites and pins, preferences, your ratings, your trips, your species sightings, your journal notes, your journal photographs, and your username with the identifier described above.
Two consequences worth stating plainly:
Location-derived data syncs to your Apple account. A sighting records the locality name — and, for a Foliage ID sighting, the coordinates — at the moment you logged it. Those go into your account and nowhere else. Journal photographs use your iCloud storage, not ours. They sync through CloudKit's private database, which Apple bills to the account that owns it and which we cannot see, list, or access. Location is stripped from every journal photo's image file; the App keeps the place and capture date as ordinary fields on its own record, inside your account. Deleting a photo, or its trip, deletes it everywhere.
Photos attached to species sightings never sync at all — they stay on the device that took them, and a sighting arriving on another device shows a placeholder.
Not synced: the install identifier, the separate identifier the trip-day feature uses, whether Nearby Alerts is on, and device-local bookkeeping such as which alerts a device has shown.
Other network activity
Besides the submissions above, and the one scheduled upload described at the end of this section, the App downloads forecast data, map tiles and species photographs from our static file server on Cloudflare R2 — unauthenticated requests carrying no account, identifier or personal data. Map screens use Apple's MapKit; prices and purchases use Apple's StoreKit; both are governed by Apple's privacy policy. Tapping "Map it!" hands a route to Apple Maps or Google Maps at your choice, after which that app's policy governs; Google Maps is offered only if it is already installed, and the App does not itself contact Google.
The App makes no calls to third-party weather services. Forecast inputs are gathered and processed on our own infrastructure, and the App downloads only the finished files.
Trip days on your Lock Screen. This is the one place the App sends something to us on a schedule rather than at your tap, and it exists only if you have Season Pass and Live Activities switched on for Fallcast. Each morning of a saved trip, Fallcast puts that day's card on your Lock Screen. The App does that itself whenever you open it. To do it on a morning you have not opened the App, Apple's push service has to start it, and for that a small service of ours holds the plan for the next few days until each morning comes.
So, while a trip is coming up, the App sends that service: a random identifier made for it alone; the token Apple issues to your phone so a Live Activity can be started on it; whether the App is a test build or the released one, so the push goes to the right Apple server; the App's version number, which the service checks and does not keep; and, for each of the coming days of the trip (at most fourteen, counting from today), the finished card for that day. That is the trip's name, the name and coordinates of the day's first stop, the forecast lines the App has already worked out for it (the color, when it is expected, whether it is still on track), the text of the notification, and the time to send it, which is seven in the morning where that stop is. The coordinates are those of a stop on your trip: a place you picked or typed, and not a reading of where you are. The App sends no position fix. The service composes nothing and reads no forecast of its own: it holds what the App worked out and, at the time given, posts it to Apple's push service, which delivers it to your phone. Apple sees that push as it sees any notification sent to your phone, and Apple's privacy policy governs that last step.
We hold each day's entry for as short a time as the morning needs. It is deleted as soon as it has been sent, or skipped because it was missed by more than three hours, or replaced when the App sends an updated plan, or dropped when Apple's push service says it cannot reach your phone, and at the very latest within minutes after that day ends. If you switch Live Activities off, or Season Pass lapses, or the trip has no days left, the App asks the service to delete what it holds the next time it runs; if it cannot reach us then, the entries still expire by themselves when each day ends. Nothing about a trip outlives the trip, and we keep no record of what was sent. If you have no Season Pass, or have Live Activities off, the App uploads no plan; the only thing it may send is that request to delete, carrying the random identifier and nothing else.
The identifier is stored as a one-way keyed hash and never in the clear (pseudonymisation, as described above, not anonymity). The push token is stored as sent, because Apple's service needs it to reach your phone; for as long as the entry exists it identifies your phone to us and to Apple. The trip name and stop names are whatever you typed or chose. As with submissions, nothing is added to what the App sent: no IP address, no device or browser identification, no other request metadata. What the service logs is counts and Apple's status codes, never a token, a trip name or an identifier. It sits on Cloudflare, separate from the ratings and photograph services, and as with any internet request your IP address is visible to the hosting provider in transit.
Purchases
Season Pass is an auto-renewing annual subscription, processed entirely by Apple. We do not receive your payment details, name, or Apple ID. The App reads your subscription's status on the device through Apple's StoreKit framework to decide which features are unlocked, and stores only the resulting flags locally; that status is not transmitted to us. Apple provides us standard aggregated sales reporting that does not identify individual customers.
App Store privacy label
Apple defines "collected" as data transmitted off the device in a way we or our partners can access. On that definition the App collects data through the three submissions above and through the optional trip-day service, and through nothing else, in three of Apple's categories: user content, identifiers, and usage data (limited to the App and model versions and timestamps that travel inside a submission).
The trip-day service adds to those categories without adding a new one. Under user content it holds the trip name, the stop names and coordinates, and the card and notification text (Other User Content). Under identifiers it holds its own random identifier and the push token Apple issues for your phone, both under Device ID. It adds nothing to usage data. Its purpose is App Functionality: starting the card you asked for.
All of it is declared linked to you. For ratings and photographs, that is because nothing we receive arrives without the identifier that can hold a username claim — a name shown in public beside an accepted photograph. Submitting anonymously keeps your username off that particular submission; it does not change what the label says about the data type. The trip-day service's identifier cannot hold a username claim and is never joined to anything else, but the entry is tied to one phone for as long as it exists, and Apple's questions are asked of the data type and not of each request, so Device ID and Other User Content stay linked. None of it is used for tracking, and the App neither reads the vendor identifier nor requests the advertising identifier.
Location is not collected: it is processed on the device, no submission of any kind carries a reading of where you are, the trip-day service holds the coordinates of stops on a trip you built (places you chose, declared above as part of the trip under Other User Content) and not your position, and the sync described above goes into your own Apple account, which Apple does not make available to us.
Permissions at a glance
| Permission | When requested | Required? |
|---|---|---|
| Location — While Using | First time a location-aware feature is used | No — you can pick a location by hand |
| Location — Always | Only when you turn on Nearby Alerts | No — used solely for that feature |
| Camera | When you tap "Take Photo" in Foliage ID | No — library photos work without it |
| Notifications | When you turn on alerts | No |
Children
The App is not directed at children and collects no personal information — no name, email, or other contact detail — from any user. A username, where one is set, is a handle you choose and can change or clear at any time.
Your choices
Revoke location, camera, or notification permission in iOS Settings. Turn off Nearby Alerts in Preferences; this stops all background region monitoring. Turn off iCloud for Fallcast in iOS Settings. Switch Live Activities off for Fallcast in iOS Settings to stop the trip-day uploads; the App then asks the service to delete what it holds, the next time it runs. Without Season Pass none is sent. Delete the App to remove all of its local data. Anything the trip-day service still holds is deleted within minutes after its day ends. Delete one of your own ratings: Preferences → "Your Ratings", swipe the row. This clears your device and iCloud copies, not a submission already sent. Decide each time whether to rate a place at all — that decision is the only control over what we receive, because saving is submitting and a submitted rating cannot be withdrawn. Decide each time whether to submit a photograph, and whether to be credited or to submit anonymously. Ask for a submitted photograph of either kind to be withdrawn, by emailing fallcastapp@gmail.com. Set, change, or clear your username in Preferences.
We keep no server-side account or profile about you. The only things we hold that came from your device are what you submitted and, while a trip is coming up and you have the trip-day Live Activity on, the plan for its next days. We neither sell any of it nor share it with third parties; the only place the trip-day plan goes besides our own storage is Apple's push service, to reach your phone.
Changes to this Policy
This Policy describes the App as of the effective date. If a future version changes any practice described here, the Policy will be updated before or together with that change: the effective date revised, the change recorded below, and material changes noted in the App's release notes.
Change log
- 2026-10-02 — Added the optional trip-day Live Activity service, off unless you have Season Pass and Live Activities on: what the App sends it, why, and how briefly it is kept. The App Store privacy label section is updated to match. One earlier statement is corrected: that notifications involve no push service. The morning start of a trip-day Live Activity uses Apple's push service. One earlier statement is made exact: that your location is never transmitted now says that no reading of where you are is, and that the coordinates of a stop you chose for a trip can be, for that feature only. No other practice changed.
- 2026-09-09 — Rewritten to be read rather than waded through; no practice changed. One correction: the previous version described Season Pass as a one-time purchase with a permanent unlock, which stopped being true when it became an auto-renewing annual subscription on 2026-09-09.
- 2026-09-08 — First version.
Contact
Questions about this Policy: fallcastapp@gmail.com