Flutter сталкивается с новыми ограничениями, а релиз iOS 26 вносит большие изменения в нативный UI. В статье расскажем, почему выбор именно нативных технологий помогут продуктам оставаться конкурентоспособными.

❗️Дисклеймер

Эта статья не прогнозирует «закат» Flutter. Она о том, как новый iOS 26 подчёркивает разницу между технологиями мобильной разработки. Можно разработать что угодно и на чём угодно — вопрос лишь в ресурсах, стоимости и итоговом качестве. 

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

В последние годы Flutter завоевал популярность, как способ сравнительно недорого запускать мобильные приложения. Это кроссплатформенный фреймворк от Google, с которым можно разрабатывать сразу под iOS и Android, используя один и тот же код на языке Dart (основной язык Flutter). 

Скорый выход iOS 26 может усилить разницу между нативными и кроссплатформенными технологиями. Apple Intelligence и новый визуальный стиль Liquid Glass в нативных приложениях будут работать максимально полно, тогда как в кроссплатформенных — с ограничениями и оговорками. 

На фоне растущих пользовательских требований к мобильным продуктам, именно нативный стек оказывается единственным способом реализовать UI/UX, соответствующий гайдлайнам Apple, и достичь полноценной интеграции с системой. Flutter и другие кроссплатформенные решения по-прежнему подходят для MVP и утилитарных задач. Но чем сложнее интерфейс и функциональность, тем выше затраты на поддержку и адаптацию.

В статье разберёмся, какие технологические изменения в 2025 году сделали ставку на натив не просто трендом, а важным преимуществом. Когда краткосрочная оптимизация затрат должна уступить место стратегическим инвестициям? И как мы в студии мобильной разработки CleverPumpkin искали компромиссы и к какому выбору пришли.

Презентация Apple: что изменилось в iOS 26

Мы придерживаемся простого принципа: экономия оправдана, если она не снижает надёжность и не создаёт долгосрочных рисков. А с выходом iOS 26 мы получили еще больше подтверждений, что выбранная стратегия верна.

На WWDC 2025 Apple представила ряд нововведений, которые напрямую затрагивают визуальные стандарты iOS и возможности системы. Эти изменения повышают требования к разработке и поддержке кроссплатформенных приложений.

Пройдемся по главным.

Liquid Glass UI — новый визуальный стиль с реалистичной имитацией стекла, анимациями, слоями, прозрачностями и реакцией на окружение. В качестве базового компонента, не требующего дополнительных трудозатрат на интеграцию, он доступен только в нативных SwiftUI и UIKit. В Flutter уже появились первые плагины с подобными эффектами, но их производительность и соответствие нативному UI пока под вопросом. 

Apple Intelligence — on-device AI, встроенный в iOS. Он работает через Core ML и Neural Engine и требует полноценной работы с системными компонентами. Кроссплатформенные фреймворки не исключают интеграцию, но она потребует дополнительных нативных обёрток и вероятно может быть неполной. При этом бизнес-логика скорее всего будет вынужденно разделена между iOS и Android, поскольку Apple Intelligence доступен только внутри экосистемы Apple. И на текущий момент нет решений, которые бы объединяли бы работу on-device AI на iOS и Android.

Интерактивные виджеты могут быть реализованы только в нативной части приложений. В Flutter их можно реализовать, написав нативный компонент вручную, что потребует привлечения разработчиков со знанием нативных языков. А если таких интеграций становится несколько, то снижается ценность единой кодовой базы, ради которой кроссплатформу и выбирают.

Улучшения Swift и экосистемы Apple — язык получает улучшения производительности, возможностей тестирования и скорости разработки.

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

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

Конкурентоспособность Flutter ослабевает

Flutter на протяжении долгого времени представлялся как «быстрая и дешёвая» разработка благодаря единому коду. MVP на Flutter можно разработать за меньший бюджет. Но с ростом продукта и, в том числе, выходом iOS 26 эта модель начинает рушиться. Требования к дизайну, производительности и нативной интеграции растут, а Flutter может не успевать адаптироваться в том же темпе. 

При стремлении устранить эти нюансы первоначальная экономия оборачивается удвоенными затратами на доработку UI/UX, внедрение обходных решений и поддержание нужного уровня пользовательского опыта. Развитие продукта становится всё более затратным. 

