👣 Flutter: как фреймворк, который «умер», стал самым популярным кроссплатформенным решением.

В русскоязычном ИТ-сообществе существует интересный феномен: некоторые технологии умудряются умирать годами, при этом демонстрируя стабильный рост и принятие в индустрии. Flutter - чемпион в этой категории. Пока в комментариях в интернете пишут очередные некрологи, статистика рассказывает другую историю: каждое третье, новое iOS-приложение в 2024 году создано на Flutter, а в Google Play таких приложений уже более полумиллиона.


Разрыв между нарративом и реальностью:

Есть два параллельных мира Flutter. В первом фреймворк постоянно умирает. Во втором живут реальные метрики - Flutter является самым популярным кроссплатформенным решением уже четвертый год подряд.

Интересно, что этот разрыв не уникален для Flutter. Подобное происходило с Kotlin («зачем нужен, когда есть Java»), TypeScript («сложно, просто пишите на JavaScript»), и многими другими технологиями, которые в итоге стали стандартом индустрии.


Что говорят цифры:

Если отключить эмоции и включить аналитику, картина выглядит иначе:

🔵Рост доли рынка: в App Store доля Flutter-приложений выросла с 10% в 2021 до почти 30% в 2024 среди отслеживаемых бесплатных приложений.

🔵Экосистема: pub.dev насчитывает 55 тысяч пакетов - рост на 10 тысяч за год.

🔵Сообщество: 170 тысяч звезд на GitHub, что делает Flutter третьим по популярности проектом Google после TensorFlow и Kubernetes.

🔵Принятие индустрией: Google Pay, Google Ads, приложения BMW, Alibaba, eBay - все используют Flutter в production.

Эти цифры не из пресс-релизов Google. Это данные из отчетов Apptopia, Stack Overflow Developer Survey и публичной статистики магазинов приложений.


Почему нарратив «Flutter мертв» так живуч:

Есть несколько психологических и социальных причин:

🔵Эффект негатива: критические комментарии получают больше внимания, чем нейтральные или позитивные.

🔵Инерция мышления: сформировавшееся несколько лет назад мнение сложно изменить, даже когда факты меняются.

🔵Трибализм: разработчики, вложившиеся в другие технологии (нативную разработку, React Native, KMP), защищают свой выбор.

🔵Сложность оценки: чтобы объективно оценить современный Flutter, нужно потратить время на изучение, что проще заменить мнением «я где-то слышал, что он тормозит».

Интересно, что аналогичная ситуация была с Docker в начале 2010-х («виртуалки надежнее») и с Kubernetes в середине 2010-х («сложно, зачем»).


Реальные проблемы Flutter в 2025:

🔵Сложность state management для новичков (хотя это скорее богатство выбора).

🔵Производительность на экстремально сложных UI (карты с тысячами объектов).

🔵Размер приложения (добавляет 4-9 МБ к базовому размеру).


🔗 Ссылка на подробную статью


💡 Вывод:

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

Flutter в 2025 году - это зрелая, стабильно развивающаяся технология с четкой нишей: создание кроссплатформенных приложений с контролируемым, одинаковым UI на всех платформах. Она не подходит для всего (как и любая другая технология), но для своей ниши предлагает отличное решение.

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


➡️ Flutter & Dart | Мобильный трудоголик

📱 Git Merge vs Rebase: В чем разница?

Обе команды объединяют изменения из одной ветки в другую, но делают это по-разному.


Git Merge:

Создает новый коммит слияния, сохраняя историю всех веток.

# Переключись на ветку, куда нужно влить изменения (например main).
git checkout main  

# Влить изменения из ветки feature.
git merge feature

Плюсы:

🔵Простота использования.

🔵Сохраняет полную историю.

Минусы:

🔵Захламляет историю коммитами слияния.


Git Rebase:

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

# Переключись на feature ветку.
git checkout feature

# Перебазировать ее на main.
git rebase main

Плюсы:

🔵Чистая, линейная история.

🔵Нет лишних коммитов слияния.

Минусы:

🔵Может усложнить работу в команде (переписывает историю).

Когда вы делаете rebase, Git фактически переписывает историю коммитов - создает новые коммиты с тем же содержимым, но другим хешем.
Если вы уже запушили ветку в удаленный репозиторий, обычный git push без --force не сработает, потому что локальная история и на сервере расходится.

git push --force

Когда что использовать:

🔵Merge: для публичных веток (main, dev).

🔵Rebase: для локальных feature веток перед мержем.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Как виджеты AbsorbPointer и IgnorePointer управляют поведением интерфейса.

В арсенале Flutter-разработчика есть десятки виджетов для построения визуала, но ключевое качество современного интерфейса - не только красота, но и его предсказуемое поведение. Как элегантно запретить двойное нажатие на кнопку, сделать слайдер только для чтения или временно приостановить все жесты в сложной форме? Для этих задач существуют специальные виджеты-контроллеры, которые оставаясь невидимыми, кардинально меняют логику взаимодействия. Сегодня разберем двух таких стражей порядка: AbsorbPointer и IgnorePointer.


Суть проблемы - управление потоком событий:

Каждое нажатие, свайп или скролл в приложении - это событие (event), которое проходит определенный путь (hit test) по дереву виджетов, чтобы найти целевой элемент. Иногда необходимо этот поток прервать или перенаправить. Именно здесь на сцену выходят невидимые виджеты-обертки. Их главная задача - влиять на процесс обработки жестов, не изменяя при этом внешний вид дочерних виджетов.


AbsorbPointer - полная блокировка:

Это стена. Когда absorbing: true, все касания останавливаются на этом виджете. События не проходят к дочерним виджетам и не ищут другие цели.

Пример: кнопка отправки формы. Нужно заблокировать ее во время загрузки, но оставить видимой с анимацией:

AbsorbPointer(
  absorbing: isLoading,
  child: ElevatedButton(...),
)

IgnorePointer - сквозное игнорирование:

Это невидимка. При ignoring: true виджет пропускает события сквозь себя. Hit-тестирование продолжается, события могут попасть в виджеты ниже.

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

Stack(
  children: [
    InteractiveMap(),
    IgnorePointer(
      child: PromoBanner(),
    ),
  ],
)

Главное отличие:

🔵AbsorbPointer: события не проходят вообще.

🔵IgnorePointer: события проходят сквозь к виджетам позади.


Критические сценарии:

🔵Модальное окно с затемнением фона - нужен AbsorbPointer для блокировки фона.

🔵Анимированный индикатор поверх контента - нужен IgnorePointer, чтобы контент оставался кликабельным.

🔵Временное отключение поля формы - IgnorePointer, если нужно сохранить структуру hit-теста.


💡 Вывод:

Выбор между AbsorbPointer и IgnorePointer - это не вопрос вкуса, а вопрос архитектуры взаимодействия. Он сводится к простому решению: нужно ли изолировать проблемную зону от всей системы событий (AbsorbPointer), или же требуется точечно выключить один виджет, не трогая общий поток (IgnorePointer).

Понимание этой разницы - признак зрелости разработчика. Оно позволяет не костылять отключение через onPressed: null (что портит UX, меняя визуальную обратную связь) или сложные флаги в состояниях, а использовать декларативный и точный инструмент. Эти невидимые виджеты - фундамент для создания проработанного, устойчивого к нежелательным действиям пользовательского интерфейса, где каждое взаимодействие находится под вашим полным контролем.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Offstage: пререндеринг без боли.

Привет! Во Flutter, где каждое изменение состояния может запускать перестроение дерева виджетов, управление производительностью часто сводится к искусству скрытия. Не буквального, а архитектурного. Когда перед нами встает задача заранее подготовить сложный фрагмент интерфейса, но не показывать его немедленно, на помощь приходит неочевидный, но мощный виджет Offstage. В отличие от простого условного рендеринга, его работа гораздо тоньше и направлена на решение конкретных проблем с производительностью и состоянием.


Принцип работы:

Ключевое отличие Offstage от Visibility с флагом visible: false или условного оператора (if (condition) Widget()) - в его отношении к дереву. Когда вы оборачиваете виджет в Offstage(offstage: true), происходит следующее:

🔵Виджет физически исключается из процесса лейаута (layout). Система его не измеряет и не размещает, как если бы его не существовало.

🔵Виджет остается активной частью дерева виджетов. Его состояние (State), контроллеры анимаций (AnimationController), подписки (StreamSubscription, Listenable) продолжают жить и работать.

🔵Виджет не отрисовывается (не вызывает paint). Это экономит вычислительные ресурсы GPU.

Этот принцип «жить, но не мешать» создает уникальные возможности.


Ключевые сценарии применения:

🔹 Пребилдинг ресурсоемких экранов и вкладок. Представьте навигацию с табами, где каждый таб - это сложный экран с сетями, графиками или списками. Используя Offstage для неактивных вкладок, вы избегаете:

