Skysta Privacy Policy, in full

1. You need an account, and what that account holds

Skysta cannot be used signed out. Every screen is behind the sign-in gate: there is no feed, no map, no Discover and no sky until you are signed in.

You can sign in two ways:

• Email and password, handled by Google Firebase Authentication. The minimum password length is six characters.
• Sign in with Apple. Skysta asks Apple for your name and email address. If you choose Apple’s Hide My Email, the relay address is all Skysta ever receives, and it is used exactly like any other address.

Skysta offers no two-factor option.

What is stored about you as a person:

That is the whole of what sits under your account. Skysta stores no phone number, no address, no date of birth, no payment details, and no contacts.

Six other things carry your account identifier and do not live under your user document, so they are not in the table above and are set out where they belong: what you have shared (§4), a report you file (§6), a spot suggestion, a spot correction or a feedback note (§9.1), a small server-side counter of how many verification emails your account has been sent (§1.1), an online-status record, and a review of a trusted spot if there is one under your account, which is a retired collection nothing writes to now (§6).

The online-status record, in full. While Skysta is open on your screen it writes a small record in a separate Google database, the Firebase Realtime Database, saying this account is connected right now. It is filed under your account identifier. That database holds nothing else of yours: this record is the only thing Skysta puts in it. Here is every field in the record, and there are no others.

It holds no place, no name, no email address, and nothing about what you were doing in the app. The rules on it let exactly one account read it, which is yours, and that database refuses every read above that point.

What it is for, and this is the honest answer. It is there so that a connection which is live can be told apart from one that has gone away. The only code that reads it is the code that tidies it up: when Skysta connects it looks over your own earlier connections and removes any whose heartbeat has gone stale, and deleting your account reads the record in order to delete it. The developer’s own tool reads the list of these records when it sweeps up anything an account deletion left behind, and all it does with what it finds is remove it. Nothing else reads it. No screen in Skysta shows your online status, or anybody else’s, to you or to anyone, and nothing on the server acts on it. It is written, it is kept, and it is deleted, and today that is the whole of its life. If that ever changes, this policy changes with it.

Every time you put the app in the background, close it, or sign out, the connection entry is removed and a single timestamp of when you were last connected is written in its place. That timestamp stays under your account identifier. Signing out does not clear it. It writes a fresh one. Deleting your account removes the whole record, the connections one by one and the timestamp with them (§11, step 9).

And one more thing can carry your identifier, but only if the developer has acted on your account: the record that a moderation or an erasure happened. §6 sets that out.

1.1 New email accounts must prove the address

An account created with an email address and password has to prove that the address is yours before the app will open.

• Skysta’s own server-side function asks Firebase Authentication to mint a verification link for the address you signed up with, and then hands the finished message (your address, the link, and nothing else about you) to Resend, an email delivery service, which sends it on Skysta’s behalf. If that route fails, Skysta falls back to asking Firebase to send its own plainer message instead. Skysta operates no mail server of its own. The function’s own log lines keep only a masked form of the address, and never the link’s secret.
• There is a small counter, and it is the only thing this step stores. So that nobody can be used to send a person a hundred messages, the function keeps one record per account: how many verification emails have gone today, and when the last one went. It is filed under your account identifier and holds no address, no name and no link. No copy of Skysta can read it or write it, and it is not reached by deleting your account in the app (§11.1). There is a second record of the same kind counting the whole service’s messages for the day, and that one is about Skysta rather than about you.
• Until you follow that link, the only screen you can reach is the one asking you to. From it you can have the message sent again, or sign out and start over with a different address.
• Skysta re-reads your account from Firebase when that screen opens and each time you return to the app, so following the link in your mail app is all that is needed. The only value it reads is Firebase’s own record of whether the address is verified. Nothing about the message is collected by Skysta: not whether it was opened, not when, and not from where.
• Sign in with Apple is exempt. Apple has already established the identity behind the credential, private relay addresses included, so an Apple account never sees this screen.
• Accounts created before 19 August 2026 are exempt. The requirement was applied to new sign-ups only.
• If Firebase does not return a creation date for the account, Skysta lets you in rather than locking you out on a missing value.

This step exists so that an address nobody controls cannot be used to open an account. It does not make Skysta able to read your mail, and it adds nothing to the list of what is stored about you above.

1.2 Skysta asks you for a name, and your byline

Skysta asks what to call you before it opens, and it is not optional. After the address check in §1.1, and before you reach the app, one screen asks for a name. There is no skip: the button stays off until you type something. That name is what appears under every sky you share from then on, and the screen says so in those words. A profile photo is offered on the same screen, and that one you can leave alone. §1’s table covers both.

An account signed in with Apple usually arrives with a name already, so it normally never sees this screen. An account without one does, whichever way it signed in.

Skysta shows you the part of your address before the @ as a friendly name for yourself, on your own screens, and it does not publish that string, ever. A Skysta watcher is the byline the app falls back to if a sky is ever shared without a name, and no shipped path now reaches that state.

You can change the name later in Settings → Edit name. It applies to every sky you share from that moment on, but not to skies already published, which cannot be edited (§7).

2. Location, at every level of precision

Skysta is an app about where the sun meets the horizon, so it needs to know roughly where you are. It asks for While Using the App access only. The first-run screens ask iOS for roughly kilometre accuracy; everywhere else in the app the request is for roughly hundred-metre accuracy. What iOS then hands back may be better than that, and Skysta neither asks for nor discards the difference.

There is one exception, and it is one you ask for. Turning on Show on the map for a photograph needs a precise position to publish, so at that moment Skysta asks iOS for temporary full accuracy and iOS shows you its own Precise Location prompt. You can refuse it, and refusing only means that photograph carries no exact pin. Nothing else in the app asks for it, and the permission is temporary: iOS drops it when you leave.

Here is every location value the app holds, and exactly how far each one travels.

The map of spots on the website. The map of spots is drawn with map tiles from OpenFreeMap (tiles.openfreemap.org), a free project run on its own servers behind Cloudflare. To draw the map, your browser asks it for the pieces of map on your screen and the fonts for the labels. Each request carries your IP address, the map area you are looking at, and the name of our site. That is how any map on any website works. OpenFreeMap sets no cookies and asks for no key or account. We send it nothing about you, and it cannot tell who you are. If your browser cannot draw this kind of map, the older map from OpenStreetMap (tile.openstreetmap.org) is used the same way, under the OpenStreetMap Foundation privacy policy.

Suggesting a spot on the website. The form at skystaapp.com/spots/suggest sends the name you gave the place, its town and two-letter state or country if you filled them in, why you think the sky is good there, whether it is better at sunrise or sunset, the exact point you marked on the map, and your email address if you chose to leave one, to our own server (the same Cloud Function at the site’s own address), which files it in the same review queue the app’s suggestions go into. Nothing else goes with it: no account, no cookie, and the server does not keep your network address. §15.1 has the whole path.

2.1 Where the published place name comes from

When a shared sky carries a place name, that name is produced by asking Apple’s reverse geocoder what sits under the capture coordinate, at the moment you share. It names where the photograph was taken. Two things about it are worth knowing:

• The geocoder prefers the town (“Orem, UT”), falling back to the county or region when no town is incorporated there. If the lookup fails, the post simply carries no place name. Skysta never substitutes a guess.
• There is no way to type a place name of your own choosing. The place name is published only when the map switch is on, and it starts off. Left off it publishes no place name and no pin, but a shared sky still carries the ~5.5 km cell described in §4. If you would rather publish nothing, keep the sky in your journal.

2.2 Your capture coordinates stay on the phone unless you map that sky

Every photograph you take with Skysta records where it was taken, at full precision, so that it can surface on the page of a nearby trusted spot. That record lives in one file inside the app’s own storage. It is never uploaded, it is deliberately excluded from your iCloud and device backups, and it is erased when you delete the photograph, sign out, or delete your account.

Read that as being about the coordinate, not about the photograph. The photograph itself is copied to your private area of Skysta’s server (§3.2). The coordinate is not: the backup record has no latitude or longitude field and the app never writes one. So a journal photograph restored onto a new phone can never be put on the map afterwards, because there is no coordinate left to publish.

One thing does come back with it. If the photograph carried a trusted spot tag when you took it, the backup record holds that spot’s public name and its identifier, and the restored photograph comes back wearing them. That is not your coordinate, but a spot name is a place, and it puts you within 500 metres of a named public overlook. A photograph taken nowhere near a trusted spot has no tag and comes back with nothing.

Two routes lead from that coordinate to the network. The first is sharing the photograph at all: every shared sky with a capture coordinate carries that coordinate snapped to a 0.05° grid, about 5.5 km, as the locality cell §4 describes. The second is the map switch described in §4. It starts off, and when you turn it on it publishes the coordinate exactly as recorded, as the pin on that one photograph.

To be precise about the word exact: what is published is the position iOS gave the app at the moment of the shutter, unrounded and unaltered. Skysta does not coarsen it, and it does not sharpen it either. Its real-world accuracy is whatever the phone achieved: often a few metres outdoors with a clear sky, and no better than the roughly hundred-metre accuracy the app asked for. Treat it as a pin on your actual position, because in practice that is what it is.

2.3 What is included in your device backup

Everything Skysta writes into ordinary app preferences is inside your device and iCloud backup, because iOS gives an app no supported way to keep preferences out of it. Files are a different matter, and there Skysta excludes what it can: the journal directory, your plan, a staged sky rating, the list of images that would not delete, the photograph you are part-way through composing, and the diagnostics buffer are all marked so that Apple’s backup skips them. One file directory is not, and it is named below.

That exclusion keeps your capture coordinates and your original photographs out of Apple’s backup of your phone. It does not mean the photographs exist in one place only: they are also in Skysta’s own storage, under your account. §3.2 describes that copy.

Here is what is actually in your device backup.

• Your watched place, meaning the coordinate and the name of the town Skysta is showing you.
• Your reminder settings, your quiet hours, your units and your interface preferences, and a pre-written sentence about tonight’s sky at that place, which the app keeps ready so a reminder has something true to say.
• Your two diagnostics answers: app counts, and crash reports (§8).
• The anonymous measurement identifier described in §8, which exists only while app counts are on and is never sent anywhere. It goes when you turn app counts off, when you sign out, and when you delete your account. It has nothing to do with crash reports, which carry an identifier of their own that Google’s library makes and §8.3 names.
• The short list of firsts described in §10.
• The account identifier of the last account signed in on this phone.
• Two of the three short per-account lists of unfinished work §10 describes: the journal backups you deleted that the server has not yet confirmed gone, and the saved spots whose add or remove has not yet reached the server. The first names photographs, the second names public spots, and neither leaves the phone. The third list, the image files of deleted skies, is a file rather than a preference and is one of the things Apple’s backup is told to skip.
• Your profile picture, cached on the phone under your account identifier so that it is on screen before the network answers. This is that one directory. It is a photograph of you, it is in your backup, and it is deleted when you sign out and when you delete your account.

None of these preference files is uploaded to Skysta. Some of the values in them do travel, and §9 says exactly where. The watched place’s coordinate goes to Apple at full precision for the forecast and the town name, and rounded to about a kilometre to Open-Meteo for the haze. With app counts on, the short list of firsts is what decides which milestone events are sent, and §8 lists what rides with them. The rest of it is in your backup because it is on your phone, and your backup is Apple’s and yours.

2.4 Looking at other people’s skies sends coordinates from your phone too