Далее рассмотрим основные проблемы подробнее.

Рост техдолга

Интеграция с нативными API в Flutter невозможна напрямую — для этого приходится писать так называемые «бриджи»: специальные мосты, которые соединяют код на Dart (основной язык разработки Flutter) с нативным кодом на Swift/Objective-C для iOS и Kotlin/Java для Android. Такой подход требует поддерживать два уровня логики: нативный и Flutter. Это усложняет архитектуру, увеличивает количество «прослоек» и влечёт дополнительные затраты на поддержку.

Любое обновление платформы может потребовать доработок сразу в двух местах: в нативной части, где реализованы API, и в коде на Dart, который с ними взаимодействует. По опыту, это увеличивает риск роста технического долга и снижения производительности.

Например, компания AGIMA опубликовала перевод статьи «Интеграция нативных SDK во Flutter-приложение». В ней отмечено, что использование мостов взаимодействия с нативным кодом требует тщательного подхода к отладке и заставляет разработчиков параллельно работать с Flutter DevTools, Xcode и Android Studio, что опять же увеличивает время на разработку. 

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

Flutter-UI — это не нативный UI

В Flutter интерфейс рендерится через собственный движок, а не через системные компоненты платформы. Поэтому даже с использованием Cupertino widgets — компонентов, стилизованных под iOS, интерфейсы на Flutter ощущаются иначе. Они не поддерживают системные жесты, анимации и визуальные эффекты так же точно, как SwiftUI или UIKit. Из-за этого скролл, анимации и отзывчивость элементов приложения могут ощущаться непривычными для пользователей. 

Liquid Glass UI — это динамические прозрачности, сложные переливы, реакция на окружение. Подобные эффекты во Flutter могут быть реализованы вручную, но это требует дополнительных трудозатрат, а интерфейс все равно может выглядеть иначе по сравнению с нативным интерфейсом от Apple. На текущий момент нет полноценной реализации Liquid Glass UI для Flutter.

Кроме того, Flutter изначально проектировался, как инструмент для создания единых интерфейсов сразу под две платформы. Но с каждым релизом iOS и Android визуалы начинают всё сильнее расходиться. iOS делает ставку на стеклянные, глубоко анимированные интерфейсы, а Android — на Material Design 3 с минимализмом и модульностью. Унифицированный Flutter-UI в этих условиях выглядит неестественно и не специфично платформам.

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

Даже сами разработчики Flutter это косвенно подтверждают. С каждым обновлением сообщество отправляет десятки запросов на поддержку нативных визуальных эффектов — от Liquid Glass до кастомных анимаций. Это показывает, что разработчики заинтересованы в создании качественного, платформо-специфичного UI. Но в результате приходится создавать два разных дизайна (под iOS и Android), при этом используя технологию, которая не может полноценно реализовать ни один из них.

Бизнес-риски 

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

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

Например, компания Ozon Tech публично описала переход с Flutter на нативную разработку из-за технических ограничений. Поддержка новых API: новые функции iOS появляются во Flutter с задержкой от месяца до года.

Таким образом, появляется кадровый риск: поддержка Flutter-приложений требует специалистов, которые одинаково хорошо владеют и Dart и нативными языками. Таких разработчиков немного, а их привлечение и удержание обходятся бизнесу дороже.

Хотя Dart по-прежнему входит в топ-30 языков программирования, в профессиональных чатах можно встретить сомнения студентов и джунов, насколько оправдано начинать карьеру с Flutter, если нативные технологии открывают больше карьерных перспектив.

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

Мультиплатформенные альтернативы Flutter

Мы в CleverPumpkin используем нативные технологии там, где важно качество интерфейса, производительность и доступ ко всем возможностям ОС. Как альтернативу предлагаем Kotlin Multiplatform. И вот почему:

Нативные технологии = максимум возможностей

iOS приложения получает трендовый Liquid Glass UI и полный доступ ко всем возможностям платформы‎. Android приложения также получают все преимущества нативной разработки. Мы используем Jetpack Compose — фреймворк от Google для создания интерфейсов.

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

Kotlin Multiplatform = ниже затраты без потери качества

