Adagio Privacy Policy

Who is responsible for your data (data controller)

Data controller: Andrei Kitenko, individual entrepreneur (Georgia).

Postal address: St. Zakaria Mkhargrdzeli 5, 113, 0163 Tbilisi, Georgia

E-mail for data protection enquiries: adagio.app.support@gmail.com

You can use that address or that e-mail for any question about the processing described in this policy.

Which law governs this processing. The controller is established in Georgia, so the processing is governed by the Georgian Law on Personal Data Protection, wherever in the world you are. For users in the European Union, the EU General Data Protection Regulation (GDPR) applies in parallel; the sections below cite its articles. The rights listed under "Your rights" can be exercised the same way under either law, at the same e-mail address.

Video and photo library access

Adagio only ever works with the video you pick yourself in the system picker.

• The selected video is read and processed locally, on your device, using the device's own hardware (neural engine, video encoder).
• The result is written to your device and, if you ask for it, to your photo library. On the Mac you have a second choice: save the finished video into a location you pick yourself in the system save panel. The app is granted write access only to what you picked there — not to the folder as a whole, and not to anything else.
• None of this is transmitted to us or to any third party.
• The app requests two photo library permissions: reading the video you selected, and saving the finished result.
• On the Mac two file permissions are added, and both are bounded by your own choice: reading the file you picked in the open panel, and writing the finished video where you picked in the save panel. Without your choice the app reads and writes nothing.
• A third and final one is the notification permission. The system asks for it once: after your first finished video, or when you press “Turn on” in the Privacy section yourself. It exists for exactly one message — that a video is ready; the notification itself is assembled on the device and is never sent anywhere. Refusing breaks nothing: the app will not ask again, and iOS Settings can turn it back on.
• Nothing else is requested: the app has no camera and no microphone access — Adagio cannot record video, it can only import it. Location, contacts and calendar are not used.
• If you choose to share a result, the app hands the file to the system share sheet. Where it goes from there is your decision; we are not told.

What is stored on the device itself

Inside the app's own protected storage:

• references to the clips you selected and to the results you created (file paths, poster images, the title you gave the clip, duration, resolution, processing settings) and the number for the next copy of each clip you have copied;
• editing drafts and the processing job queue, so work is not lost across a restart;
• the count of free results you have used and whether Pro was purchased. That counter is a single integer plus a schema version number; it contains no device identifier.
• the app's own housekeeping markers and settings — whether onboarding has been completed, whether anything has ever been imported on this device, whether a language was chosen manually, whether the request to allow notifications has been shown, the chosen limit for temporary files, the last purchase notice (approved or revoked), a dated mark that a purchase was waiting for approval (ignored after a week, used only to tell you it was approved), whether the length of finished videos made before this version has been re-measured; and for the statistics — your choice about them, the records not yet sent (the same anonymous labels as in the field list, erased when you switch the statistics off) and the number of the last time they were switched off. Apart from those records, each marker is a single yes/no value, a number or a short word; they hold no device or personal identifier and nothing about your videos. Like the free-result counter, these outlive the deletion of your clips: the «an import has already happened on this device» marker is there so that an install that has already imported is not taken for a new one when the first-run steps are counted.
• first-run marks — which steps of the first run have already happened (the introduction, the answer about photo access, the first import, the first finished video, the first save) and, with statistics on, been counted, so that each step is counted once; plus one mark that the app keeps such marks at all, so that an install from before this feature is not taken for a new one. Each is a single “yes” value, with no identifiers, dates or anything about your videos; they are never sent and are deleted with the app.
• a usage-frequency record — the last counted day, week and month, the install date (only for an install made from the version that introduced these statistics on), which returns after installing have already been counted, the current month's day and video counts, and whether statistics stayed on for that whole month — so that each opening in a day, week and month is counted once. It carries no identifiers and nothing about your videos; it is never sent — only the labels in the field list are — and it is deleted with the app.
• a technical diagnostics log of video processing — timestamped technical events (for example, which stage started or failed and with which settings). File paths, identifiers and error texts are removed before anything is written. It holds at most 1,000 lines (256 KB); older lines are dropped.

None of this is transmitted anywhere. The diagnostics log leaves the device only if you export it yourself (Settings → "Export diagnostics") and choose where to send it. All of it is deleted together with the app, with three exceptions — all three live in the system keychain, are transmitted nowhere, and are removed when the device itself is erased:

