Goshuin Ledger

Privacy Policy (app)

The Japanese version of this page is the authoritative text. What follows is a reference translation. Read the Japanese version

Goshuin Ledger (“the app”) saves your records and photos only on the device you use, and does not send them to any outside server.

Business
友田 陽大
Effective date
Last revised

Basic policy

The app has no server and asks for no account registration. It embeds no advertising SDK and no tracking mechanism. Your goshuin records, photos, notes and the names of shrines and temples do not leave the device, whatever the settings below are.

There are two exceptions, and both can be stopped in Settings. From version 1.3 you can choose whether the app sends the developer a record of where the app stopped (a crash report), and from version 1.6 whether it sends how the app is used (product analytics) — which screens you opened and how often. The two are chosen separately, in the app’s “Settings → Privacy”. What they start out as depends on the app version: in newer versions both start out as “send”. When you turn one off in Settings, sending stops at that moment, and from then on that mechanism does not even start. What is sent, and to whom, is written in the “Crash reports” and “How the app is used” sections.

What this policy governs is the app itself. The website that introduces the app (goshuinbako.com, including the page you are reading) uses web analytics to improve how it reads. For how the website handles information, see Privacy Policy (website). Analysing usage in the app itself (which screens you looked at and for how long) is a mechanism separate from the website’s analytics, and you can stop it at any time in the app’s Settings. The only traffic the app sends out is the map display, purchases and restores on the App Store and, while those settings are on, the crash reports and the app usage described above.

Information the app collects

The app does not collect your name, email address or device identifiers, and never sends your location to the developer (how your current location is handled is described under “Location”). The visit dates, shrine and temple names, notes and photos you enter are saved in a database on the device, and no third party — the developer included — can read them. That does not change when “Send crash reports” or “Send app usage” is on. However, in the traffic that sends “Crash reports” or “How the app is used”, your device’s IP address reaches the party they are sent to (how it is handled is described in each of those sections). If you write to us by email from “Settings → Feedback and contact”, the developer receives your email address, your message, and the app version, iOS version, device model and display language placed at the end of the message, and uses them only to reply and to improve the app. The email is sent from your own mail app; the app itself never sends it.

Photos

