# Keep coach check-in photos out of the camera roll: a dated collection you can find again > Model progress photos as a dedicated, dated collection with a comparison path, and treat access and deletion as separate server-side controls you build and test. > By Dave ยท 2026-11-02 > Source: https://otf-kit.dev/blog/fitness-progress-photo-privacy-and-retrieval How does a fitness app keep check-in photos separate from a phone's camera roll and still find the right pair later? Give each check-in its own dated entry in a dedicated collection, and build access and deletion as explicit controls that you implement and test. Neither comes for free because a progress screen exists. A builder posted about this pain in late October 2026, in a thread about getting a first customer after launch. It is one source, not market research. It still points at a concrete product shape, and that shape is easy to get partly right and still wrong on access. ## Give check-ins their own collection A check-in photo is not a vacation album. Store each one as a record with the member, the date, the pose or angle, an optional note, and an optional body metric. Keep the image out of the general photo library on the device so it is never mixed into the user's other media. Keep it out of the activity timeline too; [the guide to combining lifts, runs, and steps](/blog/fitness-history-lifts-runs-steps) covers why unlike records belong in separate types. Use the record as the unit of retrieval. A timeline by member and date answers "what did we have last month?" A comparison view answers "show me the start and now." Both depend on the same fields being captured every time, so capture the angle and lighting cues consistently. Otherwise the two photos you put side by side will not be comparable, and no retrieval code will fix that. ![Dex, Luna, Byte, and Nova compare a loose photo pile with a more distinguishable set of dated, contextual cards.](https://cdn.otf-kit.dev/blog/fitness-progress-photo-privacy-and-retrieval/inbody1-20261101-c9152e7c-aria-v1.png?v=20261101-c9152e7c) *Illustrative photo-entry organization idea; not a claim about Fitness Kit privacy controls or storage behavior.* ## Decide access before you build the screen Progress photos are sensitive, so write the access rules before the first screen. The questions to settle are: - **Who may view a check-in.** A member, their coach, or an admin each need a stated rule. - **Where the rule is enforced.** Ask the server for a short-lived, signed access URL for each image. The client should not be the source of truth for who may see what. - **How deletion works.** A delete should remove the stored file, the database record, and any cached copy on the device. Test that path end to end, not only the button. - **How long files are kept.** Write the retention rule down before launch, even if the rule is simply "until the member deletes them." Treat these as product requirements to build and review. A screen that displays photos does not satisfy them. Whether someone can use the app before creating an account is a related decision, and [the guest-first workout guide](/blog/fitness-guest-first-workout) walks through that trade-off. ![Byte and Nova follow a photo check-in from a dated context card into a collection, then select two entries for comparison.](https://cdn.otf-kit.dev/blog/fitness-progress-photo-privacy-and-retrieval/inbody2-20261101-04a80dff-aria-v1.png?v=20261101-04a80dff) *Illustrative capture-to-retrieval path; not a Fitness Kit workflow or a storage, retention, or deletion claim.* ## What a starter kit gives you, and what it does not The [Fitness Kit](https://otf-kit.dev/templates/fitness-kit) is an Expo starter with sign-in, a database, and fitness screens. Its progress-photo and progress-hub screens are wired to that app database, and its Photos screen shows dated entries and a comparison card. That gives a new project a working collection and retrieval UI to extend. It does not establish private-storage authorization, retention or deletion behavior, or body-image analysis. Those controls need implementation and a security review in your own app, against your own backend. The kit also does not include health sync, push notifications, or in-app payments. Check the [live demo](https://fitness.otf-kit.dev/) to see the screens, then verify the access and delete paths on your own stack before you rely on them. ## A short build checklist 1. Define the check-in record and its fields, and capture them the same way every time. 2. Choose the access model and enforce it on the server with short-lived media URLs. 3. Build retrieval by member, by date range, and as a two-photo comparison. 4. Build and test deletion across the file, the database row, and cached copies. 5. Write the retention rule down before the first real member uploads a photo. ## Show the member what is stored Members should be able to see their own check-ins as a list, each with its date and any note they wrote. Show the same information a coach sees, so a member is not surprised by a record they cannot find. If a coach can view a check-in, say so on the member's screen. A visible list is also the simplest place to offer a delete action, which keeps the deletion path in one predictable spot. ## Make the comparison mean something A comparison view is only useful when the two photos are comparable. Decide the capture rules before the first member uploads anything: the same angle, the same distance from the camera, and a note about lighting or time of day when that affects the picture. Store those values with the record, not in the photo filename, so a later screen can filter by them. Let the user choose which two entries to compare. Do not pick the first and last entry automatically, because a member may want to compare a particular week, a particular angle, or a day they felt strongest. If an angle is missing from one of the two entries, show that gap plainly instead of stretching the images to fit. ## Test deletion before any real photo Deletion is the control most likely to fail quietly. A delete button can remove the database row while the file stays in storage, or remove the file while a cached copy still appears on the device. Test the whole path with a test member: upload a check-in, open it, delete it, then confirm that it is gone from the timeline, from any comparison view, from the server, and from the device cache after a restart. Write down what a deletion means for a coach. If a coach has already viewed a photo, the app should not imply that the coach has forgotten it. State the rule in the product copy, and make sure the server enforces it for every role. ## Set the retention rule before launch Retention is a product decision, not a default. Choose how long a check-in stays after a member stops using the app, whether a coach can keep a copy, and what happens to photos when a member closes an account. Write the rule in the privacy policy and in the app before the first real member uploads a photo, so the first user is not the one who discovers it. Keep the rule small enough that you can test it. A rule such as "deleted within a stated number of days after account closure, with an admin check that the deletion ran" is easier to verify than a vague promise about security. ## Sources - [r/sideprojects: "Yesterday I launched my app. Today, I got my first customer."](https://www.reddit.com/r/sideprojects/comments/1wwtsdb/yesterday_i_launched_my_app_today_i_got_my_first/) - posted about 27 Oct 2026 (exact timestamp not exposed; viewed 31 Oct 2026). One builder's reported pain, not evidence of market-wide demand. - [Fitness Kit](https://otf-kit.dev/templates/fitness-kit) - kit page, checked 31 Oct 2026 (HTTP 200). - [Fitness Kit live demo](https://fitness.otf-kit.dev/) - the kit's live demo of its app screens, including the Photos screen.