🔵Полного пересоздания состояния и загрузки данных при каждом переключении.

🔵Мерцания или задержек, пока виджет инициализируется с нуля.

🔵Это классический паттерн для TabBarView или кастомных навигационных решений, где нужно сохранять состояние экранов.

🔹 Сложные, готовые к показу модальные окна или меню. Если диалог или боковое меню должно появляться мгновенно по жесту или кнопке, его можно заранее построить и спрятать в Offstage. В момент показа (offstage: false) произойдет только включение в лейаут и отрисовка - без инициализации контроллеров, загрузки ассетов или вычисления сложной логики. Это критично для создания ощущения отзывчивости интерфейса.

🔹 Управление жизненным циклом для оптимизации. Иногда виджет должен продолжать выполнять фоновую работу (например слушать поток данных или считать таймер), но не должен быть виден. Offstage позволяет сохранить эту логику, не отвлекая ресурсы на ненужный лейаут и отрисовку. Альтернатива - вынос логики в родительский виджет или сервис, что часто нарушает инкапсуляцию.


Технические нюансы и ограничения:

🔵Размер. Хотя Offstage не участвует в лейауте, технически он может иметь размер, если ему переданы ограничения (constraints). Однако чаще его используют с size: Size.zero, чтобы он точно не занимал места.

🔵Не для всего. Не стоит оборачивать в Offstage бесконечно растущие списки (ListView.builder) с активными подписками на скролл - это может привести к утечке памяти. Инструмент эффективен для ограниченных по сложности виджетов, которые точно понадобятся.

🔵Альтернатива IndexedStack. IndexedStack - это, по сути, умный Stack, показывающий один из нескольких детей. Под капотом он использует похожий механизм для невидимых дочерних виджетов. Offstage дает более точечный, ручной контроль в случаях, когда логика показа/скрытия сложнее простого индекса.


Пример - быстрое переключение вкладок:

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

Stack(
  children: [
    Offstage(
      offstage: _currentTab != 0,
      child: SettingsScreen(), // Живое состояние
    ),
    Offstage(
      offstage: _currentTab != 1,
      child: ProfileScreen(), // Контроллеры активны
    ),
  ],
)

💡 Вывод:

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


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter: как FractionallySizedBox и FittedBox спасают адаптивную верстку.

Создание адаптивного интерфейса во Flutter часто сводится к использованию MediaQuery и расчетам на основе размеров экрана. Но есть два менее известных, но исключительно мощных виджета, которые решают специфичные задачи адаптивности на уровне композиции, без сложной математики. FractionallySizedBox и FittedBox - это не просто обертки, а точные инструменты контроля пропорций и масштабирования.


FractionallySizedBox - размер в процентах:

Этот виджет задает размер дочернего элемента как долю от родителя. Например, кнопка на 80% ширины контейнера:

FractionallySizedBox(
  widthFactor: 0.8,
  child: ElevatedButton(...),
)

Главное условие: родитель должен иметь конкретный размер. Не будет работать в Column без Expanded, где ширина не ограничена.


FittedBox - умное масштабирование:

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

FittedBox(
  child: Text('Заголовок', style: TextStyle(fontSize: 40)),
)

Это предотвращает OverflowError и автоматически подбирает размер.


В чем разница между FractionallySizedBox и FittedBox:

🔵FractionallySizedBox управляет контейнером (задает его размер как процент от родителя).

🔵FittedBox управляет содержимым (масштабирует виджет внутри существующего контейнера).


Когда что использовать:

🔵Используйте FractionallySizedBox для: кнопок фиксированной ширины, прогресс-баров, колонок сетки.

🔵Используйте FittedBox для: текста в ограниченной области, иконок в CircleAvatar, изображений-превью.


💡 Вывод:

Изучение адаптивности во Flutter не должно начинаться и заканчиваться на MediaQuery.of(context).size.width. Такие виджеты, как FractionallySizedBox и FittedBox, предлагают декларативный и композиционный подход к решению распространенных проблем верстки. Они смещают фокус с реактивного программирования («посчитай размер экрана и обнови») на декларативное описание отношений между элементами интерфейса («этот элемент занимает половину родителя, а его содержимое подстраивается под доступное пространство»).

Внедрение этих виджетов в повседневную практику сокращает количество кастомных расчетов, делает код чище и предсказуемее, а главное - создает по-настоящему гибкий интерфейс, который корректно ведет себя не только на разных размерах экрана, но и в сложных, вложенных layout-структурах. Это следующий уровень мастерства после освоения Row, Column и Flex.