The app only receives the photos you chose in the iOS system picker, and saves a scaled-down copy of them on the device. It does not ask for permission to read your whole photo library. A photo taken with the camera inside the app is likewise saved only on the device, and is not written to your photo library; permission to use the camera is asked for the first time you use the camera inside the app. A photo recorded through “Add a goshuin” or “Shoot pages” also has an editing copy of up to 4,096px on the long edge (with no information such as the capture date and time or the place it was taken) saved only on the device, apart from the scaled-down copy, so that its cropping and corrections can be redone later. For a photo you fix with “Readjust photo”, the photo as it was before the fix, or the editing copy, is kept on the device so that it can be redrawn from the original photo. The editing copy and the photo from before the fix are deleted together when you delete that record or remove the photo from “Imported photos” (any left behind because the app quit partway are deleted the next time you open the app), and they are not included in the encrypted backup file. A visit photo you keep in a visit record is likewise saved only on the device as a scaled-down copy (with no information such as the capture date and time or the place it was taken), and is included in the encrypted backup file. When you delete the visit record, or remove the photo and save, the copy is deleted too. A photo sent to “Goshuin Ledger” from the share menu of the Photos app or another app is placed, as a file, in a location on the device that only this app and its share extension can use (an App Group), and the next time you open the app it is imported as a scaled-down copy and the original file is deleted. While you keep this app’s widget on the Home Screen, the name of the shrine or temple and the date of a goshuin you received on this day in an earlier year are written to that same location (when you remove the widget they are deleted the next time you open and close the app), and only when you choose “Show photos in the widget” in Settings is a scaled-down copy of the photo it shows placed there as well (a photo it no longer shows is deleted). Dates written on a photo are read on the device by text recognition (iOS Vision) as candidates for the visit date; the recognised text is not saved and is not sent off the device. In versions that have “Find the shrine or temple from the photo”, when you press it, the text written on that photo is also read by the same text recognition and checked against the list of shrines and temples bundled with the app and the names of the shrines and temples you registered yourself, to offer candidates (if the photo contains the location where it was taken, shrines and temples near it may be added to the candidates as well; the location of a photo taken with the camera inside the app is not used). The recognised text is not saved and is not sent off the device. In versions where “Imported photos” has a “Suggestions from photos” row, the photos you put in “Imported photos” are also read one at a time by text recognition on the device while the app is open, to offer candidates for the visit date and the shrine or temple. What is kept on the device as the result of that reading is only the date that could be read, a number pointing to the shrine or temple whose name matched (an entry in the list bundled with the app, or a shrine or temple you registered yourself), clues about the reading (how the date was written, how clear the characters were, the left or right side of a spread, the number of characters in the name, the number of lines that could be read), your choice of whether to apply a candidate or not use it, the version of the reading method, the date and time of the reading, the number of times it could not be read, and whether it could be read; the recognised text itself is not kept. When a photo imported from the photo picker or the share menu contains the location where it was taken, the numbers pointing to the shrines and temples within 500m of that place (up to 10) are worked out on the device once, at import, and kept; the latitude and longitude of the place it was taken are not kept. These are kept on the device only while that photo is in “Imported photos”, are deleted along with it when you add it to a book or remove it from “Imported photos”, are not included in the encrypted backup file, and are not sent off the device (while “How the app is used” is on, all that is sent is numbers given as ranges, such as how many photos were read and how many had a candidate applied, and whether the reading succeeded or failed). So that the app can tell you “May be the same goshuin”, a short value representing how a photo looks is made on the device from imported photos and recorded photos and kept, and when you choose “Keep as a different goshuin”, the pairing of those two photos is kept as well. Neither of these contains the photo itself; neither is included in the encrypted backup file or sent off the device (while “How the app is used” is on, all that is sent is how you answered the notice and how alike the two photos are, as one of two levels). The capture date and time contained in a photo is used as the starting value for the visit date. When a photo contains the location where it was taken, that is read on the device as a candidate for placing a pin on the map of the shrine or temple. It is not used on the map until you choose the candidate; only then is a pin placed and the map around it shown (the traffic with Apple that comes with showing a map is as described under “Location”). In a record you are still writing (a draft), the place a photo was taken also stays on the device until you save or discard it. If you choose not to include location information under “Options” in the iOS photo picker, the place a photo was taken is not read at all.

Location

The app asks for permission to use your location only in versions that have a “Current location” button on the map or the Records screen, and only when you press that button (“While Using the App” only; it never asks when you open the app or save a record). If you allow it, your current location is used on the device only to show it on the map and move the map around it, and to show nearby shrines and temples on the map or in a list, nearest first, with how far away each one is; it is never saved or sent anywhere. The “Current location” button on the Records screen reads your location once when you press it and never keeps tracking it. A pin on the map is only the point you tapped yourself, the point you chose from a photo’s capture location, or the position of a shrine or temple you chose from the list bundled with the app (data from Wikidata); nothing else is saved on the device, and the app performs no address search and no reverse geocoding. The shrines and temples shown on the map from that list are also looked up in the bundled data on the device, with no network request for them.

Maps are shown with Apple’s MapKit, which communicates with Apple’s servers to fetch map tiles. Information that accompanies that traffic, such as the area being shown, is handled under Apple’s privacy policy, and the app does not save it.

In versions where shrines and temples on the map have a “Directions in Google Maps” button (the directions icon), the app hands that place’s pin to Google Maps only when you press that button, so that Google Maps can show the route. In versions where a plan’s screen in “Visit plans” has the same button, only when you press it, the app passes to Google Maps the shrines and temples lined up in the plan that have a known location, up to four at a time, in the order you lined them up. It passes the latitude and longitude only (and their order), including for a pin you placed from a photo’s capture location. It usually opens the Google Maps app if it is installed, and your default browser (usually Safari) otherwise. Your current location, the names of the shrines and temples, the plan’s name or date, notes and your records are not passed on, and Google Maps decides the starting point. The position handed over is handled under Google’s privacy policy, and the app does not save it.

