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.

Eleven 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), any sky sent to one person (§5.3), the appreciations you have sent and received, which are held under your account in the sense that each one is filed with your account identifier and readable by your account (§5.4), the record of your phone’s notification token while you can receive their notices (§5.4), the small record our server keeps for the limits on appreciations (§5.4), a sky we took down (§6), 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 10).

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. Resend keeps its own record of the message, under its own policy. Skysta operates no mail server of its own. The function’s own log lines keep your account identifier and 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, how many have ever gone to that account, and when the last one went. The lifetime total is never reset; the daily one rolls over at midnight UTC. 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.
• Password reset emails are Firebase’s own. If you ask to reset your password, Firebase Authentication emails you the link itself. Our function and Resend are not involved, and nothing is counted.
• 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 sees this screen too. If you let Apple share your name, it is filled in for you, and you can keep it, change it, or type another before anything is shared.

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 by tapping your name at the top of Settings. 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 compass on a spot’s page reads a direction, not a place, and it goes nowhere. The dial on a trusted spot’s page turns with your phone while the page is open. To draw it, the app reads which way the phone is pointing, on the phone only, and only while the dial is on screen and Skysta is in front. That direction is never stored and never sent, and reading it asks for no permission. §10 lists it with the other things that stay with you.

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. A Satellite switch on each map, except a city’s or a place’s page outside the lower 48 states, where it has no pictures to show, swaps the map’s background for aerial photographs from the U.S. Geological Survey’s The National Map (basemap.nationalmap.gov), a public service of the United States government. Your browser asks it for nothing until you press Satellite on that map, except on the page for a city or a place in the lower 48 states, whose map opens on Satellite; from then on it asks for the photograph pieces on your screen, and each request carries your IP address, the map area you are looking at, and the name of our site. It sets no cookies and asks for no key or account, and we send it nothing about you. The choice lasts for that map and is stored nowhere, so every other page starts on the map. After you press Near me on the home page or the spots pages, or How far is it? on a spot’s page, the map shows your area, so the map pieces it asks for show that area too, and after Near me so do the small pictures of the nearest spots, which your browser then asks our own site for (§15.1).

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, sunset or both, 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. It also carries the moment the page was opened, which the server checks once and does not keep. No account and no cookie go with it, and the server does not keep your network address. §15.1 has the whole path. Pin where I’m standing on that page puts the pin exactly where you are, and the map zooms to it; move it before you send if you’d rather not share that.

The Lock Screen card, with the app closed. When Settings → Reminders → Lock Screen → Show the card is on and you have a watched place, the app writes one record to our own server, under your account. It holds your watched place rounded to about 1 km, its name, your phone’s time zone, the card switch, your Sunset and Sunrise switches, your quiet hours and days, the app version, the next window the server should handle, the last window your phone planted itself, which of Apple’s two push services your copy uses, and the token Apple gives your phone for starting a card. Four housekeeping values go with it: a number saying which shape of record this is, so an older phone’s record can still be read, the moment your phone last wrote it, a mark saying your copy of the app arranges the end of its own cards, so that the server does not arrange it a second time, and one word saying what your phone did with the last card it was asked about. That word is either that it kept the card, that it ended a second copy of the same card, or that it ended a card it had not started itself. It exists so that a card which fails to end can be explained, and it says nothing about the sky, your Sky Score, or anything you photographed. It is rewritten when any of that changes, and again the next time the app runs more than a week after the last write.

While a card is up, or waiting on your phone to start, the record also holds an entry for that card, for at most five cards at once: the token Apple gives your phone for ending that card, and the times of its window, which are when it opens, the sunrise or sunset minute, the minute the colour peaks, when it closes, and the next sunrise or sunset after it. For a card about a spot you planned, the entry also holds that spot’s name, which comes from Skysta’s own list of spots and never from anything you typed. When the card shows its times in a time zone other than your phone’s own, the entry holds that time zone. There is no Sky Score, forecast or verdict in an entry, and there is no place in the record where one could go. Your phone writes these entries itself, in a write of their own. Each one is deleted when that card’s end push is sent, or when the server gives up on it because it is more than an hour late or cannot be read.

The server adds its own notes: which window it handled, which window the end push is for, when it last pushed, when the card should end, and how many cards your phone did not answer. Up to two pushes go to your phone for each card. At the opening minute of a card our server starts, the server asks Apple’s push service to start it. Your phone hands back a token for ending that one card, and iOS wakes Skysta in the background for a moment to do it. In that same moment, for a card about your watched place, Skysta asks Apple WeatherKit and Open-Meteo for the forecast for that window at that place, the same requests the table above describes for the open app, so the card can show its Sky Score (§10), and, while Show people’s skies is on, reads the newest shared skies and your block list for the card’s last hour (§10). Nothing from that forecast goes to our server. About five minutes after the window closes the server uses the card’s ending token to end it, whoever started it: our server, iOS from a plan your phone made, or the app itself while it was open. The card leaves an hour after the close. That depends on your phone having reached our server while the card was up. If it could not, the server never had that card’s token, and the card leaves when iOS takes it, which can be several hours later. The start push carries the card’s times, your watched place’s name and the alert’s words. The end push carries the card’s times and, when the entry holds them, the planned spot’s name and the time zone. Neither carries anything about the forecast. The job’s logs carry a short hash of your record’s address, never a token, a place or a name. The record is deleted when you turn the switch off, unset your watched place, sign out, or delete your account. If your phone cannot reach our server when you sign out, the delete is tried again the next time you sign in to the same account on that phone. Our server also deletes it on its own if Apple tells us your phone’s token no longer works.

2.1 Where the published place name comes from

Every shared sky carries the name of the town it was taken in. That name is produced by asking Apple’s reverse geocoder what sits under the capture coordinate, rounded first to a grid about 1.1 km across. It names the area the photograph was taken in, not the spot you stood on. Four things about it are worth knowing:

• The point that goes to Apple is the rounded one. Your exact position is not sent to name the town your sky carries, at any setting, including with the map switch on. A shared sky with its pin on is different: any phone that opens its page, yours included, asks Apple to name the place under the pin (§2.4). If that point lands in water or names no town, up to four rounded points beside it are asked about too. Those points are only ever asked about: they are never stored, never published, and never written to our database. They are finer than the ~5.5 km cell §4 describes as riding on every shared sky, and that cell has not changed. Until 13 September 2026 the same ~5.5 km cell was used for both, and asking about a point that coarse named the wrong town roughly one time in four: a sky taken in Draper went out as Lehi, because the rounding moved the question across a county line. A name that is wrong is a false statement about where somebody stood, published to strangers, which is worse than a name that is a little more precisely asked for.

• The lookup happens when the review page opens, not when you share. The page can tell you the town it will publish before you decide: the question mark beside Show on the map opens a short explanation that names it, so the answer is there before the decision rather than after it. Since 3 October 2026 the town is not written on the page itself, only in that explanation. The consequence is worth being plain about: that rounded point goes to Apple at that moment, with your network address, even if you then keep the sky private, and keeping it private afterwards does not unsend it.

• 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. There is a way to publish without one: Settings → Location & units → Name the town, which ships on. Turned off, your sky carries no town name and the review page sends no point to Apple to be named. If you also turn on Show on the map, the pin is public, and a phone that shows that sky, yours included, can still ask Apple to name the town under the pin and show that name beside it (§2.4). It is one standing answer rather than a question on every share. If you would rather publish nothing at all, keep the sky in your journal, which publishes nothing.

This changed in September 2026. Until then the town was published only when you turned Show on the map on, the lookup ran on that switch rather than on the page, and it sent your exact coordinate rather than a rounded one. The town now rides on every shared sky, which is how it ships, and the point sent to Apple to get it is coarser than the one the old behaviour sent. The location screen during onboarding tells you this once, instead of asking on every share, and you can turn it off at Settings → Location & units → Name the town. What Show on the map still decides, and all it decides, is whether your exact position is published as a pin. The changes page records this.

2.2 Your capture coordinates are yours alone, and now they follow you

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 and on your own photo map. That record lives in one file inside the app’s own storage, it is deliberately excluded from your iCloud and device backups, and it is erased when you delete the photograph or delete your account.

Since 15 September 2026 it is also in the private copy of your journal that Skysta keeps for you, and that is a change from what this section used to say. Until that date the backup record had no latitude or longitude field at all, and this paragraph said so with some pride.

Why it changed. Signing out deletes the journal from the phone. The coordinate went with it, and because nothing else had a copy, it was gone permanently. One sign-out emptied your own photo map for good, and every photograph that came back afterwards came back placeless. The old promise was real, and the price of it was paid entirely by the person it was meant to protect.

What did not change is who can read it. The journal copy lives under your account and the server rule on it is owner-only, in both directions: exactly one signed-in account can read a journal record, and that account is yours. The coordinate is not in any shared photograph, not in any analytics, not on a share card, and not readable by another Skysta user under any circumstance. Delete the photograph and it goes; delete your account and all of it goes.