➡️ Flutter & Dart | Мобильный трудоголик

🔨 Как установить несколько Xcode с разными версиями?

При возникновении необходимости в установке нескольких, разных версий среды разработки Xcode на одной машине можно воспользоваться удобным приложением Xcodes, которое является удобным менеджером версий Xcode.


Зачем нужно:

🔵Тестирование приложений на разных версиях Xcode (включая бета-версии).

🔵Работа с проектами, которые требуют конкретной версии (например, legacy-код).

🔵Возможность не обновлять основной Xcode, если новая версия вызывает баги.


Особенности данной утилиты:

🔵Поддерживает процессоры Apple Silicon и Intel.

🔵Показывает релизные заметки для каждой версии.

🔵Упрощает установку и переключение между версиями Xcode.

🔵Автоматически скачивает нужные версии (включая старые и beta).

🔵Не требует ручного управления через xcode-select.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter+Rust: новый стек для системы HyperOS от Xiaomi

Компания Xiaomi анонсировала новую версию своей системы: HyperOS 4. Ключевое изменение: переход системных приложений на Flutter для UI и Rust для системной логики. Это не косметическое обновление, а замена технологического стека.


Проблема:

Старая кодовая база MIUI - это смесь Java, Kotlin и кастомного кода. Результат: фрагментация интерфейсов, сложная поддержка, раздутая прошивка.


Решение:

🔵Flutter для всего UI. Единый фреймворк отрисовки для всех системных приложений (настройки, файлы, часы). Цель: идентичный интерфейс на всех устройствах и упрощение разработки.

🔵Rust для системного кода. Язык для драйверов, сервисов, работы с железом. Причины: безопасность памяти (нет GC), производительность на уровне C/C++.


Архитектурные выгоды:

🔵Модульность: команды могут разрабатывать приложения независимо.

🔵Упрощение поддержки: один стек вместо зоопарка технологий.

🔵Потенциал для быстрых обновлений: возможность обновлять системные приложения отдельно от прошивки.


Риски:

🔵Память: Runtime Flutter увеличит потребление RAM.

🔵Интеграция: сложные мосты между Flutter/Rust и обязательным слоем Android (Google Play Services).

🔵Квалификация: необходимы разработчики на Dart и Rust.

🔵Отладка: сложная диагностика проблем в цепочке Flutter - Rust - Android.


🔗 Ссылка на новость


💡 Вывод:

Xiaomi пытается заменить legacy-код единым современным стеком. Цель: получить управляемую, модульную и производительную систему. Успех даст им преимущество. Провал станет дорогим уроком о пределах кроссплатформенных решений на системном уровне. Это крупнейший технологический эксперимент среди Android-производителей.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Запущен комплексный образовательный путь по Dart и Flutter

Команда Dart и Flutter представила масштабное обновление образовательных материалов - целостный обучающий путь «Getting Started Experience». Это не просто очередной туториал, а продуманная экосистема для входа в технологию, созданная с учетом современных принципов педагогического дизайна и пользовательского опыта.


Структурный подход к обучению - от любопытства к пониманию:

Новый подход кардинально отличается от традиционной документации. Вместо разрозненных статей и примеров кода предлагается последовательный путь, состоящий из взаимосвязанных модулей:

🔵Мгновенный старт без барьеров. Используя возможность горячей перезагрузки в вебе (hot reload), новички могут начать писать код на Flutter прямо в браузере, минуя сложную настройку локального окружения. Это снижает порог входа с первых секунд.

🔵Двухэтапное погружение: отдельные, но связанные курсы по Dart и Flutter. Это решает классическую дилемму: изучать язык и фреймворк вместе или раздельно. Теперь можно пройти основы Dart, а затем перейти к Flutter, либо начать сразу с фреймворка, если есть опыт в других ООП-языках.

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

🔵Видеоролики с человеческим лицом. Обучение дополнено серией видео, где ключевые концепции объясняют не дикторы за кадром, а реальные инженеры, технические писатели и менеджеры продуктов из команд Dart и Flutter. Это создает эмоциональную связь и знакомит новичков с сообществом.

🔵Интерактивные элементы и финальный босс. После каждого модуля - простые неблокирующие квизы для самопроверки. А кульминацией пути становится рекомендованная серия видео «How Flutter Works», которая раскрывает внутреннее устройство фреймворка, переводя разработчика на новый уровень понимания.


