Skip to content

docs(planning): Atomic Launcher — SearchLauncher × Atomic merge - #1252

Draft
joepio wants to merge 4 commits into
developfrom
cursor/atomic-launcher-merge-plan-f470
Draft

docs(planning): Atomic Launcher — SearchLauncher × Atomic merge#1252
joepio wants to merge 4 commits into
developfrom
cursor/atomic-launcher-merge-plan-f470

Conversation

@joepio

@joepio joepio commented Aug 3, 2026

Copy link
Copy Markdown
Member

Summary

Exploration plan for Atomic Launcher: SearchLauncher × Atomic.

Full write-up: planning/atomic-launcher.md

Core clarification (HOME ≠ merge)

Intents/Binder already get ~80%: search + todo get bread at the home bar while SearchLauncher stays HOME and Atomic is a separate host APK (android-data-reuse).

What owning HOME uniquely buys (no Atomic APK can polish into existence):

  • Default destination / zero invocation tax
  • Own empty home (widgets, favorites, gestures)
  • Hot process + natural store-host lifecycle
  • Stacked system roles (HOME + browser)
  • Launcher-plausible permissions (QUERY_ALL_PACKAGES, etc.)

What one-APK embed still buys over Binder (the other ~20%):

  • No second install / pairing / grant UX
  • Keystroke latency (one heap)
  • Browser ↔ graph with zero seam
  • Uninstall/backup atomicity; one default stack; trivial host election

Path: keep SearchLauncher as HOME → validate with Binder client (A) → embed atomic_lib in the launcher (B) when onboarding/latency/identity hurt → rebrand (C) later.

No runtime code — planning only.

Open in Web Open in Cursor 

cursoragent and others added 4 commits August 3, 2026 16:22
Map how the Kotlin SearchLauncher shell and Atomic's Rust data plane
can merge: uniffi/Android host (not Flutter rewrite), unified search
projection, quick-create verbs, and a phased path from HTTP spike to
Binder-backed on-device node.

Co-authored-by: Joep Meindertsma <joep@ontola.io>
Add presentation layers: compact search rows, favorites pins, optional
ambient peek, AppWidgets, and a warm data-browser PWA shell so Atomic
tables/docs/chats feel like first-class apps without a Compose rewrite.

Co-authored-by: Joep Meindertsma <joep@ontola.io>
Capture + unified find at the home bar are the merge's unique payoff;
rich editing can stay an app. Add a decision test so we don't merge for
wallpaper/widgets vanity.

Co-authored-by: Joep Meindertsma <joep@ontola.io>
Intents/Binder already deliver ~80% (search + create at the home bar).
Spell out what owning HOME uniquely buys vs a normal Atomic app, and
what one-APK embed still buys over a two-APK API client — so we don't
merge for the wrong reasons.

Co-authored-by: Joep Meindertsma <joep@ontola.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants