Skip to content

Personal context app (iOS) — “mini Cursor / Crusty” for life

Field Value
Status Idea / exploratory — not in the 90-day focus window
Type Product concept (native iOS) + personal knowledge / memory layer

Working names: Context · LocalMind (either could ship; wiki page slug stays personal-context-ios).

Elevator pitch (2026)

All your notes live in a simple local Markdown folder on your phone. You talk or type; the app retrieves only the relevant files into the prompt. Apple's on‑device model is the default so routine use never phones home. One tap escalates to Grok, Claude, or your own API key when you need a richer answer — and shows exactly what context is being sent before anything hits the cloud. Optional sync with the main wiki over iCloud (same folder-of-markdown discipline as projects/personal-projects-wiki, with merge/conflict hygiene TBD).

Description

A personal context layer you carry on the phone: structured, client-side markdown (e.g. soul.md, memory.md, preferences, wiki-shaped notes — the same kind of ground-truth files projects/crusty and Cursor skills assume, but yours, editable locally).

The app behaves as a memory manager on top of any LLM: it keeps an organized, editable personal wiki, then injects only relevant chunks into each prompt instead of relying on plain chat history. That lands more deliberate memory control than “hope the model remembers” or endless threads.

Positioning: Cursor, but for your whole life — conversation and memory first, not a code tree. (Cursor’s UX is optimized for repositories; a dedicated client can be tuned for dialogue + diffs to markdown + retrieval.) Super simple, privacy‑first, and it benefits automatically as Apple improves on‑device models (see also Platform risk in Open questions).

Strategic caveat (2026-05-01): this is interesting precisely because it might be an app-as-trust-surface (owned files, local storage, voice capture, human-gated edits, retrieval into arbitrary models), but it is also the iOS idea most exposed to Apple Intelligence / OS-level assistant improvements. If Apple solves generic phone memory and personalization, the remaining differentiated wedge is narrower: canonical user-owned markdown, BYOK / multi-provider choice, explicit retrieval controls, and approved edits back to files that also serve Cursor on the Mac.

Darcy’s immediate friction (why it surfaced)

  • MacBook: this wiki and AGENTS.md / rules are maintained in Cursor on the main machine (projects/personal-projects-wiki, projects/llm-maintained-context).
  • Phone / car: conversation often happens in Grok (or another provider) without the repo attached.
  • Gap: no good way today to update the same canonical markdown from mobile voice/chat so the next Cursor session and the next Grok thread stay aligned.

This app would close the loop: talk on the phone → model proposes edits → you approve → files on disk / in sync reflect the new truth.

Core product thesis (generalizable)

  1. User-paid intelligence: sign in with your own API keys and/or provider subscription you already pay for — no inference bill for the app author; optional paid tier could be sync/features only.
  2. Structured memory: wiki- or vault-shaped markdown with clear pages (identity, preferences, open loops, project notes).
  3. Retrieval, not dump: choose or automate which slices go into each turn (like rules + @-mentions, but for life context).
  4. Model choice: user picks backend; on-device Apple model (as available) flagged as the best default for privacy for sensitive slices or offline pass.

Trust posture — private context firewall

The likely wedge is not "send your deepest medical / relationship history to model APIs." Many users will not want that, and they are right to hesitate. The stronger posture is: the app stores raw personal context locally, lets the user classify sensitivity, and sends only the minimum deliberate context needed for a given task.

The app is a private context firewall:

  1. Store raw notes / markdown locally.
  2. Classify sensitivity by page or snippet.
  3. Retrieve only the minimum useful context.
  4. Show exactly what will be sent to the model.
  5. Prefer on-device models for private summarization and redaction.
  6. Send only approved summaries or selected snippets to external providers.

Examples: not "send my full medical history," but "send my current dietary constraints and exercise limitations." Not "send relationship history," but "remind me I prefer low-conflict wording and want to avoid escalating." Distrust of model providers becomes part of the value proposition: the app mediates what leaves the phone.

Use cases (Darcy)

  • Day design + balance nudges: Store how I want days to look (time blocks, non-negotiables, energy budget, band / training / deep-work mix) in structured markdown the app always retrieves. On check-in or end-of-day review, compare intent vs recent reality (manual tags, calendar hints, or “what actually happened” notes in the wiki) and surface drift — e.g. “You wanted X hours for Y; last week skewed Z” — without turning into a nagging productivity app. Optional gentle reminders when the pattern says I’m out of balance relative to my own stated norms (not employer metrics).
  • Daily prioritization aligned to goals / What-Im-Working-On: When I ask “what matters today?”, the app injects the right slices (north-star, focus window, top waypoints, explicit not-priorities) so the model’s answer grounds in the wiki instead of vibes. Same pattern as Cursor rules + project files: retrieve goals → answer → optionally propose wiki edits if priorities legitimately shifted.

General use cases beyond project wikis

  • Preference memory for everyday recommendations: food constraints, travel style, shopping preferences, music / media taste, family logistics, and "do not suggest this again" notes. Personal enough to improve answers, but usually less sensitive than raw medical or relationship history.
  • Decision journal / values layer: prior choices, tradeoffs, and "why I decided this last time" for career moves, major purchases, house projects, fitness plans, and creative priorities.
  • Life admin memory: home maintenance, subscriptions, insurance notes, car records, school schedules, pet care, gift ideas, and recurring vendors — useful context that is annoying to re-explain but not necessarily intimate.
  • Coaching memory: training goals, diet preferences, habit patterns, sleep / energy notes, and self-reported constraints. Adjacent to projects/happy-body, but kept summary-level unless the user explicitly approves more.
  • Conversation prep: briefings before calls with a contractor, doctor, teacher, client, friend, or family member: what happened last time, what matters, and what to ask next.
  • Portable prompt profile: a user-owned "how to work with me" file that follows the person across Grok, ChatGPT, Claude, Gemini, Cursor, and future providers — tone, goals, constraints, current priorities, preferred formats.
  • Capture inbox for future context: voice memo in the car → transcription → model proposes whether it updates a project, preference, decision, task, or memory file → user approves the file edit.

Prototype path (before a native ship)

Ship a discipline layer today with tools you already have:

  • Open this repo (or a copy) in Cursor with wiki/ as the project.
  • Rules / AGENTS that tell the agent how to pull context, propose patches, and respect SCHEMA.md.

That validates retrieval + edit workflows without App Store scope; the native iOS shell adds mobile capture, offline-first markdown, and a conversation UI that Cursor will not optimize for.

Business model / API cost

API-cost passthrough is an unresolved product-shape risk. If the app author resells inference, the product inherits metering, abuse prevention, margin risk, customer support for usage surprises, and App Store subscription economics. Default v1 should avoid owning variable inference cost.

Recommended MVP order:

  1. Local-first / Apple Intelligence-first. On-device model handles capture cleanup, classification, summarization, redaction, sensitivity labeling, and draft file edits where possible. External APIs are optional. This is the best first MVP because it strengthens the privacy story, minimizes variable cost, and tests whether the app is valuable as a context manager before adding hosted intelligence.
  2. BYOK / power-user mode. User stores their own provider keys in Keychain and pays OpenAI / xAI / Anthropic / etc. directly. The app charges for local storage, retrieval UX, sensitivity controls, sync, and approved file-edit workflows — not raw inference. This is likely acceptable for builders, consultants, coaches, founders, and other prosumers before it is acceptable for mainstream consumers.
  3. Provider-subscription passthrough / prompt packaging. The app prepares context packages for use in the user's existing ChatGPT / Grok / Claude / Gemini workflow, or routes through whatever first-party app / subscription the user already pays for. Lower integration, but no API-billing liability.
  4. Limited included credits (later only). Paid app or subscription includes a capped monthly usage bucket. This is the normal consumer shape but should wait until there is real usage data, because it makes the app responsible for inference cost, quota design, fraud, support, and margins.

Business-model default: do not become an inference reseller in v1. Ship local-first + optional BYOK; add hosted inference only if usage proves the retrieval / firewall workflow is valuable enough to justify the operational complexity.

Auth / keys (research note)

BYOK is straightforward ethically and technically: user pastes or stores keys in the Keychain, calls providers from their account.

Third-party “Sign in with OpenAI”-style flows are messy: there is no clean, official OAuth surface from OpenAI aimed at general third-party chat clients the way some other stacks expose. Community approaches that harvest session tokens sit in a gray area (ToS, rotation, user trust). Default product stance captured here: prefer explicit BYOK + first-party app API keys; treat unofficial token bridges as out of scope until a provider blesses a path.

Open questions

  • Naming / App Store: Context is short but collision-prone with system UI; LocalMind is more distinctive — pick after trademark / search checks.
  • Sync: iCloud Drive / Git / working copy vs merge conflicts when Cursor and phone both edit.
  • Voice: STT pipeline on-device vs provider; car-mode safety.
  • Ground-truth: human-gate every file change vs low-risk auto-apply for log.md-style entries.
  • Balance signal: what counts as “out of balance” — pure self-report vs calendar integration vs structured weekly review only.
  • Platform risk: which parts are obviated by Apple Intelligence / first-party OS memory, and which parts remain defensible because the app owns explicit markdown, retrieval, BYOK, and approved file edits?

Raw sources

  • (This page — conversation capture 2026-05-01; use cases 2026-05-01; pitch + names 2026-01-31.)