Реорганизация сайтов - ясность и навигация:

Обновление затронуло и инфраструктуру сайтов Dart и Flutter. Они были переведены на Jaspr - статический генератор сайтов на Dart. Более заметное для пользователя изменение - четкое разделение контента:

🔵Раздел «Learn»: теперь дом для всех обучающих материалов, путей и туториалов.

🔵Раздел «User Guides»: содержит основную техническую документацию и справочные материалы.

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


Что это значит для экосистемы? Тренд на качество онбординга:

Данный запуск - это сигнал всей индустрии. Команда Dart и Flutter демонстрирует, что инвестиции в developer experience (DX) начинаются не с продвинутых инструментов, а с момента, когда потенциальный разработчик только задумывается о выборе технологии. Такой подход:

🔵Снижает коэффициент оттока на старте. Меньше разработчиков бросают изучение из-за сложностей первоначальной настройки или непонимания, с чего начать.

🔵Формирует лояльное сообщество. Чувство поддержки и качественный входной опыт создают позитивное восприятие технологии в долгосрочной перспективе.

🔵Задает новый стандарт. Другим фреймворкам и языкам теперь придется равняться на столь же продуманный и человеко-ориентированный процесс обучения.


🔗 Ссылка на подробную статью


💡 Вывод:

Новый «Getting Started Experience» - это больше чем апдейт документации. Это стратегическая инвестиция в будущее экосистемы. Он превращает хаотичное первоначальное знакомство с Flutter и Dart в продуманное, поддерживающее и эффективное путешествие от первого интереса до глубокого понимания технологии. Для всех, кто присматривался к Flutter, но откладывал из-за «не знаю, с чего начать» - сейчас идеальный момент.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter на Авроре получил апгрейд: что дает включение Impeller

В мире Flutter уже несколько лет говорят о Impeller - новом рендеринговом движке от Google, призванном решить главную боль разработчиков: фризы и лаги анимаций «на холодную». Пока для iOS он включен по умолчанию, а для Android только на новых версиях, команда разработки под ОС Aurora решила не оставаться в стороне и добавила экспериментальную поддержку этой технологии в свою экосистему. Разберем, что это дает на практике и стоит ли спешить с включением.


Чем Impeller отличается от Skia и почему это важно для Aurora:

Долгое время Flutter полагался на Skia - мощный, но универсальный графический движок. Его слабое место - компиляция шейдеров в рантайме, которая и вызывает те самые пресловутые фризы при первом отображении сложных интерфейсов. Решения существовали (прекомпиляция, прогрев приложения), но они усложняли разработку.

Impeller - это ответ Google на эту проблему. Его ключевая особенность - предсказуемое время отрисовки каждого кадра за счет отказа от компиляции шейдеров на лету. Для Аврора, которая позиционируется как стабильная и производительная отечественная платформа, такая оптимизация особенно актуальна, так как напрямую влияет на пользовательское восприятие приложений.


Особенности реализации - работа с OpenGL и текущие ограничения:

На Aurora графика работает через стек Wayland + OpenGL. Команда разработки интегрировала OpenGL-бэкенд Impeller, который в upstream-версии Flutter имеет статус экспериментального и не рекомендуется к использованию. Потребовалась доработка: например, реализация корректного преобразования матриц для поддержки альбомной ориентации.

Важный нюанс: включение Impeller на Аврора - это опция, а не замена по умолчанию. Активируется она флагом --enable-impeller при запуске. Это разумный подход, учитывая, что не все сценарии отрисовки в этом режиме стабильны, возможны артефакты в отдельных виджетах (как в примере с Checkbox).


Цифры и факты - что показывают тесты производительности:

Тестирование на планшете с Aurora 5.2.0 дает неоднозначную, но в целом обнадеживающую картину:

🔵Холодный запуск и навигация. В тестовом приложении переход на новый экран с анимацией при использовании Skia вызывал фризы как на UI-, так и на Raster-потоке. С Impeller фриз остался только на UI-потоке, в то время как GPU-рендеринг (Raster) выдавал стабильные 60 fps. Это прямое свидетельство того, что Impeller справляется со своей основной задачей - стабилизацией отрисовки.

🔵Сравнение под нагрузкой. В синтетическом тесте, нагружающем UI и Raster, результаты оказались неоднозначными. При выполнении стандартных операций, таких как построение списков или рисование на Canvas, разница в производительности между Skia и Impeller была практически незаметна. Однако ключевое преимущество нового рендерера проявилось в специализированном сценарии: отрисовке сложных визуальных эффектов. При работе с тенями, размытиями, градиентами и прозрачностью производительность Raster-потока с Impeller увеличилась примерно вдвое, что демонстрирует его существенное превосходство в данной нише.


🔗 Ссылка на подробную статью


💡 Вывод:

Поддержка Impeller в операционной системе Аврора - это важный, но экспериментальный шаг. Новый рендерер демонстрирует реальные преимущества в стабильности отрисовки и производительности сложных эффектов, приближая опыт разработки под Aurora к мировым стандартам Flutter. Однако из-за сырости OpenGL-реализации и возможных артефактов в интерфейсе переходить на него на проде пока рано. Для Аврора это возможность, а не обязательство - стратегический задел на будущее, когда Impeller окончательно созреет.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter 3.41: стабильность, модульность и подготовка к будущему

Google выпустил Flutter 3.41 - релиз, который выглядит как плановый апдейт, но на самом деле закладывает архитектурные изменения на годы вперед. 868 коммитов от 145 контрибьюторов, но главное не в количестве, а в направлении.


Прозрачность разработки:

Впервые Flutter вводит публичные release-окна на весь 2026 год. Теперь каждый знает точные даты заморозки веток: 3.44 выйдет в мае, 3.47 в августе, 3.50 в ноябре. Для команд, которые зависят от стабильности фреймворка, это снимает огромный пласт неопределенности. Больше не нужно гадать, попадет ли фича в ближайший релиз - календарь открыт.


Материалы и Cupertino уходят в отдельные пакеты:

Это ключевое изменение, которое многие недооценят. Material и Cupertino больше не будут привязаны к монолитному циклу релиза Flutter. Их обновления смогут выходить независимо, в любое время. Для разработчиков это означает две вещи: во-первых, вы сможете получать новые дизайн-системы (вроде Material 3 Expressive или Liquid Glass) не дожидаясь квартального обновления движка. Во-вторых, если вы застряли на старой версии Flutter из-за легаси, вы все равно сможете обновить визуальную часть отдельно. Фреймворк становится конструктором, а не монолитом.


iOS: UIScene по умолчанию и чистый blur:

Flutter окончательно прощается с наследием AppDelegate. Поддержка UIScene включена по умолчанию - это было требование Apple для будущих версий iOS, и теперь оно выполнено. Параллельно Impeller получил улучшенный рендеринг размытия: исчезли цветные ореолы по краям, которые раньше портили впечатление от BackdropFilter. CupertinoSheet обзавелся нативным drag-хендлом - мелочь, но именно из таких мелочей складывается ощущение «родного» интерфейса.


Android: подготовка к AGP 9 с осторожностью:

Важный нюанс: обновляться на Android Gradle Plugin 9 пока нельзя. Поддержка заморожена до аудита обратной совместимости. Но новые плагины уже по умолчанию генерируются на Kotlin DSL - индустрия движется, и Flutter движется с ней. Плюс появилась возможность точечно исключать ассеты для конкретных платформ: тяжелые десктопные текстуры больше не придется тащить в мобильную сборку.


Графика: синхронные текстуры и 128-битные float:

Для тех, кто работает с кастомными шейдерами, релиз принес две важные вещи. Первая - синхронное декодирование текстур. Раньше создание текстуры для шейдера могло «уронить» кадр, теперь это делается в том же фрейме через decodeImageFromPixelsSync. Вторая - поддержка 128-битных float-текстур. Это про LUT для цветокоррекции, про SDF-шейдеры и про фотофильтры на GPU. Технический потолок поднят.


🔗 Ссылка на подробное описание релиза


💡 Вывод:

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

Выделение Material и Cupertino в независимые пакеты ломает многолетнюю монолитность - теперь дизайн-системы могут эволюционировать со скоростью индустрии, а не со скоростью движка.

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


➡️ Flutter & Dart | Мобильный трудоголик

👣 Когда pubspec.yaml работает против вас: разбор типичных ошибок

Файл pubspec.yaml для многих остается просто местом, где перечислены зависимости. На деле это единственная точка, через которую Flutter общается с нативными мирами Android и iOS. Одна неверная строчка и приложение либо не собирается, либо падает на конкретных устройствах, либо молча теряет производительность. Разбираем ошибки, которые дорого обходятся на практике.


