Why we built SideSwipe Labs: apps that don't need to know who you are

Open the App Store and scroll the privacy labels of any ten apps you use. The pattern repeats. Data Linked to You: usage, identifiers, location, sometimes contacts and health. Data Used to Track You: identifiers and usage, linked with other companies' data for advertising. The disclosures are detailed. The defaults are lenient. Across the apps you open every day, they add up to a quiet inventory of your life that a few dozen ad networks know better than you do.
In 2018, researchers at Oxford studied 959,000 Android apps and found third-party tracking in most of them. About 88% could send data to companies owned by Google's parent, Alphabet. That pattern is the reason SideSwipe Labs exists.

The default became the problem
For most of the last decade, the developer playbook was simple: ship fast, instrument everything, monetize later. Analytics SDKs were a free upgrade. Authentication required an email address. A privacy policy was a legal asset, not a product decision. The apps that grew the fastest were the ones that collected the most.
That stack answered a particular set of pressures: cloud was getting cheaper, machine learning needed server-side compute, and advertising made free tiers possible. None of those pressures had much to do with the people using the apps. They were about engineering convenience and business models.
People went along with it because the trade-off was hard to see. Nobody knows what their location history is worth on a data exchange. Nobody can audit what an analytics SDK sends. Nobody reads four thousand words of privacy policy before tapping "I agree."
The cost became visible in batches. A period tracker that the US Federal Trade Commission said had shared its users' health data with Facebook and Google, after promising to keep it private. A photo storage app that, the FTC said, ran facial recognition on its users' photos by default for most of them, and used their photos to build that technology. A fertility app the FTC charged with sharing health data without telling its users. None of these were exceptions. They were what the architecture allowed, because the architecture was never built to refuse.
We started SideSwipe Labs because we didn't want to ship into that pattern. We've benefited from cloud-first defaults ourselves, but the asymmetry kept getting worse. Apps were getting more useful. The data leaving them was getting more detailed. The recourse, if any of it spilled, kept getting weaker.
The conviction: software that respects you
The line on our homepage is the shortest version: software that respects you. The longer version is operational. We make four commitments and build everything else on top of them.
Privacy by default. No account to make, no ads, and no server of ours that holds your photos or your logs. Where an app has analytics at all, it starts off. The starting position is that nothing about you leaves your device, and any exception has to justify itself against a default of no.
Evidence-based design. Where a feature touches behavior or wellbeing, we ground it in published research and test it with people. Fia's pelvic-floor journey, for instance, is built around the duration in NICE guidance, not a number a marketing meeting picked, and its guidance cites 317 published sources, every one listed in the app.
Human-centered. We design for people who don't have the time or the technical background to audit an app's data practices. Accessibility (VoiceOver, Dynamic Type, reduced motion, color contrast) is part of the work from the first commit, not a pre-launch sprint.
Craft and quality. We ship fewer products on purpose and work on a small slate of apps at a time. Every interaction is reviewed, every animation tuned, every typeface chosen against alternatives. The output is slower. It's also denser.
Every product decision either reinforces these four or breaks them. There's no middle ground, because there's nothing else for us to optimize for.
Privacy as architecture, not as a marketing claim
Privacy as a marketing line is cheap. Privacy as an architecture is a constraint that shapes the rest of the codebase.
We chose to keep our servers out of the path of your data entirely, rather than promise secure servers, encryption at rest, or logs deleted after thirty days. Our apps run on Apple platforms, and the work happens on the chips you already own: Pressbook's photo curation, Graycard's color engine and Auto-cull, Fia's period predictions. On iPhone and iPad, what our apps store lives in the app's sandbox, encrypted by Apple's Data Protection with keys tied to your passcode. We didn't write that encryption, and we didn't want to. Trust the people who've spent decades on cryptography; don't reinvent it.
This makes some things harder. We can't push a server-side fix when something misbehaves; we ship an update. We can't sync your work through a backend of ours, so when you share, it goes through your own iCloud: Pressbook's circles, Fia's partner sharing. We can't run experiments on your behavior to tune a funnel; we test with people before we ship, and listen to email after.
It also makes some things impossible by construction. We can't sell photos or health logs we never receive. We can't hand over what you keep in our apps, because it never reached us. And a breach of anything we run can't expose your photos or your cycle, because they were never there.
The privacy guarantees aren't promises we'd have to keep: they're properties of a system that physically can't violate them.
The pattern
Every app the studio builds follows the same rule: pick a category where the cloud-first default has done quiet damage to the people who use it, then rebuild it with privacy as the architecture rather than the disclaimer. Three apps follow that rule so far.
Pressbook, our photo album maker, ships in a category that usually expects you to upload your camera roll for curation, layout and printing. Pressbook does all of that on the device: Apple's Vision framework runs there, every one of its 259 layouts is built there, and albums export as print-ready PDFs up to 600 DPI. When you share, it goes through your own iCloud, to the people you invite. Start an album, a carousel or a collage.
Graycard, our RAW photo converter for Mac, ships in a category where finishing a whole shoot has meant a library to import into, a subscription, or skills most camera owners don't have. Graycard reads the photos where they are, sets aside the misses, finishes the color with its own engine on the Mac, and exports the whole shoot ready to share. Nothing is uploaded. Why we built Graycard.
Fia, our period tracker with guided kegels, ships in a category where the cloud-first default has done visible damage. Fia keeps your logs on your iPhone, works out your next period on the device, and has no account, no ads and no analytics: its App Store label says Data Not Collected. Fia was called BloomWell while we built it. Why we built Fia.
The categories will keep changing. There are plenty of corners of the App Store where the cloud-first default has produced something people would refuse if they could see it clearly: finance, journaling, kids' apps, productivity tools that send back more than they need to. The architecture stays the same on day one of every project. Privacy by default goes at the top of the file, before the first feature.
What we don't do
A studio is also defined by what it refuses.
We don't run growth-hacked acquisition loops. No deceptive paywalls, no five-step cancellation flows, no "are you sure?" guilt screens between you and the unsubscribe button. Cancellation lives where Apple puts it: in Settings, under Subscriptions.
We don't engineer paywalls to feel like surprises. Every app we ship has a free tier large enough to judge the work from inside the app. Where something costs money, we say so plainly, on the screen where you'd reach for it.
We don't run analytics by default. In Pressbook and Graycard, analytics is a switch that starts off; turn it on and anonymized events go to PostHog in the EU, never your photos or file names. Fia has none at all. Why Fia has no analytics, and our other apps ask first.
We don't optimize for time in the app. We optimize for finished work: an exported album, a shared shoot, a finished session. The measure is whether you got what you came for, not whether we kept your attention for another minute.
The bet
The bet underneath all of this is that the user contract has shifted. Ten years ago, "free with ads" was acceptable because the costs were invisible. Today the costs are visible (in breaches, in lawsuits, in the ambient sense that everything you tap is being watched), and the willingness to be the product is wearing thin. People will pay for software that doesn't extract from them. Not everyone, not at every price, but enough.
We're betting that craft, evidence-based design, and a privacy posture that's structural rather than promotional are durable advantages. They aren't cheap to build, and the alternative has aged badly.
See it for yourself
All three apps are free to start, with no account:
- Pressbook on the App Store, for iPhone, iPad and Mac.
- Graycard on the Mac App Store, for macOS 26 or later.
- Fia on the App Store, for iPhone and iPad, with an Apple Watch app.
How to check what an app does with your data shows how to test all of this on any app, and what you should see when you test ours.
We don't want to know who you are. The simplest privacy guarantee is the one you don't have to read a policy to verify.

