Privacy Policy

Information the app processes

When you open an EML or MSG file, the app reads the file on your device so it can display the message, metadata, source, headers, and attachments. The app may create temporary local files for attachment preview, sharing, and PDF export.

This processing happens on your device. The developer does not operate a server that receives, parses, stores, or converts your email files.

Information the developer collects

Through normal app use, the developer never collects:

• Email file contents, message bodies, headers, contacts, recipients, senders, subjects, dates, or attachments.
• Filenames or folder paths of the files you open.
• Account identifiers, because the app does not require an account.
• Advertising identifiers. The app does not access the IDFA and does not link the AdSupport or AppTrackingTransparency frameworks.
• Your name, email address, phone number, contacts, photos, precise or approximate location, or health data.

Anonymous usage data

Unless you switch it off, the app sends anonymous product analytics through PostHog, to a project used only by this app. What is sent is a closed set of event names describing what happened, never what it happened to. This is the complete list, grouped by what it describes, with what each event carries. Every value is a label from a fixed list, a yes/no, a duration, or a coarse bucket; none is text taken from an email. Where a line says the next update adds, the current version does not send that yet.

Lifecycle — sent by the analytics SDK itself:

• Application Installed — the first launch after installing, with the app version and build.
• Application Opened — each launch or return to the foreground, with the app version and build and whether it came back from the background.
• Application Backgrounded — the app left the foreground. The event name only.
• Application Updated — the first launch of a new version, with the previous and the new version and build.
• $rageclick — a burst of repeated taps in one place, with the name of the screen you were on. It carries no label or text from what was tapped, because tap capture is disabled.

Reading:

• file_opened — the file format (eml, msg or tnef, the last being a winmail.dat); a size bucket such as 500KB-5MB; an attachment-count bucket such as 1-5; how the file was opened (open_in, picker, recents, folder, sample, queue); the kind-of-message labels described below; and, if the app had to salvage a damaged file, that it did (recovery), what the bytes turned out to be, whether the headers and the message text came back, and how many attachments were recovered out of how many the file claimed, both as buckets.
• file_open_failed — why (unsupported_format, corrupt, too_large, unreadable or missing); how the file was opened; when the app refuses a type it does not open, that type (mht or mhtml); what the bytes turned out to be (sniffed, described below); and, when the file was too large, its size bucket. The next update adds the size bucket to every failed open and the file's extension chosen from a fixed list (ext: eml, msg, oft, mbox, mht, mhtml, dat or other).
• pdf_exported — the page size (a4 or letter); which of the four export options were on (metadata block, attachment inventory, page numbers, header appendix), each as yes/no; and whether remote content was off or show.
• pdf_export_failed — the event name only.
• attachment_previewed — the event name only.
• headers_viewed — the event name only.
• search_used — the event name only; never the search text.
• security_check_viewed — the event name only.
• folder_added — the event name only.
• folder_scanned — how many email files the folder held, as a bucket.
• remote_content_changed — which remote-content setting you chose: show automatically, or off.
• link_tapped — the link's scheme (https, mailto, tel and so on) and whether you chose to open it. Never the address.
• email_closed — how long the message stayed open, as a bucket such as 20-60s.

Two of those properties deserve a fuller description:

• When a file will not open normally, a description of what the bytes turned out to be — one of empty, ole, rfc822, html, pdf, zip, tnef, utf16, base64, text or binary — sent as sniffed. If the app manages to salvage a damaged file, it also records that it did (recovery), which of the headers and the message text came back, and how many attachments were recovered out of how many the file claimed. These are counts and labels about the file's structure. No part of the file's contents is sent.
• A description of the kind of message you opened, worked out on your device and never sent as text. Your device decides which of a fixed list of labels fits — for example a document class (invoice, receipt, legalNotice, newsletter, corporate, personal), whether the sender's address is a consumer mailbox or a company domain, how many recipients there were as a bucket, roughly how old the message is, whether it is a reply or a forward, whether it passed through an Exchange server, and the file types of any attachments (pdf, image, spreadsheet). Only the chosen labels are sent. The subject line, the addresses, the body text, the filenames and the sender's actual domain all stay on your device.