UI остаётся нативным, а логика — общей. Это снижает бюджет на 20-40% без ущерба UX. Такой уровень экономии достигается за счёт того, что большая часть бизнес-логики пишется один раз и переиспользуется на обеих платформах. При этом не нужно дублировать работу отдельных команд — одна отвечает за общее ядро, а интерфейсы разрабатываются под каждую ОС отдельно. В результате сокращаются часы разработки, упрощается тестирование и снижается количество ошибок, связанных с расхождением логики на разных устройствах.

Например, в Lemana Pro (до переименования — Leroy Merlin) команда внедрила Kotlin Multiplatform. Все визуальные элементы и взаимодействие с пользователем разрабатывались отдельно для iOS и Android. А вот внутренняя логика приложения — обработка данных, бизнес-правила, сетевые запросы — была вынесена в общий код, который работает на обеих платформах. В результате сократились затраты на разработку и ускорился выпуск обновлений, при этом пользовательский опыт остался на высоком уровне.

Развитие Kotlin Multiplatform с 2024 года усилило его позиции. Google стал активно продвигать KMP как основное решение для кроссплатформенной разработки, в том числе в рамках Android-разработки. Напротив, инвестиции в Flutter были частично перераспределены и команда сокращена. 

Плавный переход на KMP без полной переработки 

Kotlin — язык #1 для Android, KMP поддерживается Google и JetBrains, растёт сообщество разработчиков и опыт коллег.

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

Например, в Avito применяют KMP для создания внутренних библиотек, пробуют использовать его и для продуктовых обновлений и переиспользуют всё, кроме UI. 

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

Активно применяют и международные бренды: Netflix, Autodesk, Philips и другие.

Этот подход используем и мы. Например, для сервиса покупки билетов Kassir.ru мы внедрили KMP для унификации бизнес-логики между Android и iOS. Часть функций реализована на этом фреймворке, что позволило сократить время разработки, повысить стабильность и снизить затраты на поддержку.

Что это даёт бизнесу?

Использование натива и KMP даёт нашим клиентам реальные конкурентные преимущества:

• Надёжность и устойчивость. Приложение, написанное нативно, живёт дольше, проще обновляется, легче проходит модерацию. Мы часто обновляем проекты прямо в день выхода новой iOS.

• Доступ ко всем возможностям платформы. Будь то виджеты, живые иконки, on-device AI — бизнес получает их сразу. Это важно в финтехе, e-com, образовании.

• Безопасность и производительность. Нативный код быстрее, безопаснее, потому что позволяет реализовать максимум защиты данных и проще сертифицируется. Особенно важно для банковских и медицинских продуктов.

• Инклюзивность. Поддержка accessibility-фич в iOS и Android встроена в нативные UI-компоненты. Это критично для госсектора, медицины, образования.

Делаем ставку на будущее

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

Обновления Apple только усилили давно понятный тренд — максимум возможностей даёт только натив. И если вы строите продукт с прицелом на рост, качество, конкуренцию — стратегический выбор очевиден. Независимо от того, какие обновления выпустит Flutter в будущем, фундаментальные ограничения кроссплатформенных решений остаются: задержки в поддержке новых функций платформ, компромиссы в производительности и качестве UI, растущая сложность поддержки.

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

Современный мобильный рынок не прощает компромиссов в качестве. Пользователи, попробовав идеальный мобильный сервис, ожидают такого же уровня качества от любого продукта. В этом случае приложения на кроссплатформенных фреймворках с их ограничениями в производительности и UI/UX становятся конкурентным недостатком. Нативная разработка и KMP позволяют создавать продукты, которые не просто соответствуют ожиданиям пользователей, но и превосходят их.

В следующем материале мы подробнее сравним преимущества и недостатки типов разработки на примере известных брендов. Также готовим статью о том, как изменятся интерфейсы при переходе с iOS 18 на iOS 26, и как использовать Liquid Glass UI.

_{Источник}

Это блог CleverPumpkin. 14 лет мы создаём мобильные приложения и цифровые сервисы под ключ — от идеи до поддержки. На Хабре мы делимся опытом, рассказываем о проектах, технических сложностях и решениях, которые помогают бизнесу достигать целей. Если вы ищете аутсорс-команду, способную превратить идею в надёжный и удобный мобильный продукт — пишите нам в Telegram.