Apps SDK (статус – preview) дозволяє будувати застосунки, які живуть всередині ChatGPT: з власними даними, діями і, головне, власним інтерактивним UI. Технічно це надбудова над MCP – тим самим відкритим протоколом, який ми розбирали у статті про stateless MCP: твій застосунок – це MCP-сервер під твоїм контролем, що експонує tools, resources і widgets. Для web-розробника це не «смерть сайтів», а нове питання на етапі дизайну фічі: де живе цей user intent – у твоєму UI чи в чаті користувача?

Що це таке технічно

Три факти з офіційного анонсу, які варто знати перед будь-якими висновками:

  1. Це MCP. Apps SDK побудований на Model Context Protocol і розширює його; SDK відкритий, а застосунки, за задумом OpenAI, зможуть працювати будь-де, де приймуть цей стандарт. Тобто інвестиція в MCP-сервер – це не лок-ін на ChatGPT.
  2. Застосунок = твій сервер. Логіка, дані, дії та UI-компоненти визначаються на MCP-сервері, який ти контролюєш. ChatGPT – хост, який викликає tools і рендерить widgets.
  3. UI – справжній. Не markdown-відповідь, а інтерактивні компоненти всередині розмови: списки, карти, каруселі, форми підтвердження. В офіційному репозиторії прикладів – готові компоненти і MCP-сервери, з яких можна стартувати.

Тестується це через Developer Mode у ChatGPT (для Business/Enterprise його вмикає адмін воркспейсу) – створюєш свій застосунок і ітеруєш прямо в чаті.

Якщо ти читав наш розбір MCP Apps – так, ідея та сама: tool викликається моделлю, а результат користувач бачить як інтерактивний UI. Різниця в хості й екосистемі: MCP Apps – це загальне розширення протоколу для будь-якого хоста, Apps SDK – конкретна реалізація OpenAI зі своїм рев'ю, дистрибуцією через ChatGPT і своїми правилами. Концептуально ж межі ті самі: UI живе в пісочниці хоста, діє через tools і мусить мати текстовий fallback.

Це не iframe із твоїм сайтом

Головна помилка, яку вже роблять: спробувати засунути весь продукт у чат.

Chat-native застосунок відповідає на конкретний intent. Канонічний приклад:

«Знайди мені три доставки з falafel wrap біля цього поштового індексу»

Тут застосунок доречний: модель розуміє запит, твій tool повертає дані, widget рендерить інтерактивний список із кнопками замовлення. Розмова почалась із наміру – закінчилась дією. Ідеально.

А тепер уяви dashboard із 18 табами, фільтрами й bulk-редагуванням у чаті. Це не intent – це робоче середовище. Йому місце у web-застосунку, і ніякий Apps SDK цього не змінить.

Що змінюється в голові frontend-розробника

Роками ми думали component-first: є сторінка, на ній компоненти, між ними стан. Chat-native UI вимагає intent-first мислення:

  • UI короткий – один екран відповіді, не маршрути;
  • UI контекстний – він продовжує розмову, а не починає сесію;
  • UI минущий – користувач не «повернеться на цю сторінку», він поїде далі в розмові;
  • стан прив'язаний до conversation, а не до твого роутера.

Практично важливими стають речі, які у звичайному фронтенді другорядні:

  • мапінг tool result → UI: що з відповіді сервера стає віджетом, а що лишається текстом;
  • progressive disclosure: спочатку три варіанти, деталі – на запит;
  • підтвердження дій: кнопка «замовити» в чаті – це реальна дія з реальними грошима;
  • fallback: що бачить користувач, якщо widget не відрендерився (відповідь: осмислений текст, завжди);
  • permission boundaries: що застосунку можна знати про розмову, а що ні.

Чесний критерій «чат чи web»

Простий тест, який я пропоную застосовувати до кожної фічі:

Якщо фіча починається з natural-language наміру і закінчується маленькою дією – ChatGPT-застосунок може бути хорошим surface. Пошук, підбір, бронювання, статус замовлення, швидке підтвердження.

Якщо користувач працює 40 хвилин із таблицями, фільтрами і multi-step редагуванням – web усе ще прекрасний. І буде таким далі.

Між цими полюсами – сіра зона, і саме там варто експериментувати через Developer Mode, а не переписувати продукт на віру.

Чому перші chat-апи виходять незручними

  • Портувати сайт цілком. Чат – не браузер. Почни з одного intent, який твої користувачі вже формулюють словами.
  • Ігнорувати текстовий fallback. Застосунок, який без widget-а перетворюється на «щось пішло не так», зламаний за дизайном.
  • Будувати на preview як на фундаменті. Це preview: API, правила рев'ю і дистрибуція можуть змінитись. Експериментувати – так; ставити бізнес-критичний флоу – зарано.
  • Забути, що це MCP. Якщо спроєктувати сервер чисто (tools із чіткими контрактами, стандартні resources), той самий сервер працюватиме і в інших MCP-хостах – від Claude до власного агента. Проєктуй протокол, а не інтеграцію з одним вендором.

Прожени свій продукт крізь фільтр трьох намірів

Візьми свій продукт (або продукт, над яким працюєш) і випиши три користувацькі наміри, які люди РЕАЛЬНО формулюють одним реченням: «знайди…», «покажи статус…», «забронюй…». Для кожного дай чесну відповідь: що поверне tool, як виглядатиме widget на один екран і яка дія завершує сценарій. Якщо хоч один вижив після цього фільтра – склонуй офіційні приклади, підніми MCP-сервер і спробуй його в Developer Mode. Якщо не вижив жоден – вітаю, ти щойно зекономив місяць розробки модної фічі, якою ніхто б не користувався.

Платформи приходять і йдуть, а вміння чесно відповісти «де живе цей intent» – лишається.