Every row above is about a value of yours. One flow is not, and the table above claims to hold every location value the app handles, so it belongs here.

When you browse, your phone asks Apple to name other people’s pins. A shared sky whose author switched the map on carries a coordinate, and Skysta turns that coordinate into a town name by asking Apple’s reverse geocoder from your device. In the feed this happens only for a pin that arrived with no place name and no spot tag on it, because the rest already have a name to print. On a sky’s own page it happens for every pin, named or not, because the clock printed beside the photograph is the photographer’s clock and the time zone comes out of that same lookup.

Two honest consequences. The coordinate that leaves your phone is the author’s, at the full precision they published, not a rounded one. And, as §13.2 says of every request the app makes, it arrives at Apple carrying your device’s network address, so browsing the feed puts your rough whereabouts next to the coordinates of skies you are looking at. No Skysta identifier goes with it, Skysta keeps no record of it, and the answers are cached on the phone so one valley costs one request.

3. Your photographs

Photographs are captured with Skysta’s own camera, inside a live sunrise or sunset window. There is no import path from your photo library.

Every capture is written to the journal on your device, in the app’s own container, as the camera’s own file kept byte for byte, and a reduced copy is then uploaded to your own private area of Skysta’s storage (§3.2). Skysta cannot read your photo library; the permission it holds is add-only, used when you tap Save to Photos. Choosing a profile picture uses Apple’s system picker, which hands Skysta the one image you chose and never grants access to the library itself.

When you share one, the image is re-encoded from raw pixels and reduced to 3072 pixels on its long edge before it is uploaded. Re-encoding discards every piece of embedded metadata the camera wrote: GPS tags, capture timestamps, camera serial numbers, lens data. The file that reaches Skysta’s storage contains the picture and nothing else. The only property attached to it is the content type, image/jpeg.

Before a sky goes to the feed, your own phone looks at it. A photograph you are about to publish is checked by Apple’s sensitive-content analysis, which runs on your device and nowhere else. The picture is not uploaded to be judged and no person sees it. The check answers one question, yes or no. If the answer is yes, Skysta refuses to publish that sky and tells you so, and the photograph stays in your journal like any other capture. The result is never sent anywhere and never recorded against your account: there is no note that a picture was flagged, no count, and nothing that follows you.

And the check only runs if your phone is set up for it. It needs Apple’s Sensitive Content Warning switched on in iOS Settings. When that is off there is no check at all, and Skysta does not pretend there was one or treat an unchecked picture as a cleared one. Reporting, blocking and human review are what they always were.

A photograph you keep in your journal is never checked at all, and that is deliberate rather than an oversight. Screening a private archive would be surveilling it. Nothing about a sky that is never published is anybody’s business, this app included.

Your profile picture is checked the same way. A profile picture goes in front of every other account: it is stored at a path every signed-in account may read and it is drawn beside your byline on every sky you share. So before Skysta accepts the picture you picked, the same on-device check runs on it, on the same terms as a shared sky: only when Sensitive Content Warning is on in iOS Settings, on your phone and nowhere else, with the picture never uploaded to be judged and no person seeing it. If the answer is yes, Skysta refuses the picture before anything is written anywhere: the picture you already had stays, and the one you picked is still in your library. Nothing is recorded about the refusal, here or on the share path: no note, no count, nothing that follows you.

So the honest version is this: the check runs where a picture is about to be published, and only there. The share path and the profile picture both have it. The journal is out of its reach on purpose. §3.3 is the whole of what is and is not screened.

3.1 The camera controls collect nothing

Skysta’s camera lets you choose between the lenses your phone physically has, tap to focus, and shoots at the best frame quality the sensor offers within the app’s own budget. None of that changes what is collected, stored, or sent. Which lens you picked and where you tapped are used by the camera in the moment and are not recorded anywhere, not in the journal record, not in a shared post, and not in diagnostics. The quality setting affects the size of the file on your own disk and nothing else; the copy that leaves the phone when you share is reduced and stripped exactly as described above.

Skysta does not write a location tag into the image file itself. The coordinate of a capture is held only in the journal’s own record, as §2.2 describes.

3.2 Your journal is backed up to your account

The journal used to be device-local by construction, and signing out deleted it. Somebody who signed out, or lost their phone, lost every private photograph they had ever taken, while the skies they had shared came back, because those live on the server. That was backwards, so private photographs are backed up too.

What is stored, and where. Each journal photograph is uploaded to Firebase Storage at users/{your account id}/journal/{photograph id}.jpg, with one small description record in Firestore at users/{your account id}/journal/…. That record holds the photograph’s identifier, when it was taken, whether it was inside a live light window, whether it was a sunrise or a sunset, whether you kept it or shared it, the name and identifier of the trusted spot if the photograph carried a tag, when it was shared if it was, when the backup was made, and the storage path. There is no latitude and no longitude in it, and no field to put one in.

The copy is re-encoded, not forwarded. What goes up is a JPEG rebuilt from decoded pixels at 2048 pixels on the long edge. A shared sky gets the same kind of treatment at a larger size, 3072 pixels, and re-encoding is the reason neither carries any EXIF: no GPS tag, no camera serial, no capture clock. The original stays on your phone at full size; the restored copy is smaller than the one you took.

Who can read it. Only the account that owns it. The security rules on both the file and the record allow reading, writing and deleting only when the signed-in account is the owner of that path, and Skysta fetches these photographs with your credentials rather than minting a shareable web address for them. A journal photograph is not in the feed, is not on your profile for anyone else, and cannot be reached by any share link. Those address the shared posts collection only.

Now the parts that are not reassuring, because leaving them out would make this section advertising:

• There is no switch to turn the backup off. It runs for every signed-in account. If you do not want a photograph on Skysta’s server, do not take it with Skysta.
• The developer can reach the file. Administrator credentials bypass the security rules, as they do for every service of this kind. The rules stop other accounts, not the person who runs the service. Nothing in Skysta’s operation involves opening these files, and §6 describes the situations in which the developer deletes them.
• The upload is a queue, not a promise about timing. A photograph is on your phone the moment the shutter fires and goes up afterwards, retrying until it lands. Sign out before it has, and that photograph is gone with the rest of the local journal. The app counts anything still waiting and warns you before it wipes the phone.
• It is a second copy, so deleting one place is not deleting both. Deleting a photograph in the app deletes the file and the record on the server as well, and so does deleting your account (§11). Uninstalling the app does not: the backup stays until you sign in and delete it, or ask for it to be removed.
• A failed deletion is retried until it lands. The app removes the photograph from your phone immediately and then asks the server to remove the backup. If that second request fails, say on a dropped connection at the wrong moment, the request is written down on your phone and tried again: on the next attempt, and after a relaunch, until the server confirms both the file and the record are gone. Until then the photograph is treated as deleted everywhere it could be seen: it is held back from the restore, so signing in on a new phone does not bring it back.
• Deleting a photograph is not instant everywhere, and it takes a week to finish. The Google service the pictures sit in keeps a deleted file in a recoverable state for seven days before it destroys it. That covers a journal photograph you deleted, a sky you withdrew, your profile picture, and every image belonging to an account that has just been erased. No copy of Skysta can see those files and no link reaches them, but for that week the developer could restore one with administrator credentials. Nothing inside the app changes it. §6 has the whole of it.

What did not change. The coordinate still stays on the phone (§2.2). The journal is still absent from the feed and from every other account’s view (§5.2). The local copy is still excluded from your iCloud backup (§2.3).

3.3 What is screened, and what is not

One table, because a list is harder to be wrong about.

Three things follow from the third row.

A picture Skysta would refuse to publish as a sky is refused as an avatar too, by the same check read on the same terms. The same limit applies to both: on a phone with Sensitive Content Warning off, neither path is checked at all.

Nothing about an avatar is recorded either, so there is no queue, no flag and no count. That is the same as the share path and it is deliberate.

And a person can be reported and blocked, not only a photograph. Tap somebody’s name or picture on any sky they shared to open their page; its ⋯ menu has Report this person and Block. That report is about the account, meaning the face and the name beside it, rather than about an innocent photograph. §6 sets out what a report of either kind holds and how long it is kept. One honest limit remains: every route to a person’s page runs through a sky they shared, so somebody who has never shared one cannot be reached from any screen in the app. Write to hello@skystaapp.com and a person will look at it and take it down. Terms of Use §10 says the same thing from the other side.

4. What a shared sky publishes: the exact list

When you share a sky, the app writes one image file and one record. The record contains these fields, always:

• The photograph’s identifier
• Your account identifier
• Your display name (up to 64 characters)
• Whether it was a sunrise or a sunset
• Whether it was captured inside a live light window
• The moment the shutter fired
• The moment it was published (set by the server, not your phone)
• The storage path of the image
• An unused expiry timestamp. See §6
• An empty caption field. Skysta has no caption feature; nothing you write is stored, because there is nowhere to write it. The field is sent as an empty string only because the published server rule still expects the key.

And these, only under the conditions given:

The cell is the row that matters. It exists for exactly one thing: it lets your sky appear in the Local feed of people near where it was taken, without publishing where you stood. It is never drawn on any map, it is never turned into a place name, and nothing else in the app reads it. But it is a coordinate pair on a record every signed-in account can read, several kilometres coarse, so it is on this list as what it is rather than left to be found. Skies shared before 25 August 2026 carry neither the cell nor the shape, and the app treats their absence as what it is: an older post, drawn upright, sorted by its pin when it has one.

4.1 There are two controls, and they are independent

The composer has two separate location controls, and a single post can carry the results of both at once.

The spot tag appears automatically when the photograph was taken within 500 metres of a trusted spot. It publishes that spot’s public name. Tap the ✕ beside it to take it off. It is not affected by the map switch.

Two details about that 500 metres are worth stating, because both make the tag appear more often than you might expect. It does not depend on your having planned that spot, or on your having opened it, or on your knowing it is there: standing near a trusted spot is enough. And the distance is measured to whichever published point of the spot is nearest. A spot may publish both a viewing point and a car park, and being at either one counts.

Show on the map is a switch, chosen per photograph and never remembered between posts. It starts off. For everyone, on every photograph. There is no condition on that and nothing seeds it from anything: not from your last answer, not from your age, not from where you are. Because nothing is remembered, turning it on for one photograph turns it on for that photograph only. The next one starts off again.

Here is what each way does, set out side by side, because the two are worth telling apart.

The cell is on both rows, and that is not a mistake. Leaving the switch off publishes no pin and no town name. It does not take your sky out of its area. The coarse cell still goes, whichever way the switch sits, so the photograph still reaches the Local feed of people near where it was taken exactly as it would with the pin on. The cell is never drawn on a map and it never becomes a place name. The one thing it depends on is the photograph having a capture coordinate at all, as the table in §4 says. If you want a sky to say nothing whatever about where it was taken, keep it in your journal.

There is no map preview in the composer. The screen shows the photograph, the audience picker, the location row and the switch. You are told in words what will be published, and you are not shown a pin before you post.

4.2 The pin, precisely

The published coordinate is the one the photograph was taken at, unrounded.

The composer says so beside the switch. With it off, which is how you find it: “Nobody can see where you stood, even if you share this. Either way it shows up in Local for people near you.” With it on: “Anyone can see exactly where you stood, if you share this. Either way it shows up in Local for people near you.” A pin at your home is your home. Read that row before you share a sky from somewhere you would rather not name.

4.3 When a spot is tagged, the pin drawn is the spot’s coordinate

