ScrollShot
Get ScrollShot
Get ScrollShot

ScrollShot Privacy Policy

Effective 17 September 2026

The short answer

ScrollShot turns a screen recording, or several screenshots, into one long screenshot. That work happens on your device, using Apple's own frameworks.

Under Apple's definition of "collect" — data transmitted off the device and retained — ScrollShot collects nothing.

Who provides ScrollShot

ScrollShot is made by Arda Demir Yildiz, an individual developer. It is not a company, and there is no registered entity behind it.

Contact is by email, at bladeytmail@gmail.com. The support page is published alongside this policy and offers the same address; it is a page, not a form, and nothing is submitted through it. There is no phone number and no contact form.

This policy covers version 1.0 of the ScrollShot iOS app, bundle identifier com.bl4de.scrollshot, which requires iOS 17 or later.

What the app does, and what it never does

You record your own screen with the screen recorder built into iOS, or you take screenshots yourself. Then you hand the result to ScrollShot, which stitches it into a single tall image.

ScrollShot has no screen-recording capability of its own. ReplayKit and RPScreenRecorder appear nowhere in the app. It cannot start, stop or observe a recording, and it never records anything: not your screen, not your camera, not your microphone.

The reconstruction runs entirely on the device, using Apple's Accelerate, AVFoundation, CoreGraphics and ImageIO frameworks. There is no server-side processing, because there is no server.

How your media gets into the app

Import uses the SwiftUI PhotosPicker — the system photo picker, which iOS runs outside the app. It hands ScrollShot only the items you tap.

Because of that, the app needs no photo-library permission prompt, and the NSPhotoLibraryUsageDescription key is deliberately not declared. That key is what an app needs in order to be granted read access to your library, so ScrollShot cannot be granted it, even in principle. The app cannot browse, enumerate or search your photo library, and it never reads an asset identifier — no PHAsset, no local identifier, no library fetch anywhere in the code.

There is no other route in: no Files import, no document picker, no drag and drop, no share-extension inbox, no clipboard reading, no URL scheme, no open-in-place.

One honest caveat about what you can hand over. The recording picker matches videos and the screenshot picker matches images, so you can give ScrollShot any video or any photo, not only a screen recording or a screenshot. Screenshots are copied byte for byte in their current encoding, which means that if the original carried EXIF or GPS metadata, that metadata comes into the app's sandbox with the copy. The stitching engine never reads it: from an image it reads only pixel width, pixel height and orientation, and it never opens the EXIF dictionary, the GPS dictionary or maker notes. From a recording it loads only video tracks, so audio is never read. And, as described under Saving and sharing, none of that metadata is carried into the image ScrollShot produces: the file it writes holds only the standard technical information Apple's image frameworks add, such as pixel dimensions and a colour profile.

Where that media lives, and when it is deleted

Everything below happens inside ScrollShot's own app sandbox. The originals in your library are never modified and never deleted.

The items you select are copied into the app's temporary directory. The long screenshot is then composed into a memory-mapped scratch file in that same directory, rather than being held in memory, because results can be very large: the engine's ceiling is 120,000 pixels tall, and a 1290-pixel-wide result at that ceiling is roughly 620 MB on disk.

Deletion is not immediate in every case. Exactly when it happens:

Files are written with the data protection iOS applies to app files by default. ScrollShot adds no encryption of its own, and this document does not claim any.

Deleting the app removes all of it.

The one permission ScrollShot asks for

Saving a finished long screenshot to Photos needs permission, so the app requests add-only access to your photo library, with the declared reason "Lets you save your long screenshot to your photos."

Add-only is the narrowest Photos permission iOS offers: it permits adding an image and nothing else. It gives ScrollShot no ability to see, read, browse or delete anything already in your library.

It is the only permission the app ever requests, and it is requested only at the moment you tap Save on a finished result — never at launch, and never during import.

If you refuse it, the app keeps working: it shows an inline message, does not crash, and you can still view the result and share it.

ScrollShot does not use or request camera, microphone, location, contacts, calendar, notifications, App Tracking Transparency, HealthKit or Local Authentication.

Saving and sharing

The PNG that ScrollShot saves or shares is encoded from the raw composited pixels, and ScrollShot passes no properties of its own to the encoder. It does not add anything about you or about where the picture came from: no camera or device details, no GPS or location, no timestamps, no account, message or contact information, and nothing identifying the original recording or screenshots it was made from. Apple's image frameworks do write a small amount of standard technical information when they encode the file — in practice the pixel width and height, and a colour profile so the image displays correctly elsewhere — and that is what a PNG from ScrollShot contains. None of it describes you.

Sharing uses the standard iOS share sheet, handed the local file URL of that PNG. ScrollShot does not choose the destination and has no say in what happens next. That is your choice, made outside the app, and it has consequences worth knowing: if you choose Copy, the image goes to the general pasteboard, which Universal Clipboard may sync via Apple to your other devices; if you choose Save to Files, you may place it in iCloud Drive.

That is the only way a long screenshot leaves your device. ScrollShot itself has no way to send one.

What is stored on your device

ScrollShot writes four preferences into its own sandboxed settings:

Two older settings keys from a previous version are read once and never written again.

To tell a first install apart from an upgrade, the app compares two timestamps: the creation date of its own container and the date of its own bundle. They are read on every launch, compared only with each other, and are never displayed, never stored and never transmitted.

Nothing else is persisted. No Keychain item, no database, no CoreData or SwiftData store, no App Group, no iCloud key-value storage, and no files other than the temporary media described above.

The app writes no logs: there is no Logger, os_log, NSLog or print anywhere in the app layer. A few internal safety checks inside the stitching engine carry messages, and those contain pixel row indices and buffer sizes — never anything from your images.

Two things to be aware of, neither of which ScrollShot controls. Its preferences are part of the app's data, so they are included in an encrypted device or iCloud backup, like any app's preferences. And iOS itself may keep a snapshot of the app's last screen for the app switcher, which can include a rendered long screenshot; ScrollShot does not currently hide its content from that snapshot.

What ScrollShot does not do

Stated plainly, because a short list is easier to check than a long paragraph:

The app, the internet and Apple

This is the part most easily overstated, so it is worth being exact.

ScrollShot contains no networking code of its own. There is no URLSession, no sockets, no Network.framework and no web view; CFNetwork is not even linked. ScrollShot therefore never uploads your recordings, your screenshots or your finished long screenshots: it has no means of sending them, and no destination to send them to.

That is not the same as the app never using the internet, and saying so would be misleading. ScrollShot sells a subscription, and subscriptions on iOS run through StoreKit, Apple's own framework, which talks to Apple's servers from your device. It does so on every launch, not only when the paywall is on screen. At launch the app starts listening for transaction updates, fetches the product catalogue with its localised price, reads the current entitlements of the Apple Account signed in on the device, and asks Apple whether that Apple Account is eligible for the introductory trial.

So connections to Apple do happen: made by Apple's framework, to Apple, about the subscription. Nothing about your content or your files is part of them, because the app has nothing of that kind to send. They are tied to the Apple Account signed in on your device, because that is what an entitlement and a trial eligibility are about; and because they run at every launch rather than only at the paywall, Apple's servers see a request each time ScrollShot is opened. What Apple does with traffic to its own servers is Apple's to describe, not something ScrollShot sees or controls.

Purchases

ScrollShot offers one product: an auto-renewable subscription billed weekly, identifier com.bl4de.scrollshot.pro.weekly. The subscription's own terms — what it gives you, billing and renewal — are set out in the ScrollShot Terms of Use, not here. This section covers only what happens to data.

You get one free successful long screenshot before the paywall. That allowance is spent only when the engine has actually produced a result: not when you import, not when you start a job, and not if you cancel, refuse, or the job fails. It is counted on your own device rather than on a server, because there is no server, and the count is per installation. If you subscribe, your results are not counted or recorded at all.

Whether you are offered the introductory free trial is Apple's determination. The app asks StoreKit whether your Apple Account is eligible and shows the trial only if Apple says yes; it never assumes eligibility, fakes it or stores it. If Apple says you are not eligible, you are shown the price with no mention of a trial. The price shown is whatever localised price StoreKit returns for your App Store storefront, and the price displayed to you before you confirm is the price that applies.

Apple handles everything about payment. The purchase sheet is Apple's. Your payment method, Apple Account identity, billing address, purchase history, tax and region never enter ScrollShot's code.

The only purchase-derived values the app ever sees are the localised price string, which is displayed and not stored, and, for each entitlement, four fields: the product identifier, whether Apple's signature check passed, a revocation date and an expiry date. Those are held in memory and are never written to disk. Subscription status is re-asked of the App Store on every launch rather than cached. The app attaches no account token to a purchase, so nothing links a purchase to any record on the app's side — and there is no record on the app's side. A transaction that fails Apple's verification never grants access, even after a successful payment sheet.

The Restore button on the paywall asks the App Store to sync and then re-reads your entitlements. Apple may ask for your Apple Account password during that; the app never sees those credentials.

Cancellation, refunds and subscription management are entirely Apple's. The app has no manage-subscriptions screen and no refund request. To cancel or change a subscription, go to Settings, then your Apple Account, then Subscriptions. Refunds are requested from Apple.

Requests about your data

There is no server holding anything about you, so there is nothing for the provider to retrieve, correct or delete on request. The data the app creates is on your device, under your control: deleting the app removes the temporary media and the preferences described above.

Children

ScrollShot has no account and no sign-in, asks nothing about who you are or how old you are, and sends nothing about any user anywhere. It collects no personal information from anyone, of any age. Purchases go through Apple, under the Apple Account signed in on the device.

Changes to this policy

If the app changes in a way that affects what is written here, this document is updated and the effective date at the top changes. Because there is no account and no mailing list, there is no way to notify you directly; the current version is the one published here.

Contact

Questions about this policy, or about anything in the app, go to bladeytmail@gmail.com. That is the only contact method; the support page simply points at the same address.

Effective date

16 September 2026