Paywall and purchases:

• paywall_shown — which feature asked for it (pdf_export, or settings when opened by hand) and where you were (settings, home_card or pdf_export).
• paywall_products_loaded — the same two; how many of the three plans managed to load their prices, out of how many were expected; and whether the pre-selected plan was among them.
• paywall_dismissed — the same two and which plan was selected when you closed it. The next update adds how long the paywall was open, in milliseconds (dwell_ms).
• purchase_started — the plan's product id and where the paywall was opened from. The next update adds the App Store storefront country (storefront) and whether the device is allowed to make payments (can_make_payments).
• purchase_completed — the product id; where from; how long the App Store took to reach an outcome, in milliseconds; whether the App Store reported the transaction as production or sandbox; and how the payment sheet was asked to appear (view_controller, scene or none).
• purchase_cancelled — the product id, where from, that elapsed time, how the payment sheet was asked to appear, and whether the outcome came back too fast to have been a human decision.
• purchase_failed — the product id, where from, that elapsed time, StoreKit's error category from a fixed list (such as network, not_in_storefront or purchase_not_allowed), and whether the app had a window to anchor the payment sheet to.
• restore_completed — whether a purchase was restored.

These describe the mechanics of the payment sheet, not you. Your payment method, your Apple Account and your billing address are never seen by the app and never sent — those stay between you and Apple. The next update also forwards RevenueCat's purchase events into this project; they are listed under Purchase reporting.

Ratings and support:

• review_prompt_shown — which moment triggered it (attachment_preview, finished_reading, pdf_export or folder_scan) and coarse buckets for how many files you have opened and how many times the app has launched.
• rate_tapped — the event name only. The next update adds where the tap came from (source).
• support_opened — whether it came from Settings or an error screen (source), and for an error screen the failure code and byte class described above.

Stability:

• $exception — a crash the SDK caught as it happened: the error type, the stack frames of the code that failed, and the app and OS version.
• app_crash — a crash reported by Apple's diagnostics service on the next launch: the system's termination code, the exception type and code, the signal number, stack frames, the OS version, the device type and the app build that crashed.
• app_hang — a long freeze reported the same way: its duration in seconds, stack frames, the OS version, the device type and the app build.

Added in the next update — not sent by the current version:

• onboarding_finished — the welcome screens were completed. The event name only.
• picker_shown — the file picker was opened. The event name only.
• guide_opened — the how-to-open-a-file guide was opened. The event name only.
• An is_internal flag on every event from the developer's own devices, so they can be excluded from the counts. It is never set on a customer's device.
• The six RevenueCat purchase events listed under Purchase reporting.

Attached to every event:

• Which screen you were on, from a fixed list of ten names (home, viewer, attachment, headers, security, folders, paywall, settings, onboarding, error), and whether Pro is active.
• Standard device and app context supplied by the SDK: device model, operating system version, app version and build, device language, and network type.
• A random identifier generated on your device the first time the app runs, so repeat actions from one install can be counted once. It is not the IDFA, it is not shared with any other app or website, and it is not linked to your name or any account. Purchase status is reported to RevenueCat under a similarly random app user ID.

Your IP address is discarded on receipt and is never stored. Before it is discarded, a country code is derived from it, so the developer can see which countries the app's readers are in as a total. No city, postal code, coordinates or time zone are stored: a filter on the project removes them. In the terms Apple uses, a country code is Coarse Location, and the app's App Privacy label declares it. Automatic capture of taps and view hierarchies stays disabled.

Session replay

Unless you switch analytics off, the app records a masked replay of how you move through it, so we can see where the app confuses people. It is recorded as a series of screenshots, and every part of the screen that can carry your email is masked out before each screenshot is taken:

• The message body, which is drawn in a web view, is masked as a whole.
• The header card — subject, sender, recipients — is masked.
• The headers and raw source screen is masked.
• Attachment names and the Recent files list are masked.
• All images, all text fields, and any photo-library content are masked.

What remains is the shape of the interface: which screen you were on, where the buttons were, and where you tapped. Network requests the app makes are not recorded, because the addresses in them could name a server an email tried to reach. If you switch analytics off in Settings, no replay is recorded at all.

