CA Hunt & Fish Guide — effective October 13, 2026
CA Hunt & Fish Guide is published by Fernando Enterprise LLC, a California limited liability company. The app has no accounts, no analytics, no advertising, and no trackers of any kind. There is no server behind it. The developer receives no personal information about you, holds none, sells none, and shares none.
Everything you enter into the app — your licence and tag records, your dive log, your equipment list, your waypoints, your watched places, your settings — is written to a file inside the app on your own device. The app never sends any of it anywhere, and the developer never receives it, with one exception spelled out in section 4: asking for Area information at a waypoint or a pin sends that point's coordinate to the National Weather Service for the forecast there, and nothing else. One thing does leave your phone, and it is not the app doing it: if you back up your iPhone, iOS puts these files in that backup, the same as it does for other apps. That is between you and Apple, and section 2 says exactly what is known about it.
The app does make requests over the internet, and this policy says exactly which ones, to whom, and what they carry. Section 4 is the important one, and it is more detailed than most privacy policies because the honest answer needs the detail.
Nothing.
There is no sign-up, no login, no email list, no crash reporting, no analytics SDK, no advertising SDK, no advertising identifier, no fingerprinting, and no server that could receive your data even if the app tried to send it. The developer cannot identify you, cannot tell how many times you opened the app, cannot tell what you looked at, and cannot connect anything in this app to you.
Because nothing is collected, there is nothing to sell, nothing to share, and nothing to disclose to anyone for their direct marketing purposes — and the developer does none of those things.
All of the following is written inside the app's own container on your device — most of it as files in Application Support, and the preference-shaped items in the app's own preferences store. The app sends none of it to the developer or to anyone else, and there is no server it could be sent to. All of it is removed when you delete the app. The one exception is an iPhone backup, described at the end of this section.
beach_water_quality_current.json) and keeps it, with a small companion file describing it, as beach_water_quality_live.json and beach_water_quality_live_meta.json. It is the same file for every reader — the readings seven California coastal counties published, in those counties' own words, collected by the developer and not by your phone — so it says nothing about you, nothing about which beach you looked at, and nothing about where you are. It is kept so that the layer still works where there is no signal, and so that opening it a second time does not download it again. It is replaced when a newer one is published, and deleting the app deletes it.verification_current.json) and keeps it, with a small companion file describing it, as verification_live.json and verification_live_meta.json. It is the same file for every reader — it holds no regulation, says nothing about you, and names nothing you looked at — so the request carries no query string, no body and no cookies. It is kept so the home screen still knows when the sources were last checked where there is no signal. That host is the same one § 4 already names under "Dataset downloads"; this adds no new destination. It is replaced when a newer one is published, and deleting the app deletes it.in_season_status_current.json) and keeps it, with a small companion file describing it, as in_season_status_live.json and in_season_status_live_meta.json. It is the same file for every reader, so it says nothing about you, nothing about which regulation you looked at, and nothing about where you are, and the request carries no query string, no body and no cookies. It is kept so the notes still show where there is no signal. That host is the same one § 4 already names under "Dataset downloads"; this adds no new destination. It is replaced when a newer one is published, and deleting the app deletes it.kelp_canopy_current.json) and keeps it, with a small companion file describing it, as kelp_canopy_live.json and kelp_canopy_live_meta.json. It is the same file for every reader — where CDFW's 2016 aerial survey mapped kelp along the coast, read from CDFW's archive by the developer and not by your phone — so it says nothing about you, nothing about which stretch of coast you looked at, and nothing about where you are. It is kept so that the layer still draws where there is no signal, and so that switching the layer on again does not download it again. It is replaced when a newer one is published, and deleting the app deletes it.beach_water_quality_cache.json), together with when each station was last asked about, and it used to keep a county-status sidecar beside it. It keeps neither, and the first launch of every version since deletes all three (beach_water_quality_cache.json, beach_status_live.json, beach_status_live_meta.json) if they are on your phone, so that this sentence is true of your phone and not only of a new one. The file described in the bullet above is a different file, with a different name, holding the counties' own published words rather than the State's measurements.If you back up your iPhone to iCloud or to a computer, iOS decides what goes into that backup, and these files live in the app's Application Support folder, which iOS ordinarily includes. That backup is between you and Apple under Apple's terms. The developer does not control it, never sees it, and cannot read it.
Everything you entered can be viewed, edited, and deleted inside the app, on the screen where it was created — the wallet, the dive log, the equipment list, the waypoint list, the watchlist, and Settings. Deleting a record deletes it from the file on your device.
Five of the items in section 2 are the app's own bookkeeping rather than something you entered, and they have no delete button of their own: the record of which version of the Terms you accepted and when, the app's record of the dataset, whether you are a founding user, which subscription you have already been shown the terms for, and the cached map tiles. The first four exist so the app behaves correctly and the fifth so the map draws offline; none is sent anywhere, and all five go when the app is deleted.
Deleting the app removes everything at once. There is no copy on any server, so there is nothing to ask the developer to delete and no request process to go through: the delete button in the app, and deleting the app, are the whole mechanism.
Your GPS position stays on your phone. When you use "Where am I?", the location fix is compared against boundary data already stored on the device, and the answer is computed there. The fix is not sent to the developer, to any server, or to anyone else. There is no code path in the app that sends your device's position over the network.
What does leave the device is the places you look at, not where you are. These are two different things, and the old version of this policy blurred them. Specifically:
basemap.nationalmap.gov) or NOAA (encdirect.noaa.gov) for the tiles covering the area on your screen. Those servers therefore see which part of California you are looking at. Tiles already fetched are kept in the app's cache on your device, so the same area asked for again may not produce a request at all. And, with the Depth overlay on, the app asks that same NOAA service for the depth contours covering the area on your screen. That request carries the corner coordinates of your screen, so that server sees which stretch of coast you are looking at — the same shape of disclosure as the tiles themselves. It is made when the map comes to rest, not while you are moving it, and not at all when you are zoomed out past the point where the app draws depth.epqs.nationalmap.gov) for that point's elevation. You do not have to tap anything more for that request to go out, so it is worth being plain about: opening the readout sends that coordinate. It is a point you chose on the map, not a reading of where you are — but if you press where you are standing, it is the same point, and you should know that. Opening a waypoint you saved earlier does not send anything; the elevation request happens only on the readout for a point you just pressed.encdirect.noaa.gov) what depth its nautical charts give for that point. Like the elevation request above, it goes out automatically when the readout opens — you do not have to tap anything more — so that server sees the point you pressed. It is a point you chose on the map, not a reading of where you are, but if you press where you are standing it is the same point. When the Depth overlay is off, the app makes no depth request at all, and the readout shows no depth row. Opening a waypoint you saved earlier sends nothing. That service is already named above for the chart tiles; the Depth overlay adds no new host.api.weather.gov), NOAA tides and currents (api.tidesandcurrents.noaa.gov) and the National Data Buoy Center (www.ndbc.noaa.gov). Area information is different: when you open or refresh it for a pin you dropped, coordinates you entered or a waypoint you saved, wherever that point is, the app sends the point's coordinate to the National Weather Service (api.weather.gov) for the forecast and the nearest weather station's readings there, and nothing else. The National Weather Service answers for the United States and its waters, and the page says so when a point is outside them. The rest of the page is worked out on your phone, and a waypoint's name and note stay on the device.thredds.cdip.ucsd.edu) for the last three hours of wave height, wave period, wave direction and sea-surface temperature at every one of its buoys at once. It does not ask about the buoy nearest you, and it could not: the request names no buoy, no spot and no coordinate, and it is byte-identical for every reader of this app anywhere in California. That server therefore learns that this app asked, and nothing else — not which spot you opened, not which stretch of coast you were looking at. The app then picks the buoy for your spot out of the answer, on your phone. Asking for one buoy at a time would have been faster to write and would have told them which one you wanted, which is why it is not what happens.erddap.caloos.org, or erddap.cencoos.org for a few stations) for the last two days of readings at that one station. Unlike the buoy request above, this one names a station, so that server sees which pier's readings you asked for — the same shape of disclosure as the tide station and the buoy number in the paragraph above this section's satellite ones, and for the same reason: it is the only way to ask. It is a pier this app publishes in its own dataset, not a reading of where you are, and the app always shows you how far that pier is from the spot — two kilometres at some, forty at others — because the same number means two different things at those two distances. A spot with no such instrument within 100 km makes no request at all and the app says so.fernando-enterprise-llc.github.io) — the same file for every reader, naming no spot in the request, asked for once rather than once per spot. That host is the same one § 4 already names under "Dataset downloads" below; this adds no new destination.api.tidesandcurrents.noaa.gov, already named above) and shows those instead; the computed curve is the fallback and is labelled as computed.fernando-enterprise-llc.github.io) for one file holding NOAA CoastWatch's satellite water-clarity values for every spear entry point. It is the same file for every reader, it names no spot in the request, and it is asked for once — never once per spot. Your device does not contact NOAA CoastWatch (coastwatch.noaa.gov) for this. NOAA's satellite grid is read once a night by the developer, on the developer's own machine, and what your phone downloads is the result of that reading — so NOAA's servers see neither you, your device, nor which spot you opened. It used to work the other way: opening a spot sent that spot's coordinates to NOAA CoastWatch, twice, and when that server did not answer the screen said so instead of telling you anything about the water. That host is the same one § 4 already names under "Dataset downloads" below; this adds no new destination.fernando-enterprise-llc.github.io) for one file holding the readings seven California coastal counties published. It is the same file for every reader, it names no beach, no station and no county in the request, and it is asked for once — never once per beach and never as you pan. When the layer is off, the app makes no water-quality request at all. It used to ask the California Open Data Portal (data.ca.gov) for the State's bacteria results at the monitoring stations for the beaches on your screen, and that request named those station codes; it does not, and data.ca.gov is no longer a host this app contacts for anything. Your device never contacts a county. The counties are read once a day by the developer, on the developer's own machine, and what your phone downloads is the result of that reading — so no county server sees you, your device or anything you looked at. That host is the same one § 4 already names under "Dataset downloads" below; this adds no new destination. The list of coastal counties and the address each one publishes its readings at still ships inside the app, so opening that list downloads nothing; tapping a county hands its address to your browser, and the paragraph on links you tap below says what that means.fernando-enterprise-llc.github.io) for one file holding the kelp beds CDFW's 2016 aerial survey mapped along the whole coast. It is the same file for every reader, it names no bed, no spot and no stretch of coast in the request, and it is asked for whole — never as you pan. Before asking for it the app reads that host's small index of live files, the same index for every reader, and it downloads the kelp file only when your device holds no copy or the index lists a different one; what arrives is checked against the size and checksum the index lists before it is kept. When the layer is off, or your device is not entitled to Pro, the app makes no kelp request at all — so, as with the three smaller files under "Dataset downloads" below, a host that kept request logs could tell a device that asked for it from one that did not. Your device never contacts CDFW for this. The survey is read by the developer, on the developer's own machine, and what your phone downloads is the result of that reading. That host is the same one § 4 already names under "Dataset downloads" below; this adds no new destination.api.weather.gov) for the forecast and any alerts, NOAA tides and currents (api.tidesandcurrents.noaa.gov), the National Data Buoy Center (www.ndbc.noaa.gov) and NOAA CoastWatch (coastwatch.noaa.gov). It contacts no host that is not already named in this section. The trip planner is now the ONLY part of this app that asks NOAA CoastWatch anything: the spear spot pages stopped doing so, as the water-clarity paragraph above describes, and a trip plan is something you press a button to run rather than something that happens when a screen opens. Readings this app collects centrally rather than on your phone — stream gauge flows, for one — arrive with the dataset download described below and cost your device no request at all. Each request the app makes about a PLACE names a place or a station the app already publishes in its dataset — a lake, a zone, a named tide station, a numbered buoy. One request is not like the others, and it is the subject of the paragraph after next: when you plan a trip around a spot of your own rather than around a place this app publishes, the forecast for that spot is asked for by its coordinates, because coordinates are the only way to ask for it. Those are coordinates you placed — a pin you dropped or pasted — and never a reading of where you are; nothing in this app reads your position to build a plan. Those servers therefore see which places, or which spot, you asked about, which is the same shape of disclosure as the map tiles above, at the moment you press the button rather than continuously.api.weather.gov), to fetch the forecast for that spot. That is the same host § 4 already names for every other trip, and it is told a position rather than a place name — which is a real difference from the rest of this section, and it is your choice to make: pick a place from the app's own list instead, and the app asks about the place rather than about your pin. Deleting the saved trip deletes the pin with it.fernando-enterprise-llc.github.io). That includes the files a subscription unlocks. Taking the regulations dataset itself first: The download is the same for everyone and carries nothing about what you bought — every device asks for the same files and receives the same bytes — and whether your device is entitled to Pro is decided on the device from Apple's signed transaction record, after the files have arrived, so the file host is never told which tier you hold, never asked to check one, and has no account, sign-in or token to check it against.Three smaller files sit beside that dataset and work differently, and it is worth being plain about them rather than leaving you to work it out. CDFW's waterfowl hunt results, CDFW's deer harvest table and the operator directory are bytes only a device that can open a Pro planner screen has any use for, so before asking for them the app decides — on your own device, from the same signed record — whether it can open one, and if it cannot it does not ask for them at all. Which of those three a device asks for is therefore not identical for every reader, and a host that kept request logs could tell the two groups apart from the file names alone. Nothing in any of those requests names you, your device, your purchase or your position, there is no server of the developer's anywhere in that path, and the developer keeps no logs of any of it.
Every one of those requests carries your device's IP address to the server that answers it, the same as opening any web page. Several of them also carry a line identifying the app and the developer — "CAHuntFishGuide/1.0 (support@fernandoenterprise.com)" or the same in a slightly different form — because the National Weather Service and NOAA require a caller to identify itself and refuse requests that do not. That line names the developer, never you. The developer receives nothing from any of these requests, keeps no logs, runs no server in the path, and has no account to attach anything to. Those servers are run by the agencies and companies named, under their own privacy practices, not the developer's.
Season reminders, deadline reminders and wallet reminders are local notifications scheduled by the app on your device. There is no push server, no push certificate, and no notification service in between. Nothing about a reminder leaves your phone, and the reminders still work with the phone in airplane mode.
The optional subscription — CA Hunt & Fish Pro — are sold and billed by Apple through your Apple Account. Apple handles the payment; the developer never sees your payment details, your name, your billing address, or your Apple Account. Which tier your device is entitled to is determined on the device from Apple's own signed transaction record, and whether you are a founding user is determined the same way, from Apple's signed record of when your account first obtained the app. Both of those come from Apple to your device and go no further. Apple's handling of that data is governed by Apple's privacy policy. Refunds are handled by Apple at reportaproblem.apple.com.
This app does not track you over time or across other apps or websites, and no third party collects information about your activity through it. Because the app does not conduct that kind of tracking at all, there is nothing for it to change in response to a browser or system "Do Not Track" signal, and it does not respond to one.
No. There is no analytics SDK, no advertising SDK, no attribution SDK, no session-replay script, and no third-party tracker of any kind in this app. No other party collects personally identifiable information about your activities over time or across different websites or apps through your use of it.
The servers named in section 4 receive the individual requests described there and nothing more, and they are government agencies and platform providers operating under their own published practices.
The app shows state and federal health-related information about *places* — fish-consumption advisories and safety notices — attributed to the agency that published them, with the date. It also shows beach water-quality readings for the counties that publish them and allow this app's developer to read them automatically, in those counties' own words and numbers, with each county's own date; it shows no water-quality reading of its own, works out no band or conclusion from a county's numbers, and for every other county it links out to the page that county publishes. That information describes a location on the day it was sampled or issued. It is not a determination about you, about your health, or about whether anything is safe to do, and the app makes no such determination. The app collects no health information about anyone.
The app is not directed to children. It is rated 13+, its subject is state hunting and fishing regulation, and it has no accounts, no messaging, no user-generated content shared with anyone, and no advertising. It collects no personal information from anyone, of any age, including no transmitted location information.
The publisher of this app is Fernando Enterprise LLC, a California limited liability company, reachable at support@fernandoenterprise.com or by mail at 2710 Alpine Boulevard, Alpine, CA 91901. CA Hunt & Fish Pro is $34.99 per year or $5.99 per month, billed by Apple; the app itself is free. Questions and complaints may be sent to either address. The Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs may be contacted in writing at 1625 North Market Blvd., Suite N 112, Sacramento, CA 95834, or by telephone at (800) 952-5210.
The developer does not disclose personal information to third parties for those third parties' direct marketing purposes, because the developer holds no personal information.
This policy will change when the app changes. When it does, the updated version is posted at this address with a new effective date, and the previous version stays published so that the policy in force on any past date can be checked. If a change ever means the app starts collecting something it does not collect today, that change will be described here in plain words, on this page, before or when it takes effect — not folded silently into a list.
Questions about this policy or the app: support@fernandoenterprise.com (Fernando Enterprise LLC, publisher), or by mail at 2710 Alpine Boulevard, Alpine, CA 91901. You may also open an issue on the public data repository at https://github.com/Fernando-Enterprise-LLC/ca-hunt-fish-releases/issues. Reports of wrong or outdated regulation data are the most useful thing you can send.
CA Hunt & Fish Guide is an independent, unofficial reference and is not affiliated with, endorsed by, or approved by the California Department of Fish and Wildlife or the State of California.