What Mapsake Sends When You Submit Feedback

Feedback should be understandable before you send it

Good bug reports make Mapsake better, but a useful report should not require surrendering a mystery bundle of personal data. The feedback screen in Mapsake shows separate controls for different kinds of diagnostics so you can decide what belongs with your message.

The new website feedback form is the simplest route: choose a category, write a message, and optionally include an email address for a reply. It does not accept attachments or collect app diagnostics because a browser cannot inspect your private Mapsake database.

The in-app form can include more context, but only through the choices described below.

The message and contact fields

Every report includes the category and text you enter. Contact information is optional. If you do not provide an email, the report can still be read and acted on, but there may be no way to ask a follow-up question.

Avoid putting passwords, API keys, complete public-share management links, or unrelated personal records in the message. If a bug can be demonstrated with a generic place name or approximate date, use the least sensitive example that still explains it.

Logs and performance information

The main in-app diagnostics switch is enabled by default because it often provides the context needed to distinguish a display problem from a data or sync problem. It can include:

• recent Mapsake diagnostic logs;
• live performance measurements from the current session;
• summary statistics about the local Photo Explorer image database;
• Maplight diagnostic state.

Logs describe what the app was doing, which operations failed, and broad counts or timings. They are not intended to include photo image data. Performance measurements can show slow tasks, frame behavior, and resource conditions that are difficult to reproduce from a written description alone.

You can turn this option off before sending.

iCloud and sync diagnostics

Sync issues are unusually hard to understand from one device because the important event may have occurred elsewhere. The separate iCloud diagnostics option can include more detailed technical material: CloudKit and local record identifiers, device and network context, sync events and errors, and the local sync records needed to diagnose convergence.

That is why it is a separate, explicit checkbox. The package may be detailed, but it is designed not to include your photos, passwords, API tokens, signing keys, or raw management secrets.

Use it when the problem concerns missing changes, duplicates, a device that will not catch up, or an iCloud state that behaves differently across your Apple devices. Leave it off for an unrelated visual or wording issue.

Country and photo-import diagnostics

If a country or region is missing, unexpectedly present, or receiving the wrong photo evidence, country diagnostics can include information about the photos that contributed to that place: location and date metadata, source device, and the reasons a filter included or excluded the evidence.

The actual image pixels are not included by that checkbox. The goal is to explain the matching decision without copying the photo library into a support report.

This option is most useful when you can name the affected country and describe the expected result. If the issue concerns only one or two photos, a deliberately selected screenshot may communicate more clearly than a large diagnostic set.

Friends and sharing diagnostics

Friend and public-map problems can involve several states: a share code, whether a record is reachable, and which place names were present in a generalized snapshot. Friends diagnostics can include that sharing state so the failure can be located.

It does not attach your friends' photos. When reporting a public link, do not paste any private management credential into the message. The ordinary public slug or share code is normally enough.

Screenshots and screen recordings

The app lets you deliberately attach up to five screenshots or videos. These files are different from diagnostic checkboxes: you choose each one yourself and can review it before sending.

Check the full frame for notifications, email addresses, faces, map locations, or other content that is not needed for the report. Crop or redact when possible. A short recording that begins immediately before the problem is often more useful and less revealing than a long capture of the entire session.

The website form is text-only. That limit reduces spam and avoids creating a second public upload system for sensitive files.

What the website uses to discourage spam

The public form uses Cloudflare Turnstile to distinguish normal submissions from automated abuse. Turnstile receives the browser and network information needed to evaluate the challenge under Cloudflare's service. Mapsake verifies the short-lived result on the server before storing a submission.

The form also uses a hidden honeypot field, request-size limits, origin checks, and temporary per-address rate limiting. Mapsake does not store the submitter's IP address with the feedback record.

If the anti-spam service is unavailable or not configured, the form fails closed rather than accepting an unverified flood. The support email remains available.

What happens after submission

Website and in-app reports enter the same private administrative review queue, with their source clearly labeled. Website feedback stores its category, message, optional contact address, and submission time. In-app reports may additionally have the diagnostic text and attachments you selected.

Reports are used to answer support requests, reproduce bugs, prioritize improvements, and understand where documentation is unclear. They are not published as testimonials or added to a marketing list by submitting the form.

A useful report in five lines

The most effective reports usually include:

1. what you were trying to do;
2. the exact action immediately before the problem;
3. what you expected;
4. what happened instead;
5. whether it happens every time.

Add the Mapsake version and device when known. For a feature request, explain the underlying job rather than only the interface you imagine. “I need to distinguish airport connections from destinations” gives more design context than “add another toggle.”

The controls exist so useful detail and informed consent can coexist. Send the smallest package that can explain the problem, and use the individual diagnostic switches when the extra context genuinely applies.