Версии, которые живут своей жизнью:

Самая частая проблема: использование кареток ^2.0.0 без понимания последствий. Запись ^2.0.0 означает «любая версия от 2.0.0 до 3.0.0, кроме ломающих изменений». Но что считать ломающим изменением для pub и что для нативного кода не всегда совпадает. Плагин может обновиться с 2.0.0 до 2.3.0, где для Android внезапно потребуются новые разрешения, а вы узнаете об этом только после релиза.

Выход: явные диапазоны версий '>=2.0.0 <3.0.0'. Да, строкой длиннее, зато контроль полный.


Платформы все же отличаются:

То, что отлично работает на iOS, может валиться на Android, и наоборот. Указывая зависимости глобально, вы часто тянете в сборку код, который не нужен на другой платформе. Или, что хуже, конфликтующие нативные библиотеки.

В pubspec.yaml можно (и нужно) указывать зависимости отдельно для каждой платформы с уточнением минимальных версий SDK, классов плагинов и прочих нативных параметров. Это не только решает конфликты, но и уменьшает размер итогового приложения.


Ресурсы, которые раздувают приложение:

🔵- assets/ - классическая запись, которая тащит в сборку вообще все, включая служебные файлы, исходники и мусор. На реальном проекте такой подход может добавить к размеру APK и IPA десятки мегабайт.

🔵Правильно - указывать точные пути и разделять ассеты по платформам. Картинки для ретина-экранов, шрифты, нативные ресурсы - все должно лежать в своих папках и подключаться адресно.


Окружение, о котором забывают:

Помимо версии Dart и Flutter, в environment стоит указывать ограничения для нативного мира: min_android_sdk, min_ios_version, kotlin_version, swift_version. Это страхует от ситуаций, когда разработчик с новым Kotlin пушит код, а у CI стоит старая версия, и сборка падает.


Плагины, которые конфликтуют:

Зависимости - это не только имена пакетов, но и их настройки. Разрешения, конфигурации, порядок инициализации - все это влияет на рантайм. Часто плагины тянут одни и те же нативные библиотеки, и без явного указания версий возникают конфликты, которые проявляются только на этапе выполнения.

В pubspec.yaml можно уточнять не только версию, но и конкретные параметры плагина для каждой платформы, включая разрешения и классы.


Сборка, которая не оптимизирована:

Флаг uses-material-design: true многие ставят не задумываясь, хотя приложению могут быть не нужны иконки Material. Но речь не только об этом. В секции flutter можно (и нужно) указывать параметры сборки для каждой платформы: proguard, multidex, bitcode, target platform. Это напрямую влияет на размер и скорость запуска.


Тесты, которые не включают:

dev_dependencies часто остаются минимальными: только flutter_test. Но для полноценной проверки нативной интеграции нужны инструменты: integration_test, flutter_driver, мок-генераторы. Их отсутствие не ломает сборку, но делает тестирование поверхностным, а баги уходят в прод.


💡 Вывод:

pubspec.yaml - не просто список зависимостей, а полноценный конфигурационный файл, управляющий нативной частью приложения. Отношение к нему как к формальности приводит к сбоям, раздутому размеру и потерянному времени на отладку. Аккуратное управление версиями, разделение по платформам и явные настройки сборки превращают этот файл из источника проблем в инструмент контроля качества. В Flutter «просто собралось» и «собралось правильно» - часто две большие разницы.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter: организация кода с помощью BLoC

Когда новичок приходит в разработку на Flutter, он быстро сталкивается с двумя вещами: виджетами и управлением состоянием. И если с виджетами все более-менее понятно: нарисовал кнопку, вывел текст, то управление состоянием вызывает вопросы. Особенно когда речь заходит о BLoC. Многие воспринимают его как очередную библиотеку, которую можно подключить и забыть. На деле BLoC - это способ перестать смешивать логику и интерфейс и начать думать потоками данных.


Состояние - это все, что видит пользователь:

Все, что отображается на экране - это состояние. Цвет кнопки, текст в заголовке, видимость лоадера - все это состояния. Даже пустой контейнер - это состояние, просто со значением «ничего не показывать».

Когда приложение маленькое, состояние можно хранить прямо в виджете. Вызвал setState и интерфейс обновился. Но как только логика усложняется, такой подход превращает код в кашу. Презентация мешается с бизнес-логикой, а разобраться, почему при нажатии на кнопку что-то пошло не так, становится сложно.

Выход - отделить логику от отрисовки. Вынести состояние наружу, сделать его независимым от виджетов. И вот здесь появляется BLoC.


Как BLoC меняет правила игры:

BLoC (Business Logic Component) работает по простой схеме: события -> обработка -> новые состояния. Пользователь нажал кнопку - это событие. BLoC его поймал, сходил в репозиторий, что-то посчитал и выдал новое состояние. Виджет это состояние увидел и перерисовался.

Важно, что BLoC ничего не знает о том, как именно рисуется интерфейс. Ему все равно, текст это, кнопка или анимация. Его задача: принять событие, выполнить логику и вернуть состояние. За это его и ценят: логика становится переиспользуемой и тестируемой независимо от UI.


Архитектура вокруг BLoC:

BLoC тянет за собой организацию кода. Чтобы он работал осмысленно, нужно выстроить слои:

🔵Data Layer: модели, репозитории, провайдеры данных (API, база).

🔵Business Logic Layer: сам BLoC, который обрабатывает события и общается с репозиториями.

🔵Presentation Layer: виджеты, которые подписаны на состояния и реагируют на них.

Такое разделение позволяет менять один слой, не трогая другие. Захотели заменить REST API на GraphQL - меняете только Data Layer. Интерфейс переехал на новую дизайн-систему - трогаете только Presentation Layer.


Улучшенное тестирование:

Когда логика вынесена из виджетов, ее становится легко тестировать. BLoC можно скормить события и проверить, какие состояния он выдал. Это не требует запуска приложения, эмулятора или взаимодействия с UI. Просто юнит-тесты, которые бегут за секунды.


🔗 Ссылка на подробную статью


💡 Вывод:

BLoC - это не просто способ управлять состоянием. Это способ думать о приложении как о потоке данных, где интерфейс - лишь отражение текущего состояния. Да, порог входа выше, чем у setState. Но когда проект вырастает, именно архитектура спасает от хаоса. BLoC заставляет разделять ответственность, писать тестируемый код и не смешивать логику с отрисовкой.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Elementary: MVVM архитектура в Flutter без боли и лишнего кода

Когда проект вырастает, вопрос организации кода встает особенно остро. Разработчики начинают искать способы отделить логику от интерфейса, сделать код тестируемым и не потерять в производительности. Одно из решений: библиотека Elementary, которая предлагает свой взгляд на построение архитектуры Flutter-приложений, основанный на MVVM и вдохновленный лучшими практиками Clean Architecture.


Особенности Elementary:

В основе подхода лежит четкое разделение на три слоя:

🔵View (ElementaryWidget): только описание интерфейса. Здесь нет логики, только декларативное построение UI на основе данных, которые приходят из WidgetModel.

🔵ViewModel (WidgetModel): презентационная логика. Определяет, что показывать, как реагировать на действия пользователя, управляет состояниями виджетов.

🔵Model (ElementaryModel): бизнес-логика и работа с данными. Взаимодействует с сервисами, репозиториями, API. Не имеет доступа к Flutter-специфичным вещам.

Такое разделение решает несколько проблем, с которыми сталкиваются разработчики в больших проектах.


Почему это удобно:

🔵Четкие границы ответственности. Любой новый разработчик в команде сразу понимает, где искать UI, где презентационную логику, а где работу с данными. Это снижает порог входа и упрощает код-ревью.

🔵Тестируемость. Бизнес-логика изолирована от фреймворка, ее можно покрывать юнит-тестами без запуска виджетов. WidgetModel тестируется отдельно, подменяя зависимости. В результате тесты пишутся проще и охватывают больше кейсов.

🔵Производительность за счет умных обновлений. Elementary использует паттерн «наблюдатель» для свойств. Вместо тотального перестроения всего виджета обновляются только те части UI, которые подписаны на изменившиеся данные. Это особенно заметно на сложных экранах с большим количеством интерактивных элементов.

🔵Полностью декларативный UI. WidgetModel предоставляет всё необходимое для отрисовки, а ElementaryWidget просто описывает, как это должно выглядеть. Подход UI = f(state) реализуется естественно и без лишних усилий.


О гибкости Elementary:

Elementary не навязывает жестких правил, но задает удобные рамки. Внутри WidgetModel вы можете использовать любые привычные инструменты - ValueNotifier, Stream, ChangeNotifier. Главное, чтобы они выполняли свою задачу: уведомлять UI об изменениях точечно, а не целиком.

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


🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Flutter & Dart | Мобильный трудоголик