One honest limit. If you signed out before 15 September 2026, those coordinates were already erased from your phone and had never been anywhere else. Nothing can bring them back, and photographs from before then may come back without a place on the map. Coordinates recorded from that date on survive.

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 while it is 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, 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.
• Which shared skies you have already seen, which you reported, the town under the pinned skies you have looked at, which months of your journal Skysta has already shown back to you, the spot and time of your plan, which the app also keeps in preferences, and a scrambled note of which accounts finished setup on this phone (§10).
• When you last opened your Activity list, and the notification token this phone last gave our server for appreciations’ notices (§5.4, §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 the pins on shared skies, yours included. 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.

A sky with a town and no pin sends its rough cell instead, and only from its own page. When you open a shared sky full screen that publishes its town but carries no pin, your phone asks Apple’s reverse geocoder for the time zone of the cell of about 5.5 km that the sky already carries (§4), so the day and time printed under it are the photographer’s. Only the time zone is used. The name Apple gives back is never shown, because the town on the sky is the one its author published. The feed never asks about a cell, and a sky that publishes no town never sends its cell from your phone. A sky tagged at a trusted spot whose time zone Skysta already lists uses that one and asks nothing.

Two honest consequences. For a pin, the coordinate that leaves your phone is the author’s, at the full precision they published, not a rounded one; for a sky with a town and no pin, it is the ~5.5 km cell every signed-in account can already read. 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 2048 pixels on its long edge before it is uploaded. Skies shared before 21 September 2026 stay at 3072. 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 things attached to it are its type, image/jpeg, and a note telling browsers they may keep a copy.

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, or Communication Safety, switched on in iOS Settings. When both are 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 or Communication Safety 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 in one more place: on your own phone, before another person’s shared sky is saved for your Lock Screen card (§10). A sky it flags is simply not saved. 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. Since 15 September 2026 it also carries the latitude and longitude, readable by your account alone; §2.2 says why.

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 is treated the same way, at the same 2048 pixels (skies shared before 21 September 2026 are at 3072), 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 is still readable by nobody but you (§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 and Communication Safety both 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 still sent as an empty string because the server rule once required the key. The rule no longer does.

And these, only under the conditions given:

The cell is the row that matters. It does three things. It puts your sky in the Local feed of people near where it was taken. On the map it is drawn as a town-sized area, about 5.5 km across, never as a point. And when your sky also carries its town but no pin, a reader who opens it full screen has their phone ask Apple for the cell’s time zone, so the time printed under it is yours (§2.4). The town’s name is worked out from a different, finer point that is only ever asked about and never published (§2.1). The cell 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 on every photograph, and it starts off. For everyone. Nothing seeds it from anything you did not choose: not from your last answer, not from your age, not from where you are. Turning it on for one photograph turns it on for that photograph only, and the next one starts off again.

Unless you have asked for it to start on, at Settings → Location & units → Show on the map, which ships off. That is the one thing that can seed this switch, it is a decision you make once rather than a memory of your last answer, and it changes where the switch starts and nothing else: every photograph still shows you which way it is set, and one tap still decides that photograph. With it on, the explanation behind the question mark beside Show on the map says your next sky starts with the pin on because you set that in Settings, instead of telling you that it starts with the pin off. While Precise Location is off in iOS it says the pin starts on only when Precise Location is on, because without it no exact pin can be dropped and the switch is drawn off.

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

The town name is on both rows and is not this switch’s to decide. Since September 2026 every shared sky carries the town its coarse cell falls in, and the switch that turns that off is Settings → Location & units → Name the town, not this one. §2.1 has it.

The cell is on both rows, and that is not a mistake. Leaving the switch off publishes no pin. It does not take your sky out of its area, and it does not take the town name off it either. 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. On the map that sky appears as a town-sized area of about 5.5 km with the town’s name on it, drawn from the cell and never from a point; zoom in and the area grows to cover streets rather than shrinking to a spot. 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 location row with its switch and a question mark beside Show on the map, and two buttons, Keep it private and Share this sky. With the pin on, the Share button reads Share with the pin. 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 under the switch, for as long as the switch is on: “Anyone on Skysta can see your exact spot.” With the switch off there is no line under it, unless Precise Location is off in iOS, when one line says that turning the switch on asks for it first, or that there is no exact pin to drop. The question mark beside Show on the map opens a short explanation you can read at any time, and it changes nothing and shares nothing. It gives that same sentence for the pin on, and for the pin off it says what other people will see instead, with this photograph’s town and spot tag, for example “No pin. The map shows Orem, UT as an area.” It also says where the switch starts for your next sky, and that Settings → Location & units is where you change that and the town. A pin at your home is your home. Read that explanation 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 it is 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. Every shared photograph also has a download link from Firebase Storage that carries an access token, and that link works for anyone who has it, signed in or not. From version 1.0 (16) of the app, the app no longer asks for that link to show you a photograph, because it downloads the picture with your own sign-in instead, but any signed-in account can still ask Firebase Storage for it, and can 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 Send this sky 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.

Sending your own sky is a different act, and it does send the picture. Choosing Send this sky on one of your own shared skies draws a card and hands it, with the sky’s link, straight to your phone’s share sheet. There is no screen in between and nothing to answer. Only a sky you have shared can be sent. A sky you keep in your journal has no Send at all.

What the card carries. The photograph. Your display name and profile picture, which are already public beside every sky you share. And whether it was a sunrise or a sunset. That is all: since 16 September 2026 the card has carried no Sky Score, no light, no spot name and no town. The message it goes out in carries the sky’s link and one line about the light the app worked out for that minute, such as “Afterglow, 6 min after sunset”.

What that card never carries. No coordinate, ever, and that is not a setting that happens to be off. The data the card is drawn from has no latitude and no longitude in it at all, so there is no switch to get wrong and no future change at that layer that could put one on a card. No file from your journal, no post identifier, no account identifier, and no place name.

This used to be a review screen, which asked whether to send the photograph or the reading alone, and whether to name the place. It was removed in September 2026 in favour of one tap, and on 16 September 2026 the card itself was cut back to the picture and who sent it. If a sky is pinned on Skysta’s map, that pin was agreed when you published it and §7 is where it comes off.

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.

The picture the receiver sees at the top of the message is not fetched from that page and is not fetched from us at all: it is the card, carried in the message from the sender’s phone. That is why somebody with no Skysta can see the sky, and why seeing it makes nothing public. A messaging app that ignores what the sender attached falls back to the page, and gets the Skysta logo.

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 → Help → My suggestions; no other account can see them at all.
• 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.
• Your phone’s notification token (§5.4). Only your own account can read it.
• An appreciation you sent, except the author of the sky you appreciated, who sees it with your display name and profile picture (§5.4).
• How many people appreciated your skies. You see that count on your own skies; nobody else sees it anywhere (§5.4).

5.3 A sky sent to one person

A test version of the app could, for one day in September 2026, send a sky from the journal to one person by a secret link. No released version ever could. If such a sky exists, only its sender and the one account that opened its link can see it, it carries no location, and deleting the photograph or the account deletes it.

5.4 Appreciations

You can thank somebody for a sky they shared. Open somebody else’s shared sky, from the feed, anybody’s profile, a spot’s page or a shared link, and tap the heart in its bottom corner, and Skysta sends that sky’s author an appreciation. Tap it again and it is taken back. You cannot appreciate your own sky, or a sky that was sent privately to one person (§5.3). Your phone shows you a small mark on the skies you have appreciated, and nobody else sees it.

What is recorded. One record per person per sky, written by our own server and never by your phone directly. Before it writes anything, our server checks that the sky exists, that it is not yours and that it was not sent privately, applies the limits described below, and reads the author’s block list. The record holds exactly these: the sky’s identifier, its author’s account identifier, your account identifier, your display name as it stood when you sent it, whether the sky was a sunrise or a sunset, and when you sent it. It is held under your account and under the author’s, in the sense that it is filed with both account identifiers and both accounts can read it. Nothing about it is written on the sky itself: a shared sky is readable by every signed-in account (§5), so a count or a list there would be public, and that is why there is none. What a shared sky publishes is still exactly what §4 lists.

Who can see it. Two accounts and no others: yours, and the sky’s author’s. The security rules let exactly those two read it, and let either of them delete it. Appreciating a sky shows your display name and your profile picture to that sky’s author, in a list the author opens from the feed called Activity, newest first, with a button on each row that opens the sky. Nobody else is told that you appreciated it, and no other screen shows it.

The count. On your own sky, and only there, a heart in the bottom corner shows how many people appreciated it (nothing shows until somebody has), and tapping it opens the list for that sky. People you have blocked are never counted. Nobody else ever sees a count, on the feed, on a profile, on a spot’s page or anywhere else, and there is no total. Appreciations decide nothing: the feed’s order does not read them, and neither does the Lock Screen card, its last hour or a spot’s page.

The notice. When somebody appreciates one of your skies, our server sends you a notification through Apple’s push service. It reads, for example, “Sam appreciated your sunset.”, or “sunrise”, matching the sky, and “Someone appreciated your sunset.” when the sender has no name or is called Skysta. It carries the sender’s display name, and no score, no place and no coordinate. It is a banner with no sound and no badge. You are told about each person’s appreciation of a sky once: if they take it back and send it again, no second notice is sent. At most six notices an hour reach any one person; any more still appear in Activity, without a notification. Opening the notification opens Activity. A notification already delivered stays on the phone it reached, and taking an appreciation back cannot recall it.

Your phone’s notification token. For the notice to reach you, your phone gives our server the token Apple issues it for notifications, in a record that holds that token, your account identifier, which of Apple’s two push services your copy uses, the app version, and when it was last written. Only your account can read or delete that record. It is stored only while Settings → Reminders → From people → Appreciations is on and notifications are allowed for Skysta in iOS, and it is deleted when you turn that switch off, when you sign out, and when you delete your account; turning notifications off for Skysta in iOS deletes it the next time you open the app with a connection. Our server also deletes it if Apple tells us the token no longer works. One gap, said plainly. Signing out deletes it before your session ends, and waits only a few seconds for the network. If your phone cannot reach our server at that moment, or your session ends without you signing out (a password changed on another device, for example), the record stays, so appreciations’ notices for that account can still reach this phone until somebody next signs in to Skysta on it, or Apple tells us the token no longer works. That next sign-in settles it, whoever it is: the record is taken over by the account signing in, then kept for them if they have these notices on and deleted if they do not. Either way the earlier account’s notices stop reaching that phone. For this, your phone keeps a copy of the token it last gave our server and the account identifier that record names (§10). The switch starts on, and it works only if notifications are already allowed for Skysta: the app never asks for notification permission just for this.

The limits record. So that nobody is told twice or too often, our server keeps a small record of its own, filed under an account identifier: counts for its daily and hourly limits, and which notices have already gone, kept as short one-way scrambles rather than anybody’s account identifier. No copy of the app can read it, write it or delete it, so the Delete account button cannot reach it, just as it cannot reach the verification email counter (§1.1). Our own erasure of an account removes it, and so does asking (§11.1).

Blocking. If you have blocked somebody, you are never notified about their appreciations and they are never shown to you. Each one is still recorded, so the person you blocked cannot tell they are blocked. From every row in Activity you can reach Report and Block for whoever sent it: tapping their picture opens their profile.

How long it lasts. An appreciation lasts until its sender takes it back, the sky’s author removes it from their list, the sky’s shared record is deleted, which both Delete and Make private do (§7), or either account is deleted (§11). Our server deletes every appreciation of a sky when that sky’s record is deleted.

What appreciating is not. It carries no words of your own: there are still no comments and no messages in Skysta. No analytics event records it (§8).

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 your skies, newest first. The page shows your newest sixty. Older ones are not deleted and still open from their own link; 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 gallery, which shows the newest forty.

No server in Skysta deletes a shared sky or a photograph on its own. There is no scheduled cleanup job for them and nothing that wakes up on a timer to remove one. 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). A sky taken down that way is kept privately, as the list below says.

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.

• Appreciations (§5.4) last until the person who sent one takes it back, the sky’s author removes it from their list, the sky’s shared record is deleted, or either account is deleted. Your phone’s notification token is kept while Appreciations is on and notifications are allowed, and is deleted when you turn that switch off, sign out, or delete your account, or when Apple tells us it no longer works; a sign-out that cannot reach our server leaves it in place (§5.4). The limits record our server keeps for appreciations is out of every copy of the app’s reach, so the Delete account button does not remove it; our own erasure of an account does, and so does asking. A notification already delivered stays on the phone it reached.

• 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.

• 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. A takedown’s line also holds the post’s identifier, the reason we wrote, up to 200 characters, whether the picture was kept, and whether the account was switched off. 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.

• A sky we took down is kept, privately, so a wrong decision can be undone. Its record goes into a store no copy of the app can read: the whole post as it was, with your account identifier, your name, any exact pin, the town and the spot, plus the reason we wrote. Its picture, unless we chose to destroy it, stays at the same storage address it always had. No screen in Skysta shows it and no Skysta link reaches it, but that address is readable by any signed-in account that knows it, and the picture’s own web link keeps working for anyone who already holds it, until we destroy it or put it back. Nothing removes either on a timer. The Delete account button cannot reach them. Our own erasure of an account does, and so does asking.

• 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 10 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, from a timer inside the admin tool whenever that tool is running, 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. The admin tool runs all the time on that Mac, and a timer inside it checks every half hour. A dated copy more than thirty days old is deleted at the next check. 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.

  Until 20 September 2026 the rule had never deleted anything; from that day the oldest daily copies age out on their own. Everything that came off that disk before then 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.

• A copy of some app counts, on the developer’s Mac. On 26 August 2026 the developer downloaded 942 app count events from Google, sent between 21 and 23 August 2026 by phones with app counts switched on, to work out the app’s own figures. Each one carries the kind of event, Google’s install identifier for the phone, the app’s version, the phone family and its iOS version, session counts and a rough time of day, and some also carry the identifier of a trusted spot that was opened, a Sky Score band or a rating. They carry no account identifier, no name, no email address and no coordinate, so none of them can be tied to your account or found by it. The file is kept, on the same encrypted laptop as the daily copies and out of the code repository, with no date set for deleting it.

The record behind the Lock Screen card (§2) lasts exactly as long as that switch is on. Turning the switch off, unsetting your watched place, signing out, or deleting your account deletes it; the deletion on sign-out waits at most three seconds for the network and is retried the next time the same account signs in on that phone. Our server also deletes it on its own if Apple tells us your phone’s token no longer works. Each card’s own entry in that record, its ending token and its window’s times (§2), goes sooner: it is deleted when that card’s end push is sent, or when the server gives up on it because it is more than an hour late or cannot be read.

The small copies of shared skies that your phone keeps for the Lock Screen card’s last hour (§10) stay on your phone only. They last until the next window’s skies replace them, you sign out, you delete your account, or you turn Show people’s skies off. If you do not open Skysta again they stay in the phone’s cache folder, which iOS may clear on its own, until you next do.

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. No scheduled job deletes a backup, no server wakes up on its own to do it, and no rule fires on a timer: nothing in this service can delete a journal backup by itself. The one scheduled job on Skysta’s servers is the Lock Screen card’s (§2), and the only things it ever deletes are its own record and the card entries in it. The timer inside the developer’s own tool deletes old daily copies (§6), and nothing else. 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 from the feed or your public page, 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, opened from the feed or your public page, 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 from your journal, tap the ⋯ menu, choose Delete. Opened anywhere else, the same menu has Make private, which takes the shared sky down and keeps the photograph. The record goes first, then the image file. Our server watches for a deleted record and removes its photograph too, unless we took the sky down and kept the picture so it can be put back (§6), and tries again if that fails. When a shared sky’s record is deleted, our server also deletes every appreciation of it (§5.4). If the app’s own attempt fails, say on a dropped connection at the wrong moment, it also writes the file’s address down on your phone and retries 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. With crash reports on, Crashlytics’ companion library also sends a small record each time the app opens: an identifier it makes for this installation, a number for the session, and the phone’s model and iOS version. It stops when crash reports are off. Settings → Privacy → Crash reports.
• App counts. The nine kinds of count listed below, and nothing else. Settings → Privacy → App counts.

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. 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, the phone’s model and iOS version, the versions of the tools the app was built with and whether it came from the App Store, 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 Firebase Analytics and nothing else. It used to govern one more thing, and §8.1 says what that was and that it is gone.

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 four: sunrise reminder, sunset reminder (the note at peak colour counts as one of these), leave by, or camera opens, 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 a plan you made;
  • 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. A copy of some of it, 942 events sent between 21 and 23 August 2026, was also downloaded to the developer’s Mac on 26 August 2026, and it is kept there (§6). 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. Crash reports and app counts 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; its library also sends Apple’s identifier for vendor, which is the same for every app one developer makes on your phone (Skysta is the only app we make); and Google can infer a coarse region from the network address your requests arrive from. Skysta does not stop any of these. The rough region is named in What each switch sends, beside the switches in Settings. 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

Retired 10 September 2026. No part of the app asks how a sky turned out, and no rating is written anywhere. Earlier builds could ask one question after a sunrise or a sunset, with app counts on, and file the answer with the watched place rounded to about 5.5 km and no identifier of any kind. The question is gone from Home and from the camera, the small adjustment your answers used to make to your own score on your phone is gone with it, and the collection those records went into is closed to every read and write. Records written by earlier builds cannot be found, because they carried no identifier. The number and the heading stay so that older references to this section still land somewhere true.

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.

Four 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. 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.

We use your email address to sign you in, to answer you, and to tell you if we act on a report you filed or take down something you shared. A person writes those emails, from hello@skystaapp.com.

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 → Help → 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. A suggestion is read at a desk. What that reading is: we check what you wrote against public sources and check your coordinate against a map. Nobody goes to the place, and nothing about you is used to do it.

You can see the status of your own suggestions in Settings → Help → 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 → Help → 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 with you

• The coordinate of every capture, meaning where each photograph in your journal was taken. The full-precision record is on the device and, since 15 September 2026, in the private copy of your journal that only your account can read (§3.2). Nothing reads it there but a restore onto your own phone. Sharing a photograph is the only thing that publishes anything from it: a ~5.5 km cell on every shared sky, and the exact pin too when the map switch is on (§4). A sky that stays in your journal is published nowhere.
• Your reminder schedule. Sunrise and sunset reminders are scheduled locally by iOS, and no server sends them. Our own server pushes the start and the end of the Lock Screen card, described below, and, while you can receive them, an appreciation’s notice (§5.4), which is sent when a person appreciates your sky and never because of the forecast. A reminder’s own words name clock times, and sometimes one short sentence about how tonight looks, written on your phone from the forecast the app already showed you. That sentence names no place, no spot and no number, and it never decides whether a reminder is sent.
• What your Lock Screen shows, and it is more than you might expect. While a light window is open, Skysta puts a live card on your Lock Screen and in the Dynamic Island. It never appears before the window opens. It names the place Skysta is watching, or the spot you planned if you planned one. It shows the Sky Score and its short verdict beside the times WHEN THERE IS ONE TO SHOW: your phone puts a number on the card only if the reading behind it is recent enough to still stand at the minute the card is delivered, and leaves that space empty otherwise rather than printing a stale one. A card our server started begins with no number, and so does a card your phone scheduled, unless, when it was scheduled, your phone already held a reading for that window recent enough to still stand when the card starts. When iOS wakes Skysta for a moment as the card starts, Skysta asks Apple WeatherKit for the forecast for that window at your watched place, and Open-Meteo for the haze, exactly as it does when it is open, works the score out on your phone, and puts it on the card once, with the Apple Weather mark beside it. If the forecast does not answer within about twelve seconds, does not reach the light, or would be more than three hours old, or the card is for a spot you planned, the card keeps its times and stays without a number. iOS does this wake for cards our server starts. Whether it does it for the cards your phone schedules itself on iOS 26 is still being checked, so read that half as happening where iOS allows it. The score and the verdict are worked out on your phone and never leave it, and your phone 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 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. For those four, it is still your phone that starts them, and the times are solar geometry worked out on the device. Your phone gives our server each card’s ending token and times so the card can be taken down after the light, as §2 describes. And when one of them starts and iOS wakes Skysta for a moment, Skysta asks Apple WeatherKit and Open-Meteo for that window’s forecast, as described above, so the card can show its score. Beyond those four, and on earlier versions of iOS, our own server can start the card while Skysta is closed, through Apple’s push service, using the small record §2 describes. Either way our server ends the card about five minutes after the window closes, whoever started it. The start push carries the card’s times, the name of your watched place, and the alert’s words. The end push carries the card’s times and, when the card has them, the name of a spot you planned and the time zone the card shows its times in. Neither carries a score, a verdict or anything from the forecast, because a number a server worked out is not a reading of the sky the card is shown under. That record exists only while the switch below is on. Skysta has its own switch for it: Settings → Reminders → Lock Screen → Show the 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. When the light is over the card stays for one more hour, saying so and offering to show you what other people caught, and then it goes. That depends on your phone having reached our server while the card was up: then the server’s end push takes it down an hour after the close. If it could not, the card goes when iOS takes it, which can be several hours later. That last hour can show a few skies from the feed, up to five, small and square, under “See what people caught.” A Lock Screen card cannot use the network, so the app saves small copies of those skies on your phone, in a folder the card can read: while Skysta is open around a sunrise or sunset, and, when iOS wakes the app for a moment as a card starts, then too, with the app closed, where iOS allows it as above. Waking for that reads the newest few shared skies and your block list from our server, the same reads the feed makes when you open it. Each copy is 186 pixels square, made fresh from the shared photograph so nothing but the picture comes across: no location, camera or time details from the original. Beside them sits a short list of which shared skies they are and which window they belong to. Nothing about who took them is saved. They are never backed up and never leave the phone. The same feed you would see decides which: the newest skies you have not seen yet, the ones near your watched place first. Never your own skies, never a sky sent privately to one person, and never anything from a person you blocked. Before they are saved the app checks with our server that each sky is still shared, and saves nothing if it cannot check, and it chooses no sky until it has your block list from our server. A sky you report on this phone, or anyone you block on it, comes off the card at once. A person you block is not chosen again, and a sky you report is not chosen again while you stay signed in on this phone. A sky its author deletes is taken off the next time Skysta checks with our server, every few minutes while Skysta is open before the light ends; once the light has ended, the card keeps the skies it was given until it leaves. They are replaced by the next window’s skies, and deleted when you sign out, when you delete your account, and when you turn off Settings → Reminders → Lock Screen → Show people’s skies, which starts on. Off deletes the saved copies straight away, and the card then shows its words only. The card keeps to the card switch, your quiet hours and your days, and not to the Sunset and Sunrise reminder switches. A card that starts ITSELF has to make a sound, because iOS requires an alert on it and offers no silent one. Since 19 September 2026 a morning card is planned whenever the card switch is on, the same as an evening one, whatever the Sunrise switch says, so quiet hours and your chosen days are how to keep one from arriving before dawn. Turning a reminder off does not take the card away, and turning the card off does not turn a reminder off. Turning Live Activities off for Skysta in your iPhone’s own Settings → Skysta → Live Activities stops all of it, and that one wins whatever Skysta’s switch says.
• A few small notes. A week of the Sky Scores your phone worked out, with no coordinate, in a file Apple’s backup skips; and, in the app’s preferences, which shared skies you have already seen, which you reported, the town under the pinned skies you have looked at, which months of your journal Skysta has already shown back to you, and a scrambled note of which accounts finished setup on this phone. Signing out clears all of them except the last (§11.2).
• Two notes for appreciations, in the app’s preferences: when you last opened your Activity list, so the feed can show a dot when something new has arrived, and the notification token this phone last gave our server, with the account identifier that record names, so it can delete or settle that record later (§5.4). Signing out clears the first. The second goes when its record is deleted, so a sign-out that cannot reach our server leaves it behind (§11.2).
• Your units, your plan, and your interface preferences.
• Which way your phone is pointing, on a trusted spot’s page. The small compass dial there turns with your phone. The direction is read on the phone only, only while the dial is on screen and Skysta is in front, and it is never stored and never sent. Reading it asks for no permission (§2).
• An appreciation’s notice, once delivered, stays on the phone it reached, and taking the appreciation back cannot recall it (§5.4).
• 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 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, 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 records are held in memory only, apart from the notes above: which skies you have seen, and the town under each pinned one. Pictures are different, in two ways. The app keeps up to about 200 MB of shared skies in the phone’s download cache, so they are not downloaded again every time: the ones it has shown you, the few next to them that you are about to reach, so they are ready before you get there, and, when the Lock Screen card shows other people’s skies, the ones it picks from, up to eight at a time. Before you open the feed, getting it ready downloads at most two on mobile data and none in Low Data Mode; the Lock Screen card’s picks are downloaded when the card needs them, on any connection. That cache is emptied when you sign out and when you delete your account, and blocking someone removes their skies from it. And the Lock Screen card’s last hour keeps up to five small copies of shared skies, as described above, with the list of which skies they are.

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. An Apple account is also sent through the sheet inside those two minutes when the app is not holding the code step 11 needs, which is the case once Skysta has been closed and opened again since you signed in. 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. Any sky sent to one person (§5.3) goes with them, record and image file alike.
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, then every appreciation you sent or received, then the records that let our server send your phones appreciation notices (§5.4). The list of places you saved lives under your account and is exactly as private as your block list. If any of these will not delete, the deletion stops here and says so.
7. The record behind the Lock Screen card is deleted. If it cannot be confirmed gone, the deletion stops here, because our server reads that record on a timer and would go on starting cards on a phone nobody is signed into.
8. Your profile photo is deleted, from the device and from storage.
9. Your block list is deleted.
10. 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.
11. 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. If it is not holding one, step 1 sends you through the Apple sheet, even inside those two minutes, and that gives it one. 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.
12. 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.
13. Your journal, reminders, cached images, saved-spot mirror, unfinished photograph and preferences are wiped from the device, with the pictures the app holds in memory, the phone’s download cache of shared skies (§10), and the copies of shared skies kept for the Lock Screen card, 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 8 and 9, 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 11, the Apple token, is the third, for the same reason. Every other step stops the sweep: steps 1 to 7, the online-status record at step 10, and the account record at step 12, where a failure leaves your account intact rather than stranding the document. Step 13 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.

Your appreciations go too. Deleting your account deletes every appreciation you sent and every one you received, and the record of each of your phones’ notification tokens (§5.4). The limits record our server keeps for appreciations is the exception, and §11.1 lists it.

Every photograph in steps 2, 4, 5 and 8 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.
• The limits record our server keeps for appreciations (§5.4), for the same reason: no client can touch it. It holds counts for the daily and hourly limits and which notices have already gone. Our own erasure of an account removes it.
• A sky we took down (§6), with its kept picture. Our own erasure of an account removes them, and so does asking.
• If a sky was sent to you as its one person (§5.3), your account identifier on that sky’s record, which is the sender’s.
• 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 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 two, and it is worth saying which and why. Write to hello@skystaapp.com and say what you want gone.

• 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.

Two more things outlast the button, and nobody removes them by hand, because they end on their own. A deleted photograph stays recoverable for seven days before the storage service destroys it, and a deleted record stays readable for one hour, the account record with your email address included (§6). Your pictures are gone from the app and from every link the moment the sweep finishes; “deleted” and “destroyed” are seven days apart, and you should hear that from us.

And app counts cannot be found by account at all. Those already sent, and the copy on the developer’s Mac (§6), carry no account identifier, so there is no way to pick out yours.

And a notification already delivered stays where it is. If you appreciated somebody’s sky and the notice reached their phone, it stays on that phone, and nothing in Skysta can recall it (§5.4).

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, 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. Signing out also deletes this phone’s notification token from our server, so appreciations’ notices for that account stop reaching it (§5.4). If the phone cannot reach our server at that moment, the record stays, with the phone’s own copy of the token, and §5.4 says what follows.

Four small things are deliberately left behind, and sometimes a fifth or a sixth. 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). And a scrambled note that this account finished setup on this phone, with its Sunrise and Sunset switches, stays so you are not walked through setup again. The first two clear themselves as the server confirms each item, and all four go when you delete your account. And when a sign-out has not confirmed with our server that the Lock Screen card’s record is gone, your account identifier stays on the phone too, so that delete can be tried again the next time you sign in to that account on it (§6). And when a sign-out could not delete this phone’s notification token record, the phone keeps its copy of that token and the account identifier that record names, so the next sign-in here can settle it (§5.4).

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, with their coordinates where the backup has them (§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 nothing in Skysta deletes it on a timer. There is no friends-only setting.
• “Show on the map” starts off, so leave it off, and leave the switch in Settings → Location & units that would start it on alone. 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 unless that switch in Settings is on. 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. But the town it falls in goes out with it unless you turn Name the town off, and on the map it shows as a town-sized area. 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, Skysta puts a card on your Lock Screen naming the place or the spot you planned and showing the score (§10), and it can do so with the app closed. Anybody who picks your phone up can read it. If you would rather they could not, turn the card off at Settings → Reminders → Lock Screen → Show the card, 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.
• An appreciation says who sent it. Tapping the heart on somebody’s sky shows them your name and profile picture (§5.4). If somebody’s appreciations make you uncomfortable, block them, and you will not be told about them again.

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 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 two 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 it is a tap you make on one photograph, or a standing answer you set once in Settings, or neither (§4.1). The spot tag comes off with one tap (§4.1). Location permission itself is yours to refuse or revoke in iOS Settings. Turn Settings → Reminders → From people → Appreciations off and your phone’s notification token is deleted and no appreciation’s notice reaches you (§5.4).
• 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. A name is needed too: the app asks for one before it opens, with no skip (§1.2). Everything after that is optional: a profile photo, a photograph, a location on a post, an appreciation, 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, your name and email when you use Sign in with Apple, which come from Apple, and the appreciations other people send you, which come from them.

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.

13.2 Where your data is processed

Skysta is operated from Utah, in the United States. Its service providers, Google Firebase, Apple, Resend, Open-Meteo and Microsoft, which hosts the hello@skystaapp.com mailbox, and on the website OpenFreeMap, OpenStreetMap and the U.S. Geological Survey, 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 and Google each see your device’s network address on the requests your phone makes to them. Resend does not: our server talks to Resend, never your phone. Each of them can learn from a network address 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

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, unless you set it to start on at Settings → Location & units. It is what publishes the exact capture coordinate, and it publishes nothing until you turn it on for that photograph. The name of the town goes out whichever way it sits; Name the town, in the same place, is the switch for that. §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 exact pin and starts off, and from Name the town, which governs the town’s name and starts on. §4.3 explains what happens when both the tag and the pin 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 the database never writes other people’s records to your phone. What the app does keep from other people’s skies, their pictures included, is listed in §10. 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.

Appreciations are written by our server alone. No copy of the app, modified or not, can write or change one, or address a notification to anybody. Our server writes an appreciation only after checking that the sky exists, is not the sender’s own and was not sent privately, and the rules let exactly two accounts read it, its sender and the sky’s author, and let either of them delete it. A notification token record can only ever name the account that wrote it, and only that account can read or delete it. The limits record is closed to every copy of the app (§5.4).

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, precise location, and one row of other data covering the online-status record, the date you last opened the app, and the count of verification emails sent to you, and now also the limits record our server keeps for appreciations (§5.4). All of that is for app functionality, all of it is linked to your account, and none of it is for tracking. It also declares product interaction, for analytics, and crash data, for app functionality, and neither of those is linked to your identity. And it declares a device identifier, for analytics and for app functionality, linked to you. Four things fall under that row. One is the identifier Google and Crashlytics make for themselves when you turn diagnostics on, which is never joined to your Skysta account. Another is Apple’s identifier for vendor, which Google’s library sends with app counts (§8). The third is the tokens Apple gives your phone for starting and ending the Lock Screen card, which are stored under your account while that switch is on, an ending token only while its card is up or waiting to start, and deleted with it (§2). The fourth is the token Apple gives your phone for notifications, stored with your account identifier while you can receive appreciations’ notices (§5.4). The tokens are why the row is linked.

Skysta’s own manifest is not the only one inside the app. Many of the libraries the app is built with ship one of their own, and several of them declare other diagnostic data for themselves, collected for analytics or app functionality, not linked to you and not used for tracking. Skysta’s label on the App Store lists other diagnostic data as linked to you all the same, because a few technical values Skysta keeps are tied to your account: the app version on your online record, on the Lock Screen card’s record, on your phone’s notification token record and on a feedback note you send, the outcome of your last Lock Screen card, and your account identifier in the verification email step’s logs (§1.1). The label also lists coarse location for analytics as well as app functionality, because with app counts on Google works out a rough region from your network address (§8). Two of them are Firebase Authentication and Firestore, which run for every signed-in session whatever the diagnostics switches say, and §8 describes the header they send.

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 saved list, the spot correction, the Lock Screen card record or appreciations, and it is worth saying which existing declaration each one lands under rather than letting silence imply nothing new happens.

• The Lock Screen card record (§2) lands under coarse location for the watched place rounded to about 1 km, and under the device identifier for the tokens. Both are linked, because the record lives under your account. The entry for each card that is up or waiting to start lands under three: the name of a spot you planned under coarse location, its ending token under the device identifier, and its times under other data, with the mark saying your copy of the app ends its own cards and the other housekeeping values.
• 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.
• An appreciation (§5.4) lands under user identifier for the two account identifiers on it, under name for the sender’s display name, and under other user content for the thank-you itself, which reaches one other person, the sky’s author. Your phone’s notification token lands under the device identifier, and the limits record our server keeps for appreciations under other data. All of it is linked, because each is filed with an account identifier.

15.1 The website

skystaapp.com, where this policy is published, sets no cookies, runs no analytics, and loads no third-party scripts. Apart from the map, whose pieces and label fonts come from the map hosts named below, 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 map hosts named below, forbids the page from posting a form anywhere, 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 website. Since 3 September 2026 the website can show the Sky Score for a place you name; since 19 October 2026 it does so on each city’s, place’s and spot’s own page, not on the home page. 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. The same happens for a city’s page (skystaapp.com/sky) when you open it by pressing that city, or press its button, one city at a time; a city’s page opened any other way reads nothing until you press its button. It happens for a place’s page when its address names the place (a town you picked in a search, or an older link to the home page), and for a spot’s page when you ask it for that spot’s Sky Score. Each reads once; Read again asks again. When you look up a place by name, what you type goes through our server to Open-Meteo’s geocoder to find matches; on the home page, the list of cities, a place’s page and the suggest page that happens as you type, from the second letter. The cities Skysta has pages for are matched in your browser.

The website reads where you are only when you press a button. When you press Show my sky or Use where I am, a page for your own sky opens and asks your browser for permission, once, and the position is rounded to about 5.5 km before it leaves your browser; that rounded position goes to our server for the forecast, and to OpenStreetMap’s Nominatim service so the page can name the town, and the name OpenStreetMap gives back is looked up at Open-Meteo to find the town’s time zone. It is never written into the page’s address. That page then also lists the checked spots within about 80 km of it and shows them on its map, so your browser asks our own site for the spot list and those spots’ small pictures, and the map pieces and, in the lower 48 states, the aerial photographs it asks for show your area too. Near me on the home page and on the spots pages, and How far is it? on a spot’s page, also ask your browser, round the position the same way and keep it in the page, sending it nowhere: Near me sorts the spots by distance, How far is it? shows the distance, and both then move the map to show your area, so the map pieces your browser asks for, from OpenFreeMap or, when the newer map cannot be drawn, OpenStreetMap, or, after you press Satellite, the U.S. Geological Survey, show that area too. Near me also puts the nearest spots at the top of the list (on the home page, three of them, worked out in the page itself), so your browser then asks our own site for those spots’ small pictures, and those requests show your area too. The home page’s Find a spot search matches the spots by name, town or state in your browser; nothing you type leaves it unless you follow the “See all” link to the spots page, which carries your words in its address. The page asks our own site for the list of spots, their picture list and the small pictures of up to six matches, so those requests show what you searched, and the home page’s map then moves to the matching spots, so the map pieces it asks for show that area, never where you are. On the suggest page, Pin where I’m standing puts the pin exactly where you are, unrounded, and moves the map there; move it before you send if you’d rather not share that. Nothing on the site reads your position without one of those presses. The home page’s cities, and the list at skystaapp.com/sky, are each city’s name and country, built into the page: they read no position, send nothing and show no Sky Score. Each city’s page shows that city’s times, worked out in your browser from its clock, and its year of sunrise and sunset times, built into the page. A place’s page can be named by its coordinate, rounded to about 5.5 km, its time zone and its name, in its address (a town you picked in a search, or an older link to the home page, which now opens that page); opening it reads that place’s Sky Score with no press, sending that coordinate, not yours, to our server for the forecast. That part of the address is one a browser never sends to any server. Your own rounded place never reaches the address bar.

Our server keeps answers in memory so nearby readers share one request: forecasts for up to twenty minutes, cloud layers for half an hour, the haze reading for an hour, and place searches and town names for up to a day. To slow abuse it also counts, in memory and for one minute, how many requests each network address makes. It writes nothing down: no record of who asked about where, and nothing tied to any account. The request itself does pass through Google’s platform, which runs our server, and Google’s ordinary request logs for it, kept for up to 30 days, hold the web address the page asked for, which includes the place or the rounded position, together with your network address. Skysta does not use those logs to find out who asked about where. Apple, Open-Meteo and OpenStreetMap receive those requests from our server, not from your browser.

The map of spots. The live map is on the home page, on the spots pages, starting at skystaapp.com/spots, on each city’s and place’s page, and on the page for suggesting a spot. On the home page it starts as you scroll near it, showing the whole country, so the pieces it first asks for say nothing about where you are (each request still carries your network address, as above); until then, and if your browser cannot draw it, the home page shows a picture of the map served from the site itself. It 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. A Satellite switch on each map, except a city’s or a place’s page outside the lower 48 states, where it has no pictures to show, swaps the background for aerial photographs from the U.S. Geological Survey’s The National Map (basemap.nationalmap.gov). Nothing is asked of it until you press Satellite on that map, except on a city’s or a place’s page in the lower 48 states, whose map opens on Satellite; from then on, as you pan and zoom, your browser asks it for the photograph pieces on your screen, and each request carries your network address, the map area you are looking at, and the name of our site. It sets no cookies and asks for no key or account, and we send it nothing about you. The choice lasts for that map and is stored nowhere. The small picture beside each spot in a list is a photograph of that place’s ground, made ahead of time from the same public imagery (for Alaska, from EOX’s Sentinel-2 cloudless 2016) and kept on our own site, so showing it asks nobody else for anything. 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, sunset or both, 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, with one more field that a person never sees and leaves empty, for the same reason. 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, a count of accepted suggestions for the day, and, for a day, the name and pin of each suggestion it accepted so the same place sent twice is caught, 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.

16. Changes to this policy

If Skysta changes what it collects, who receives it, or how long it is kept, this policy is updated and the effective date at the top changes with it.

How you will be told, and its limits. A material change gets a dated entry on the changes page, in the words used at the time and never edited afterwards, and the effective date at the top moves. Those entries are this section’s: they are numbered §16.1, §16.2 and onwards on that page, which is why there are none under this heading. The Privacy Policy link in Settings → About opens this page on skystaapp.com, so it always shows what is published there.

That is the whole of the mechanism, and it is worth being blunt about what it is not. Skysta has no in-app announcement and no changelog screen, and it never sends you a notification about a change to this policy. So that page is the notice, and reading it after an update is how it reaches you.

If a change ever needs your consent, it will be asked for on screen before anything new is collected, rather than announced.

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.

The Skysta app is offered only 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. The website can be read from anywhere, and its Sky Score works for any place, but it is not aimed at people outside the United States either. If that ever changes, this policy changes with it and the effective date at the top moves.