Что произошло​

В 2020 году Shopify поставил на React Native: одна кодовая база, меньше издержек. В январе 2025-го их руководитель мобильной разработки писал, что у React Native светлое будущее. 10 сентября 2026 года тот же человек опубликовал Native is now the future of mobile at Shopify. Приложение Shop уже переписано и лежит в сторах; основное приложение Shopify — больше 300 экранов, виджеты, приложение для Apple Watch, Siri Shortcuts — выйдет позже в этом году.

Они не говорят, что React Native был ошибкой. Они говорят, что в 2020 году это был правильный выбор, а условия изменились.

Что дал нативный код​

Из поста о миграции приложения Shop:

Шесть основных инженеров, двенадцать недель от прототипа до сторов. Сам прототип занял у одного инженера одну неделю.

Преимущества нативного кода были известны всегда. Просто они всегда выглядели мелочью — чуть быстрее запуск, чуть меньше сборка, на пару платформенных багов меньше — на фоне стоимости того, чтобы делать всё дважды.

Почему именно сейчас​

Держать две кодовые базы раньше означало держать две полноценные команды разработки. Теперь большую часть кода пишут агенты, и они же могут взять на себя обслуживающую работу: проверить, что фича ведёт себя одинаково на обеих платформах, сравнить, верифицировать. Shopify формулирует это так:

Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer the deciding factor it was in 2020.

То же самое происходит везде. С агентами можно перенести почти любую библиотеку на свой стек или переписать целый фреймворк — и сделать это быстро. Это меняет то, что считается хорошим или плохим техническим решением.

Как они это сделали​

Интересно не само решение, а то, как доверить переписывание такого масштаба агентам в компании, где любая ошибка стоит реальных денег. Они не просто сказали модели переписать приложение. Они построили конвейер.

Логика отделена от UI. Бизнес-логику отделили от интерфейса настолько чисто, что она работает headless, на десктопной машине. Агенты тестировали её через CLI и консольные тесты — посмотреть состояние приложения, перейти куда-то, выполнить действие — за миллисекунды, не поднимая эмулятор. UI проверяли отдельно: новые экраны сравнивали по скриншотам с работающим React Native-приложением в тех же контрольных точках. Их инструмент для этого, Tardis, ещё и собирал события аналитики в обоих приложениях, чтобы агенты могли сравнить названия событий, их количество и полезную нагрузку.

Маленькие чекпойнты. Их система Helix режет экран на маленькие упорядоченные куски, каждый из которых можно отревьюить за минуты. Каждый кусок должен подтвердить своё поведение тестами, совпасть с работающим приложением на визуальном ревью, пройти двух состязательных код-ревьюеров и получить одобрение человека — и только тогда попадает в коммит. Замечания с ревью запоминаются, так что по ходу миграции циклу нужно всё меньше помощи.

Где агенты не справились. Даже внутри такого конвейера сгенерированный код приносил дублирование, архитектурный дрейф и проблемы с производительностью. Shopify прямо говорит, что нативная экспертиза осталась необходимой — всё это сработало только потому, что код ревьюила команда нативных экспертов.

Что остаётся за цифрами​

Несколько вещей в видео не поместились:

• Сравнение идёт со старой архитектурой React Native. В комментариях отметили, что никто не знает, какие были бы цифры у New Architecture — а переход на неё был крупным рефакторингом, который Shopify всё равно предстоял.
• Это был перенос, а не новый продукт. У агентов было работающее приложение, которое можно читать и с которым можно сравнивать. Shopify говорит, что агенты работали лучше всего именно там, где была готовая реализация; разработка чего-то нового так не ускоряется.
• Две платформы теперь навсегда. Паритет функциональности «всё время», два ревью, два релиза — и никаких обновлений по воздуху в обход стора.

Стоит ли беспокоиться Flutter-разработчикам?​

Думаю, нет — я в этом вполне уверен.

Это ещё один пример того, как агенты делают возможным чуть больше. Крупнейшие техкомпании всегда писали нативно, с параллельными командами под каждую платформу, и в кроссплатформу не уходили. Shopify — большая компания, но не настолько; агенты позволили ей работать по стандартам компаний с более сильными командами разработки. Это тот же сдвиг, что и возможность небольшого бизнеса сделать своё приложение, на которое раньше нужна была средняя компания. Стоимость достижения того же результата падает — на каждом уровне.

И переписывание — это боль в любом случае. Большинству компаний оно просто не стоит того: гораздо лучше вложить силы в продукт — новые фичи, более высокое качество, — чем гоняться за последним процентом багов и выжимать мегабайты из сборки. Выигрыш, который получил Shopify, для большинства команд значит куда меньше.

Так что я не ожидаю, что это заметно сдвинет рынок труда, а Flutter — и того меньше. На мой взгляд Flutter сильно впереди React Native, поэтому от таких трендов страдает меньше.

Что я из этого забираю — тот же урок, который изменил мою собственную работу: недавно я довольно радикально переписал свой фреймворк именно потому, что стал доверять агентам очень большие задачи за короткое время. Говорит ли кто-то вокруг вас о переходе с одного стека на другой с помощью агентов?

Видеоверсия, на русском, — на YouTube.

Мы подключили его к Claude Code на демо-приложении и посмотрели, что он даёт на практике.

Подключение​

Одна команда:

claude mcp add --transport stdio dart -- dart mcp-server --enable all

Без --enable all половина инструментов выключена. Внутри всё идёт через Dart Tooling Daemon — тот же, которым для отладки пользуется DevTools. Следующая сессия агента запускает сервер и получает список инструментов.

Что агент умел и раньше​

Анализатор, тесты, dart fix, форматирование, поиск по pub.dev. Всё полезное — и всё то, что агент делает без сервера, через терминал и веб. В демо он пошёл искать по pub.dev через инструмент; пакет он нашёл бы и без него.

Что действительно ново: запущенное приложение​

Вот за что стоит держаться:

• ошибки времени выполнения из живого приложения — сразу агенту;
• дерево виджетов в том виде, в каком оно в приложении прямо сейчас;
• тапы и ввод текста через Flutter Driver — тапнуть, ввести текст, подождать, получить смещение, снять скриншот;
• вычисление выражения внутри запущенного приложения — агент может распечатать значение на месте, а не искать нужное место в коде и добавлять print;
• hot reload после правки.

В демо агент вытащил ошибки времени выполнения, нашёл overflow в вёрстке, исправил его и сделал hot reload — при этом ему не показывали, где проблема. Без MCP он не увидел бы этих смещений и гадал бы.

Очевидное применение — то, которое масштабируется. Вы собрали большое приложение и хотите проверить каждый экран. Обычно вы находите каждый overflow глазами, а потом описываете: «в этом виджете overflow». С сервером агент сам обходит экраны и собирает ошибки вёрстки. Или вы сами прокликиваете, а агент собирает ошибки через MCP.

Чего это стоит​

Описания всех 24 инструментов попадают в контекст каждой сессии и перечитываются на каждом шаге агента. Задача занимает от двадцати до нескольких сотен шагов, и каждый тащит весь список — закешированный, но всё равно прочитанный и всё равно занимающий контекст, внутри которого агенту приходится думать.

Вывод​

Для инструмента, который нужен на редком баге вёрстки, эта цена платится постоянно. Поэтому в DartWay он не будет включён по умолчанию. Мы добавим его в фреймворк как инструмент по требованию — подключается на прогон визуальных сценариев или на починку багов вёрстки, и не присутствует в обычных сессиях разработки. Держать его в каждой сессии — избыточно.

Видеоверсия, на русском, — на YouTube.

Важна оптика, поэтому начну с неё. Основная часть нашей разработки больше не происходит перед запущенным приложением. Одна сессия ведёт разговор о работе; она запускает отдельные сессии агентов — на разработку и на код-ревью; несколько задач идут одновременно, в фоне; а результат смотрится на тестовом сервере пару раз в день. Несколько ключевых фич Serverpod 4 сделаны под другую картину — разработчик за столом, весь стек поднят локально.

Fullstack hot reload​

База, сервер и Flutter-приложение поднимаются одной командой. Правка в любом месте — от модели до экрана — подхватывается на лету, вместе с кодогенерацией, и приложение сохраняет состояние. Больше никаких четырёх терминалов и перезапусков руками.

Стоит ли? Удобно — и почти не задевает то, как мы работаем. Когда агенты работают параллельно, локального стека часто вообще нет: изменения уезжают на тестовый сервер и проверяются там, и в большинстве случаев этого достаточно. Поднять стек никогда не было сложной частью.

Postgres без Docker и MCP-сервер​

Для локальной разработки теперь есть встроенный Postgres, так что Docker опционален. А запущенное приложение поднимает MCP-сервер: твой кодовый агент может залезть в живой стек — логи, миграции, работающее Flutter-приложение.

Стоит ли? Полезно на редком сложном баге. Проблему, которая у нас реально есть, это не решает: агент и так видит логи и на практике редко испытывает недостаток информации, чтобы разобраться, что происходит. (Ту же идею мы смотрели в собственном MCP-сервере Dart — отдельный пост.)

Офлайн и база на клиенте​

Те же модели и ORM теперь генерируют SQLite во Flutter, а одна строка — database: sync — включает двустороннюю синхронизацию с сервером.

Стоит ли? Направление верное; DartWay идёт туда же. Пока помечено как экспериментальное, и до зрелости ему нужно время.

Future calls и общие модели​

Фоновые задачи объявляются обычными методами Dart, поддерживаются и регулярные. Модели могут жить в отдельном пакете, общем для сервера и Flutter-приложения.

Стоит ли? Общие модели между фронтендом и бэкендом — известная боль, и это была одна из причин, по которым мы ушли с Serverpod. Теперь это есть, и шаг разумный.

Serverpod Cloud​

Деплой бэкенда, базы и веб-приложения одной командой, от $5 в месяц. Фреймворк бесплатный, бизнес — на хостинге; модель понятная.

Стоит ли? Сегодня агент поднимает инфраструктуру за пару промптов: сервер, Docker, база. А если ты не понимаешь, как устроен твой сервер, отдавать его кому-то всё равно некомфортно.

App Studio​

Десктопное приложение, внутри которого уже есть Flutter, Dart и Serverpod. Своего AI в нём нет: подключаешь Claude Code, Cursor или любого другого агента. На выходе — обычный проект, код у тебя на руках, а не закрытая песочница вроде Lovable.

Стоит ли? Две оговорки.

Первая: Serverpod даёт инструмент под каждую задачу, но не связывает их в архитектуру. Чтобы хорошо собрать всё из этого списка, тебе всё равно придётся быть архитектором своего приложения, иначе получится каша. Мы много раз на это натыкались, когда строили на Serverpod напрямую, до появления DartWay.

Вторая важнее. Настоящая разработка не спотыкается о настройку окружения. Прототип или первая версия делаются легко. Тяжело становится, когда экранов и фич много и они должны оставаться согласованными между собой, а большой набор требований должен выполняться точно. Окно чата рядом с запущенным приложением здесь не помогает: где живут все требования и как это всё остаётся синхронизированным? Именно этот вопрос решает, получится ли реальный продукт, и App Studio на него не отвечает.

Вердикт​

Хороший релиз хорошего фреймворка, и на него стоит посмотреть, если ты делаешь fullstack Dart. Большая часть делает локальный цикл приятнее; сложные проблемы разработки с агентами — архитектура и согласованность большого продукта — оставлены тебе.

Видеоверсия, на русском, — на YouTube.

Звучит тревожно, но по большей части это не так — сегодня. Вот что мы выяснили, мигрируя реальный проект с 3.44.0 на 3.47.2, и одно широко разошедшееся утверждение про этот релиз, которое не выдерживает столкновения с кодом.

Сегодня ничего не горит​

Мы взяли живой проект, перевели его с 3.44.0 на 3.47.2 и запустили: flutter analyze чистый, тесты зелёные, библиотеки по-прежнему внутри SDK и не помечены как deprecated. Депрекация назначена на ноябрьский релиз. Вот тогда часы и пойдут.

Так что это хороший месяц для миграции и плохой месяц для паники. Окно существует ровно затем, чтобы миграция прошла скучно.

Миграция — одна команда, но с двумя ловушками​

dart fix --apply --code=migrate_design_widgets

Ловушка первая: простой dart fix --apply этого не сделает. Фикса нет в наборе по умолчанию; без --code=migrate_design_widgets команда отработает, отрапортует об успехе и не изменит ничего по делу. Это тот тип отказа, который читается как «уже мигрировано».

Ловушка вторая: она пишет material_ui: any в ваш pubspec. any значит, что следующий ломающий релиз этого пакета приедет к вам в сборку молча. Замените на каретку с версией сразу, как фикс отработает.

Утверждение, которое неверно: ChangeNotifier никуда не уехал​

Самая часто повторяемая фраза про этот релиз — что ChangeNotifier и компанию вынесли из SDK в package:listen. В 3.47.2 произошло не это.

Классы по-прежнему в SDK и не помечены как deprecated. listen — это вторая, независимая реализация тех же имён, а не новый дом для старых. Это разные типы, и компилятор относится к ним именно так:

• передайте ValueNotifier из listen во flutter'овский ValueListenableBuilder — и получите ошибку компиляции, а не тонкий баг в рантайме;
• то же самое в обратную сторону и для любой другой пары с общим именем.

Где listen действительно к месту — код, в котором нет Flutter: сервер, CLI, логика, общая для того и другого. Там типов из SDK никогда не было, а теперь есть эквивалент. Внутри Flutter-приложения переход на него сегодня не даёт ничего и стоит вам совместимости по типам с каждым виджетом, который ждёт версию из SDK.

Primary constructors сами не включатся​

В Dart 3.13 приехали primary constructors, и они за флагом версии языка. Без sdk: ^3.13.0 в pubspec.yaml вы получите experiment_not_enabled даже на правильном SDK — тулчейн в порядке, это проект не просит.

Стоит, впрочем, сказать прямо: ценность экономии на бойлерплейте конструкторов сильно падает, когда этот бойлерплейт пишет не человек. Если ваши конструкторы генерируются, это изменение про читаемость, а не про продуктивность.

Остальное​

Impeller по умолчанию на десктопе, iOS 15 и macOS 12 как новые нижние границы и работа над Wasm — всё реальное, ничего срочного, и ни на что из ваших дел в этом месяце не влияет.

Что реально сделать до ноября: прогнать миграцию в ветке, нормально запинить material_ui и не трогать ChangeNotifier.

Проверено миграцией живого проекта с 3.44.0 на 3.47.2 — before/ и after/ собираются и проходят тесты каждый на своём SDK. Видеоразбор — на YouTube.

Вот во что она обходится на самом деле, в том порядке, в каком приходят счета.

Поиск никогда не был проблемой​

Фреймворк хранил одну колонку userIdentifier и искал по строгому равенству. Попроси его найти профиль по телефону или почте — и расширять просто негде: не потому что запрос сложный, а потому что сама аутентификация требует, чтобы эта колонка существовала. Убери её — и ядро падает на старте.

Так что первая правка — не «искать по двум полям». Это дать приложению право голоса в том, как находится пользователь:

DwAuthConfig(
  findUserProfileByIdentifier: (session, identifier) async {
    // приложение само решает, что значит «тот же самый человек»
  },
);

Колонка перестаёт быть обязательной, идентификатор приходит уже нормализованным, а фреймворк перестаёт делать вид, что знает, что такое личность в вашей предметной области. Три обязанности переезжают в приложение, и документация говорит об этом прямым текстом — резолвер, который молча делает не то, хуже, чем отсутствие резолвера.

Поиск по двум полям сам по себе ничего не чинит​

Вот эта часть нас и удивила, и ради неё написан этот пост.

У пользователя, который зарегистрировался по телефону, колонка с почтой пустая. Поиск по обоим полям не находит ничего нового, потому что во втором поле ничего нет. Поиск одновременно корректен и бесполезен.

Чтобы заполнить эту колонку, нужен способ привязать второй канал к существующему аккаунту — а значит, addAuthProvider и changeIdentifier должны реально работать. У нас оба бросали UnimplementedError, и экрана для этого не было ни в одном макете. Пока его нет, вход с другого канала по-прежнему тихо создаёт второй аккаунт, ровно как и раньше.

Дубли уже есть​

Дальше идёт то, что отложить не получится. Мы пошли добавлять уникальные индексы на phone и email и обнаружили, что уникальных индексов не было вообще — ни на новых колонках, ни на старом userIdentifier. Две строки с одинаковым значением уже были легальны, и поиск возвращал ту, которую базе захочется отдать.

Индекс не добавить, пока дубли не слиты. А дубли существуют именно потому что вход со второго канала раньше создавал новый аккаунт. Баг и его разгребание — один и тот же объект.

Слияние — это событие, а не действие​

Слияние аккаунтов необратимо: один профиль поглощает другой, и после этого никто не восстановит, что откуда пришло. Поэтому мы описали его как событие ProfileMerge, а не как вызов метода — кто слил, кого и что переехало. Действие оставляет базу консистентной, а историю потерянной; событие оставляет и то, и другое.

Что мы сказали бы себе неделю назад​

• «Вход по телефону или почте» — задача не про экран авторизации. Это задача про идентичность профиля, а экран — последние пять процентов.
• Выкатывайте привязку второго канала в том же релизе. Без неё фича — это поиск, который ничего не находит.
• Проверяйте уникальные индексы до того, как что-то пообещали. У нас их не было за всю жизнь проекта, и никто не заметил, потому что ничто их не требовало.
• Проверяйте на живой базе полным кругом: регистрация по телефону, привязка почты, вход по почте в тот же аккаунт, одна строка в таблице. У нас 23 серверных теста, включая этот проход; версия этой статьи, написанная по чтению кода, была бы неверна в двух местах.

Со стороны фреймворка это приехало в ядро dartway 0.12.1 — резолвер аутентификации и работающий changeIdentifier. Если вы на более ранней версии, интересная часть — миграция, а не API.