If the map switch is on and the post carries a trusted spot tag, the pin other people see is the trusted spot’s own published coordinate rather than yours: a named public overlook, which the tag already places you within 500 metres of. Combined with the timestamp it still says you stood at a named place at a particular minute.

Be clear about what that does and does not do. It changes what Skysta draws, not what is stored. The record still holds your exact capture coordinate, because that is what the map switch publishes. As §5 says, every field of every post is readable by any signed-in account, so somebody reading the record rather than looking at the map sees the exact point, not the spot’s. Sharing a sky with the map switch on publishes where you were, whether or not a spot tag is also present. The switch starts off, so that only happens on a photograph you turned it on for.

5. Who can see a shared sky

Every signed-in Skysta account. There is no friends list, no followers, no private audience. If it is not in your journal, it is visible to everyone who has the app.

That applies to the whole record, not just the parts Skysta chooses to draw: the security rule grants any signed-in account read access to every field of every post, and to every shared image and profile photo.

Two consequences are worth stating plainly.

Image links work without an account. Skysta asks Firebase Storage for a download link when it displays a photograph, and the link Firebase returns carries an access token that works for anyone who has it, signed in or not. Anyone who can see your photograph in the app can extract that link and give it to anyone at all.

Nothing prevents a viewer from keeping what they see. Skysta itself does not help them do it, and §5.1 explains what the app does and does not offer, but a screenshot is always available, on any phone, to anyone looking at any screen.

Treat a shared sky as public. It is.

5.1 What sharing a sky actually sends

Save to Photos appears only on your own photographs. It is on your journal captures and on skies you shared yourself. It is absent, not disabled but absent, from everybody else’s. A viewer cannot use Skysta to put your photograph into their camera roll.

Sharing somebody else’s sky sends an address, never the picture. Choosing Share on a sky you did not photograph hands the system share sheet a link of the form https://skystaapp.com/s/<identifier>, together with a short fixed invitation and subject line. The photograph’s pixels are not attached, so a sky forwarded by a viewer into Mail, Messages, a social app or a cloud drive arrives there as a link and nothing more. There is no control anywhere in the app that would let a viewer pass your picture on.

Sharing your own sky is a different act, and by default it does send the picture. Choosing Share on one of your own captures opens a screen that asks two questions and draws the card it is about to send, updating as you answer. The first question is what goes on the card: the photograph, which is where it starts, or the reading on its own with no picture. The second is whether the place is named on it: no place, which is where it starts, or the place’s name as a word. Whatever you choose, what leaves is a rendered image, and if that sky is already on the feed its link goes with it.

What that card never carries. No coordinate, at any setting. No file from your journal, no post identifier, no account identifier. The place, when you switch it on, is a name and never a point, and it is a name the app already held rather than one looked up for the occasion. And if the sky is already pinned on Skysta’s map, the sheet says so before you send, because that pin was agreed when you published and this screen cannot take it back. §7 can.

What the link does. Opened on an iPhone with Skysta installed, it opens that sky inside the app. The sign-in and email-verification gates stand in front of it, so whoever tapped the link has to have an account before the photograph is drawn. And if they have blocked its author, or the post has been deleted, they are told so instead. Opened anywhere else, it lands on a page at skystaapp.com that explains that the sky lives in the app. That page never shows the photograph, and the preview card a messaging app generates from it shows the Skysta logo, not the sky.

What the link does not do. It confers no permission you did not already grant by publishing. It reaches only the shared posts collection, so no link of any shape can address a private journal capture. A journal capture does have a copy on the server (§3.2), and this remains true of it: it sits at a path only its owner’s account may read, and the app fetches it with that account’s credentials rather than through a web address that could be passed on.

5.2 What other people cannot see

• Your email address. The document holding it is readable by you alone.
• Your journal: the photographs on your phone, and their backup on the server. No other account can read either one (§3.2).
• Your block list, or the fact that you blocked anyone.
• Your saved spots. The shortlist under your account is readable by one account, yours, and the same is true of the copy on your phone.
• Any report you file. Reports cannot be read back by any app, including this one.
• Any feedback you send. It cannot be read back by any app either.
• Any spot correction you send from Something wrong here? on a spot’s page. That one cannot be read back by any app either, not even by you, for the reason §9.1 gives.
• Your spot suggestions. You can see your own in Settings → My suggestions; no other account can see them at all.
• Any sky rating you give. Nothing in Skysta ever shows one back to anybody, you included, and the record carries no account identifier that could tie it to you in the first place (§8.1).
• Your online status, and the timestamp of when you were last connected that stays behind between sessions (§1). Both are keyed to your account identifier, and the rule on that data permits only you to read it.

6. How long things last, and what never goes away

This is the part most privacy policies get wrong, so read it carefully.

A shared sky stays in the public Moments feed for three days, measured from the moment it was published.

After three days it is not deleted. It moves. It remains, indefinitely:

• on your profile, where anyone who taps your byline sees everything you have ever shared, however old; and
• on the page of the trusted spot it was tagged at, if it carries a tag, where it becomes part of that place’s permanent gallery.

No server in Skysta deletes anything on its own. There is no scheduled cleanup job and nothing that wakes up on a timer. The record carries a field named expiresAt; the server checks its value once, at the moment of publication, and after that nothing reads it and nothing acts on it. Nothing in Skysta removes a shared sky on a timer.

Read that as being about timers, because two people can remove one. You can delete your own sky at any time, and that is the only route any copy of this app offers anybody. And the developer can take one down on moderation, with administrator credentials from outside the app (Terms of Use §10).

There are two genuine server-side retention windows, and both are below: the seven days Google Cloud Storage keeps a deleted photograph recoverable, and the one hour Firestore keeps a deleted record readable at an earlier moment. Neither deletes anything on a schedule. Each delays a deletion finishing. There is a third clock in this section and it is not on a server: the thirty days the developer’s own dated copies live on a laptop.

A spot you suggest from the website is kept until a person has reviewed it, and if we publish the place it stays as the record of where the spot came from. The email address you gave is kept only until we have replied about that one place, then deleted by hand, and the review desk flags any address still held every time the queue is opened. To have the suggestion or the address removed sooner, write to hello@skystaapp.com with the name of the place and roughly when you sent it. Website suggestions are in the daily database copy for up to thirty days like everything else in that copy.

Everything else:

• Your journal, on your device, stays there until you delete the photograph, sign out, or delete the app.

• Your journal’s backup (§3.2) is kept until you delete the photograph, delete your account, or the dormant-account rule in §6.1 reaches it. Signing out does not remove it. That is the entire point of it.

• Your account record, meaning email, name and profile photo, is kept until you delete your account.

• Your saved spots are kept until you unsave them or delete your account. Signing out clears the copy on the phone and leaves the list on the account, which is the whole reason it is on the account.

• Diagnostics, if you have switched them on, are kept by Google rather than by Skysta, under Google’s own retention settings for Analytics and for crash reports. Nothing in Skysta’s own code decides either period, and neither can be read from outside the Firebase console. No figure is given here, because no figure has been read off that console and written down. If the number matters to you, write to hello@skystaapp.com and it will be read off and sent to you.

• A review of a trusted spot, if there is ever one under your account, is kept until it is removed by hand. This is a retired collection, no part of the app writes one now, and the rules open it to no signed-in account at all, including whoever wrote it, so the Delete account button cannot reach it. Anything in it comes out by hand. Write to hello@skystaapp.com.

• Sky ratings (§8.1) are kept indefinitely. They are a calibration set for the forecast, and there is no identifier on them that anybody could use to find yours, which also means neither you nor the developer can pick one out to delete. If that is a reason not to answer the question, do not answer it, or leave app counts off.

• Reports cannot be deleted through the app by anybody, including the person who filed them. There are two kinds: a report about a sky, and a report about an account, which is the face and the name beside it (§3.3). A sky report holds which post, whose sky it was, who filed it, the reason picked from the fixed list, and when. An account report holds which account, who filed it, the reason, when, and the display name the account was showing at the moment the report was filed, written down because a name is one of the two things that kind of report exists to flag, and a name can be changed the minute somebody objects to it. Neither kind has anywhere to type, so a report never holds free text. It is one report per account per subject, so filing twice does not count for more. Kept, they part company by direction rather than by kind. A report filed about you or your sky is kept for good, because it is somebody else’s complaint and deleting it would erase the complaint along with its subject. A report you filed carries your account identifier in the record itself, so it cannot be stripped, only removed, and it is removed when the developer erases your account by hand or when you ask for it. It is not removed by the Delete account button (§11.1).

• The record that the developer acted on an account is kept for good. It is one of two things on this page that survive an erasure on purpose; the other is the report somebody else filed about you, in the bullet above. When a post is taken down, or an account is switched off, switched back on, erased, or has its journal backup deleted under the rule in §6.1, a line is written into a permanent log so that the decision stays reviewable afterwards. The line holds the account identifier, what was done, when, and counts of what it cost. Nothing is written here unless the developer acts. An account that is never moderated and deletes itself from Settings leaves no line at all.

  No name and no email address is written into it. Switching an account off, or switching it back on, used to write the display name, or the email address if there was no name. The erasure lever used to write an address on the very line recording that it had erased an account. Both were fixed on 22 August 2026, and the live log was swept the same day. What a line keeps is what was done, to which account, and when.

  A report the developer marks resolved does not keep the reporter’s words. That line used to hold the reason the person who filed the report typed, and the report’s own identifier, which has the reporter’s account identifier inside it. A line written now holds neither: the reason is not written at all, and the identifier is replaced by a one-way scramble of it. Be clear about the limit of that scramble. It carries no name and no account identifier on its face, and it is opaque to anyone reading the log on its own, but it is computed from two values the developer already holds, so the developer could work it out again. It is not a secret from that desk.

  The Delete account button in Settings cannot reach this log at all, by design, so anything that ever does need to come out of it comes out by hand. Write to hello@skystaapp.com.

• Spot suggestions, spot corrections and feedback you send are kept until the developer removes them. None of the three can be edited or deleted by any copy of the app, and none of them is removed when you delete your account. Ask, and they will go.

  One of the three does not go the same way as the other two when the developer erases an account. A correction and a feedback note are deleted outright. A spot suggestion is not: the erasure lever takes your account identifier off it and keeps the rest, because a spot in the catalogue that came from somebody’s suggestion would otherwise lose the record of where it came from. What stays on it is the place name you gave, the town, the exact coordinate you marked, and what you wrote about why the sky is good there. What goes is the one field that says it was yours. If you would rather the whole record went, say so when you write in; asking by hand can do what the lever will not.

• The verification-email counter described in §1.1 is kept until the developer removes it. It is one line of numbers under your account identifier, and deleting your account in the app does not reach it.

• Your online-status record (§1) is kept until you delete your account. While you are connected it holds a live connection entry. The moment you background the app, close it, or sign out, that entry goes and a single timestamp of when you were last connected stays behind. Nothing prunes that timestamp, no rule expires it, and signing out writes a new one rather than removing the old. It goes at step 9 of §11.

• Deleting a photograph is not instant. It takes seven days to finish. Google Cloud Storage, where every Skysta photograph lives, keeps a deleted file in a recoverable state for seven days and then destroys it. That covers a sky you withdrew, a journal photograph you deleted, your profile picture, and every image belonging to an account that has just been erased. For those seven days the app cannot see the file, no link reaches it, and no other account can touch it, but the developer could restore it with administrator credentials. After seven days it is unrecoverable. No switch in Skysta changes this; it is a setting on the storage service itself.

