Packboard

Inspiration

Repeated work rarely fits in one clipboard item. An app launch, sponsor reply, client handoff, or support response combines text, links, screenshots, and documents scattered across multiple apps. Packboard turns that working set into a reusable object while keeping it local and private by default.

What it does

Packboard organizes reusable text, links, images, and files into focused Packs. Users can capture material inside the app or from another app's Share Sheet, search locally, copy text and links with clear feedback, export files and images, and reach trusted snippets from a keyboard that does not request Full Access.

Sharing is deliberately different from syncing a private library. A user chooses the exact items that may leave the device, reviews the outbound payload, and publishes an unlisted web preview. A recipient can inspect that preview before opening Packboard and import the Pack without duplicating an already imported revision. The publisher can unpublish the Pack and remove its hosted assets.

The free tier completes the core loop. Packboard Pro uses RevenueCat to unlock higher local and hosted-Pack limits, with localized App Store terms, Restore Purchases, and Customer Center.

Version 1.2 adds role-based starter workflows, a private Quick Reuse widget and App Intent for explicitly chosen favorites, QR campaign cards, a private single-use post-install public-Pack handoff, followed-Pack update previews with a preserve-local-copy choice, and clearer value-based Pro explanations. Local save, search, and reuse still work offline without an account.

How we built it

Packboard is a native SwiftUI iPhone app with a Share extension and a closed-access keyboard extension. The three targets coordinate through an App Group using locked, atomic local storage. Assets are digest-checked, while private deletion and publishing credentials stay in Keychain rather than the shared container.

Public Packs use a versioned JSON contract and a Cloudflare Worker backed by KV, R2, rate limits, Workers AI safety checks, and strongly consistent Durable Objects. Publication follows private draft → verified asset upload → explicit activation. Public rendering escapes content and applies restrictive browser security headers. Unpublishing removes the public manifest and assets and permanently tombstones that public identifier.

RevenueCat and RevenueCatUI provide the purchase and entitlement layer. A Release build fails closed without its approved Apple public SDK key. New premium access requires a trusted active pro entitlement, while a network failure never blocks the free local library.

Challenges we ran into

The first hard problem was making three Apple processes behave like one reliable local product without weakening the keyboard's privacy boundary. The main app and Share extension can write, while the keyboard stays read-only and useful with Full Access disabled. Cross-process locks, atomic replacement, a last-valid backup, and storage-generation checks prevent an old process from resurrecting data after local erasure.

Publishing created a second trust boundary. Explicit selection had to be real while the system handled interrupted uploads, duplicate retries, unsupported formats, objectionable content, asset integrity, safety reports, publisher blocking, unpublish races, and stolen or expired credentials. A staged protocol, strict schemas, fail-closed screening, opaque publisher identities, idempotency records, quotas, owner credentials, and permanent tombstones turned that boundary into testable behavior.

The third challenge was honest evidence. A preview request is not a person, an App Store button request is not an install, an opt-in reporting installation is not every user, and an on-device catalog price is not booked revenue. We keep those definitions separate so the growth story remains reproducible.

Accomplishments that we're proud of

The private library works without an account or network. The keyboard inserts saved text and links without requesting Full Access or recording keystrokes. Public sharing requires explicit item selection and a final outbound preview. Supported public content is screened before activation; an unavailable or inconclusive scanner keeps the Pack private. Every public Pack exposes fixed-reason reporting and Community Standards. Unpublish removes hosted assets and blocks identifier replay. RevenueCat purchase, restore, trusted entitlement, Paywall, and Customer Center paths have no debug or stale-state Release back door. Accessibility and quality are covered across unit, integration, and device-level UI journeys.

What we learned

A reusable item is helpful, but a reusable working set is the durable unit of value. The best first-run experience starts with a complete Pack that can be duplicated and adapted rather than an empty database or a tutorial.

Privacy also became a product interaction rather than a policy paragraph: choose the items, inspect exactly what will leave the device, publish, then retain an obvious unpublish control.

Instrumentation needs product semantics before it needs a dashboard. Separating store installs, opt-in product behavior, Pack-scoped recipient behavior, raw web requests, and transactions prevents attractive but unsupported conversion claims.

What's next

During judging we will keep the released app, purchase and restore path, public Pack service, policy pages, and judge access stable. Product changes will be driven by measured activation, repeat reuse, retention, Pack sharing, and real RevenueCat revenue.

Built With

• cloudflare-kv
• cloudflare-r2
• cloudflare-workers
• durable-objects
• revenuecat
• revenuecatui
• storekit-2
• swift
• swiftui
• typescript
• uikit
• vitest
• workers-ai
• xctest
• xcuitest