• the free-result counter, so that reinstalling the app does not reset your free allowance; it holds nothing but a number and a schema version;
• the purchase record, so the app recognises your purchase after a reinstall and support can find your order if you lose access to your store account. It holds the product identifier, the store's transaction identifier, the purchase environment (production or test), the ownership type and the purchase date. It holds no identifier of your store account.
• your choice about the statistics, if you have switched them in Settings — "off", or "on" together with a random number created when you switched them on and used only to match this record against the one inside the app: without a match, a reinstalled app does not take an old "on" for your choice. The number is linked to nothing else.

Anonymous app performance statistics

What this is. The app sends aggregate technical measurements: how long processing took and how long the processed range was, how many frames were produced, at which quality mode and factor, which class the source video falls into (resolution class, frame-rate class, aspect ratio), which frame-size class the processing model was chosen for, how far the frame had to be shrunk, the device's thermal band during the work, how the job ended (success, failure, cancellation) and for which reason, on which platform and major OS version, whether the system's own frame engine handed the work to our model and for which of five reasons, plus anonymous counters of steps taken in the app and of actions on a result, the choices in the processing wizard (goal, scope, and the step at which the wizard was left), the steps of the first run (the introduction shown, finished or skipped and on which slide; the answer to the system's photo-access question or “Later”; the first import, the first finished video and the first save — each once per install), how often the app is used (the first opening in a day, week and month; a new install; an opening on day 1, 7 and 30 after it; for the last month — on how many days the app was opened and how many videos were made, in buckets) and the steps toward buying Pro: the first, second or third free video used; the free videos ran out; where the Pro offer or the purchase screen was opened from (a result, the Pro button, Settings) and a follow of the offer's "Purchase status" link; how the store's payment sheet ended (purchase, awaiting approval, declined, error); a tap on "Restore purchase". These counters carry no amounts, prices, currency, receipts or transaction identifiers.

The complete list. Every measurement, every label on it and every value that label can take is published as a separate document: Exactly what Adagio sends. It is checked against the app's own measurement schema automatically, so it cannot fall behind the code.

What is explicitly NOT sent: video, frames or thumbnails; file names, paths or photo library identifiers; device, installation, user, account or advertising identifiers; exact resolution, duration or frame rate; EXIF data and geotags; capture timestamps; IP addresses and user agents as part of the statistics; error text, logs and stack traces as part of the statistics (a technical crash report works separately — see "Crash reports"); screenshots or session replay; the recipients you shared a result with; transaction identifiers, receipts and payment details.

Why. So we can select the processing model that suits the real capability of a class of devices, find release defects, see how often the app is used and at which step new users stop on their way to their first saved video, and understand at which step people decide not to buy Pro. This is not advertising and not profiling. The records carry no device, installation or user identifier. One upload holds the records of one device and is stored with one shared timestamp, so the records of one upload are linked to each other; we store nothing that would link different uploads to each other or to you, and we do not attempt such matching.

Legal basis. Our legitimate interest in keeping the app working and improving its quality, and in understanding how often it is used and how people come to their first video and to buying (Article 6(1)(f) GDPR). The statistics are audience-measurement in nature: they carry no device, installation or user identifier, are not combined with other data, and not shared with third parties for their own purposes.

Where it is processed. The data is received by a gateway and a monitoring system located in the European Union (Frankfurt, Germany). The statistics records themselves are not transferred outside the EU; only the day's overall totals — how many videos were processed, what share of them failed and roughly how many devices used the app — leave it, in the owner's digest: the morning one and the same digest as of now, which he may ask for himself (see "The owner's service chat in Telegram").

The pass for an upload. Before every upload the app obtains a fresh pass from the Google Firebase App Check service, by which the gateway knows the data came from the genuine app and not from some other program. For this, the device's system vouches for the app — Apple App Attest on iPhone and iPad, DeviceCheck on Mac. The request carries no statistics: it holds Apple's confirmation, our app's designations in Firebase and technical details the Firebase library adds itself (its own version and the platform version); as with any request on the internet, Google sees the device's network address. Google processes these requests under the Firebase terms, including outside the EU.

How long it is kept.

We copy the App Store reports as they are into our own storage in Google Cloud (Frankfurt, Germany), where a retention rule protects them from being changed or deleted before their time; a report received for an earlier day is kept 12 months from the day we received it, not from the day it covers. Only overall totals from these reports reach the owner's chat, with first downloads split only into iPhone/iPad and Mac; countries, device models and versions never reach it.

How to turn it off. Settings → “What is sent” (the same screen opens from Settings → Privacy Center → “What is sent”) → “Work statistics” (a switch); the same switch turns collection back on. Turning it off stops transmission immediately and erases anything still waiting to be sent from the device. The app keeps working in full — the statistics have no influence on video processing.

Crash reports

What this is. If the app terminates abnormally — or iOS closes it on screen for no reason it can explain, which usually means it ran out of memory — the app sends a technical crash report the next time it starts. On a Mac this includes an internal error of the app intercepted by the system: the app closes, and the report is sent the same way.

Besides crash reports, short notices of failures inside the app go to the same service:

• an unhandled error — the fact itself and in which of two parts of the program it occurred;
• a failed operation — the area of the app (for example, import, processing, saving, purchase), a reason from a predefined list of codes (for example, "timed out", "disk full", "file missing"), and the app version and build number and the device type (iPhone, iPad or Mac).

These notices contain no error text, file names, paths or identifiers — only these values, the details of the moment of failure (below) and the technical fields of the Sentry service itself.

Where and after what the failure happened. Every such notice and every crash report also carries a few values — only from the predefined lists below, so a file name, a text or anything about you cannot be among them:

• os — the system and the first two numbers of its version, for example ios 26.1 or macos 15.6;
• screen — the screen you were on (launch — the app is still starting), one of: launch, onboarding, library, import, trim, clip, analyze, wizard, processing, result, paywall, purchase_status, settings, settings_language, settings_privacy, settings_help, settings_metrics, settings_terms, settings_policy;
• engine — what made the frames of the current processing (the system engine, our model, or not chosen yet), one of: apple, rife, none;
• pro — whether Adagio Pro is unlocked (unknown — the store has not answered yet), one of: yes, no, unknown;
• steps — up to the 20 last steps in order, without times: going to a screen (except the Pro and purchase status screens) or a stage of work, one of: launch, onboarding, library, import, trim, clip, analyze, wizard, processing, result, settings, settings_language, settings_privacy, settings_help, settings_metrics, settings_terms, settings_policy, background, foreground, import_done, analysis_ready, render_start, render_done, result_played, result_saved, result_shared.

Steps are moves between screens, the app going to the background and back, and the stages of the "import → processing → result" path. Taps, typed text, step times and steps toward a purchase — neither opening the Pro screens nor the payment sheet — are not in this list; a Pro screen can only appear in the screen field, when the failure happened on it.

What a crash report contains (the complete list; everything else is removed on the device before sending):

• the type of failure and how it was caught, the system signal code, and whether the failure was handled;
• the state of the program at the moment of the crash: which functions of the app and of system libraries were running (addresses in program code and function names) and which thread crashed;
• the names of program modules — the app itself and system libraries — with their build identifiers, load addresses and sizes;
• the app version and build number, the build environment (for example, test), the operating system name and the first two numbers of its version, the device model and family (for example, "iPhone", "Mac"), the processor architecture, whether it is a simulator, and whether the app was on screen;
• where and after what the failure happened: the screen, the engine, whether Pro is unlocked and the last steps (the list above);
• the name and version of the Sentry library built into the app and the public key of our Sentry project;
• a random report number, the time of the crash and a random launch number, which tie the report neither to you nor to your device.

What a report does not contain: video, frames or thumbnails; names of files or clips, or paths; error text or logs; screenshots; taps, typed text, step times or steps toward a purchase; device, installation, user or advertising identifiers. As with any request to a server, the device's network address is visible to Sentry when the report arrives, but storing it is prohibited in our organization's Sentry settings.

Who receives it. The Sentry service (Functional Software, Inc.) — our data processor under a data processing agreement. Reports are stored on Sentry's servers in the European Union (Frankfurt, Germany). Only we have access to them. Short notes about failures — the name of the error, how many times it happened and when it last did, the kind of device (iPhone, iPad or Mac) and the app version — also reach the owner in the service chat in Telegram (see "The owner's service chat in Telegram").

Why, and on what legal basis. To find and fix crashes. The legal basis is our legitimate interest in keeping the app working (Article 6(1)(f) GDPR). Reports are always sent and have no separate switch: a report is reduced to the minimum needed to find the cause of a crash and cannot reveal who you are or what you processed.

How long it is kept. 30 days, after which Sentry deletes the report.

How to object. You have the right to object to this processing (Article 21 GDPR) — write to adagio.app.support@gmail.com. Because reports carry no identifiers, we cannot locate the reports of a particular person; we will consider your objection and reply to you.

If you write to us

If you e-mail us — for support or with a question about your data — we receive your e-mail address, your name if your mail program shows it, and whatever you put in the message and its attachments — including the diagnostics log, if you choose to export and attach it. The app itself never sends us anything of this kind: a message exists only if you decide to write.

Why. Only to answer you and resolve your request. Legal basis: our legitimate interest in answering the people who write to us (Article 6(1)(f) GDPR); when the request concerns your rights under the GDPR, handling it is our legal obligation (Article 6(1)(c) GDPR).

How long it is kept. Correspondence is deleted within 30 days once 12 months have passed since the last message in it. You can ask us to delete it sooner.

Where. Mail arrives in a Gmail mailbox; Google processes it under its own privacy policy (see "Transfers outside the EU").

A copy in the owner's chat. So that no message is lost and it is answered sooner, a copy of every message that reaches the support address goes into the private service chat of the owner of Adagio in Telegram (see "The owner's service chat in Telegram"): the sender's name and address, the subject, the text (a very long message is cut short) and the names of any attachments. A script inside the mailbox itself — it runs at Google, like the mailbox — sends the copy straight to the chat through our service bot; our own service in Google Cloud plays no part in this and stores nothing of the message. Links in the copy are shown as plain text and cannot be opened from the chat; attachments themselves are not forwarded. Nobody is in the chat but the owner and our service bot; messages there are kept until the owner deletes them. The message in the mailbox is kept for the period stated above.

Please do not attach videos or other personal material — we do not need them to help you.

Purchases

Adagio saves one video for free, after which saving and exporting is unlocked by a one-time Pro purchase.

• The purchase is processed by the App Store (Apple) or Google Play (Google). Card details, payment data and your store account identifier are handled by the store, not by us, and are never passed to us.
• What remains on the device is the count of free results used and the purchase record described above under on-device data — which includes the store's transaction identifier, the value support can use to find your order.
• The anonymous statistics include the steps toward buying listed under "Anonymous app performance statistics" — among them how the store's payment sheet ended (purchase, awaiting approval, declined, error). They carry no amounts, prices, currency, receipts or transaction identifiers. Besides that, they can carry the anonymous fact that a request to the store failed, with no detail of any kind.
• Apple's notifications about purchases and refunds. When someone buys Pro on the App Store, or Apple refunds a purchase, Apple sends a signed notification about it to our service in Google Cloud (Frankfurt, Germany). The app plays no part in this. The notification carries the product, the kind of event, the price and currency, the date, the store's country and numbers that identify the purchase: the transaction number, the number of the original transaction and a number Apple gives the app on your Apple account (the same for all your purchases in Adagio). It carries no name, e-mail or payment data, and the app attaches no identifier of its own to the purchase. The service checks Apple's signature and at once, before anything is stored, discards all of these numbers and the store's country. What remains is a reduced event — what happened, Pro, the continent, the amount and currency, the day; until it is shown in the chat it waits in our service's queue for at most a week. These events make up the day's totals: how many Pro purchases and refunds there were and Apple's decisions on refunds (a refund reversed, a refund declined, Apple asking for information to decide on a refund — we do not answer such requests), on which continent, and for what amount in which currency. The totals are kept 35 days. So that one notification is not counted twice, the service keeps a short fingerprint of its number from which the number itself cannot be recovered: 48 hours on receipt, and the last 500 with the totals. The totals and refunds are shown to the owner in the service chat in Telegram (see "The owner's service chat in Telegram"). Why: to see purchases and refunds the same day rather than a day later from the store's report. The legal basis is our legitimate interest in running the app's sales (Article 6(1)(f) GDPR).
• Refund rules and purchase terms are set by the app store.

The owner's service chat in Telegram

So that the app can be run without opening several websites every day, the owner of Adagio receives service messages in one private Telegram chat. They are sent by our service bot: all of them, alerts about our own service included, through our service in Google Cloud (Frankfurt, Germany), except copies of e-mails, which go straight from the mailbox (see "If you write to us"). Nobody is in the chat but the owner and that bot.

What goes there:

• the morning digest — around 09:00 Tbilisi time, overall totals only, with no data about people: the app's totals for the last 24 hours — how many videos were processed, how many failed (and what share that is) and how many were cancelled, roughly how many devices used the app, and the same a week earlier for comparison, how many errors the crash reports had, how many times they happened, how many of them are new and the name of the most frequent one; the store's totals for the last day Apple has published: how many first downloads there were and the same a week earlier, how many Pro purchases and refunds there were and how much Apple will pay out (first downloads are split only into iPhone/iPad and Mac, with no countries, device models, versions or identifiers; an Apple report published later is added to the same digest); the state of versions and builds in the App Store, the app's overall App Store rating and the number of ratings, how many Apple reports are already kept in the archive, how many data sources answered, and an overall verdict — all is well, worth a look or there is a problem — with its reasons; on Mondays — also downloads, Pro purchases and processed videos for 7 days against the 7 before;
• the digest as of now — when the owner asks for it, at any time of day: the same parts as the morning digest, read at the moment he asks: the app's totals for the last 24 hours, the store's totals for the last day Apple has published;
• short notes about failures from crash reports and failure notices (see "Crash reports"): the name of the error, how many times it happened and when it last did, the kind of device (iPhone, iPad or Mac) and the app version;
• the state of App Store review and test builds — these carry no data about people;
• alerts about our own service — for example, that the gateway receiving the statistics answers with errors, and that this is over; these carry no data about people;
• new App Store reviews of Adagio, which are public on the App Store anyway: the stars and the text, without the reviewer's nickname;
• the day's purchase totals from Apple's notifications: Pro purchases, continent, amount, Apple's decisions on refunds, and a separate message about each refund — continent and amount (see "Purchases"); for a test purchase or refund in Apple's test environment (made by us or our testers) — a short note that it arrived, with no continent or amount, not counted in the totals;
• copies of the e-mails you send to the support address (see "If you write to us").

Before anything is sent to the chat through our service, keys, links, paths and file names, e-mail and network addresses, long numbers (order, transaction and account numbers) and country names are removed from it automatically; copies of e-mails are sent as described in "If you write to us". Videos, frames and clip names never reach the chat.

Why, and on what legal basis. To see failures, sales and messages in time and answer them sooner. The legal basis is our legitimate interest in running the app and in answering the people who write to us (Article 6(1)(f) GDPR).

Where, and for how long. The messages are stored by Telegram (Telegram Messenger Inc.) on its servers, including outside the EU, under its own privacy policy; Telegram group chats are not end-to-end encrypted. In our chat, messages are kept until the owner deletes them; you can ask at any time for the copy of your e-mail there to be deleted (see "Your rights").

Children

Adagio is not directed at children under 13 and does not knowingly collect their data. The app has no accounts, no profiles and no social features.

Your rights

Under the GDPR you have the right to request access to your personal data, its rectification or erasure, restriction of processing, data portability, and to object to processing based on legitimate interest.

One limitation we are obliged to state plainly: we have no way to locate "your" records inside the statistics — they are anonymous by construction and contain no identifier tying a record to a person or a device. An access or erasure request for a specific record therefore cannot be executed by us. That is a consequence of not holding data about you, not a refusal. You may object to the collection of statistics at any time and without giving a reason, using the switch in Settings; that stops transmission immediately. An objection to crash reports is made by e-mail, as described under "Crash reports". The same limitation applies to crash reports: they carry no identifiers, so we cannot locate the reports of a particular person.

Correspondence you have sent us is the exception: we can find it by your e-mail address, so you can ask us for a copy of it or for its deletion at any time; deletion also covers the copies of those messages in the owner's service chat in Telegram.

Everything that is personal to you stays on your device. It is deleted by an action of yours — deleting a clip or a result in the app, deleting the file from your photo library, or deleting the app — and in one case by the app itself: a clip has exactly one finished video, so when you process it again, that clip's previous finished video is replaced and removed from the device. The app says so before the run starts, and anything you already saved to your photo library is untouched.

You also have the right to lodge a complaint with the data protection supervisory authority where you live.

Transfers outside the EU

The statistics records are processed in the EU and are not transferred outside it — except the day's overall totals in the owner's digest in Telegram — the morning one and the one he asks for (see below); the pass for uploading them (Google Firebase App Check, see "Anonymous app performance statistics") carries no statistics, and Google may process that request outside the EU, including in the United States, under its own terms. Crash reports are stored by Sentry in the EU; under Sentry's terms, the content of the reports does not leave the selected storage region. For auxiliary functions of its service (for example, e-mail notifications to us), Sentry uses sub-processors in the United States on the basis of the EU-U.S. Data Privacy Framework and, where that does not apply, the EU Standard Contractual Clauses. E-mail you send us is received in Gmail; Google may process it outside the EU, including in the United States, under its own terms. The owner's service chat in Telegram — the morning digest and the digest as of now, short notes about failures, the day's purchase totals, alerts about our own service, App Store reviews and copies of e-mails (see "The owner's service chat in Telegram") — is stored by Telegram Messenger Inc., including outside the EU, under its own terms. The App Store reports and the day's purchase totals are stored in Google Cloud in the EU (Frankfurt, Germany). Video is not transferred anywhere at all. Payments are processed by Apple and Google under their own privacy policies.

Changes to this policy

If the data we collect, the purposes or the retention periods change, we publish a new revision with a new effective date and state what changed. Changes that broaden data collection take effect no earlier than the publication of the corresponding revision.

Contact

For any question about this policy or about personal data, write to the address given under "Who is responsible for your data".