• A deleted record is readable for one hour. Firestore, where the records live rather than the pictures, keeps the previous version of a deleted or overwritten document readable at an earlier moment for one hour. That includes the account record with your email address in it. It needs administrator credentials, no copy of the app can do it, and after that hour it is gone from the database. This is Firestore’s own floor and the smallest setting available.

• Copies in the developer’s own backups, kept for thirty days, with three exceptions. Once a day, the first time the developer opens the admin tool, it writes a copy of nine collections to a folder on the developer’s own Mac, so that a bad script cannot destroy months of curated work. Those nine are the account records, the shared posts, the reports, the feedback, the spot suggestions, the moderation log, the spot catalogue and its working queue, and one retired collection of planned gatherings. So a copy taken before you deleted your account still holds what was there at the time.

  What a daily copy holds about you, thirty days or no thirty days: your account record with your email address, any sky you had shared with its coordinate and its place name, and any spot suggestion with your account identifier on it. A daily copy holds database records and no pictures, which is what the tool that writes them does.

  The rule, and the three holes in it. A dated copy more than thirty days old is deleted the next time the admin tool is opened. It is not a timer, because nothing in Skysta wakes up on its own: it runs on the first real request the tool makes, so a session that only browses candidates or runs a research import prunes nothing at all. The three holes are these. The three most recent copies are kept whatever their age, so that a rule written to protect you can never leave the developer with nothing. One dated copy, from 20 August 2026, is protected by name and will not be deleted by the rule ever, because the admin tool checks a sealed inventory bound to that exact folder when it starts. And a copy whose own record of when it was taken cannot be read is skipped rather than guessed at from the date on the file.

  The rule has never deleted anything. Everything that has ever come off that disk came off by hand. A rule that is working and a rule that has no work look identical from outside, so it is said out loud rather than left to be assumed. How many copies are on that disk on the day you read this is a measurement with a shelf life, not a fact about how Skysta works, so no count is given.

  That folder sits on one laptop, on no server and in no code repository, and the disk is encrypted. There is no automated way to take one record out of one file, so if you want yours out before the thirty days reach it, write to hello@skystaapp.com and it will be removed by hand.

6.1 The one retention rule Skysta operates: dormant journal backups

The journal backup is the one thing Skysta stores whose size grows with people who have stopped using it, so it is the one thing in the service itself with a retention rule. Here it is, exactly.

The measure. Your user document carries a lastActiveAt field, rewritten when you sign in and when you bring the app back to the foreground, at most once an hour. Skysta takes whichever is most recent of that stamp, Firebase’s own record of your last sign-in, and the day you created the account, so an account only looks quiet when all three say so.

The rule. If an account has not been used for six months, its private journal backup may be deleted. Nothing else about the account goes: the account itself, the profile, and every sky it has shared all remain, because a shared sky sits on other people’s spot pages and profiles and removing it would change what everyone else sees. Photographs still on that person’s own phone are untouched. They simply will not come back on a new one.

How it happens, honestly. It is not automatic. Skysta runs no scheduled job, no server that wakes up on its own, and no rule that fires on a timer: nothing in this service can delete anything by itself. The deletion is a page the developer looks at and a button the developer presses, one account at a time, and every press is recorded. Six months is the point at which an account becomes eligible, not a clock that goes off. So a backup older than six months may still be there, because nobody has pressed anything. Eligibility is a floor, not an alarm clock.

The software enforces that floor. The button reads the account’s own last-active date before it deletes anything, and refuses outright if that date is inside the last six months, naming the date on which the backup does become eligible. Six calendar months, counted properly, rather than 180 days, which is up to four days short of them. The page can still be set to show accounts quiet for three months, because looking is not deleting, but pressing the button on one of those rows fails and says why.

If you would rather your backup went sooner, delete the photographs or the account in the app, or write to hello@skystaapp.com.

7. You cannot edit a shared sky. You can take its location off.

Once a sky is published, nothing about it can be changed. Not by you, not by the app, and not by any modified client. The server refuses all updates to published posts outright, with one exception, which only ever removes:

Taking the place off a sky you already shared. Open it, tap the ⋯ menu, choose Remove the place. The map pin, the town name, the trusted-spot tag and the ~5.5 km locality cell (§4) all go, and your photograph stays exactly where it is.

Four things are worth knowing before you tap it.

• It is all of the place or none of it. The pin, the town name, the older region field, the spot tag and the locality cell are removed together. A control that took the pin off while leaving “Provo Canyon” on the post would be telling you a location had been removed when the post still said where you were, and a coarse cell left behind would be the same thing said more quietly. After this tap the record holds no location value of any precision.
• It is one-way. The server rule that permits this update permits only fields being removed. There is no value any copy of this app, modified or not, can write into a location field on a published post. So a sky can lose its place, and no sky can be moved or given one afterwards, including by you. The app says so before you confirm.
• It does not reach into other people’s screenshots. It removes the record. Anybody who already looked at the post already saw it.
• It is one request, and it is not retried. If it fails, say on a dropped connection at the wrong moment, the app tells you it could not remove the place and the post is unchanged. Nothing is written down to try again later, so tap it again when you have signal. The row is on the ⋯ menu of your own post whenever that post names a place at all, and it is simply absent when there is no place on it to remove.

To delete one sky: open it, tap the ⋯ menu, choose Delete. The record goes first, then the image file. If the image file will not delete, say on a dropped connection at the wrong moment, the app writes the file’s address down on your phone before it deletes the record, and keeps retrying it: on your next attempt, when the app next comes to the foreground, and again before your account is allowed to be deleted.

And then the file takes a week to finish going. Google Cloud Storage keeps a deleted photograph in a recoverable state for seven days before it destroys it. The sky is off the feed, off your profile and off the spot’s gallery the moment the record goes, and no link reaches the file, but for those seven days the developer could restore it with administrator credentials. There is no switch in Skysta that changes that. §6 has the whole of it.

8. Diagnostics and analytics: off unless you turn them on

Skysta collects nothing under either heading until you say so. There are two separate answers, and neither implies the other. Both start off and neither is ticked for you:

• Crash reports. If Skysta breaks, the report about the break goes to the developer. It is technical and it is not about what you did. §8.3 sets out what is on one, field by field, and what is not. Settings → Privacy → Crash reports.
• App counts and sky ratings. The nine kinds of count listed below, and the one-tap question about how a sky turned out that §8.1 describes. The rating record is the only one of these that writes down a place and a time, which is why it stays with the ask that says so rather than becoming a small warm row of its own that is easy to agree to without reading. Settings → Privacy → App counts and sky ratings.

Collection starts disabled at the level of the app’s own configuration, before any code runs, and stays disabled until you say otherwise. You can turn either back off at any time, and signing out turns both off for you, so neither answer passes to the next account on that phone. §8.2 is the whole of that.

The crash question is asked where a crash happened, and how that works is worth understanding. The crash library installs itself and writes its report to your own phone before it ever looks at whether sending is switched on. Only the sending is switched. So on a phone that has not answered the question yet, a crash is caught, a report is written to your storage, and nothing is sent anywhere. The next time you open Skysta, a card on Home says the app crashed last time and asks for that report, naming what is on it. Say yes and it goes, and crash reports stay on from then. Say no and it is deleted off your phone. Either way you are asked once, never again, and nothing had left your phone before you answered. It is a card inside the app: it is never a notification, a badge or a red dot, and it is never shown while you are signed out.

When crash reports are off, no crash report is sent. If you have not been asked yet, a report waits for that one question rather than being destroyed before you can be asked about it, and the library keeps at most four of them, dropping the oldest.

If you say no, or switch crash reports off later, what happens to a report already on the phone depends on when it was written. A report is only ever waiting on a launch where sending was off. On such a launch the app tells the library to delete what is waiting, and it is deleted. On a launch where sending was on, anything that was waiting went at the moment the app opened, so by the time you reach the switch there is normally nothing left on the phone to delete, and if the upload had failed the delete does not bite until the next launch, when it does. In both cases the app stops collecting the next one.

When counts are off, Skysta sends no analytics event, and the rating card in §8.1 is not shown at all. One thing is still written down and it never leaves the phone: the short list of firsts described in §10, which exists so a milestone cannot be counted twice and so that turning this switch on later does not replay your first month as though it were today.

And one thing goes whether either switch is on or off, so it is named here rather than hidden behind the word nothing. Every request the app makes to Firebase Authentication and to Firestore carries a small header that Google’s own libraries attach, called X-Firebase-Client. It holds an anonymous line naming which Firebase pieces the app is built with, and the calendar dates the app has been used, at most one date a day. Google’s own privacy manifests for those two libraries declare it as diagnostic data collected for analytics, not linked to you and not used to track you. No switch in Skysta governs it, because it rides on the requests that make the app work at all.

Two things are deliberately left out of that paragraph, because they are not established. Firebase’s installation library ships the same manifest declaration, but nothing in Skysta’s code shows it registering an identifier while both switches are off, so no claim is made either way. And only those two libraries were read in their own source, so only those two are named.

The counts switch governs two separate things. The first is Firebase Analytics, described here. The second is the one-tap question about how a sky actually turned out. The record it writes, the one carrying a coordinate rounded to about 5.5 km, goes into Skysta’s own database and never into Firebase Analytics, and §8.1 sets it out field by field. That card sends nothing at all to Firebase Analytics.

Crash reports are not on the counts switch. They have their own answer, and turning counts on does not turn them on. The two do touch in two places, and both are named in §8.3: the last few counts before a crash ride inside the crash report as a breadcrumb list, and a crash sends one count of its own.

When counts are on, these are all the events Skysta itself sends. Nine kinds of event, and this is all of them. Firebase adds a few of its own on top, and the bullet after the list names those, because a section that called nine the whole of it would be wrong:

• That you brought Skysta to the front. One event each time, carrying only how the app was opened: straight from the icon, from a notification, or from a link. Not one per day and not one per install: flick back to Skysta ten times in an afternoon and that is ten events. Nothing at all is recorded when you leave, so the gap between one of these and the next is not measured by Skysta.

• That a reminder was placed, and whether you opened it. Two events. The first says which kind of reminder was set, which is one of sunrise reminder, sunset reminder, leave by, camera opens, weekly note or a gathering you joined, and how far ahead of its own moment it was placed, as a band rather than a time. The second says which kind you opened. The first exists only so the second can be read: without it, a reminder you ignored and a reminder that was never placed look identical. Neither carries a score, in any form, or a place, or an identifier. Nothing anywhere reports that a reminder was delivered, because iOS never tells an app that.

• That you photographed a sky, and that you kept it. Two events, and they are bare. Neither carries the photograph, a caption, a coordinate, or any identifier, and nothing else rides with them either: what reaches Firebase is the fact that it happened, plus the common fields in the second-to-last bullet.

• That a capture failed, and which category of failure. One of nine fixed words, never free text and never an error message. This is the only bug report in the list that is not a crash: a camera that silently fails to save is not a crash, and without this it is invisible, because most people just give up and say nothing.

