Why We Built Pressbook: Private Photo Albums Without the Cloud

Open the App Store and scroll the privacy nutrition 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: diagnostics, third-party advertising, audience inference. The disclosures are detailed. The defaults are lenient. What it adds up to, across the apps you actually open every day, is a quiet inventory of your life that a few dozen ad networks know better than you do.

A 2024 Oxford Internet Institute study found that 87% of apps share user data with third parties. That number 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 was an answer to a particular set of pressures: cloud was getting cheaper, machine learning needed server-side compute, advertising revenue made free tiers possible. None of those pressures had anything to do with the people using the apps. They were about engineering convenience and business-model viability.

Users went along with it because the trade-off was opaque. Nobody knows what their location history is worth on a third-party data exchange. Nobody can audit what an analytics SDK actually emits. Nobody reads four thousand words of privacy policy before tapping "I agree."

The cost became visible in batches. Health data sold to insurers. Period-tracker data subpoenaed in criminal cases. Photo libraries quietly ingested into training sets. Session-replay tools recording typed-but-deleted text on banking forms. Each of these wasn't an exception. 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. Not because we'd never benefited from cloud-first defaults (every engineer here has), but because the asymmetry was getting worse. Apps were getting more useful. The data leaving them was getting more granular. The recourse, if any of it spilled, kept getting weaker.

The conviction: software that respects you

The phrase 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. Zero data collection. No analytics SDKs. No ad networks. No required accounts. No telemetry pings. The starting position is that nothing about you leaves your device, and any deviation from that has to justify itself against a hard-coded baseline of no.

Evidence-based design. Where a feature touches behavior, decisions, or wellbeing, we ground it in published research and validate it through structured user testing. The shape of BloomWell's pelvic-floor curriculum, for instance, is anchored to the duration described in NICE guidance for programs of this kind, not a number a marketing meeting picked.

Human-centered. We design for people who don't have the time or the technical literacy to audit an app's data practices. Accessibility (VoiceOver, Dynamic Type, reduced motion, color contrast) is built in from the first commit, not added during a pre-launch sprint.

Craft and quality. We ship fewer products on purpose. We work on a small slate of apps at a time, not a sprawl of side projects. Every interaction reviewed, every animation tuned, every typeface chosen against a list of alternatives. The output is slower. The output is also denser.

Those four are the pillars. Every product decision either reinforces them or breaks them. There is no middle ground because there is 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 zero-server. Not "secure servers." Not "encrypted at rest." Not "we delete logs after thirty days." No servers in the path of your data at all. Today our apps run on Apple platforms. Compute runs on the Neural Engine and GPU you've already paid for. On iOS, storage lives in the sandbox under FileProtectionType.complete: when your phone is locked, the files are unreadable to other apps, to file-system tools, and to forensic recovery without your passcode.

This makes some things harder. We can't push a server-side fix when a model misbehaves; we ship an OS-cycle update. We can't sync your work across devices through a backend we control; we hand off to whichever service you already use: iCloud Drive, AirDrop, Files. We can't run A/B tests on your behavior to optimize a funnel; we test internally, ship, and listen to feedback through email.

It also makes some things impossible by construction. We can't sell what we never collect. We can't be subpoenaed for the things you store in our apps because they never reached us. We can't have a breach affecting users because there's nothing on a server to breach. The privacy guarantees aren't promises we'd have to keep: they're properties of a system that physically can't violate them.

The cryptographic layer underneath is iOS Data Protection at FileProtectionType.complete, the strongest tier Apple ships. We didn't write that; Apple did. We opted every file our apps write into the strongest available tier. Trust the people who've spent decades on cryptography; don't reinvent.

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 selection rule: pick a category where the cloud-first default has done quiet damage to the people who use it, then rebuild the category with privacy as the architecture rather than the disclaimer.

The first two implementations of that pattern are already in market.

Pressbook, our photo album creator, ships in a category that usually expects you to upload your camera roll for AI curation, layout, and printing. We do all of that on the device. Apple's Vision framework runs locally. Our scoring formulas combine those signals locally. Our layout engine assembles 249 layouts locally. Our PDF exporter produces a 600 DPI print-ready file locally. Your photos never leave. The album is ready in roughly two minutes for two hundred photos. There is no cloud you have to trust because there is no cloud in the path. Start an album, a carousel, or a collage.

BloomWell, our upcoming women's wellness app, is being built around pelvic-floor training, cycle tracking, Ayurvedic nutrition, and postpartum and menopause support: categories where the cloud-first default has been most visibly damaging. Reproductive cycle data has shown up in court records, insurance underwriting, and ad targeting. BloomWell follows the same architecture as Pressbook: data stays in the device sandbox, encrypted on disk, with predictions computed locally. No required account. No server sync. The Apple Watch companion is being built the same way.

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. Each of those is a candidate. The architectural posture stays the same on day one of every project we begin. Privacy by default isn't a feature we add at the end. It's the line at the top of the file.

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 iOS 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, not from a marketing landing page. Where something costs money, we say so plainly: on the screen where you'd reach for it, not in fine print at checkout.

We don't run user analytics by default. Where any of our apps ship an optional funnel-telemetry path, the consent gate defaults to off and the carrier is anonymized at every layer: anonymous IDs only, file paths and identifiers stripped before send, every auto-capture surface (session replay, screen tracking, swizzling) disabled. We collect a small set of explicit funnel events from people who opted in. That's all.

We don't optimize for time-on-app. We optimize for finished work. An album that gets exported is a success. A workout that gets completed is a success. The metric is whether the user got the thing they came for, not whether we kept their 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 subpoenas, 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. Not because they're cheap to build (they aren't), but because the alternative has aged badly.

If you want to see what that looks like running on a phone, Pressbook is live today: the product site is pressbook.app, the app is on the App Store, and how-tos live in the Pressbook journal. Pricing is $0 to start, with Pro at $4.99 a month, $29.99 a year, or $79.99 lifetime. Support answers product questions. BloomWell is up next. The apps after them will run on the same conviction: different categories, same architectural baseline, same refusal to extract from the people using them.

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.