Holdboard

Why Holdboard was built

Holdboard started from a repeat pain in real work sessions: copied content is temporary, but tasks are not. During debugging, payments, support chats, and content writing, I needed more than one active clip. iOS clipboard behavior is intentionally simple, so critical items like OTPs and links were frequently lost when I copied the next item. I built Holdboard to solve this gap with a product that feels quick during normal typing, but reliable and private when content is sensitive.

• Primary goal: preserve useful copied content across rapid context switching.
• Product goal: reduce tap count between copy, organize, and reuse operations.
• Security goal: protect sensitive entries without degrading common flows.

App workflow

The app is designed as a loop users repeat all day, not as a one-time archive. Every step optimizes for fast return-to-task behavior.

• Capture: user copies content, then opens Holdboard app or keyboard extension to save it intentionally.
• Normalize: clip is converted into a consistent model (type, source, timestamp, metadata).
• Classify: clip is assigned to group/tag so retrieval remains predictable at scale.
• Protect: users can lock entries behind Face ID and separate private from regular clips.
• Retrieve: from keyboard or app, user pastes/copies instantly with minimal context switching.
• Retain/Clean: optional auto-delete policies remove stale clips and keep vault quality high.

Architecture overview

Holdboard is intentionally split into small modules so each responsibility is isolated and easier to harden. This reduced regression risk while iterating quickly.

• Main App module: library view, tagging, edit/delete actions, settings, Face ID gate, and retention controls.
• Keyboard Extension module: low-latency list rendering, quick search/filter, and immediate paste/copy actions.
• Storage module: normalized clip schema, duplicate detection, ordering, and policy-based expiry.
• Security module: lock state transitions, protected action checks, and sensitive-surface masking.
• Sync boundary: app and keyboard share only necessary data paths to reduce accidental leak/overexposure.

Main challenge: keyboard extension

The keyboard extension was the hardest engineering area. It runs in a constrained environment where users still expect instant response. Any delay feels broken because this happens mid-typing.

• Runtime constraints: tighter memory/time limits than the full app made heavy UI/state patterns unsafe.
• State handoff: app-to-keyboard communication required strict boundaries to avoid stale or inconsistent data.
• UX pressure: retrieval had to be near-instant even with large clip history.
• Privacy pressure: sensitive clips needed guardrails without interrupting every normal action.

GIF support and richer media handling

After stabilizing text-first workflows, I implemented GIF/media support. This looked simple in UI, but required repeated fixes around rendering and payload handling in keyboard context.

• Rendering consistency issues appeared across different source apps and paste targets.
• Preview behavior needed fallback logic when full media rendering was not reliable.
• Insertion reliability required multiple passes to prevent partial/failed paste outcomes.

Auto-delete logic: repeated bug-fix cycles

Auto-delete looked straightforward but became one of the most iterative systems. Early logic removed clips in edge cases where users expected retention.

• Initial bug class: expiry and manual actions collided, causing unexpected removals.
• Second bug class: ordering/race issues created inconsistent cleanup timing.
• Fix approach: separate retention evaluation from UI mutation path and revalidate before delete.
• Result: predictable retention behavior with lower risk of accidental loss.

Background limits and App Store constraints

A core constraint is platform policy. Continuous, always-on clipboard background behavior is not a safe shipping strategy for App Store review. Product design had to align with acceptable iOS behavior from day one.

• The app does not attempt permanent background clipboard monitoring.
• Capture is intentionally user-driven: open app or keyboard to save/manage clips.
• This keeps the feature set policy-safe and lowers rejection risk.
• Tradeoff accepted: slightly more explicit user action in exchange for reliable, shippable behavior.

Build outcome

Holdboard shipped as a keyboard-first clipboard system focused on practical reliability: fast retrieval, explicit capture, and strong privacy boundaries. Instead of overpromising impossible background behavior, the product is scoped around what iOS supports consistently and what can pass review safely. That scope made the app stable enough for real daily use.