• A handful of once-per-install milestones, each fired at most once for as long as the app is installed: the first time the app was actually worth having to you, whether you came back for another sky afterwards, and whether you opened the app again at all on day one, day seven or day thirty. What travels with them is banded or a fixed word, never a number about you:

  • how many days it took, as a band and never a date;
  • which way you first got value out of the app, which today is either a plan you made or a sky you rated;
  • which of a few things you did first in your first session, which is a plan, a photograph, or the honest answer that you did neither. This is one word about something you did, never a screen you saw;
  • which kind of coming back counted, on the second of the three: a plan, directions to a spot, opening a reminder, another photograph, or another kept sky;
  • which part of the app you arrived through;
  • whether notifications are switched on;
  • and one yes or no for whether there were any trusted spots near you. Say that one plainly: it is worked out from where you were. It is not a coordinate and cannot be turned back into one, but it is a single bit about your surroundings, and a section that promises no location signal rides on analytics has to name it.

• Your app version and build, that it is iOS, the major OS version, whether it is an iPhone or an iPad, which release channel the build came from, and a coarse time-of-day band. These ride on all nine.

• What Firebase Analytics adds by itself, which no switch inside Skysta governs. It is Google’s software doing it, not Skysta’s code, and a section that only listed Skysta’s own nine would be hiding it. Whenever collection is on, the Firebase SDK sends its own events alongside ours: a session start, an engagement event carrying how many milliseconds the app was in the foreground, the first open of a new install, and one each for an app update, an OS update and the app being removed. The engagement one is the one to look at twice, because it is a raw duration and it is finer than anything Skysta ever sent. Two things about it are true and both matter: it is app-wide and is not attached to a screen, because Firebase’s automatic screen reporting is switched off in this app and no screen name is sent at all; and the only way to stop it is the counts switch itself. Turn counts off and none of this is sent. The crash switch has no effect on any of it either way.

Skysta used to be able to send 90 kinds of event and can now send nine. What went, on 26 August 2026, was every event that recorded a screen being opened, a control being pressed, how long you stayed on a screen, or the name of a place you looked at. The most important of those: the identifier of a trusted spot you opened, planned, or started directions to. Three events carried it, that identifier named a public place, and a record of them was a record of the places you chose to look at. All three are gone, and so is the rule that allowed the field, so nothing else can start carrying one. This was not a fix for anything unlawful, and nothing described here was ever collected without the switch being on. It is a decision about what the app should be able to do.

Nothing about this undoes what was already collected. The removal is forward-only. Firebase already holds whatever this app sent before 26 August 2026 under the switch, and Skysta cannot reach back into it from here. Write to hello@skystaapp.com and we will tell you what we can find out about it.

And this is what is deliberately never attached:

• Your account identifier. The analytics user ID is explicitly set to null on every configuration pass. Diagnostics are never linked to your Skysta account.
• Your name, email, photographs, any text, or any coordinate. Those field names are on a blocklist, and every event is validated against a fixed contract before it is sent. An event that fails validation is dropped rather than trimmed. The contract also refuses any event that is not one of the nine, so an event cannot be switched back on by a single line of code. The public spot identifier is refused by name.
• Skysta generates an anonymous installation identifier when you opt in. It is never sent anywhere and it is deleted when you opt out. Nothing is sampled: every one of the nine is sent every time.

Firebase Performance Monitoring is not in Skysta at all. The library is not linked into the app, so there is nothing to switch. It was left out because its automatic instrumentation can observe the addresses of the network requests an app makes, and that is not something to ship first and think about after.

What your consent cannot cover: when counts are on, Google generates its own app-instance identifier, and can infer a coarse region from the network address your requests arrive from. Skysta cannot prevent either, and says so in the Settings screen next to the switch. A crash report reaches Google’s servers too and carries a network address with it in the same way, whatever the counts switch says.

Turning crash reports on is immediate for the report already on your phone and takes a launch for the ones after it. When you say yes, whatever is already waiting goes then and there. It is only the app’s standing permission to collect the next one that the underlying library applies at the next launch. Settings says the same thing beside the switch.

8.1 The sky rating, and the ~5.5 km coordinate on it

After a sunrise or a sunset you were shown a score for, Skysta may ask one question: how did it go? Four answers, Amazing, Good, Okay or Miss, one tap, and no text box. It exists so the developer can find out whether the forecast is any good, which is why it lives behind the App counts and sky ratings switch and appears at all only when that switch is on.

Why it did not get a switch of its own. A row reading “tell us how the sky turned out” is a small, warm, harmless-sounding thing that would be agreed to far more often than the same record is agreed to today, sitting as it does beside the paragraph below that names the rounding in kilometres. Splitting it out would have made this record easier to say yes to without reading. The cost is stated rather than hidden: if you want to help the forecast but not be counted, you cannot have that, and the switch says so.

The question is asked in two places. The first is Home’s card, after the sky. The second is the capture flow: right after you keep or share a photograph, the same four answers and a visible skip, and it may appear while the light window is still open, because by then the question is about a sky you just photographed rather than one still coming. It is the same question feeding the same collection, one answer per sky however many surfaces ask, and answering it in one place retires it in the other. Skipping it writes nothing.

The record carries a coordinate, and this is exactly how coarse it is. The place is snapped to a 0.05° grid before it is stored, which is a step of about 5.5 km of latitude. It is not the point the shutter fired at. It is not your address. It is the town Skysta was showing you, rounded to a cell several kilometres across, and the server refuses the write outright if the number is finer than that grid.

What one rating holds, in full: your answer; whether it was a sunrise or a sunset; the minute the sky was; when the app read the forecast, and how far ahead of the sky that was; how stale the forecast already was; the score the app had shown, and the confidence and the certainty word beside it; whether the light’s path beyond the horizon had been read; whether a haze reading was measured; whether the score had been vetoed, and whether that was for precipitation, for overcast, or for cloud sitting in shadow; the rounded cell; the weather readings the score was built from and the terms it was computed with; the app version and build; a single word saying it came from the capture flow, present only on those records; and the moment the server received it. That is the whole document. The server refuses it if it carries so much as one field that is not on that list.

Two of those fields mean something different on a capture-flow record. On a Home rating, the record holds when the app read the forecast and how far ahead of the sky that was, which is the pair that makes it a graded prediction. On a capture rating those two moments are stamped equal on purpose, so the lead reads zero: the record marks itself as an observation made at the sky, not a forecast graded ahead of it, and the server refuses a capture-flow record whose stamps say otherwise. The real age of the forecast reading still travels honestly in its own field. And the rounded cell on a capture rating is the watched place’s, the same town Home’s card would have asked about, not the point the shutter fired at.

What it does not hold, and this is the important part. No account identifier. No installation identifier. No device identifier. Nothing at all that says who answered. Every other queue in Skysta pins its author to the signed-in account; this one deliberately does the opposite, because an account identifier sitting beside a place and a time is a note of where somebody was on a given evening, and one is not worth the other.

Say the honest consequence out loud: because there is no identifier, nobody can find your ratings, so nobody can delete them. Deleting your account does not sweep this collection, and §11.1 says so rather than implying a sweep that cannot happen. If that is not a trade you want to make, leave the switch off. Closing the card without answering stops this record being written at all.

This record is never written unless you tap an answer. The forecast is staged in a file in the app’s own storage, kept out of your device backup for the same reason the journal is, and it holds the same rounded cell. It is deleted when it expires unanswered, when you turn counts off, and when you sign out. It is sent only when you answer.

Nothing is sent when you ignore the card. Being shown it, closing it, and letting it run out used to send three Firebase Analytics events. All three were removed on 26 August 2026. So a question you ignore now leaves no trace at all: nothing is written, and nothing is sent.

8.2 The diagnostics choices are stored on the phone, and signing out ends them

Your answers are written on the device rather than on your account. But they do not outlive your session: signing out switches both off, and off is what the next account signed in on that phone finds. Deleting your account clears them too.

Five things go at the same moment, and they are worth naming because each was a way for one person’s answer to reach the next. Both switches are turned off, in the app’s memory as well as on disk. The anonymous measurement identifier from §8 is deleted. Any events still queued to be sent are thrown away rather than sent under whoever signs in next. Any staged sky rating goes, unsent. And any crash report still waiting on the phone is deleted rather than sent, because it was written during a session that has ended and it is not the next person’s to be asked about.

The crash answer goes back to unanswered rather than to no. That means the next person on the phone gets the question in their own right the first time the app breaks on them, instead of inheriting a refusal nobody made. Unanswered sends nothing, exactly as a no does, so nothing reaches anybody either way.

One consequence for you, and the app says it beside the switches. If you turn either on, sign out, and sign back in, it will be off and you have to turn it on again. That is the trade for the answer belonging to you rather than to the phone.

8.3 What is actually on a crash report

A crash report is written by Google’s Crashlytics library, not by Skysta’s own code, so this is a description of somebody else’s file format. It was read in that library’s own source rather than taken from its marketing page, because two of the things everybody says about crash reports turn out to be wrong.

What one carries.

• Where in the code it broke. Every thread’s stack, the processor registers, the names of the threads and of the work queues they were running. Where the library can, each line of the stack carries a function name, the file it came from, and which piece of software it belongs to.
• Which pieces of software were loaded, with their internal identifiers, their file paths inside the app, and which processor they were built for.
• What kind of phone. The model and the internal machine name, the iOS build and version number, and the platform. Not the processor’s name: the library’s own source puts that field on the branch it compiles for a simulator, not the one it compiles for an iPhone, and Skysta ships iPhone builds.
• Your language and region setting. Named on purpose, because it is the field a reader would not expect. It is the one iOS uses to decide what language to show you in and how to write a date, not a location.
• Memory figures, including how much was free, how much the app was using, and how much processor time it had spent.
• The app’s own identifier, version and build number.
• What went wrong: the kind of failure, its name, and its reason.
• Which way the phone and the app were turned at the time.

Two things everybody says about crash reports that are not true of this one.

• Free disk space is not on it. It is a common claim and it used to be right. Google’s library stopped collecting it, and now writes zero in both of those fields with a note in its own source saying why. Free memory is collected and is on the list above; free disk is not.
• It is not identifier-free. Every report carries an installation identifier the crash library generates, and Firebase’s own installation identifier. Both halves of that are worth saying. It says nothing whatever about your Skysta account, your email address or your name, and nothing links it back to you. And it does tie one phone’s crashes to each other, which is the whole reason it exists: without it, ten crashes from one broken install look like ten broken installs.

What is never on one, and why we can promise it. No name, no email address, no photograph, no caption, no coordinate, no place name, nothing you typed. Skysta never attaches a user id to a crash report, never sets a custom field on one, and never writes a line into one. There is no code in the app that could: every call the app makes to the crash library lives in a single file and that file only ever switches collection on and off, sends what is waiting, or deletes it.

The one thing on a report that is free text, and it is not ours. The “reason” on a failure is written by whatever broke, which may be Apple’s code or another library rather than Skysta’s. §8 promises that the nine counts are never free text. That promise is about the counts and it is not extended to a crash report’s reason, because it could not honestly be.

A crash report is fatter when counts are on, and this is the one place the two answers touch. The crash library listens for Firebase Analytics events and writes each one into the report as a breadcrumb, so with counts on, the last few counts before the break travel inside the crash report. With counts off there are no counts, so there are no breadcrumbs, and the report carries no behaviour at all. Crash reports carry nothing about what you did is only true while counts are off, so it is written with the qualifier rather than without it.

And a crash sends one count of its own, in the other direction. When the app breaks, the crash library asks Firebase Analytics to record a single event saying so, which is what produces the “how many people did not crash today” figure. With counts off that event is dropped. The crash report still arrives; the percentage does not move.

9. Who else receives your data

Skysta contains no advertising libraries and no third-party tracking libraries. It does not use Apple’s tracking permission because it does not track you.

