Library Shelf is a single trusted iPhone app that lets a user create, collect, run, revise, and share small hyper-personalized mini apps. The goal is not to recreate the public App Store inside an app. The goal is to give each user a private shelf of lightweight tools that solve narrow personal needs, run inside one host app, and can be remixed safely over time.
The motivating idea is extremely personalized software: software with an audience of one, a household, a small team, or a niche community. These tools do not need to satisfy a broad market, support every possible preference, or become standalone products. They need to fit the user’s exact context, data, habits, devices, and taste.
Library Shelf should make personal software feel as easy to create and maintain as a note, shortcut, or saved document, while still giving it enough structure to behave like an app.
Most software today is built for markets. Hyper-personalized software is built for situations.
A person may want a tiny tool for a very specific job:
- a radio dial with exactly the stations they care about
- a kitchen timer that matches their cooking style
- a travel checklist for one family trip
- a home camera wall for their exact rooms
- a personal reading queue that matches their own tagging habits
- a clock, dashboard, or ambient display for an old device on a shelf
- a research capture tool for one project
- a tiny CRM for a handful of relationships
These apps are too small, too personal, or too idiosyncratic to justify normal product development. They are also often more useful than general-purpose commercial software because they can ignore everyone else’s requirements.
Library Shelf exists to make these tiny applications easy to create, keep, improve, and trust.
Library Shelf is a host app with a personal library of mini apps. A mini app is a self-contained experience that runs within the host app and is managed by the host app. The user should experience each mini app as a real tool with a name, icon, screenshots, state, permissions, history, and versioning.
The host app provides the stable foundation:
- identity and account state
- personal app library
- creation and remix flows
- app metadata
- permissions and privacy controls
- storage boundaries
- version history
- safety checks
- backup and sync options
- sharing and import/export flows
- observability and debugging views
The mini apps provide the personalized experiences:
- small workflows
- dashboards
- utilities
- media tools
- local data views
- personal displays
- domain-specific interfaces
- single-purpose automations
The host app should feel like a personal software shelf, not a public marketplace. Words like “library,” “shelf,” “workshop,” “gallery,” “tools,” “recipes,” and “remixes” are closer to the desired shape than “store.”
Library Shelf should build on the same broad pattern as CodexMobile: a native host app with a local chat interface and a bundled Codex runtime that can drive creation workflows from inside the app. The product should feel like chatting with a builder that understands the user’s personal app shelf, current mini apps, templates, screenshots, permissions, and revision history.
At a high level, the host app should include:
- a Codex chat interface for creating and revising mini apps
- a cross-compiled Codex binary bundled with the app, similar in spirit to the CodexMobile implementation
- a Codex login flow so users can authenticate with their own Codex account
- bundled local skills focused on mini-app creation, remixing, testing, repair, permissions, and gallery packaging
- a runtime model for mini apps that keeps them inside Library Shelf rather than installing them as separate native apps
- a local app library that stores mini app metadata, screenshots, versions, and user-facing state
The bundled skills are central to the product. They should teach Codex how to create mini apps for the Library Shelf environment: ask clarifying questions only when necessary, infer a narrow first version, generate a useful preview, respect host-app permissions, create icons and screenshots, write clear metadata, and produce a remixable artifact. A future implementation can decide the exact mini-app runtime and storage model, but the product should treat skills as first-class packaged product knowledge rather than hidden prompts.
The login flow should make the relationship between Library Shelf and Codex understandable. Users should know when they are signing into Codex, what capabilities that enables, and how generated app creation uses their account. The product should also have graceful states for logged out, expired session, limited mode, and account errors.
The product should be designed as a safe single-app mini-app system rather than a mechanism for installing arbitrary native iOS apps.
The product should avoid patterns that look like bypassing platform app distribution. It should not present itself as an alternative native app store for iPhone apps. It should not frame mini apps as separately installed native apps. It should make clear that mini apps run inside Library Shelf and are governed by Library Shelf’s safety, privacy, and review model.
The long-term strategy can include paths for generated mini apps to graduate into native apps through appropriate channels, but the initial product should focus on the safest and most broadly distributable shape: a trusted host app with personalized mini apps inside it.
People who enjoy shaping their own tools and want software that fits their personal workflow. They may be technical, semi-technical, or simply willing to prompt and iterate.
Needs:
- fast creation
- remixable templates
- control over data
- local-first behavior where possible
- simple debugging
- version history
- the ability to keep tools private
People who already glue together tools, automations, spreadsheets, dashboards, and notes.
Needs:
- structured data sources
- dependable execution
- clear permissions
- reusable templates
- device-specific views
- lightweight maintenance
- integrations with existing workflows
Groups of 2-10 people who want small tools for coordination.
Needs:
- shared mini apps
- simple roles
- shared data
- auditability
- comments or change requests
- safe collaboration
People who create useful starting points for others.
Needs:
- publishing workflows
- remix tracking
- attribution
- template packaging
- usage feedback
- optional monetization paths
The product should optimize for tools that are useful to one person before they are useful to a market. A mini app can be successful even if nobody else would want it.
Every mini app should have clear boundaries. The user should understand what data it can access, what it stores, what it can change, and whether it communicates externally.
Traditional apps expose settings because they must serve many users. Library Shelf should let users fork and remix apps because the better endpoint is often a new variant, not a larger settings screen.
Mini apps are visual tools. Creation and iteration should use screenshots, previews, and visible state as first-class feedback. A screenshot is not just documentation; it is evidence for the next iteration.
The best mini apps should have a narrow job and a strong interface. The product should encourage focused tools instead of sprawling dashboards.
Users should feel safe changing their apps. Every meaningful change should be versioned, reversible, and understandable.
Personal software still needs upkeep. The product should treat broken data sources, expired permissions, stale APIs, and failed runs as normal lifecycle states.
Mini apps should prefer portable data, clear metadata, and open formats where possible. A user’s app shelf should not become a trap.
The home screen is the user’s personal app shelf.
It should show:
- pinned mini apps
- recently used mini apps
- in-progress creations
- broken or attention-needed apps
- suggested remixes
- templates relevant to the user’s recent activity
- status of sync, backup, or local storage
Each mini app should have:
- name
- icon
- short description
- latest screenshot
- last opened time
- permissions summary
- version or update state
- quick actions such as open, edit, duplicate, share, archive
The shelf should feel personal and durable. The user is building a small library of tools they own.
Each mini app should have a detail page that gives the user confidence and control.
It should include:
- current screenshots
- description
- creator or origin
- app type or category
- data used
- permissions required
- local/cloud storage summary
- version history
- recent runs or events
- known issues
- fork/remix actions
- export/share options
- reset/archive/delete actions
This page is the equivalent of an app’s card, README, settings, and changelog combined.
The create flow should start from intent, not from technical structure.
Possible starting points:
- “Describe the app you want”
- “Start from a template”
- “Remix an existing app”
- “Import a mini app”
- “Build around this data”
- “Build from screenshot”
- “Build for this device mode”
The product should help the user turn a rough request into a usable first version. The user should not have to specify every screen, data model, or state. The builder should infer a simple product shape and show it quickly.
The first version should be treated as a draft. The product should invite iteration:
- “Make the controls bigger”
- “Use only these stations”
- “Add a night mode”
- “Split this into two screens”
- “Use my family calendar”
- “Make it work offline”
- “Turn this into a template”
Fork and remix are core concepts.
A user should be able to:
- duplicate a mini app
- change its purpose
- change its data source
- change its layout
- simplify it
- specialize it for a person, room, trip, project, or device
- publish a remix as a template
- keep a remix private
Examples:
- Fork a generic clock into a bedside clock, kitchen clock, and desk clock.
- Fork a radio dial into country-specific, genre-specific, and family-safe versions.
- Fork a video clipper into a short-form social clipper, lecture trimmer, or family archive tool.
- Fork a home dashboard into versions for the hallway iPad, bedside iPhone, and office monitor.
Remixing should preserve lineage. The user should be able to see where an app came from and what changed.
Templates are reusable starting points.
Template categories might include:
- clocks and ambient displays
- media tools
- dashboards
- personal databases
- home and device controls
- travel and checklists
- learning and study tools
- research capture
- lightweight CRMs
- family operations
- health and habits
- games and toys
- device repurposing
Templates should be opinionated enough to produce a useful first result, but flexible enough to become personal. The goal is not to offer infinite blank-canvas freedom; the goal is to accelerate the path from “I wish I had…” to “I am using it.”
The gallery is a curated place to discover templates and examples. It should not feel like a general app marketplace. It should feel like a library of patterns that can become personal tools.
Gallery entries should emphasize:
- what problem this solves
- who it is useful for
- what can be personalized
- what data it needs
- screenshots
- examples of remixes
- safety and privacy notes
- maintenance expectations
The best gallery entries should invite the user to personalize:
- “Make this for my kitchen”
- “Use my city”
- “Use my playlists”
- “Use my camera feeds”
- “Use my reading list”
- “Use my family schedule”
Permissions should be understandable at the mini-app level.
A user should be able to answer:
- What can this mini app read?
- What can it write?
- Does it use network access?
- Does it store data locally?
- Does it sync data?
- Does it use photos, location, calendar, contacts, microphone, camera, or files?
- Can it share data with other mini apps?
- Can I revoke access?
The product should avoid broad hidden permission sharing. If a mini app needs access to sensitive data, the user should see that request in context.
Permission summaries should be visible in the mini app detail page and during installation/remix.
Library Shelf should treat user data as durable and portable.
At a product level, mini apps should favor:
- local state where practical
- clear export paths
- readable metadata
- user-visible data ownership
- backup and restore
- migration between app versions
- graceful failure when data sources disappear
The user should not feel that a personal app can silently lose important state.
Every mini app should have version history.
Versioning should support:
- snapshot before each major change
- human-readable change summaries
- rollback
- side-by-side comparison
- screenshot history
- data migration notes
- “stable” and “draft” versions
- named milestones
Version history is especially important because generated software invites rapid changes. The user should feel free to experiment because they can always return to a known good version.
Mini apps should have a lightweight quality model.
Quality signals may include:
- launch succeeds
- first screen renders
- primary workflow completes
- text fits
- controls are reachable
- permissions are handled
- empty, loading, error, and offline states exist
- screenshot matches expected state
- recent run has no errors
- data sources are reachable
The product should make testing visible to users without overwhelming them. A mini app can have a simple health state:
- Ready
- Needs attention
- Draft
- Broken data source
- Permission needed
- Update available
- Running test
Personal software still needs observability. The product should expose enough state to understand what happened without asking the user to read low-level logs.
Useful observability concepts:
- recent activity
- build or generation history
- errors and warnings
- data source status
- permission status
- last successful run
- last screenshot
- performance summary
- storage usage
- sync status
For advanced users, deeper logs can exist, but the default experience should explain problems in product language.
Sharing should support several levels:
- share a screenshot
- share a mini app as a template
- share a private install link
- share with a household or small team
- publish to a curated gallery
- export for archival storage
Sharing should not imply that a user’s private data is included. The product should clearly distinguish:
- app structure
- template logic
- visual assets
- configuration
- personal data
- credentials or secrets
The safest default is to share structure without personal data.
Collaboration should be lightweight and scoped.
Possible collaboration features:
- invite someone to use a mini app
- invite someone to edit a mini app
- request a remix
- comment on a screenshot
- propose a change
- accept or reject a generated update
- keep personal forks separate from shared originals
The product should make it clear when a mini app is private, shared, or public.
The product can support multiple business models without making monetization the center of the experience.
Possible models:
- subscription for personal app creation and hosting
- usage-based generation credits
- paid template packs
- paid expert-created skills
- team plans
- managed app maintenance
- concierge app creation
- premium sync, backup, and observability
- private gallery for organizations
The strongest commercial value is likely not in selling individual mini apps. It is in making personalized software reliable, maintainable, and easy to create.
Creators should be able to publish high-quality templates and skill packs.
Creator features might include:
- template author profiles
- template analytics
- remix counts
- reviews or ratings
- support notes
- versioned releases
- compatibility notes
- monetization options
- attribution and lineage
Creators should be rewarded for durable patterns, not just flashy demos. A good template should help many users create private variants.
Skill packs are an important product concept. They are the instructions, constraints, taste, and workflows that help the builder produce better apps in a particular domain.
Examples:
- iPhone shelf display skill
- home dashboard skill
- personal finance tracker skill
- media clipping skill
- travel planner skill
- family operations skill
- research capture skill
- SQLite local-first app skill
- accessibility-first app skill
- kid-safe mini app skill
Skill packs should be treated as reusable product knowledge. They can define quality bars, domain vocabulary, recommended flows, test expectations, and safety constraints.
The product should include a review model appropriate to personal mini apps.
Safety concerns include:
- data exfiltration
- misleading UI
- unsafe generated behavior
- hidden network activity
- permission overreach
- harmful content
- scams in public templates
- broken or abandoned templates
- insecure handling of secrets
- children’s privacy and age-appropriate content
The review model may differ for:
- private mini apps
- shared mini apps
- public gallery templates
- paid templates
- mini apps using sensitive data
- mini apps using external services
The product should be stricter as distribution widens.
Maintenance is a product feature, not an afterthought.
Mini apps can break because:
- a data source changes
- credentials expire
- permissions are revoked
- a template update conflicts with a personal remix
- a sync error occurs
- device capabilities differ
- the mini app grows beyond its original scope
Library Shelf should help users keep apps alive:
- identify broken apps
- suggest repairs
- rerun tests
- update templates
- preserve working versions
- explain failures clearly
- archive abandoned apps
One important use case is turning older devices into dedicated personal appliances.
Examples:
- clock
- radio
- photo frame
- camera wall
- weather station
- recipe display
- music controller
- home control panel
- reading kiosk
- ambient dashboard
Library Shelf can support device modes where a mini app is designed for an always-on screen, a shelf, a desk, a kitchen, a car mount, or a bedside table.
Device repurposing is a strong emotional wedge because it turns old hardware into personal infrastructure.
Library Shelf should feel:
- personal
- calm
- trustworthy
- playful when appropriate
- technically capable
- transparent
- user-controlled
It should not feel like:
- a crypto marketplace
- a spammy app directory
- an enterprise low-code dashboard
- a fake App Store clone
- a generic chatbot wrapper
The product should make users feel that they are shaping their own tools, not browsing a catalog of someone else’s software.
Traditional no-code products ask users to assemble software from components.
Traditional app stores ask developers to publish software for markets.
Traditional automation tools ask users to wire actions together.
Library Shelf should feel different because the user starts with intent, receives a working mini app, then improves it through use. The central loop is:
- Describe
- Generate
- Preview
- Use
- Screenshot
- Revise
- Save or remix
The product value is in shortening that loop while keeping the result understandable and safe.
The first product should focus on mini apps inside one host app. A future product may allow some mini apps to graduate into standalone native apps through appropriate distribution paths.
Potential graduation paths:
- export source or project files
- generate a native app package for a developer account
- publish through standard app review
- distribute as a custom app for organizations
- distribute through approved regional alternative marketplace flows where available
- deploy internally through appropriate enterprise or device-management channels
This should be treated as a graduation path, not the core first product. The core product is the personal mini-app shelf.
Useful product metrics:
- mini apps created per user
- mini apps used repeatedly
- time from prompt to first usable app
- number of successful remixes
- percentage of mini apps with healthy status
- rollback frequency
- template-to-remix conversion
- private sharing frequency
- user retention by number of useful mini apps
- user-reported displacement of existing apps or workflows
The most important qualitative metric:
Did the user create a tool that would not have existed otherwise and then keep using it?
A user asks for a radio app that feels like an old iPod interface, includes only public internet radio stations they care about, and can sit on an old phone in the kitchen. Library Shelf creates the app, gives it a dial interface, stores the station list, and lets the user fork it later into country, genre, and family-safe variants.
A user wants a tiny video tool for trimming family videos before saving them. Library Shelf creates a simple mini app with a picker, preview, start/end controls, speed settings, and a save action. The user later remixes it into a lecture clipper and a social clipper.
A user turns an old device into a desk clock. The first mini app shows time, date, and weather. The user remixes it into a night clock, a world-clock board, and a focus timer.
A user wants a project-specific research tool that collects links, notes, screenshots, and summaries into one local workspace. The mini app is useless to almost everyone else, but extremely useful for that project.
A family creates a shared mini app for chores, calendar events, meal planning, and reminders. Each family member can fork a private view while the shared app keeps common state.
Future builders should resolve these through prototypes and user testing:
- How much creation should happen through chat versus structured controls?
- How visible should the generation process be?
- What is the right default balance between private apps and shared templates?
- How should users understand permissions at the mini-app level?
- How should template authors be rewarded?
- What should be allowed in public gallery templates?
- How should the product prevent mini apps from becoming bloated?
- What is the best way to represent app lineage and remix history?
- How much observability should casual users see?
- What is the minimum useful versioning model?
- When should a mini app graduate into a standalone app?
Library Shelf should make it normal for a person to have software that exists only because they wanted it.
The product succeeds if a user can say:
I described a tiny app, used it five minutes later, changed it after seeing it on my device, and now it sits on my shelf because it solves something only I cared about.