Privacy Policy

1. Who we are

This Privacy Policy explains how TECHNOGRADE YAZILIM TEKNOLOJİ VE TİCARET LİMİTED ŞİRKETİ, a company registered in Türkiye, with its registered office at Merkez Mah., Feriköy Fırın Sok. No: 69/2, Şişli, İstanbul, Türkiye ("Company", "we", "us"), collects and processes personal data when you use the Pionare iOS application (the "App") and the website at pionare.app (the "Website"). Together we call them the "Service".

For the purposes of the Turkish Personal Data Protection Law No. 6698 (KVKK) and the EU General Data Protection Regulation (GDPR), the Company is the data controller for the personal data described below.

Contact for privacy matters: [email protected]

2. Summary

The short version. Every point here is expanded later, and where the truth is inconvenient we say so rather than round it up.

• You do not need an account, and you are not asked to make one. The first time you open the App it creates one for your iPhone — a guest account, with no email address and no name — and everything you make, and anything you buy, belongs to it. You can save it later with Apple, with Google, or with an email address and a password; all three are handled by Google Firebase Authentication and we never receive your password. If you sign in with Apple, Apple may send us the name on your Apple account, which we keep as a display name. The Website has no guest mode: there, signing in is the only way in.
• You must be 13 or older to use the Service. This is a requirement of our Terms of Use, not something we verify — we do not ask for or store a date of birth.
• You can create content by applying one of our effects or styles to a photo, by writing your own description, or by turning a photo into a short video. You can also build a personal profile from photos of yourself.
• To create anything, your photo is uploaded to our servers and the AI provider fetches it from there. Replicate, Inc. is the only company we send your photos to; where it serves a model on the publisher's behalf, that publisher may process the photo as Replicate's sub-processor. The model behind most photo effects is an OpenAI model, reached through Replicate rather than directly. OpenAI also receives your text when you tap "Rewrite with AI", and — where the optional profile gender-detection step is configured to use an OpenAI model — the links to your profile photos when we generate your profile avatar and banner. Section 8 is the full account.
• Your uploads and your results are stored on our servers, in Frankfurt, against your account. There is no automatic deletion. Earlier versions of this policy said generated content was deleted after 7 days. That was wrong: nothing expires, and your creations stay until you delete them or delete your account.
• Stored files sit at web addresses that we do not publish and that are hard to guess, but they are not access-controlled: there is no password, no signature and no expiry, so anyone who has the link can open the file without signing in. Treat a Pionare file link like a password.
• Photos you upload as the input to a generation are not deleted today — not when you delete the result, and not when you delete your account. Section 17 explains why, and how to have them removed.
• A personal profile lives on our servers, not on your device, and it is available on any device you sign in on. The photos behind it are kept for as long as the profile exists. Earlier versions of this policy said profiles were stored on your device and their photos discarded. Both statements were wrong.
• The App does run an on-device face-detection check when you pick photos for an effect, using Apple's Vision framework. It counts faces and nothing more, it never leaves your device, and we never receive it. Section 6 sets this out in full, including the one device-side log line it writes.
• We do not train any model on your photos today, and we will not without telling you first — see Section 5.
• We use no analytics SDK, no crash reporter and no advertising SDK of our own. The only measurement tool in the App is AppsFlyer, and it starts as soon as the App has an account to name — on a new install that is the guest account, so it is running before you have signed in to anything. It keeps measuring installs and subscriptions whether or not you allow tracking. Section 12 explains what your answer to the tracking prompt does and does not change.
• Our servers now keep your IP address briefly. An earlier version of this policy said they never recorded it. They do: in a counter that limits how many accounts can be made from one network, held for about two hours and used for nothing else. Section 3(k).
• On iOS, purchases are processed by Apple. We never see your card details. The Website does not sell anything today.
• You can delete your account from inside the App. A saved account is deactivated at once and can be restored for about 30 days, after which it is erased — with the limited exceptions listed in Section 18. A guest account is different: deleting it happens at once and cannot be undone, because there is no sign-in you could come back through.

3. Data we collect

a) Account data. There are two kinds of account. The first is made for you; the second is one you sign in to.

A guest account is created the first time you open the App, before you are asked for anything and without any step of your own. It holds no email address, no name and no password. What identifies it is an anonymous identity at Google Firebase Authentication together with a random key the App keeps on your iPhone — item p below. Everything you make, and anything you buy, belongs to it.

A saved account is a guest account you have signed in to, or an account you already had. Signing in uses one of the following, all of which run through Google Firebase Authentication as our processor:

• Sign in with Apple — Apple sends us a unique identifier, an email address, and, on first authorisation, the name on your Apple account. If you choose Apple's Hide My Email option, we receive a private relay address rather than your real one, and we never learn your real address.
• Sign in with Google — Google sends us a unique identifier and the email address on your Google account.
• Email and password — you provide an email address and choose a password. The password is set, stored and checked inside Google Firebase Authentication. It never reaches our servers, in any form, hashed or otherwise, and we cannot read it or recover it.

On your account record we store: an internal user identifier; which kind of account it is; the email address, whether it is verified, and a display name, where a sign-in provider supplied them; one entry per linked sign-in method (the provider, its own identifier for you, and the email it sent); the dates the account was created and last changed; your consent records; one entry per device you have used it on; and, while it is still a guest account, the hash of the key in item p, with the dates that key was issued and last seen and the identifier of the device it was issued to. A guest account has no email address, no display name and no sign-in method, so those fields are simply absent from it.

Earlier versions of this policy also listed "a second identifier used by our purchase service". There is no longer such an identifier: the same internal user identifier addresses our purchase service, and Adapty is given the Firebase identifier of the account instead — see Section 11.

Saving a guest account, and signing in to one you already have. These are two different things and they move different data:

• Saving — you sign in with Apple, with Google, or with an email address no account is using yet, and the guest account becomes that account. Nothing is copied or moved anywhere, because the record is the same record; it gains a sign-in method, an email address and perhaps a name, and loses the key in item p, which it no longer needs.
• Signing in to an account you already have — a different record, so the App shows you what the guest account holds and asks you to confirm before anything happens. If you agree, we move what the guest paid for onto the account you signed in to, together with your creations, your personal profiles, the reports you filed and your consent records, which keep the dates on which you originally gave them. Free, gift and compensation credits stay on the guest account, as does its usage history. A purchase someone else paid for is returned to them rather than moved. The guest account itself is kept, not deleted, and signing out of the account you moved to returns you to it.
• One account may take in only a small number of guest accounts in any 30-day period — five at the time of writing. Past that, the next one waits for a person at our end to look at it. The limit exists to stop one account collecting purchases from many phones.

We do not ask for your date of birth, your phone number, or your postal address.

b) Age. Being 13 or older is a requirement of our Terms of Use. The App's opening screens ask which age range you are in, and the youngest range offered is 13-17 — so the question cannot tell us that someone is below our minimum age. It is optional and you can skip it, nothing in the App depends on the answer, and it is never checked against anything. We do store the range you pick on your account, as one of the onboarding answers described in item q below. We do not collect a date of birth, so what we hold is a band and never a birthday. The 13+ requirement itself is a term of the contract between us, and it remains unverified.

c) Photos you provide for a generation. To create an image or a video, the App uploads the photo you select. This photo may show identifiable people. Only use photos you have the right to use, and do not upload photos of other people without their permission. Photos on this path are re-encoded on your device before upload, which drops embedded camera metadata; if that step fails, the original file is uploaded as it is.

d) Photos used to build a personal profile. If you create a profile you provide up to 8 photos of yourself at creation, and a profile may hold up to 20 photos; you may hold up to 10 profiles. Unlike the generation path above, these are uploaded as the files the picker hands us, at full resolution and up to 25 MB each, with no re-encoding of our own. We do not read, use or store any embedded camera metadata, and we do not strip it either; whether the metadata your camera wrote into a photo — its capture time, and a location if your camera recorded one — survives iOS's own conversion when the photo leaves the picker is outside our control, so you should assume it can travel with the file into our storage and on to the AI provider. We are adding a step that removes embedded metadata on upload, and we will say so here when it ships. Section 5 covers profiles separately, because it is the most sensitive processing in the Service.

e) A name and a gender for each profile. Creating a profile requires you to type a name for it and to choose a gender. Both are stored on the profile. Where profile asset generation is switched on, an AI vision model may also infer a gender from your profile photos and overwrite the value stored on the profile — see Section 5.

f) Descriptions you write. The text you type to describe what you want, and any expanded or rewritten version of it produced by the writing assistant.

g) The style or effect you select. An identifier for the preset style, effect or feature you chose, and the settings that go with it.

h) Generated images and videos, and a record of each generation: which feature was used, when, whether it succeeded, the reason if it failed, and what it cost in credits.

i) Purchase and subscription data. When you buy a subscription or a credit pack on iOS, Apple processes the payment. We, through our subscription provider and our own purchase service, receive confirmation of the transaction, your entitlement status — for example active, expired, in trial or in billing retry — and your credit balance and its history. We never receive your payment card number.

j) Identifiers. Your account identifier, a device identifier, and — while the account is still a guest — the hash of the key in item p. The device identifier is the vendor-scoped identifier iOS gives us (identifierForVendor) — it is not your advertising identifier. Because push notifications use Firebase, a Firebase installation identifier is also generated on your device. AppsFlyer assigns its own attribution identifier. If you allow tracking when iOS asks, your device's advertising identifier (IDFA) may be read by AppsFlyer on the device; our own code never reads it in either case.

One consequence is worth stating rather than leaving to be worked out. The account identifier we give AppsFlyer, the one inside the file links we hand the AI provider, and the one that travels with a push notification are the guest account's until you save it. So an identifier for you exists, and is already in use with those third parties, before you have signed in to anything. Saving the account keeps the same identifier; signing in to a different account replaces it.

k) Technical data. For each device on your account: the device identifier, the platform, the app version, and the dates we first and last saw it.

Your IP address. Earlier versions of this policy said our servers never recorded or stored it. That is no longer true, and we would rather correct it here than let it stand. Because the App now creates an account for every install, we count requests on a few routes to stop that being abused: creating a new guest account, reopening one, signing in with Apple or Google, and the App's own reads of our purchase service. Each counter is a number stored under a key, and the key is built from your address — an IPv4 address whole, an IPv6 address cut to its /64 prefix. There is no account field on a counter and nothing about what you did; it expires within about two hours, and nothing re-creates it. The same mechanism counts against a short hash of your email address when you sign in with Apple or Google, and against a short hash of the guest key when the App reopens an account. It is used for rate limits and for nothing else — never to identify you, never for analytics, never for advertising — and two of these limits are currently set to count without refusing anyone. Your IP address is in any case visible in transit to our hosting and network providers (Section 11).

We store no browser user-agent. We collect no crash logs and no performance telemetry, because the App and our servers contain no crash-reporting or error-monitoring tool at all.

l) Consent records. When you accept the in-app AI and data-use disclaimer, we record its version, the moment you accepted it, the platform and the app version. Superseded versions are kept so that what you agreed to, and when, stays answerable. Acceptance is recorded in the background; if that request fails, the record may exist only on your device until the next time the App reconciles it.

m) Content reports. If you report one of your own results, we store the reason you chose, any message you write (up to 2,000 characters), your account identifier and a copy of the link to the reported result, so the report survives the result being deleted.

n) Support data. If you email us, we receive your email address and whatever you write.

o) On-device face checks. Nothing is collected. See Section 6.

p) The key that identifies a guest account. The App generates a random 32-byte key on your iPhone and stores it in the iOS keychain, marked so that it never leaves the device: it is not synced to iCloud and it is not included in an encrypted backup. We never receive the key itself — only its SHA-256 hash, which is what lets us recognise the account when the App asks to reopen it, and which we cannot turn back into the key. The hash is never shown in the App, never returned by our API and never visible in our administrative tools. Anyone who did obtain the key could reach that guest account, which is why it stays on your device and why you should not copy it anywhere. We remove it from our records the moment the account is saved or deleted. Section 16 explains what this means if you lose or replace the phone.

q) What you answer on the opening screens. The first time you open the App it asks five questions: your gender, your age range, what you want to use Pionare for, what you want to experiment with, and who you would share your creations with. Each is optional, most offer a "prefer not to say" option, and you can skip the step. Your answers are stored on your account, together with the date you first answered and the date you last changed an answer. We keep them on the account rather than on the phone so that they survive a reinstall. The gender answer decides which list of styles the App shows you; the rest tell us who uses Pionare and what they want from it, which is how we decide what to build and which styles to add. No answer is used for advertising, and none of them is shared with any third party by us. The screens themselves are run by Adapty, which also keeps the answers on its own side — see Section 11.