Backups

The data on the device is included in the standard iOS backup (iCloud Backup and Quick Start). The backup file (.goshuin) the app exports is encrypted with the passphrase you set, and the passphrase is neither saved nor sent anywhere. If you forget the passphrase, not even the developer can decrypt the file.

Purchase information

The in-app purchase is processed by Apple’s App Store. The app receives only whether the purchase is active, and does not collect or save payment information such as your name or means of payment.

Crash reports (can be turned off in Settings)

While “Settings → Privacy → Send crash reports” is on in the app, the following is sent, and only when the app stops. What happens when you turn it off is described at the end of this section.

  • Where it stopped (the position in the program) and the kind of error (when the app itself crashes or freezes, this includes the description of the reason that iOS recorded)
  • The device model and OS version, and the app’s version and build number

Your goshuin records, photos, notes, the names and positions of shrines and temples, the name of your device and your IP address are not included. What may be sent is written in the code as an allow-list, and from reports of errors caught inside the app, anything not on it is stripped before sending, whatever kind of value it is. A report of the app itself crashing or freezing is sent directly by Sentry’s component, so it does not pass through this allow-list, but it is set up to attach no device name, IP address, screenshot, view hierarchy or history of your actions. Because there is no account, what is sent is never tied to you as a person. As for launches, moving between screens and the like — usage itself is not sent by crash reports (usage is a separate choice, under “How the app is used” below).

The processor is Functional Software, Inc. (“Sentry”, in the United States; the data is stored in the United States as well). For how they handle it, see the Sentry Privacy Policy. When a report is sent, your device’s IP address reaches Sentry, but it is not attached to the report, and Sentry is set not to write the IP address of the connection it receives into the report. When you turn the setting back off, sending from inside the app stops at that moment, and nothing is sent from the next launch on. However, during the same launch in which you turned it off, a report of the app itself crashing or freezing may still be sent. Also, reports left on the device from before you turned it off may be sent later, if you turn the setting back on.

How the app is used (can be turned off in Settings)

While “Settings → Privacy → Send app usage” is on in the app, what is sent — so that the developer can fix which features are hard to use, and where — is the order in which you opened screens, and whether what you were doing finished. While it is off, not a single event is sent.

  • The name of a screen (a fixed name this app decides), the order it was opened in, and how long it was shown
  • The name of an action (a photo imported, added to a book, exported, the purchase screen opened, and the like) and how it turned out
  • That the app froze or ended partway (the name of the screen at the time and a range for how long it stopped; in newer versions)
  • About the purchase screen: how many times you opened it, how many records you had and how many days since you installed the app (each as a range, never the records themselves), and, when it closed, whether a price was shown, whether you tapped buy and how it was closed. If you choose a “reason for not buying now”, that choice (one of five fixed options). In newer versions
  • The app’s version and build number, the OS version, the device model and screen size, and the language and time zone you have chosen
  • A random number made on the device when sending begins (it is neither an account nor a device identifier; turning this off discards it, and turning it on again does not bring the old number back)
  • Whether you installed the app from an Apple ad (in newer versions). This is Apple’s answer to the app’s query, and if you came from an ad it includes that ad’s campaign, ad group, keyword and ad ID numbers (digits assigned by Apple). The query uses only a temporary code Apple creates on the device; the words you searched for and the advertising identifier (IDFA) are not involved. The traffic for this query is handled under Apple’s privacy policy

Your goshuin records, photos, notes, the names of shrines and temples, visit dates, positions, the name of your device and anything you typed are not included. What may be sent is written in the code as an allow-list, and every value is one of a fixed set of choices, a number, or a yes or no. There is no mechanism at all for sending text you typed yourself. The app also records nothing of the screen, and embeds no component that could. The one exception is the Apple ad ID numbers below, which are sent as the digits Apple assigned; nothing but digits gets through.

