What “native UI in ChatGPT” actually means

Inline, chat-first UI. Your component renders inside the thread next to the model’s messages; users continue the conversation while interacting with your UI.

Components ≠ a web app port. The recommended pattern is task-focused surfaces (lists, summaries, selectors) that complement chat. Fullscreen is supported, but the composer remains present and the goal is not to replicate your entire product.

Bridge & isolation. Components are typically React apps in an iframe that talk to ChatGPT through the window.openai component bridge defined in the SDK reference.

UI elements users already expect. OpenAI describes apps that include elements like maps and playlists (among others) used without leaving the conversation—useful mental models when you design your own components.

The conversion model for Apps in ChatGPT

OpenAI’s design guidance is clear: design for conversational prompts → tool calls → compact UI. To maximize completion and reduce drop-off:

1. Keep the task small. Each tool/component should do one job clearly (e.g., “generate quote,” “create ticket”), matching how ChatGPT decides to call tools.
2. Stay inside the conversation. Prefer inline components and short, follow-up prompts over multi-screen flows. Reserve fullscreen for steps that truly need focus (review, checkout, long forms).
3. Design structured inputs. Reflect your JSON schemas (from the MCP tool) in minimal fields and confirmations. This aligns user intent with the tool contract and keeps the model’s calls predictable.
4. Label actions accurately. If a tool creates/updates/deletes external state, mark it as a write action so the client can insert confirmations and guardrails. This is required by the developer guidelines and materially improves trust/conversion.

Component patterns that work (and why)

1) Result list → details → confirm

• Return a structured list (e.g., search results) with a single primary action (“Book,” “Create,” “Add to…”) that opens a concise confirmation step.
• Why it works: mirrors the “suggest → refine → act” rhythm of chat; keeps the composer visible for natural language tweaks.

2) Inline configurator

• A compact selector (chips, sliders, pickers) that writes to the tool’s schema and shows a live preview message.
• Why it works: couples free-form prompts with a small, auditable set of structured params back to your MCP tool.

3) Fullscreen review (use sparingly)

• One focused surface for high-stakes tasks (e.g., finalizing an order). Keep the composer available; exit cleanly back to the thread.
• Why it works: aligns with guidelines—fullscreen to deepen engagement, not to rebuild your whole product.

OpenAI’s examples repo (“Pizzaz” demo) shows how an app can combine multiple components to cover the full tool surface area—useful as a reference implementation.

Technical fundamentals you must get right

window.openai lifecycle. Treat it as the authoritative bridge for sending/receiving events between your component and the host (e.g., sizing, actions, navigation). Start from the SDK reference and the custom UX guide.

Contract-first design. Define tool inputs/outputs in your MCP server with narrow JSON Schemas; your UI should only collect what the schema needs. This keeps calls predictable and enables safe retries.

Preview status & testing. Apps SDK is in preview; test end-to-end in Developer Mode before submissions open later this year.

Accessibility & mobile usability

Assume mobile usage: keep tap targets large, avoid horizontal overflow, and prefer multi-step confirmations over dense forms. These align with the SDK’s guidance to keep experiences simple and natural within the composer.

Use clear, honest labels for actions and state, particularly for anything with side effects (writes/egress). The guidelines require accurate action labels and friction for destructive actions.

Performance that respects the chat context

Lightweight bundles. Your component runs in an iframe; keep payloads small and lazy-load heavy subviews to avoid jank in the conversation. (OpenAI’s custom-UX docs recommend structuring/bundling components purposefully.)

Fast, idempotent tools. Design your MCP calls to be side-effect free unless explicitly marked as write actions; return structured results the model can reason over.

Security, privacy, and trust signals (non-negotiable)

Sensitive data bans. Do not collect PCI, PHI, government IDs, API keys, or passwords in your app. Publish a clear privacy policy.

User control & confirmations. Any tool that changes external state or egresses data must be surfaced as a write action so ChatGPT can require explicit user confirmation. Label these accurately in your tool metadata.

Appropriate for broad audiences. Apps must be suitable for general users; adhere to OpenAI usage policies.

Design checklist you can hand to your team

1. Start with the prompt. Can a single conversational instruction trigger your tool with minimal fields? If not, reduce scope.
2. Pick the smallest UI that works. Inline component first; fullscreen only to deepen engagement (review/confirm).
3. Mirror your schema. Every field maps to an input in your tool’s JSON Schema—nothing extra.
4. Mark writes. Flag create/update/delete and any data egress as write actions; design a clear confirmation step.
5. Name things plainly. Titles, labels, and tool metadata must say exactly what the tool does; avoid ambiguity.
6. Test in Developer Mode. Validate discovery (does ChatGPT pick the right tool?), mobile layout, and confirmation UX well before submission opens.

Common mistakes (and how to avoid them)

• Re-creating your whole SaaS in fullscreen. Violates the spirit of the guidelines and usually hurts completion—keep it focused and conversational.
• Collecting data “just in case.” The guidelines require data minimization and ban sensitive data; over-collection risks rejection and user distrust.
• Unlabeled side effects. Failing to mark writes prevents the client from inserting confirmations—both a UX and a policy failure.

Where this is heading

OpenAI’s product post confirms apps in ChatGPT and the Apps SDK are live in preview, with submissions opening later this year and a growing catalog of third-party apps. As you design, optimize for discoverability and clarity—the directory will favor experiences that feel native and valuable in chat.

How we can help

Our team designs contract-first MCP tools and Apps SDK components that follow OpenAI’s design, security, and developer guidelines—so your app is delightful in chat and submission-ready when the directory opens. If you want, we can turn this post into a component library checklist mapped to your top use cases.