Age. The Service is intended for people aged 13 or over. We do not knowingly collect personal data from anyone under 13. If you believe someone under 13 has provided us with personal data, contact [email protected] and we will delete it and close the account.

4. Creating an image or a video

When you create something from a photo — an effect, a style, an edit or a video:

• The photo you selected is uploaded from your device to our file storage, which is operated by DigitalOcean in Frankfurt, Germany.
• We then ask the AI provider to run the model. We do not send it the image bytes: we send it the link to the stored file, together with your description, the style you chose and the model settings. The provider fetches the photo from that link over the public internet. We send no email address, no name, no device identifier and no advertising identifier. The link itself, however, contains the internal account identifier that your files are filed under, and that identifier is the same on every upload you make — so a provider could in principle tell that two photos came from the same account, even though it has no way to turn that identifier into a person. We would rather tell you that than write "nothing that identifies you", and we are changing the way these links are built so that it stops being true.
• The provider returns the generated image or video. We store it in the same file storage and record the generation against your account, so your Library survives closing the App, changing device or losing the file.
• The link to the finished result is also sent to our own notification service and travels inside the push notification that tells you your image is ready — which means Apple's and Google's push infrastructure handle that link. See Section 10.
• Anything you save to your device — to your photo library or inside the App — stays there until you delete it. Deleting the App removes what is stored inside the App; images you saved to your photo library are not affected.

Retention, stated plainly. There is no automatic deletion of anything you create. Your results are kept until you delete them or delete your account. The photo you uploaded as the input is kept too: we do not record where each upload was stored, so deleting a result — or even deleting your whole account — does not currently remove it. Section 17 explains what this means and how to have uploads removed.

Video. Video is generated from a photo you provide. The App does not accept video files as input and does not access your video library.

Creating from a description alone. On the Create screen you write a description and we generate an image from it. No photo is uploaded on that path, so the first bullet above does not apply to it: what we send the provider is your text, the style you chose and the model settings. The result is stored against your account in the same way.

Safety screening. Our AI providers apply their own safety systems to what is submitted and to what is produced, and may refuse to generate certain content. You can report any of your generated results from the result screen. Reports are reviewed by a person; nothing is removed automatically, and we may remove content, disable a feature, or suspend or close an account.

5. Personal profiles

This is the most sensitive processing in the Service, so we set it out separately and in full. This section was materially wrong in earlier versions of this policy and has been rewritten to describe what the Service actually does.

What a profile is. A profile is a record on our servers. It holds the photos of yourself you uploaded, a name you type, a gender you choose, and — where profile asset generation is switched on — a generated avatar and banner made from those photos. It is keyed to your account.

This is data about your face. Depending on where you live, photographs of your face may be treated as special category data under the GDPR, or özel nitelikli kişisel veri under the KVKK, and may be covered by specific biometric privacy laws in some countries and US states. We process them only to provide the profile feature you asked for.

Where it is stored. On our servers — not on your device. The profile record is held in our database and the photos in our file storage, both operated by DigitalOcean in Frankfurt, Germany. Because the profile belongs to your account, it is available on every device you sign in on, and it survives reinstalling the App, changing device or resetting your device.

Who else receives the photos. The links to your profile photos are sent to Replicate to generate your avatar and banner. Where the optional gender-detection step is switched on, the same links are also sent to a vision model to infer a gender from the photos, which then overwrites the gender stored on the profile; depending on which model is configured for that step, that model runs either at OpenAI or at Replicate. Section 8 explains both. As in Section 4, what we send is a link, and that link contains the internal account identifier your files are filed under; no email address, no name and no device identifier is sent. Nothing about a profile is ever shared with other users or with any advertising network.

How long the photos are kept. For as long as the profile exists. They are re-read each time we generate a profile asset. They are not discarded after the profile is built — an earlier version of this policy said they were, and that was wrong.

No faceprint, and no model trained on you. We do not build a face template, an embedding, a faceprint or any other biometric identifier from your profile photos, and we cannot use a profile to identify you, to match you against other images, or to search for you. No per-user AI model is trained on your photos. The code to fine-tune a model on a profile exists in our backend but is not reachable from the App and is not switched on; if we ever enable it we will update this policy and ask for your consent before it applies to your photos.

What a profile does today. A profile currently provides your avatar and the banner you see in the App. It does not yet change the images you generate.

Consent, and what is wrong with it today. Before any photo leaves your device, the App asks you to accept an AI and data-use disclaimer on its own screen, and that acceptance is recorded against your account with its version, the platform and the app version. That single account-level disclaimer is the only consent the Service records, and it is the consent we rely on here. We will not pretend it is more than it is:

• It is asked once per account, before your first upload of any kind. For most people that is an ordinary photo effect, possibly months before they create a profile.
• Its text does not mention a face, biometrics, a personal profile or special-category data. It covers uploading a photo for AI processing in general.
• There is no separate consent screen for photographs of your face, and no separate record of one.

So if you are asking whether we hold a specific, informed, explicit consent for processing photographs of your face — of the kind GDPR Article 9(2)(a) and KVKK Article 6(2) describe for special-category data — the honest answer today is that we hold a general consent to AI processing of your photos, plus your own deliberate act of creating a profile and uploading those photographs to it. We consider that insufficient for data this sensitive and we are adding a profile-specific consent step, with its own text and its own record, which we will describe here when it ships. Until it does: if you would rather we did not process photographs of your face, do not create a profile — every other part of the Service works without one. You can withdraw at any time by deleting the profile; withdrawal does not affect processing already carried out.

One further limitation, for completeness: the App records your acceptance of the disclaimer in the background rather than waiting for our servers to confirm it. If that request fails, you may have accepted the disclaimer with no record of it on our side.

Only your own likeness. You may only build a profile from photos of yourself. Creating a profile of another person is prohibited by our Terms of Use. Note that nothing in the Service verifies whose face is in a profile photo.

Editing a profile. The App does not currently offer a way to rename a profile, change its gender or add photos to it, although our API supports all three for the account that owns the profile. If you want a different profile, delete it and create a new one.

How to delete it. You can delete a profile in the App at any time. This deletes the profile record, its photos and its generated avatar and banner from our database and from our file storage, cancels any work still running and returns credits for work not delivered. Two caveats. Removing each stored file is best-effort, as Section 17 explains. And where we still owe you credits for a profile we did not deliver, the deletion waits until that return succeeds — if our purchase service is briefly unavailable, the App asks you to try again in a moment. It does not remove images you have already generated and saved, and it does not remove the copies your device holds.

6. Face data

This section describes every use of a face-related API in Pionare, so that it can be read on its own.

Pionare uses on-device face detection. It does not use face recognition. Specifically: when you finish picking photos from your photo library, or take a photo with the camera, on the screen where you choose the photos for an effect, the App runs Apple's Vision framework request VNDetectFaceRectanglesRequest on those photos, on your device.

What we do not do. Pionare does not use ARKit, the TrueDepth camera or any depth-capture API. It does not use face recognition, face tracking, facial-landmark detection, face-capture-quality detection or any other Vision or Core Image face request beyond the rectangle detection described above. It does not create a faceprint, a face template or any other biometric identifier, and it cannot identify you, match you against other images or search for you. No face detection or face analysis of any kind runs on our servers. The App also declares a Face ID usage string in its bundle, but it does not use Face ID or any biometric authentication — no biometric data is requested or read for signing in.

Where it runs, exactly. One screen and one call: the photo-selection screen used for effects and styles. It runs before you continue, before the AI and data-use disclaimer, and before any byte is uploaded. It does not run when you create a personal profile — those photos are uploaded with no local face check. If the check cannot run, it fails open and every photo you picked is kept, so it is a convenience filter and not a control that enforces anything.

One iOS side effect worth naming. If a photo you select lives only in iCloud, iOS may download the full-size original to your device so the check can read it. That transfer is between Apple and your device; it does not involve us.

Photographs of faces are a separate matter. This section is about face-detection data. The photographs themselves — which may show your face — are uploaded, stored and sent to an AI provider as described in Sections 4, 5 and 17. Those two things are governed separately, and neither implies the other.

7. Descriptions and the writing assistant

You can describe what you want in your own words. The text you type is sent to the AI provider as part of the model input. Where you are describing a change to a photo you selected, the link to that photo goes with it; on the Create screen, where you write a description on its own, no photo is uploaded at all and the description is the entire input.

If you use the writing assistant ("Rewrite with AI"), your text is sent to OpenAI, which expands or rewrites it; the rewritten text is then used for generation. Only the text is sent — no photo, no account identifier. Using the assistant is optional.

Our backend also contains an optional step that would ask an OpenAI vision model to describe your uploaded photo and add that description to the prompt. It is switched off for every feature in the Service, so no photo reaches OpenAI on this path today. If we switch it on we will update this policy.

8. AI processing providers

Two third parties process the photos you upload, the photos behind a personal profile, and the descriptions you write, on our behalf and as our data processors. They are the only two we contract with; each may use its own sub-processors, and in Replicate's case that includes the publisher of the model you are using, as explained below. (A separate AI use that touches account records rather than your photos is described at the end of Section 11.)

The models. Every generation runs through Replicate. The vendors whose models run on your photo are OpenAI, Google, ByteDance and xAI, all reached through Replicate. At the time of writing the model identifiers are openai/gpt-image-2 (the great majority of photo effects and styles), google/nano-banana-2 (a small number of photo effects), google/nano-banana (the Edit-screen styling menu), bytedance/seedance-1.5-pro and xai/grok-imagine-video-1.5 (video). We can change which model a feature uses from our own dashboard, without an update to the App, so treat those identifiers as examples current on the date at the head of this policy rather than as a closed list; the four vendors, and the fact that everything goes through Replicate, are the part we commit to keeping accurate. Depending on how Replicate serves a given model, the model's vendor may process your photo as Replicate's sub-processor.

Providers that receive nothing today. Two other companies appear in our systems without receiving your data, and we keep them listed here because we may switch one on later. fal.ai, operated by Features and Labels, Inc., was named as a current provider in an earlier version of this policy; it is not one, and it has never received your data. Higgsfield is a connection we finished building on 23 September 2026 — no credentials for it are configured, no feature in the App or on the Website uses it, and no request has ever been sent to it. If we do switch either of them on, the photo you upload or the text you write would be sent to that company to produce the result you asked for, and we will update this policy, and the date at the head of it, before that happens.

We do not use MiniMax, AILabTools, Phot.AI, Remini, Vance or KlingAI. Today Replicate and OpenAI are the only AI providers that receive a photo, a profile photo or a description you wrote; the one other AI use in the Service touches account records rather than content and is described at the end of Section 11.

Each provider processes your data under its own terms and data-use policy, and keeps inputs and outputs for its own operational period, which we do not control. Each also publishes its own policy on whether data submitted through its API may be used to train its models; we link both below rather than summarise them, because they are their statements to make and to change, not ours. See Replicate's privacy policy and OpenAI's privacy policy. Both apply their own content restrictions, which prevent certain material from being generated.

Future providers. We may add or replace AI providers, including providers located outside Türkiye and the EU. When we do, we require them to protect your data under appropriate agreements and safeguards, and we update this policy. This processing involves transferring your data to servers in other countries — see Section 19.

9. Permissions the App asks for

iOS asks you for each of these, and you can change any answer later in iOS Settings. The explanations below match the wording shown in the system prompts.

The App does not ask for, and does not use, your location, your contacts, your microphone, your calendar, your health data or your video library. It declares a Face ID usage string but does not use Face ID or biometric authentication.

10. Push notifications

The App asks permission to send notifications once there is an account to attach the token to — which on a new install is the guest account, so this happens before you have signed in to anything — and after the opening screens and the tracking prompt. If you allow it, your device is issued a push token by Firebase Cloud Messaging. The App sends that token to our API, which passes it to our own notification service — a separate service we operate, not a third-party vendor — which is the system of record for push tokens. Only the account that owns a token can register it.