None of this is used for advertising or for tracking. It is never combined with data gathered from other companies’ apps or websites, and it is never handed to a data broker.

The processor is PostHog, Inc. (“PostHog”, in the United States; the records sent are stored in the United States as well). For how they handle it, see the PostHog Privacy Policy. When it is sent, your device’s IP address reaches PostHog. PostHog is set not to record the IP addresses it receives, but that setting has been in place only since October 2026, and what it received before then still holds the IP address recorded when it was received (it is not used to estimate your region). When you turn the setting back off, sending stops at that moment and anything not yet sent is discarded on the device.

Provision to third parties

Your records, photos and notes are never provided to a third party. The outside parties the app communicates with are Apple (App Store payments and MapKit maps, and, while “How the app is used” is on, the check of whether the app was installed from an Apple ad), Sentry while “Crash reports” above is on, and PostHog while “How the app is used” is on. In none of those cases are your goshuin records, photos or notes sent.

Beyond this, the app opens a web page or another app only when you press a button or link. In versions with shrine and temple profiles, the Wikipedia article cited as the source and the page for its text’s license (Creative Commons), and, in versions where a shrine or temple has an “Official website” row, its official website as registered in Wikidata, open in the in-app browser (Safari), and “Directions in Google Maps” opens Google Maps as described under “Location”. Traffic to a page or app you open is sent by that browser or app and is handled under the policy of whoever runs it; the app does not receive what you view there. The profiles themselves (founding, sect, the Wikipedia summary and so on) are data bundled with the app and shown on the device, with no traffic for them.

Retention and deletion

Your records (visit dates, shrine and temple names, notes) and the copies of your photos are saved only on the device and stay there until you delete them. The developer has no server and never receives this data, so there is nothing held, and no retention period, on the developer’s side. What is sent by “Crash reports” is deleted by Sentry after 30 days. The retention period for what is sent by “How the app is used” is the period set under the agreement with PostHog (once that period is decided, it will be stated in this policy).

  • Deleting a goshuin also deletes the copy of its photo from the device. A photo lined up in “Imported photos” is deleted, copy and all, when you remove it from that list (the original in your photo library stays).
  • An exported backup (.goshuin) can be deleted under “Settings → Backup and phone change → Export history”. A CSV or PDF is created in a temporary area on the device each time you export, and handed to whichever destination you choose in the Share sheet.
  • A copy you saved elsewhere through the Share sheet — the Files app, iCloud Drive, email — is under your control. Delete it there when you no longer need it.
  • When you delete the app, iOS deletes the database on the device, the copies of your photos and any export files still inside the app along with it.
  • Data taken into the standard iOS backup is under Apple’s control. If you do not want it, delete the iCloud backup from the iOS Settings.
  • The record of your purchase is held by Apple and remains after you delete the app. After reinstalling, “Settings → Restore purchase” brings the purchase back. All the device holds is a note of whether you have purchased, and that goes when the app is deleted.

Withdrawing consent and requesting deletion

Because neither your records nor your photos are sent off the device, none of that data is in the developer’s hands. Sending “Crash reports” and “How the app is used” can be stopped by turning them off in Settings (sending stops at that moment). If you would like what has already been sent to be deleted, please contact us at the address below. However, because what was sent is not tied to your name or contact details, it may not be possible to identify which of it is yours, and so it may not be possible to delete it individually. In that case, we will tell you so and give the reason. To withdraw your consent to the handling described in this policy, delete the data on the device as described above and delete the app. Photos are received only as the ones you point at in the iOS system picker each time, so no continuing permission to your photo library is left behind.

Questions about how to delete, and requests to withdraw consent or delete data, are taken at the contact address below. We answer without delay once you write to us.

How to have the email address you registered on the website’s waiting list (which is now closed) deleted, and how to stop the website’s web analytics, are described in Privacy Policy (website).

Revisions

If this policy is revised, the revision is published on this page and the last-revised date is updated.

Contact

Questions about this policy: tomodahinata@gmail.com