Як я створив StemJSON — мову, якою ШІ пише нативні мобільні застосунки

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт! Мене звати Василь Кричун, я Senior Engineering Manager із понад 20-річним досвідом в IT, переважно в мобільній розробці. Починав ще із Symbian та J2ME, згодом працював з iOS і Android, а останні кілька років займаюся інтеграцією ШІ в мобільні продукти.

Ця стаття про те, чому я вирішив написати власну декларативну мову програмування для мобільних застосунків, що, на перший погляд, виглядає дуже амбітно і викликає питання — навіщо, особливо в період буму ШІ, коли будь-хто з мінімальним досвідом може створити потрібний додаток. Звучить просто, але власне тут і криється проблема.

Шлях від прототипу, згенерованого ШІ, до повноцінного додатку в App Store

Зараз ШІ достатньо добре створює вебдодатки, які одразу можна побачити в браузері, внести правки і навіть опублікувати на якомусь доступному хостингу. Все це може зробити людина з мінімальним ІТ-досвідом або навіть без. З мобільними застосунками все трохи складніше. За рік ШІ-інструменти дуже сильно еволюціонували, і зараз повноцінний мобільний проєкт може бути створений дуже швидко, але далі починаються проблеми, які людині без технічного бекграунду вирішити складно.

Рік тому, під час роботи з ШІ, мене муляла ця «несправедливість» 😜 щодо мобільної розробки. Я подумав, що було б добре мати можливість створювати повноцінні мобільні застосунки з ШІ, які одразу можна було б бачити і використовувати (запускати) на своїх смартфонах, без усіх технічних складнощів, пов’язаних з розробкою.

Я почав досліджувати цей напрямок. Два класичні підходи, які пропонувала індустрія, це гібридний додаток з нативною оболонкою та динамічним вебконтентом і добре відомий SDUI/BDUI підхід, коли бекенд надсилає JSON з інструкціями, а мобільний клієнт вже рендерить користувацький інтерфейс на основі нього.

На перший погляд вебконтент у нативній оболонці міг би вирішити цю проблему, якби існував нативний застосунок-контейнер (host), у який користувач міг би завантажувати згенерований ШІ вебдодаток. Але без доступу до нативних функцій це по факту той самий мобільний браузер.

А доступ до функцій на кшталт камери чи GPS потребує додаткових фреймворків (JavaScript-bridge), яких багато і серед яких немає універсального. Тобто ШІ довелося б щоразу підказувати, який саме фреймворк використати, а це робить підхід надто складним для генерації додатків самими користувачами. Та й відверто кажучи, я ніколи не був прихильником гібридної розробки 🙃

Інший варіант — це server-driven UI з добре відомим JSON. Десятки великих компаній мають розроблені внутрішні рішення, є деякі публічні, які дозволяють використовувати JSON для опису UI та частково логіки. Але майже всі ці системи проєктувалися до ери LLM, під людей і бекенд-команди, а не під генерацію штучним інтелектом. Крім того, вони мають обмежені можливості для створення повноцінної логіки.

Є ще третій, дуже амбіційний підхід — створити власну мову програмування з нуля. Але перемогла більш прагматична ідея — використати JSON. Це добре відомий формат для передачі структурованих даних. Парсер для JSON є фактично в кожній мові й на кожній платформі, часто прямо в стандартній бібліотеці, а навколо формату давно склалась зріла екосистема інструментів.

Більше того, у типізованих мовах декодування JSON у нативні структури (Swift Codable, Kotlin kotlinx.serialization) саме собою валідує структуру. А оскільки я задумував інтерпретовану runtime-систему, цей крок ставав своєрідним аналогом compile-time-валідації. У звичайній мові структуру перевіряє компілятор перед запуском, а тут ту саму роль бере на себе декодер, і структурні помилки відсіюються ще до того, як опис почне працювати на пристрої.

LLM теж бачили за час тренування терабайти JSON, активно його використовують і добре розуміють. Основним блокером було — як описати повноцінну логіку. Я почав експериментувати в цьому напрямку, і крок за кроком вималювалось рішення, яке дозволяє описати повноцінну логіку мобільного додатку і не лише. Я назвав його StemJSON.

Що таке StemJSON

StemJSON — це декларативна domain-specific language (DSL) на базі JSON. Мова описує дерево компонентів, реактивні стани, події, дії, навігацію і доступ до даних. Один JSON-документ може містити опис цілого екрану, окремої фічі або навіть повноцінного додатку.

Найпростіший спосіб пояснити — показати. Ось повноцінний робочий лічильник:

{
  "id": "hello_module",
  "type": "module",
  "state": { "count": 0 },
  "children": [
    {
      "id": "counter_value",
      "type": "text",
      "context": { "_text": "${count}" },
      "style": { "common": { "font": { "kind": "system", "size": 48, "weight": "bold" } } }
    },
    {
      "id": "btn_plus",
      "type": "button",
      "context": { "_label": "+" },
      "events": {
        "onTap": [
          { "state": { "id": "increment", "input": { "count": "{{ ${count} + 1 }}" } } }
        ]
      }
    }
  ]
}

Лічильник — це «hello world», щоб показати синтаксис. Але щоб зрозуміти, наскільки далеко це заходить, гляньте на інший приклад — шашки. Це повноцінна гра: дошка, правила ходів, взяття шашок, дамки. І найцікавіше тут — суперник.

Гра в шашки, згенерована як StemJSON-модуль

Спрацьовує одна з ключових можливостей StemJSON: модуль може описати звернення до зовнішнього сервісу. У випадку шашок цей сервіс — сама ж мовна модель. Тобто ШІ згенерував додаток, який під час гри сам звертається до ШІ, щоб зробити хід суперника. Виходить така собі рекурсія: ШІ створив гру, в якій граєш проти ШІ 🤖 І все це один JSON-документ, який рендериться нативно на телефоні, без жодного рядка Swift чи Kotlin.

Що важливо: це не «ШІ написав код гри, запусти й молись». Гра — це опис. І цей опис можна перевірити ще до запуску.

Ключові дизайн-рішення

Розкажу про кілька рішень, на яких тримається вся ідея.

Найголовніше — це стан замість коду. У звичайному додатку логіка це код, який виконується. У StemJSON усе інакше: є стан (дані модуля) і є дії, які цей стан змінюють. Кнопка не «виконує функцію», вона описує, який стан треба змінити і як. Ніяких прихованих сайд-ефектів. Через це поведінка модуля передбачувана: одні й ті самі дані завжди дають однаковий екран.

Звідси випливає ще одна важлива річ — усе можна перевірити до запуску. Оскільки модуль це опис, а не програма, його можна проаналізувати статично, тобто зрозуміти, що він робить, які дані читає, до чого звертається, ще до того, як він хоч раз запуститься на телефоні. Для мене це виявилось критичним. Коли додаток генерує ШІ, просто довіритись не можна, потрібен спосіб зловити помилку до того, як вона потрапить на пристрій користувача. Тут це вбудовано в саму природу формату.

Складна логіка будується як ланцюг дій, де кожен наступний крок спирається на результат попереднього. Умови, розгалуження, обробка відповідей описуються декларативно, без «справжнього» коду. Крім того, модуль може описати звернення до стороннього сервісу за заданим сценарієм, і саме це дозволило шашкам «ходити розумом» мовної моделі. Так само можна дістати погоду, курс валют чи будь-що інше.

І окремо про саму специфікацію. Спочатку я писав її для розробників, але коли головним «читачем» став ШІ, виявилось, що йому потрібна інша подача: коротша, без пояснень «для людей», зате щільніша. Тож я тримаю дві редакції специфікації, повну читабельну для розробників і стислу для мовних моделей, утричі меншу. Менше тексту для ШІ означає менше витрачених токенів на кожну генерацію, а отже дешевше і швидше.

А чи безпечно запускати те, що згенерував ШІ?

Питання, яке виникає одразу — якщо ШІ генерує додаток, а він потім працює на моєму телефоні, що завадить згенерувати щось шкідливе?

Тут знову рятує те, що модуль — це опис, а не виконуваний код. Йому не вдасться «непомітно» щось зробити: усе, до чого модуль звертається, хай то камера, мережа чи сховище, задекларовано в самому документі. Тому ще до запуску можна побудувати повний перелік того, на що модуль здатен, і показати або перевірити його. Це принципово інша модель довіри, ніж «завантажив бінарник і сподіваєшся».

Додатково модулі ізольовані один від одного: один згенерований інструмент не має доступу до даних іншого. Тобто навіть у межах одного застосунку трекер води нічого не знає про список покупок.

Перевірка боєм. Pluri

Реалізація моєї ідеї просувалась добре: я допилював специфікацію і необхідні iOS- та Android-рантайм-бібліотеки, усував виявлені проблеми. Намагався генерувати додатки різної складності та покриття, щоб перевірити ліміти і можливості. При цьому я навчився за декілька ітерацій генерувати досить складні додатки (можна глянути приклади на GitHub — для iOS та Android), але це все ще були інструменти для розробників, а не для кінцевих користувачів, фантазія яких може бути нестримна 🤪

StemJSON-модулі, що рендеряться нативно на iOS

Тож мені потрібен був реальний продукт — мобільний додаток, в якому людина без технічних навичок, зокрема роботи з ШІ, могла б згенерувати собі необхідний інструмент, утиліту чи навіть гру. Те, що власне і було початковою ідеєю.

Тут я стикнувся з труднощами. ШІ-моделі через API працюють не так, як через стандартні чати. Більша частина магії залежить від системних промптів, налаштувань та додаткових інструментів. Виявилось, що мало мати специфікацію. Різні LLM-моделі інтерпретують її по-різному через своє навчання, як би дивно це не звучало.

Наприклад, я помітив, що мовні моделі від OpenAI краще слідують специфікації. Claude-моделі, заточені в основному на програмування, більше галюцинують у сторону класичних мов програмування. Довелось методом проб і помилок створювати ще відповідну обгортку із системних промптів та інструкцій, щоб досягти прийнятної якості генерації через API. Це і стало основою для мобільного додатку Pluri.

Pluri — це мобільний застосунок, який дозволяє користувачу звичайними словами описати, що він хоче і який функціонал, і ШІ створить додаток, який можна одразу відкривати і використовувати. Тобто кожен користувач може створити щось унікальне виключно для себе та своїх потреб, а також може поділитись з іншими.

Зверніть увагу на підписи в списку, це і є ті самі описи звичайними словами, з яких народились інструменти: «create a 2048 game», «a daily water tracker built around a circular progress ring». Гра, трекер, словник — це геть різні речі, але всі вони описані однією й тією ж мовою й запускаються нативно на телефоні.

Зараз цей застосунок ще на рев’ю в Apple. І тут сталося майже символічне: один раз Apple відхилив додаток за пунктом 2.5.2, тим самим, що забороняє завантажувати й виконувати код, який змінює функціональність застосунку. Тож зараз я, по суті, доводжу рев’юерам те, з чого починалась уся ця історія: StemJSON це не код, а декларативний опис, який рантайм рендерить нативно. Іронія в тому, що це саме та властивість, яка робить підхід передбачуваним і безпечним, і саме її доводиться пояснювати.

Що вже працює, а що попереду

StemJSON поки що покриває не все. Наприклад, поки немає drag&drop, вбудованих графіків, готової роботи з камерою чи іншими складними бібліотеками. Частину з цього можна вже зараз під’єднати ззовні, через механізм зовнішніх сервісів, але «з коробки», однією лише мовою, це ще не описується. Я свідомо рухаюсь від простого до складного. Cпочатку щоб надійно генерувалось те, що потрібно більшості користувачів, а решту додаю в міру появи реальних запитів і сценаріїв.

Попереду ще багато роботи: розширювати саму мову (нові компоненти й можливості), покривати більше кейсів у генерації, вилизувати якість першої спроби, доводити паритет між iOS та Android. Але головне для мене вже підтвердилось — концепція робоча. ШІ справді може згенерувати повноцінний нативний інструмент за описом звичайними словами, і цей інструмент запускається на телефоні. А далі це вже питання техніки й обсягу роботи.

Де все це подивитись

StemJSON-специфікація опублікована і є у відкритому доступі. Є готові StemRuntime SDK для iOS та Android, які вміють будувати (рендерити) додатки на основі цієї специфікації, і проєкти-приклади для обох платформ, де видно, як усе працює та інтегрується. Все це на GitHub і на сайті stemjson.com.

Окремо виділю MCP-сервер, який я випустив нещодавно. По суті він перетворює ШІ-асистента (Claude, Cursor та інші) на свого роду IDE для StemJSON: дає йому інструменти пошуку по специфікації, скафолдингу й валідації, щоб той генерував коректні StemJSON-модулі чи окремі фічі прямо в робочому середовищі розробника, а далі їх можна вбудувати у власні проєкти. Коли Pluri опублікується, ці ж модулі можна буде запускати і в ньому.

Наостанок про ідею, якої в початковому задумі не було, вона з’явилась уже по ходу роботи. Я називаю її Stem AI Area. Розробник може виділити у своєму застосунку ізольований блок, підключити StemRuntime і дати кінцевому користувачу можливість кастомізувати його власними словами.

Користувач описує потрібну фічу, ШІ генерує, а рантайм одразу рендерить нативний модуль просто на місці, підлаштовуючи застосунок під кожного на льоту. Це вже не просто спосіб згенерувати додаток, а можливість зробити застосунок таким, що добудовує себе під конкретного користувача.😎

Буду радий думкам, конструктивній критиці й питанням у коментарях.