# ChatGPT стає runtime для застосунків. Що web-розробнику робити з Apps SDK? > Apps SDK (preview) дозволяє будувати логіку та UI всередині ChatGPT поверх MCP. Розбираємо, які фічі мають сенс у чаті, чим chat-native UX відрізняється від сайту і як спробувати через Developer Mode. - Автор: Юра Скиба (https://cookiesoftware.io) - Опубліковано: 2026-10-15 - Категорія: AI в роботі розробника - Canonical: https://cookiesoftware.io/blog/chatgpt-apps-sdk-web-developer --- Apps SDK (статус – preview) дозволяє будувати застосунки, які живуть всередині ChatGPT: з власними даними, діями і, головне, власним інтерактивним UI. Технічно це надбудова над MCP – тим самим відкритим протоколом, який ми розбирали у [статті про stateless MCP](/blog/mcp-2026-stateless-typescript): твій застосунок – це 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-відповідь, а інтерактивні компоненти всередині розмови: списки, карти, каруселі, форми підтвердження. В офіційному [репозиторії прикладів](https://github.com/openai/openai-apps-sdk-examples) – готові компоненти і MCP-сервери, з яких можна стартувати. Тестується це через Developer Mode у ChatGPT (для Business/Enterprise його вмикає адмін воркспейсу) – створюєш свій застосунок і ітеруєш прямо в чаті. Якщо ти читав наш [розбір MCP Apps](/blog/mcp-apps-ui) – так, ідея та сама: 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 на один екран і яка дія завершує сценарій. Якщо хоч один вижив після цього фільтра – склонуй [офіційні приклади](https://github.com/openai/openai-apps-sdk-examples), підніми MCP-сервер і спробуй його в Developer Mode. Якщо не вижив жоден – вітаю, ти щойно зекономив місяць розробки модної фічі, якою ніхто б не користувався. Платформи приходять і йдуть, а вміння чесно відповісти «де живе цей intent» – лишається.