Today we send one kind of notification: a message telling you that a generation you requested has finished. That is a service message, not marketing. Our notification service is also capable of sending service or product announcements to groups of accounts, and if we ever do that we will say so here first. There is no in-app switch to refuse notifications selectively — iOS Settings and signing out are the controls you have, and we are looking at adding a proper one. The visible text is generic ("Your image is ready"), but the payload behind it contains the link to the finished result, along with the generation identifier, the feature identifier and the credit cost. Because the notification is delivered through Apple's Push Notification service and Firebase Cloud Messaging, Apple and Google handle that link in transit. This is the one case in which a third-party tool touches something you created.

The App does not report back when a notification arrives or is opened; there is no delivery or open telemetry of our own.

Turning it off. There is no notification switch inside the App today. Use iOS Settings to stop receiving notifications; note that this stops delivery but does not remove the stored token. Signing out removes that device's token, and deleting your account removes every token on the account. Two things are not removed: the send history kept by our notification service, which includes the payload and therefore a link to content you generated, and the entry in our technical request log for the call that registered the token, which contains the token itself and has no expiry. Section 17 covers both.

11. Third-party tools in the Service

Tools we do not use. There is no analytics SDK in the App or on the Website — no Firebase Analytics, no Google Analytics, no Mixpanel, Amplitude, Segment, PostHog, Plausible, Hotjar or Clarity. There is no crash reporter or error-monitoring tool of any kind — no Firebase Crashlytics, no Sentry — in the App or on our servers. There is no Meta or Facebook SDK, no advertising SDK, and no ads are shown. Earlier versions of this policy listed Firebase Analytics, Firebase Crashlytics and Meta Platforms as providers; they are not present in the Service, and the data those entries described is not collected.

Other than the notification payload described in Section 10, and other than passing through Cloudflare in transit, none of the providers above receives your photos, your personal profile, your descriptions or the content you create.

One further AI use, on account data rather than content. When we prepare a notification audience — for example "accounts that have not generated anything in a month" — our administrative tools can send that description, together with sample values taken from account records, to an AI model inside our notification service, which turns it into a database query. Those sample values can include email addresses and display names. No photo, no profile photo and nothing you have generated is involved. We are confirming which provider and which terms apply to that model and will name it here; if we cannot do so on terms we are satisfied with, we will switch the feature off.

Style catalogue. The App retrieves the list of available styles, effects and categories from our servers, so we can offer new ones without an app update. That request carries technical data such as your app version; it does not carry your photos.

12. Advertising and tracking

We advertise Pionare on third-party platforms, and we need to connect an install or a subscription back to the advertisement you saw. The App's own privacy manifest declares this as tracking, and declares that the device identifier we collect is linked to you and used for third-party advertising and analytics. We own that description rather than soften it.

• Once the App's opening screens are out of the way, iOS asks whether you allow Pionare to track you across apps and websites owned by other companies (Apple's App Tracking Transparency prompt). It is asked once per install.
• If you allow it, AppsFlyer may read your device's advertising identifier (IDFA) on the device and use it, with the identifiers listed in Section 3(j), to measure and optimise our advertising, and to combine data from the App with data from other companies for that purpose. Under Apple's definitions, this is tracking. Our own code never reads the IDFA in either case.
• AppsFlyer may pass attribution and subscription-revenue events on to the advertising platform that served the ad, according to the integrations we enable in our AppsFlyer account. No advertising network receives your photos, your profile, your descriptions or your creations.
• If you decline, your advertising identifier is not accessed — but advertising measurement does not stop. We would rather be clear about this than let the prompt imply otherwise. AppsFlyer starts as soon as the App has an account to name — on a new install, the guest account, before any sign-in — regardless of your answer, and we continue to measure installs, sessions and subscriptions using AppsFlyer's own identifiers and your account identifier. What your answer controls is your device's advertising identifier and the cross-company combination that depends on it. The App works fully either way — no feature, allowance or price depends on your answer.
• The tracking prompt mentions keeping your offers and recommendations relevant. The only mechanism behind that is which subscription or credit offer screen we show you, based on whether you already subscribe. It is not ad targeting inside the App, and the App shows no advertisements.
• We integrate no advertising SDK of our own, we show no advertisements, and we upload no audiences to any ad platform. Our attribution SDK may use Apple's own advertising-measurement interfaces — SKAdNetwork and Apple Ads attribution — as part of its standard behaviour; that is a function of the SDK rather than of code we wrote, and we do not switch it off.
• You can change your decision at any time in iOS Settings → Privacy & Security → Tracking.
• We do not sell your personal data.

13. The Website at pionare.app

The Website is an information site with our legal pages and a sign-in page. It is covered by this policy.

• No guest mode on the Website. The App makes an account for you; the Website does not. Signing in is the only way to have a session there.
• Signing in on the web. The Website offers the same three methods as the App — Apple, Google, and email and password — against the same Firebase project and the same account. Section 3(a) describes the data involved. Web sign-in does not create a device entry on your account.
• What the Website stores on your device. After you sign in, your session — an access token, a refresh token valid for up to 30 days, and your account record — is stored in your browser's local storage in plain text. Anyone with access to that browser profile can read it. Sign out, or clear the site's data, when you are finished, and do not sign in on a shared computer you do not control.
• Signing out on the web only clears your browser. Unlike the App, web sign-out removes the session from that browser but does not revoke it on our servers, so a token that was copied out of that browser beforehand can remain usable until it expires — up to 30 days. If you think a web session has been copied, change your password (or, for Apple and Google sign-in, revoke Pionare's authorisation with them) and write to [email protected]. We are changing web sign-out so that it revokes the session properly.
• No tracking on the Website. The Website sets no analytics or advertising cookies and contains no tracking pixels, tag managers or advertising tags. The sign-in session described above is the only thing it stores in your browser.
• No age check. As in the App, being 13 or older is a contractual requirement that we do not verify.
• Buying on the Website. Today the Website sells nothing: there is no pricing page and no checkout, and no payment provider is active on it. If we do start selling subscriptions or credits on the web, the checkout will be operated by Paddle as merchant of record; Paddle would receive your payment details directly and we would still never see your card number, and anything you buy on the web would be delivered to the same account balance you use on your phone. We will update this policy before any web purchase is possible.

14. How we use your data and our legal bases

Where we rely on consent, you may withdraw it at any time. Where we rely on legitimate interests, you may object. We do not carry out automated decision-making that produces legal effects for you.

15. How we share data

We do not sell your personal data. We share it only with:

• Replicate and OpenAI — as described in Section 8. They receive your photos and your text. They receive no email address, no name and no device identifier; the file links we hand them contain an internal account identifier, as Section 4 explains.
• Apple — for app distribution, in-app purchases, Sign in with Apple, and push delivery (which includes a link to your finished result).
• Google — for Firebase Authentication (all accounts), Sign in with Google, and push delivery through Firebase Cloud Messaging (which includes the same link).
• Adapty and AppsFlyer — for subscription management and advertising measurement, as described in Sections 11 and 12. They receive identifiers and purchase events, never your content.
• DigitalOcean — our hosting, database and file-storage provider, and Cloudflare, the edge network in front of it, which carries our traffic in transit.
• Professional advisers and authorities — where required by law, to comply with legal process, or to protect our rights, our users or the public.
• In a business transfer — if the Company is involved in a merger, acquisition or sale of assets, subject to this policy.

There is no sharing between users: the Service has no feed, no profiles other users can see, and no way for another Pionare user to see anything you create. You can of course share one of your own results out of the App into another app yourself, using iOS's share sheet; what happens to the file after that is outside the Service, and Section 16 explains why a file link should be treated as confidential.

16. Where your data is stored, and who can reach it

Location. Your account record, your generation records, your personal profiles, your uploads and your creations are held in a database and a file-storage bucket operated by DigitalOcean in Frankfurt, Germany (EU). Our API, our purchase service and our notification service run in the same hosting account.

Stored files are reachable by anyone holding the link. Every file we store for you — the photo you uploaded, the image or video we generated, your profile photos, your avatar and banner — is stored as a publicly readable object. Its address is made up of a folder path derived from your account identifier and the generation it belongs to, plus a file name carrying a timestamp and a short random token. We do not publish these addresses anywhere and an outsider is unlikely to guess one, but the address is not protected by a password, a signature or an expiry, and its random part is short rather than cryptographic. Anyone who obtains the link — because you sent it to someone, because it was forwarded, or because it was captured from a notification — can open the file, without signing in, for as long as the file exists. This is also how the AI provider reads your photo: we hand it the link and it fetches the file over the public internet. Because the folder part of the address is derived from your account identifier, sharing one file link also discloses the folder your other files sit in. Please treat a Pionare file link as confidential.

On your device. Your sign-in credentials and session tokens are stored in the iOS keychain. Because they are marked as available after first unlock rather than device-only, they are included in an encrypted device backup, and a restored device reports the same device identifier.

The two items that identify a guest account are marked device-only: the key described in Section 3(p), and a marker recording which iPhone first wrote it. Neither is synced to iCloud and neither is included in an encrypted backup, so a phone restored from a backup starts a new guest account rather than reopening the old one — and the old one, with its credits, its subscription and everything it made, cannot be reached from the new phone at all. Those two items are also not removed when you delete the App, which is why reinstalling returns you to the same account.

The App also keeps ordinary local data: a list of your recent creations with their links, the descriptions you wrote, pending jobs, your preference flags, a note of the last purchase made on this phone, and the support code described in Section 20. All of that is removed when you delete the App. On the web, your session sits in your browser's local storage — see Section 13.

Access inside the Company. Our administrative tools are behind authentication, and we use them only for support, abuse handling and operations. Those tools can list accounts by email address and display name, delete an account, and configure the styles, features and models the App offers. We are reviewing how administrative access is authenticated and will describe the arrangement here once that work is complete; we would rather say that than make a claim about it now.

Technical logs. Our servers keep a request log for a limited set of routes — mainly the administrative and catalogue routes, plus the one call that registers your push token. Where a route is logged, the full request and response bodies are stored, which is why your push token ends up in that log. Generation and authentication routes are deliberately not logged, so your photos, your descriptions and your credentials never enter it. The log stores no IP address and no user-agent, and it has no account field. It is not anonymous, though: the stored request path for the push-registration call contains your account identifier, so those rows are attributable to you, and they sit next to the push token itself. They have no expiry. Our separate application log records operational messages only; the code path that would write a failed request's headers and body into it is disabled by the log level in production. Retention is covered in Section 17.

17. Data retention

Two things in the Service expire on their own: sign-in sessions, and credit grants — free and subscription credits are granted weekly and lapse a week after they are issued, while the credit packs we currently sell carry no expiry. Everything else is kept until you or we remove it. In particular, nothing you create is deleted on a timer. Earlier versions of this policy described a 7-day automatic deletion of generated content; no such mechanism exists and none ever ran.

• Account data — kept while your account exists. Deletion is described in Section 18.
• Rate-limit counters — the IP, email-hash and guest-key-hash counters described in Section 3(k) expire within about two hours of the window they count, and nothing re-creates them.
• Photos you upload for a generation — kept indefinitely. This is the least flattering fact in this policy and we would rather state it than dress it up: we do not record where each uploaded input was stored, so deleting the result does not remove it, and neither does deleting your account. If you want uploads you have made removed, write to [email protected] and we will locate and delete them from our storage by hand.
• Generated images and videos, and their generation records — kept until you delete them in the App or delete your account. Nothing expires on its own. Content you saved to your device or to your photo library is not affected and stays until you delete it.
• Personal profiles, their photos and their generated avatar and banner — kept for as long as the profile exists. Deleting the profile deletes them from our database and our file storage.
• Files whose deletion failed. Removing a stored file is best-effort. If our storage refuses a delete, we still remove the database record, which leaves the file behind with nothing left to locate it by — the same situation described above for uploaded input photos, but reached through the delete button. We do not currently record which keys failed. We are changing that, so that these files become findable and deletable.
• Descriptions you write — kept on the generation record, for as long as that creation exists.
• Sign-in sessions — an access token lasts 15 minutes; a refresh session lasts at most 30 days and its record is deleted automatically when it expires. We store a cryptographic hash of the refresh token, never the token itself.
• A deleted guest account — erased immediately rather than after a grace period (Section 18). Where it still holds purchase records we cannot erase, the account row survives as a shell carrying only its identifiers and the dates of its deletion — no email, no name, no content. Its usage, request and activity rows are repointed to an anonymous marker rather than deleted.
• Consent records — kept, including superseded versions, for as long as the account exists, so that what you agreed to and when remains answerable.
• Onboarding answers — kept on the account for as long as the account exists, and erased with it. Adapty's own copy is kept under its retention, which our deletion does not reach.
• Content reports — kept while we investigate and to enforce our Terms; deleted when your account is erased. Because the report copies the link to the reported result, it outlives the result itself.
• Technical request logs — kept indefinitely today: there is no expiry on them. That includes the entry holding the push token described in Section 10, whose stored request path also contains your account identifier (Section 16). We are adding an expiry and removing that route from the log.
• Credit grants — individual grants lapse on their own. Free credits and subscription credits are issued weekly and expire a week after issue, whether or not you use them; the credit packs we currently sell carry no expiry at all. The underlying ledger rows that record the grant and the spend are accounting data and are kept as described in the next bullet.
• Purchase, credit and entitlement records — kept for at least 10 years, because Turkish tax and commercial law require it. We state that as a floor and not as a limit, deliberately: these records live in our purchase service, which today has no deletion or anonymisation route at all. So they survive account deletion, we cannot erase them on request, and nothing deletes them at the ten-year mark either. Adding that route is on our list.
• Notification send history — our notification service keeps a record of each notification sent, including its payload and therefore a link to content you generated. Deleting your account removes your push tokens but does not remove this history.
• Data held by Adapty and AppsFlyer — kept under their own retention settings. Our deletion process does not reach them; if you ask us, we will pass an erasure request on to them.
• Data held by our AI providers — Replicate and OpenAI keep inputs and outputs for their own operational periods under their own terms, which we do not control.
• Backups — records we have deleted may persist for a period in our hosting provider's routine backups before they are overwritten.
• On your device — the local copy of your recent creations, the descriptions you wrote and your preferences are removed when you delete the App. Files you saved to your photo library remain until you delete them.

18. Deleting your content and your account

Deleting individual creations. In your Library you can select results and delete them, up to 200 at a time. This deletes the stored files for those results and their generation records, including any intermediate steps. It does not delete the photo you uploaded as the input (Section 17), and it does not withdraw a report you have already filed. Removing the stored file is best-effort: if our storage refuses a delete, the record is still removed, which can leave the file behind with nothing left to locate it by — see the "files whose deletion failed" bullet in Section 17.

Deleting a personal profile. Described in Section 5. It removes the profile, its photos and its generated avatar and banner from our servers, subject to the same best-effort limitation on the file deletion itself.

Deleting a saved account. Open Settings in the App and choose Delete Account. Then:

• If you signed in with Apple, the App first asks Apple to revoke Pionare's sign-in authorisation.
• Your account is deactivated immediately and every session on every device is revoked. An access token issued in the last few minutes can remain usable for up to 15 minutes; after that nothing can reach the account. The App also clears its local data and signs you out.
• For a grace period of about 30 days — the App shows you the exact date when you delete — the account is recoverable: signing in is refused, and the App offers to restore the account instead. Restoring brings back your content, your credits and your subscription entitlement. This window is why your data is not erased the moment you ask.
• When the grace period ends, an automatic process erases the account irreversibly: your profile photos and generated profile assets, the stored files for your creations, your push tokens, your generation records, your flow runs, your profiles, your session records, the reports you filed, your identity at Firebase Authentication, and finally the account record itself. It also deletes any fine-tuned model version held at Replicate for one of your profiles — no such version exists today, because the fine-tuning feature described in Section 5 is not switched on, and if that changes the step is already part of this cascade.
• Erasure is thorough but best-effort. If a step fails — for example a third party is briefly unavailable — we retry; if it still cannot be completed, the deletion finishes anyway and we keep a record of what was left so it can be completed by hand.

Deleting a guest account. A guest account has its own control — Settings, then Delete my data — and it works differently, because it has to. A guest account has no sign-in you could come back through, so a 30-day grace period would protect nothing: it would only mean keeping your data for 30 days after you asked us to destroy it.

• The erasure runs at once and cannot be undone. There is no grace period, no restore, and no way for us to bring the account back afterwards.
• Before you confirm, the App asks our servers what the account actually holds and shows you all of it: how many creations and personal profiles, how many credits of every kind — free, gift, compensation and purchased alike — whether a subscription is active, whether a purchase is still arriving, and whether a generation is still running. If you are about to lose credits you paid for, it asks a second time.
• Deleting does not cancel a subscription. It is billed by Apple and must be cancelled in Settings → your name → Subscriptions; the App offers you that screen before you confirm.
• The same confirm offers to save the account instead. If what you want is to stop being a guest rather than to lose everything, that is the option to take.
• The erasure itself is the same cascade described above, and the key in Section 3(p) is removed from our records before any of it begins. Afterwards the App starts a new, empty guest account on the phone.

What survives account deletion. In the interest of not overstating it: the purchase, credit and subscription ledger (kept for at least 10 years for tax and accounting, with no route to erase it — Section 17); the notification send history described in Section 17; technical request logs, including the entry containing a push token; the photos you uploaded as generation inputs, for the reason given in Section 17; data held by Adapty and AppsFlyer; and copies in our hosting provider's routine backups until they are overwritten. Everything else in the list above is erased.

Signing out is not deletion. In the App, signing out revokes that device's sessions, removes the device from your account and removes its push token; each of those steps is best-effort, so one of them can fail while the others succeed. It is offered only on a saved account — a guest account has nothing to sign back in with, so the App does not offer it one — and signing out of a saved account returns the phone to its guest account. Signing out is different on the Website — see Section 13. In neither case does it delete any content, credits or subscription.

Deleting the App is not deletion. Removing the App from your device does not delete your account. Use Delete Account first if that is what you want.

19. International data transfers

Your account data, your uploads, your creations and your personal profiles are stored in Frankfurt, Germany, inside the EU. Several of our providers are outside Türkiye and the European Economic Area, in particular Replicate and OpenAI (United States), Apple, Google, Adapty, AppsFlyer and Cloudflare. Your personal data may therefore be transferred to and processed in countries whose data-protection laws differ from those where you live. In the generation flow specifically, the transfer takes the form of a provider outside the EEA fetching your photo from a publicly readable link (Section 16).

Where such transfers occur, we take steps to ensure an appropriate level of protection — for example through your explicit consent where the KVKK requires it, and through contractual safeguards such as the EU Standard Contractual Clauses where the GDPR applies.

20. Your rights

Depending on where you live, you have rights over your personal data, which may include the right to:

• learn whether we process your data and request access to it;
• request correction of inaccurate or incomplete data;
• request deletion of your data;
• object to or request restriction of certain processing;
• request portability of data you provided to us;
• withdraw consent at any time, without affecting processing already carried out; and
• lodge a complaint with a supervisory authority.

Under the KVKK you may exercise the rights set out in Article 11 and, if unsatisfied, apply to the Turkish Personal Data Protection Authority (Kişisel Verileri Koruma Kurumu). If the GDPR applies to you, you may complain to your local data-protection authority.

How to make a request. Email [email protected] from the address on your account, or write to us with enough information to identify your account. There is no automated data-download or request form in the App or on the Website: access, correction, portability and objection requests are handled by a person, by hand. We will respond within 30 days.

If your account is still a guest account there is no email address on it, so there is nothing for us to match you against. What the App can give you is an identifier: the support email it composes for you carries your account identifier, and where it has failed to reopen a guest account it shows a support code beginning with R- and keeps it in Settings. That identifier or code is what we would ask for. We would rather say this plainly than imply a process we do not have — we verify a data-subject request by no other means, so if you have neither the phone nor the code, we may not be able to identify your guest account at all, and a request we cannot attach to an account is one we cannot answer. Saving the account with Apple, Google or an email address is what removes that problem.

You can also act directly, without contacting us:

• Delete individual results in your Library.
• Delete a personal profile in the App, at any time, independently of your account.
• Delete your account in the App — Settings, then Delete Account (Section 18).
• Change or withdraw tracking consent in iOS Settings → Privacy & Security → Tracking.
• Turn notifications off in iOS Settings.
• Sign out in the App, which unlinks that device and removes its push token.
• Clear the Website's stored session from your browser by signing out or clearing site data. Note the limitation in Section 13: this clears your browser but does not revoke the session on our servers.
• Delete files you saved to your photo library.

21. Security

What we do: data is encrypted in transit; your password is set and held by Google Firebase Authentication and never reaches us in any form; refresh tokens are stored only as cryptographic hashes and expire automatically; every account route checks that the caller owns the account it is acting on; sign-in credentials are held in the iOS keychain; administrative tools sit behind authentication and are used only for support, abuse handling and operations; and generation and authentication requests are excluded from our request logs so your photos, descriptions and credentials are not written into them.

What you should know about the limits, stated honestly rather than glossed: stored files are publicly readable to anyone holding the link and those links do not expire (Section 16); a web session is held in your browser's local storage in plain text and signing out on the web does not revoke it on our servers (Section 13); session credentials on your device are included in encrypted device backups; the request log described in Section 16 has no expiry and holds a push token alongside an account identifier; and we run no crash-reporting or error-monitoring tool, so we depend partly on you telling us when something goes wrong.

No method of transmission or storage is completely secure, and we cannot guarantee absolute security. Keep your sign-in details to yourself, treat file links as confidential, and tell us at [email protected] if you believe your account has been accessed by someone else.

22. Apple App Privacy

Apple requires us to disclose our data practices on the App Store product page (the "privacy nutrition label"), and the App also carries a privacy manifest inside the binary. Our intention is that both match this policy, which means they should cover an email address, user and device identifiers, photos and videos you provide, the content we generate for you, purchases, and — where you allow tracking — an advertising identifier used for third-party advertising and measurement; and that neither should declare biometric data, because no face data is collected (the check in Section 6 stays on your device), nor crash or performance data, because none is collected. We are reviewing both disclosures against this policy: the manifest shipped in the current build declares only a device identifier, which is narrower than what we describe here — and narrower still now that an account identifier exists, and is sent to AppsFlyer and to Adapty, before anyone has signed in. This policy is the fuller and more accurate statement, and we are bringing the disclosures into line with it. If you spot a difference, tell us at [email protected].

23. Changes to this policy

This policy was last updated on 10 October 2026, which corrected Sections 3(b), 11 and 14 and added Section 3(q): the answers given on the App's opening screens, the age range among them, are now stored on the account, where an earlier version of this policy said they never reached us. The revision of 7 October 2026, which added the disclosure in Sections 3(b) and 11 that the App's opening screens ask five questions — your age range among them — and that Adapty keeps those answers on its own side. The revision of 6 October 2026 rewrote the policy for guest accounts, which the App now creates for every new install: the account requirement is gone from Section 2 and Section 3(a), the key that identifies a guest account is set out in Section 3(p), and Sections 10, 11 and 12 correct the claim that AppsFlyer and the notification prompt waited for a sign-in — they do not, and have not since the App stopped asking for one. It also corrected Section 3(k): our servers do now store your IP address, briefly, in the counters that limit abuse, where an earlier version said they stored none. Section 18 states that deleting a guest account is immediate and irreversible, Section 16 that its key is not in any backup, and Section 20 that we may be unable to identify a guest account at all. The second identifier that used to be attributed to our purchase service no longer exists and has been removed throughout.

The revision of 24 September 2026 corrected several statements in the version before it that did not describe the Service accurately: the 7-day automatic deletion of generated content, the claim that personal profiles were stored on your device and their photos discarded, the statement that no face-detection API was used, the naming of fal.ai as a current AI provider, and the listing of Firebase Analytics, Firebase Crashlytics and Meta Platforms as tools in the App.

One inconsistency you may notice in the App itself. The AI and data-use disclaimer screen inside the current build still names fal.ai, and still says that your photos and results are stored on your device rather than in an account on our servers. Both statements are wrong and this policy is correct. We said on 24 September that the screen would be rewritten and re-shown in the next release; three releases have shipped since and it has not been, so we will not repeat the promise with a date on it — it is overdue, and it is now also the only legal screen a new user sees before their first upload. Until it is corrected, treat this policy — not that screen — as the accurate description of what happens to your photos, and please read Section 5 before creating a personal profile.

We may update this policy again. We will change the "Last updated" date and, for material changes, give additional notice such as an in-app message. Where what we do with your uploads or who processes them changes materially, we will also ask you to accept the in-app AI and data-use disclaimer again.

24. Contact

TECHNOGRADE YAZILIM TEKNOLOJİ VE TİCARET LİMİTED ŞİRKETİ, Merkez Mah., Feriköy Fırın Sok. No: 69/2, Şişli, İstanbul, Türkiye. Email: [email protected]