Skysta does not sell your personal information and does not share it for cross-context behavioural advertising. It never has, and there is nothing in the app that could.

9.1 The three things you can send the developer

All three are permanent until removed by hand, and all three carry your account identifier. Feedback and spot corrections go into collections no copy of Skysta can read back at all. A suggestion goes into one where you can read your own and nobody else’s.

A spot suggestion carries the name you gave the place, its town if you entered one, its two-letter state or country code, whether it is better at sunrise, at sunset, or at both, what you wrote about why the sky is good there, the exact unrounded coordinate you marked on the map, your account identifier, and the moment the server received it. It also carries two housekeeping values that are not about you: a review status, which starts at submitted and is what Settings → My suggestions shows you, and a note that the submission came from the iOS app. That coordinate is a place you chose to nominate; it is not a reading of where you were standing. Nothing else about you is attached. No parking note, no photograph, no app version.

You can see the status of your own suggestions in Settings → My suggestions, and nobody else can see them. You cannot withdraw one from inside the app. No copy of Skysta may edit or delete a submission, and a submission is not removed when you delete your account. Write to hello@skystaapp.com to have yours removed.

And a developer erasure does not remove one either. It takes your name off it. What comes off is the account identifier. What stays is everything else listed above: the place name you gave, the town, the state or country code, whether it is better at sunrise or sunset, what you wrote, and the exact unrounded coordinate you marked. The reason is that a spot published in Skysta’s catalogue came from somebody’s suggestion, and deleting the suggestion would leave the catalogue with no record of where the place came from. That is a real reason, and it still leaves a record of a place you nominated, in a queue, with your words on it. Asking by hand takes the whole thing, which the lever will not.

A spot correction sent from Something wrong here? at the foot of a trusted spot’s page carries the identifier of that spot, the spot’s name as you saw it, which of the place is wrong, getting in is wrong, the season or hours are wrong, there is a safety problem, it is closed or gone or something else you picked, what you wrote, up to 1000 characters, your account identifier, the moment the server received it, and a status that starts at open. Nothing else: no coordinate of yours, no photograph, no app version.

Be aware of two things about it. No copy of Skysta can read a correction back, including yours. A list of the places the catalogue is currently wrong about is not something to make readable from a phone, so there is no screen where you can see what you sent. And deleting your account does not remove it. Write to hello@skystaapp.com to have yours removed.

Feedback sent from Settings → Share feedback carries the note you wrote (between 5 and 1000 characters), which of idea, problem or other you chose, your account identifier, the moment the server received it, and the app version. Please do not put anything in that box you would not want kept: it is read by a person, it cannot be read back or deleted by any copy of the app, and it is not removed when you delete your account. Write to hello@skystaapp.com to have a note removed.

The same warning applies to all three: a person reads them, and what you type is what is kept. Do not put anything in any of those boxes that you would not want stored under your account identifier until somebody deletes it by hand.

10. What stays on your device and nowhere else

• The coordinate of every capture, meaning where each photograph in your journal was taken. The full-precision record is on the device and nowhere else, and that sentence needs its exception said beside it: sharing a photograph publishes a ~5.5 km cell computed from that record, and the exact pin too when the map switch is on (§4). A sky that stays in your journal sends nothing derived from its coordinate anywhere.
• Your reminder schedule. Sunrise and sunset reminders are scheduled locally by iOS. Skysta sends no push notifications and operates no notification server. A reminder’s own words name clock times and nothing else: no place, no spot, no score.
• What your Lock Screen shows, and it is more than you might expect. While a light window is open, and for up to about an hour and a half before one you have planned, Skysta puts a live card on your Lock Screen and in the Dynamic Island. The card leaves on its own shortly after the window ends. It names the place Skysta is watching, or the spot you planned if you planned one, and it shows the Sky Score and its short verdict beside the times. None of it leaves the phone: no Skysta server sends it, and your device draws and updates the card itself. But it sits on the screen of a locked phone, so anybody holding it reads all of that without unlocking anything. The open-window card appears whether or not you planned a sky, and it appears for sunrises as well as sunsets. On iOS 26 it starts on its own, with Skysta closed. The app hands iOS the next four windows while it is open, and iOS starts each card at the minute its window opens, playing the system alert sound as it lands. That is still your phone doing it: no Skysta server is involved, nothing is sent anywhere, and the times are solar geometry worked out on the device. On earlier versions of iOS the card can only start while the app is open. Skysta has its own switch for it: Settings → Lock Screen card, which starts on, and a card that would start inside your quiet hours or on a day you did not pick is never scheduled. It is not tied to the reminder switches, so turning the card off does not turn a reminder off and turning a reminder off does not take the card away. The card also keeps to the days you picked and your quiet hours, if you set either. Turning Live Activities off for Skysta in your iPhone’s own Settings → Skysta → Live Activities stops it as well, and that one wins whatever Skysta’s switch says.
• Your units, your plan, and your interface preferences.
• Your two diagnostics answers: whether app counts are on, and whether crash reports are on, off, or still unanswered. Both are cleared when you sign out and when you delete your account (§8.2).
• Events waiting to be sent, and only when app counts are on. An event raised in the moment before the connection is ready is written to a small file on the phone, so a launch that ends early does not lose it, and it goes as soon as the connection is real. Nothing is written there at all while counts are off. The file holds at most 500 of them, anything still waiting after seven days is thrown away instead of sent, and every entry is checked against the same rules on the way out as on the way in: no name, no address, no coordinate, no account identifier. Turning counts off deletes it, and so do signing out and deleting your account.
• The spot suggestion, the spot correction or the feedback note you were part-way through writing. None of the three is saved to disk at all: an unsent draft is held in memory and is gone when you close the sheet.
• The photograph you are part-way through composing, until the journal takes its own copy. It is written to disk so a phone call cannot lose it, and it is excluded from your device backup. See §2.3.
• Three small lists of unfinished work, none of which leaves the phone: the journal backups you have deleted and the server has not yet confirmed gone (§3.2), the image files of skies you deleted whose files would not delete (§7), and the saved spots whose add or remove has not yet reached the server (§11.2). The first two name your own photographs; the third names public spots and nothing else. All three are cleared as the server catches up, item by item. Only one of the three is wiped on sign-out. The list of images from deleted skies goes. The list of journal backups you deleted stays, on purpose, kept under your account identifier outside everything sign-out erases, so that a photograph you deleted stays deleted rather than coming back the next time you sign in. And the saved-spot list stays for the matching reason, so that a spot you unsaved stays unsaved. Both go when the server confirms each item, and when you delete your account.
• A sky rating you have not answered yet, which holds the ~5.5 km cell and the forecast behind it. This one is on the list with an asterisk: if you tap an answer it is sent (§8.1), and if you do not it is deleted where it sits and never sent anywhere.
• A short list of firsts, kept whether or not app counts are on. The app writes down on the phone that it has already counted a milestone: when it was installed, that a first sky was photographed, that a first plan was saved, that a first rating went, and which of a handful of return points have been passed. It is a list of ticks and dates, not a diary: no photograph, no place, no text, no score. It exists so that a milestone fires once and not twice, and so that switching counts on in month two does not replay month one as if it had just happened. It is written even when counts are off, and in that case it is never sent anywhere at all. It belongs to the phone rather than to the account: signing out leaves it, and deleting your account clears it. That has a cost worth naming. A second person signing in on the same phone inherits ticks somebody else earned, so their own first sky and first plan would never be counted. It is a list of ticks and dates with nothing in it about anybody, but it is one person’s ticks sitting on a phone the next person uses.

Skysta also deliberately disables the on-device cache its database library would otherwise use. Because the feed is readable by every signed-in account, that cache would have written other people’s shared locations and names into an unencrypted store on your phone and kept them after sign-out. Feed data is held in memory only.

11. Deleting your account

Settings → Delete account. Here is precisely what happens, in order.

1. You prove it is you, before anything is touched. Firebase refuses to delete an account on a session that has been open for a while, so Skysta checks first: unless you signed in in the last two minutes, an email account is asked for its password and an Apple account is sent through the Apple sheet again. Nothing below this line runs until that succeeds, and backing out at this point leaves everything exactly as it was.
2. Every sky you have shared is withdrawn: the record and the image file, in batches, until none remain.
3. If any of them cannot be removed, the deletion stops there and your account is left intact, with a message telling you how many failed. This is deliberate: an account that is gone can never remove its own posts, because the rule that permits the deletion requires the author to be signed in.
4. Every image file left over from a sky you deleted earlier is retried. When you delete one sky, its record goes first and its file second; if the file will not go, its address is written down on your phone (§7). This is the last moment anybody can act on that list, because the storage rules accept only your own account for those files. If any of them still will not delete, the deletion stops here and says how many photographs are involved.
5. Your journal’s backup is deleted: every photograph and its description record, from Skysta’s storage. The whole backup, however many photographs it holds: the app walks the collection page by page until there is nothing left, and there is no ceiling on how many it will take. This runs before the account record goes, for the same reason as step 2: the rules pin these deletions to the owner’s own account, so nothing could reach them afterwards. If any of them will not delete, the deletion stops here too, and says how many.
6. Your saved spots are deleted. The list of places you saved lives under your account and is exactly as private as your block list. If any of them will not delete, the deletion stops here and says so.
7. Your profile photo is deleted, from the device and from storage.
8. Your block list is deleted.
9. Your online-status record is deleted, connection by connection. There is no path back to it afterwards: the rules on it accept only the account it describes, and that account is about to be gone.
10. Your Apple sign-in token is revoked, if you signed in with Apple and the app is still holding the authorisation code Apple gave it. That code is kept in memory only. So the app has it if you signed in, or proved who you were through the Apple sheet, in this run of the app. It does not if you signed in with Apple, closed Skysta, opened it again and deleted inside the two minutes step 1 counts as fresh. It is one attempt, and unlike the steps above it a failure here does not stop the deletion: being unable to reach Apple must not trap you inside an account you asked to leave. If you want to be certain, you can also remove Skysta yourself under Settings → your name → Sign in with Apple on your iPhone.
11. Your account record is deleted, and if the request fails it is tried again; if it still will not go, the deletion stops here with your account intact rather than stranding the document. Then your Firebase account is deleted.
12. Your journal, reminders, cached images, saved-spot mirror, staged sky ratings, unfinished photograph and preferences are wiped from the device, and both diagnostics answers and all diagnostics state are cleared.

Three of those steps do not stop the deletion, and it is fairer to say so than to imply a guarantee. Steps 7 and 8, the profile photo and the block list, are attempted and then the sweep carries on either way. Each is a single small private record rather than a pile of photographs, and a dropped connection while clearing one must never trap somebody inside an account they asked to leave. Step 10, the Apple token, is the third, for the same reason. Every other step stops the sweep: steps 1 to 6, the online-status record at step 9, and the account record at step 11, where a failure leaves your account intact rather than stranding the document. Step 12 is in neither set: it happens on your phone after the account is already gone, so there is no sweep left for it to stop. If a profile photo or a block list is ever left behind, write to hello@skystaapp.com.

If Firebase still considers the session stale by the time the sweep has finished, the app asks you to prove it is you once more and then completes the last step. It says so rather than leaving you guessing.

Every photograph in steps 2, 4, 5 and 7 takes another seven days to finish going. Google Cloud Storage keeps a deleted file in a recoverable state for a week before destroying it, as §6 describes. When the app tells you your account is gone, the records are gone and the pictures are unreachable by anybody holding a link or signed in to Skysta, and the files themselves are destroyed seven days later. Nothing in the app changes that.