This data is used only to understand which features are used and where the app fails. It is not used for advertising, it is not combined with data from other companies, and it is never sold or shared with a data broker.

Crash and performance reports

On the same consent, the app reports unhandled crashes and app hangs so they can be fixed. A report contains the error type, the stack frames of the code that failed, the app and OS version, and a duration. It never contains message content, filenames, or attachments.

Two channels are used, because neither sees everything. The analytics SDK reports crashes it can catch as they happen, as $exception. Apple's own diagnostics service additionally reports crashes it cannot — for example when iOS ends the app for using too much memory — as app_crash, and long freezes as app_hang, delivered the next time the app is launched. Those reports carry the system's termination code, the error and signal numbers, stack frames, the app build and OS version, and for a freeze its duration. They are attached to the same device and app context listed above. They do not contain message content, filenames, attachments, or any text your app or another app supplied.

Purchase reporting

Purchases go through Apple's StoreKit, and the app decides whether Pro is unlocked from Apple's own record on your device. Alongside that, RevenueCat observes the transactions Apple reports so the developer can see revenue totals. It receives the transaction as Apple describes it — product id, price, currency, store and whether it was production or sandbox — together with device and app version context and the random app user ID mentioned above. It does not receive your name, email address, Apple Account or payment details, because Apple never gives those to the app. The App Privacy label lists this under Purchases.

The next update gives RevenueCat the same random identifier analytics uses and forwards its purchase events into the analytics project, so a purchase can be joined to the paywall events that led to it: rc_initial_purchase_event, rc_non_subscription_purchase_event, rc_renewal_event, rc_cancellation_event, rc_expiration_event and rc_billing_issue_event. Each carries the product id, price, currency, store and environment. None carries a name or email address, and no Apple ID or payment detail is involved.

Turning it off

Open Settings → Privacy in the app and switch off Share anonymous usage data. Collection stops immediately, any queued events are discarded, and the random identifier is reset. Purchase reporting stops on the next launch. Nothing else about the app changes.

Getting in touch

Contact Support in Settings, and Report This Problem on an error screen, both open your own mail app with a message you can read and edit before sending. The prefilled part contains the app version and build, your iOS version, your device model, your language, whether Pro is active, and — for an error report — the failure code, the byte class of the file that would not open, and its file extension chosen from a fixed list (eml, msg, oft, mbox, mht, mhtml, dat, or other). It never contains the filename itself, the subject, any address, or any part of the file's contents. Nothing is sent unless you send it.

Support email

If you email support, the developer receives the information you choose to send, such as your email address, device details, app version, screenshots, logs, sample files, or support messages.

Remote email content

Some HTML emails include remote images, fonts, links, or other resources hosted by the sender or by third parties. If remote content is enabled in the app, viewing or exporting that email may cause your device to request those external resources. Those external servers may receive technical request information such as your IP address, user agent, and the requested resource URL.

The app includes a Remote Content Off setting for local-only viewing and PDF export. When that setting is used, the app blocks remote HTTP and HTTPS resources from the email content.

Local storage and deletion

The app may store recent-file metadata and temporary files on your device to support opening, preview, sharing, and export workflows. You can remove local files using iOS file management, the app's clear-recents control where available, or by deleting the app from your device.

Because the developer does not store your email files on servers, the developer cannot delete email files from your device for you.

Website privacy

This website is a static support and marketing site. It does not use cookies, advertising pixels, analytics scripts, or newsletter forms. The hosting provider may process standard server logs for security, abuse prevention, debugging, and delivery of the website.

Children's privacy

EML & MSG Viewer is a general productivity utility and is not directed to children. The developer does not knowingly collect personal information from children through the app.

International use

If you contact support, your message may be processed in the country where the developer or service providers operate. Do not send sensitive email files to support unless you are comfortable sharing them for troubleshooting.

Changes to this policy

Sheenu Jain may update this policy when the app, website, or legal requirements change. The effective date above will be updated when changes are made.

Contact

For privacy questions or support requests, contact cloudedgetech101@gmail.com.