11.1 What account deletion does not remove

Being exact about this is more useful than being reassuring.

• A post the app cannot read back. If a record was written in a shape the current app cannot decode, the app cannot see it, so it cannot delete it, and it does not count it as a failure, and the deletion reports success and proceeds. No copy of Skysta writes a record in that old shape, so a post made through this app is one this app can read back. The failure mode is written down because it is still in the code, not because anything of yours is known to be stranded. Once your account is gone, the rule that permits deleting a post requires an author who can never sign in again. Those records, and their images, stay readable by signed-in accounts and can only be removed with administrator credentials. Write to hello@skystaapp.com and they will be removed by hand.
• Reports you filed, and reports filed about you. Both contain both accounts’ identifiers, and the button reaches neither. They part company after that. One filed about you is permanent by design: it is somebody else’s complaint. One you filed is not permanent, it is simply out of the button’s reach, and it goes when you ask or when the developer erases the account by hand.
• The record that the developer acted on your account, if one was ever acted on. This is one of the two items here that are meant to outlive you, the other being the report in the bullet above that somebody else filed about you, and §6 describes it in full: a line saying what was done and when, keeping your account identifier. Nothing is written unless the developer acted. A line carries no name and no email address. The Delete account button has never been able to reach this log and still cannot.
• Spot suggestions, spot corrections and feedback you sent (see §9.1). All three carry your account identifier, and the deletion reaches none of them. The correction is worth naming on its own, because it is the one that carries up to a thousand characters you typed alongside your account identifier and is not readable back by any copy of the app. And a developer erasure does not treat the three alike: it deletes the correction and the feedback note outright, and it takes your account identifier off a spot suggestion while keeping the suggestion, with the coordinate you marked and what you wrote still on it. §6 says why, and asking by hand can still take the whole record.
• The verification-email counter described in §1.1. It sits under your account identifier, no client can touch it, and the deletion does not reach it. It holds no address, no name and no link: only how many messages went and when the last one did.
• Your sky ratings, if you gave any (§8.1). Nothing is swept here, and this is not a defect to be fixed later: the records carry no identifier, so there is nothing on them that could be searched for. That is the price of their being unlinkable, and it is stated rather than dressed up as a sweep.
• Other people’s block lists, if they had blocked you. Those are their private records.
• A review of a trusted spot, if you ever left one. The collection is a leftover: nothing in the app writes or reads one now, no copy of the app can delete one, and no rule opens the collection to any client at all, so a review carrying your account identifier and what you wrote is removed by hand rather than by the button.
• The seven days a deleted photograph stays recoverable, described in §6. Your pictures are gone from the app and from every link the moment the sweep finishes. The files themselves are destroyed a week later by the storage service. This one is not on the list because somebody has to remove it: it is on the list because “deleted” and “destroyed” are seven days apart and you should hear that from us.
• The hour a deleted record stays readable, also described in §6. The same point, one hour instead of seven days, and it covers the account record with your email address in it.
• The developer’s own dated copies (§6). A copy taken before you asked to be deleted still holds what was there at the time. That means your account record with its email address, any sky you had shared with its coordinate and its place name, and any spot suggestion with your account identifier on it. No copy in that folder holds a photograph. No tool takes one record out of one file, so anything you want out comes out by hand, one file at a time, on request.

Every item on this list can be removed by hand except four, and it is worth saying which and why. Write to hello@skystaapp.com and say what you want gone.

• A sky rating cannot be removed, because nothing on it says it is yours. Nobody can search for it, the developer included.
• A record that the developer acted on your account is not removed, because a moderation decision that can be erased by the person it was about is not a record of anything. The identifier stays. If you think a decision about your account was wrong, that is a different question and a better one, and the answer is in the Terms of Use at §10.
• A report somebody else filed about you is not removed, because it is their complaint rather than your record. Nothing reaches it, not even by hand.
• The seven-day storage window and the one-hour record window cannot be shortened by hand either, and nobody needs to remove them, because they end on their own. They are listed for completeness and because this section promises to be exact rather than reassuring.

11.2 Signing out

Signing out ends the session and wipes the phone clean of the account that was on it: the journal, cached photographs, your profile picture, your plan, the local copy of your saved spots, any sky rating still staged and unanswered, an unfinished photograph in the composer, the town Skysta was watching, your personal preferences, your two diagnostics answers, the anonymous measurement identifier behind them, and any diagnostics events still queued to be sent. It does nothing to skies you have already shared. Those stay published until you delete them individually or delete your account. Your saved spots stay on the account too, and come back when you sign in.

Three small things are deliberately left behind. The list of journal backups you deleted that the server has not yet confirmed gone stays on the phone, under your account identifier, so that a photograph you deleted stays deleted rather than coming back when you sign in again. The list of saved spots whose add or remove had not yet reached the server stays for the matching reason, so that a spot you unsaved stays unsaved. And the short list of firsts stays, so that switching counts on later does not replay your first month (§10). The first two clear themselves as the server confirms each item, and all three go when you delete your account.

One thing is written on the way out rather than cleared, and it is not on the phone. Signing out replaces the live part of your online-status record with a single timestamp of when you were last connected (§1). It sits in a separate Google database under your account identifier until you delete your account. It is one number. It holds no place, no name and nothing about what you did, and only your own account may read it.

It does not cost you your journal. Signing out leaves the backup in place, and signing in again, on that phone or another one, brings those photographs back, without their coordinates (§2.2). The one exception is a photograph that had not finished uploading when you signed out: that one is only on the phone, so wiping the phone loses it. The app counts them and warns you before it does.

11.3 By email

Write to hello@skystaapp.com for any request to access, correct, export, or delete your data, including the items above that the app cannot reach itself. This includes anything you sent from the website.

Requests are answered within 45 days. If a request turns out to be complicated, we may take up to another 45 days, and if that ever happens you will be told inside the first 45 days, and told why. If a request is refused you will be told why, inside the same period.

Before we act on a request to delete or hand over data, we have to be reasonably sure the request is really from you. Usually that means answering from the email address on the account. We will not ask you for a government identity document, and we will never ask for a password by email.

12. Children

Skysta is not directed to children under 13, and we do not knowingly collect personal information from anyone under 13. The Terms of Use require every account holder to be 13 or over, so those two lines now sit at the same age.

Skysta does not ask your age and does not verify it. There is no age question in the app and nothing that estimates how old you are. This is worth saying plainly rather than leaving you to infer it from silence: the 13-and-over rule in the Terms of Use is a condition you accept, not something the app tests.

If you are a parent or guardian and you believe a child under 13 has created an account, or that we hold personal information about a child under 13, write to hello@skystaapp.com. We will delete the account and everything it has posted, and we will tell you when it is done. You do not need to prove anything complicated to get that: tell us the email address on the account, or point us at a post, and we will act.

If we learn that an account belongs to somebody under 13, we remove it and everything it has posted, because that is the Terms of Use rule and because we do not knowingly hold a younger child’s information.

What a young person should understand about Skysta, in case they are here anyway:

• A shared sky is visible to every account on the service, and it stays on your profile permanently. There is no friends-only setting.
• “Show on the map” starts off, so leave it off. Turned on it pins the photograph exactly where you were standing. It is one tap on the share screen either way, and it goes back to off on the next photograph. And know this even with it off: a sky you share carries a rough cell, about 5.5 km across, of where it was taken, so people near you can find it in their Local feed. It is never a pin and never a town name, but it is not nothing. If you already shared one with the pin on, you can take the place off it without losing the photograph (§7), but anybody who already looked has already seen it.
• Take the spot tag off, and look for it every time. It appears on its own whenever you are near a trusted spot, so check the compose screen rather than assuming there is nothing to remove.
• Your own phone shows things too, before anybody unlocks it. When a light window is open, or a sky you planned is coming up, Skysta puts a card on your Lock Screen naming the place or the spot and showing the score (§10), and on iOS 26 it does so even when the app is closed. Anybody who picks your phone up can read it. If you would rather they could not, turn the Lock Screen card off in Skysta’s own Settings, or turn Live Activities off for Skysta in your iPhone’s Settings.
• Nobody can save your photograph out of Skysta, but anybody can screenshot it or forward the link. Once it is out, it is out.

13. Your choices and your rights

These rights are offered to everybody who uses Skysta, whether or not the law where you live requires it. That sentence is doing real work, so here is the honest version behind it. Laws like the California Consumer Privacy Act apply to a “business” that meets certain thresholds of revenue or of how many people’s data it handles. Skysta is one person, before launch, and almost certainly meets none of them. Rather than claim a status it does not have, or make you work out whether a statute covers you, Skysta offers the same set of rights to everyone and answers every request the same way.

Here is what you can ask for.

• Know what we hold. Ask what personal information Skysta has about you, the categories it falls into, where it came from, why it is held, and who has received it. §13.1 is the standing answer for everybody, and you can ask for the specific pieces held about you.
• Get a copy. Ask for a copy of your personal information in a portable, readable form.
• Correct it. If something is wrong, tell us and we will fix it. Your name and your profile picture you can change yourself in Settings.
• Delete it. Settings → Delete account does this for everything §11 lists. For anything else, write in. §11.1 is the exact list of what the button cannot reach, and of the four things that cannot be removed even by hand, with the reason for each.
• Limit what is collected. Both diagnostics answers are off until you turn them on and can be turned off at any time (§8). The map switch starts off, and turning it on is a tap you make on one photograph or not at all (§4.1). The spot tag comes off with one tap (§4.1). Location permission itself is yours to refuse or revoke in iOS Settings.
• No retaliation. You will never be treated worse, or given a worse version of Skysta, for asking for any of this.

How to ask. Write to hello@skystaapp.com and say what you want. §11.3 has the timing and how we check it is really you.

Skysta does not sell your personal information, and does not share it for cross-context behavioural advertising. It never has. There is no “Do Not Sell or Share My Personal Information” link because there is nothing to opt out of.

Nothing about you is decided automatically. Skysta does not profile you and makes no automated decision about you. The Sky Score is a forecast about the sky, not an assessment of you.

Do you have to give Skysta any of this? An account is required by Skysta, so an email address or an Apple credential is required, and without one the app will not open. A rough position is needed for the app to do the one thing it does; refuse the location permission and the forecast screens cannot work. Everything after that is optional: a display name, a profile photo, a photograph, a location on a post, a suggestion, a note, diagnostics. Refusing any of them costs you that feature and nothing else.

13.1 The categories of information Skysta collects

This is the same information as the rest of this policy, sorted into the categories that privacy statutes use, so that it can be compared with other services. Every row points at the section that describes it properly.

On precise geolocation, which some laws treat as sensitive. Skysta uses it for one thing: to run the app, meaning the forecast for where you are and the pin on a sky you share. It is not used to build a profile of you, it is not used for advertising, it is never sold, and it is never shared for cross-context behavioural advertising. Publishing the exact pin starts off, it sits on the share screen with a switch beside it, and it is a decision you make photograph by photograph.

Where it comes from. All of it comes from you and from the device you are holding, except for the town name under a pin, which comes from Apple’s reverse geocoder, and your name and email when you use Sign in with Apple, which come from Apple.

Why it is collected. To run your account, to show you the forecast, to run the feed and the trusted-spot pages, to answer support and moderation, to keep the service secure and free of abuse, and, only with your say-so, to count how the app is used and to learn whether the forecast was right.

13.2 Where your data is processed

Skysta is operated from Utah, in the United States. Its service providers, Google Firebase, Apple, Resend and Open-Meteo, store and process data on their own infrastructure, which may be located outside the state or the country you live in.

One thing worth saying plainly about every one of them. A request made over the internet arrives carrying the network address it came from. That is how the answer finds its way back, and no app can send a request without it. So Open-Meteo, Apple, Google and Resend each see your device’s network address on the requests Skysta makes to them, and a network address can suggest roughly where in the world you are. None of them receives a Skysta identifier alongside it, Skysta does not log these addresses itself, and it does not use them for anything. This policy is precise about coordinates everywhere else, so it should be precise about this too.

13.3 The one location thing that starts on by default

Two location disclosures sit on the share screen, each with its own control, and neither publishes anything until you press Share. Only one of them starts on.

The map switch, from §4.1, starts off, for everyone, on every photograph. It is what publishes the exact capture coordinate and the name of the town, and it publishes neither until you turn it on for that photograph. One tap turns it on, one tap turns it back off, and the next photograph starts off again. §4.1 sets both states out side by side.

The trusted spot tag, also from §4.1, starts on. It appears on its own when the photograph was taken within 500 metres of a trusted spot, and you take it off by tapping the ✕ beside it.

The tag is the one that needs the longer answer, because unlike the switch it is not a control you went looking for, and it is the one that arrives already on. Here is the whole of the reasoning, so you can weigh it for yourself rather than take it on trust.

• Why it exists. A trusted spot’s page is a record of what the light actually does at that place, built out of the skies people photographed there. It is the reason the spot catalogue is worth having. When the tag had to be added on purpose, only photographs from people who had planned that spot in advance ever reached its page, and almost every page stayed empty.
• What it discloses about you. The public name of a public overlook, and by implication that you were within 500 metres of it at the minute in the post. It is not a coordinate. It is not your home. It does not appear at all unless you took the photograph near a curated public viewpoint.
• The safeguards. The tag is shown to you on the compose screen, with a ✕ on it, before anything is published, and nothing is published until you press Share. It is a separate control from the map switch, which governs the coordinate and the town name and which starts off. §4.3 explains what happens when both are on.
• The balance. A public place name, shown to you and removable before you post, against a catalogue that only works if skies reach it. That is the judgement being made. If you disagree with it, the next paragraph is yours.

How to take it off, in order of how little each one costs you.

1. Before you share: tap the ✕ on the tag. Nothing is ever published.
2. On a sky you already shared: open it, tap the ⋯ menu, choose Remove the place (§7). The spot tag goes, along with the pin and the town name, and the photograph stays. It cannot be undone.
3. Or write to hello@skystaapp.com and any tagged sky of yours will be taken down by hand.

One thing Skysta cannot do for you. There is no setting that removes the tag from every future photograph. It has to be taken off each time, on the compose screen. Saying otherwise would make this section advertising.

14. Security

Everything Skysta sends travels over TLS. Access to the feed requires a signed-in account, with the important exception of the image links described in §5. The database’s on-disk cache is switched off so that other people’s data is never written to your phone. Your journal lives in the app’s private container and is excluded from your device backup, and its copy on the server (§3.2) sits behind rules that grant read, write and delete to one signed-in account: the one that owns the photographs. Unlike a shared sky, a journal photograph is never turned into a web address that works without an account. The app downloads it with your credentials.

Security rules are enforced by the server, not merely asserted by the app. The shape of every published record is validated field by field: only a fixed list of field names is accepted, every one of them is type-checked, the author has to be the account making the request, the image has to sit at that account’s own path under that post’s own name, and the publication time is the server’s clock rather than your phone’s. Nobody, using any client, can edit a post once it exists, with the single exception described in §7: the author may take the place off their own sky. That exception is written to subtract and nothing else. The rule permits an update only when the eight place fields are the only ones touched and every one of them is gone afterwards: the pin’s two coordinate fields, the town name, the older region field, the spot’s name and identifier, and the two fields of the locality cell. So there is no value any client, modified or not, could put into a coordinate field through it. A sky can lose its place; no sky can be moved or given one.

The sky rating in §8.1 is checked the same way from the other side: the rule refuses the write outright if the coordinate on it is finer than the 0.05° grid, so a modified client cannot file a doorstep coordinate in a field the developer would read as a region.

Three limits are worth stating rather than glossing.

• The pin’s precision is not limited server-side. A published pin is exact by design, as §4.2 describes, so the rule checks only that a coordinate is a number in range.
• The rule does not police the combinations. It stops a location field being written with the wrong type or an absurd value; it does not require that a coordinate arrive alongside the other fields the map switch writes. What guarantees the switch governs the whole disclosure is the app’s own code, which writes those fields together or not at all.
• Taking the place off is one request and is not retried. If it fails, the post is unchanged and the app says so. Nothing queues it for later.

No service is perfectly secure. The plainest thing that can be said is this: a location you publish is readable by every signed-in Skysta account, and the photograph attached to it can be screenshotted by any of them. Do not publish anything you would not be comfortable being public and permanent.

15. Tracking and Apple’s privacy manifest

Skysta declares no tracking and lists no tracking domains. It does not use Apple’s App Tracking Transparency framework because it has nothing to ask permission for.

The app’s privacy manifest declares that it collects: email address, user identifier, name, photographs, other user content, coarse location, and precise location, all for app functionality and none of it for tracking. It also declares product interaction, for analytics, and crash data, for app functionality. Those last two are not linked to your identity.

Skysta’s own manifest is not the only one inside the app. Every library the app is built with ships one of its own. Thirty-two are checked out alongside Skysta’s source, and twenty-nine of those belong to libraries the app actually links; the other three belong to Firebase products Skysta does not build with at all. Of the twenty-nine, six declare a data type Skysta’s own manifest does not: other diagnostic data, collected for analytics, not linked to you and not used for tracking. Two of the six are Firebase Authentication and Firestore, which run for every signed-in session whatever the diagnostics switches say, and §8 describes the header they send. Both figures are read off the checked-out source rather than the built app, so one library that ships its manifest inside a prebuilt binary is in neither.

Precise location is in the manifest because the published map pin is exact (§4.2). The declaration and the behaviour must continue to move together: if either changes, the other changes in the same release.

The journal backup does not add a manifest type. Photographs were already declared as collected and linked to your identity, because shared skies always were. The backup adds private photographs under that same declaration, which is why this policy spells it out in §3.2 rather than leaving the manifest to carry the news.

Nor do the sky rating, the saved list or the spot correction, and it is worth saying which existing declaration each one lands under rather than letting silence imply nothing new happens.

• The sky rating (§8.1) falls under coarse location. Its coordinate is rounded to about 5.5 km, and it carries no identifier of any kind, which makes it the one coarse value in the app that is genuinely unlinked. The declaration stays linked because the other coarse values are.
• The locality cell on a shared sky (§4) lands under that same coarse-location declaration, on its linked side: a post carries your account identifier, so its cell is coarse location tied to you.
• Saved spots are identifiers of public places filed under your account, so they land under user identifier. No coordinate of yours goes with them.
• A spot correction (§9.1) is free text stored with your account identifier, so it lands under other user content, exactly where a spot suggestion and a feedback note already were.

15.1 The website

skystaapp.com, where this policy is published, sets no cookies, runs no analytics, and loads no third-party scripts. Its fonts, pictures and code are served from the site itself, and a Content-Security-Policy header served with every page permits scripts only from the site’s own address, permits requests only to the site itself and to the two map tile hosts named below, forbids form submissions to anyone else, and forbids the site being framed. Skysta keeps no record of your visit and there is no consent banner because there is nothing to consent to.

The Sky Score on the home page. Since 3 September 2026 the home page can show the Sky Score for a place you name. The number is worked out in your own browser, by the same model the app runs on your phone, from a forecast the page fetches. To fetch it, the page sends the place to a small server of our own (a Cloud Function at the site’s own address, /api/), which asks Apple WeatherKit for the hourly forecast at that coordinate, asks Open-Meteo for the cloud layers at that coordinate and at three points along the sun’s path beyond the horizon and for the air-quality reading, all rounded to about 1.1 km, and returns the answers. When you type a city name, the name goes to Open-Meteo’s geocoder to become a coordinate. When you press Show my sky or Use where I am, your browser asks you for permission, and the position is rounded to about 5 km before it leaves your browser; that rounded position is also sent to OpenStreetMap’s Nominatim service so the page can name the town. Our server keeps forecasts in memory for a few minutes so nearby readers share one request, and keeps nothing else: no log of who asked about where, and nothing tied to any account. Apple, Open-Meteo and OpenStreetMap receive those requests from our server, not from your browser.

The map of spots. The home page draws the trusted spots on a map whose background comes from OpenFreeMap (tiles.openfreemap.org), a free project run on its own servers behind Cloudflare. As you pan and zoom, your browser asks it for the pieces of map on your screen and the fonts for the labels. Each request carries your network address, the map area you are looking at, and the name of our site, which is how any map on any website works. OpenFreeMap sets no cookies and asks for no key or account; we send it nothing about you, and it cannot tell who you are. The map’s own code is served from our site, not from OpenFreeMap. If your browser cannot draw this kind of map, the older map from OpenStreetMap (tile.openstreetmap.org) is used the same way, under the OpenStreetMap Foundation privacy policy. The spot list itself is a file built into the site, so looking at it reads nothing from Skysta’s database.

Suggesting a spot. Since 3 September 2026 the page at skystaapp.com/spots/suggest lets you suggest a viewing spot without an account. Pressing Send sends one request to our own server (the same Cloud Function, at /api/suggest) carrying exactly these fields: the name you gave the place, its town and two-letter state or country if you filled them in, why you think the sky is good there, whether it is better at sunrise or sunset, the exact point you marked on the map, your email address if you chose to leave one, and the moment the page was opened, which the server uses once to tell a person from a script and does not keep. The server writes one record into the spotSubmissions collection of Skysta’s Firebase database, the same queue the app’s suggestions go into, with submittedByUserId empty and source set to website. To slow abuse it keeps, in memory only, a count of requests per network address for an hour and a count of accepted suggestions for the day, and nothing on disk; the address itself is never written to the record or to a log. Google’s platform request logs for Cloud Run and Hosting still record network addresses, as they do for every request to the site. The email address is held until a person has replied about that one place and is then deleted by hand, as §6 says. The town search on that page sends the text you type to Open-Meteo’s geocoder, as the Sky Score’s search does, and the map is the same OpenFreeMap map described above.

The site is served by Google’s Firebase Hosting, which, like any web host, receives the requests your browser makes and processes the associated network addresses to deliver the pages; Skysta does not use that information to identify anyone. Nothing you do on the website is linked to a Skysta account.

The share page. skystaapp.com/s/… is one static page that every shared-sky link resolves to. It is the same page for every link and it holds no information about any post: no photograph, no place, no name. It exists to tell somebody without the app what the link was for.

17. Contact

hello@skystaapp.com is the address for everything: questions, corrections, access requests, erasure requests, and complaints. It is read every day. Anything under §11.3 is answered within 45 days.

Skysta is made and operated by Cy Liassides, in Utah, in the United States. There is no company behind it and no staff.

Skysta is offered in the United States. It is not directed to people in the European Economic Area, the United Kingdom, or anywhere else, and it is not available on any App Store outside the United States. If that ever changes, this policy changes with it and the effective date at the top moves.