⏰Привет! Это Анна, Flutter Team Lead Friflex

Сегодня поговорим о той самой лотерее, которой опасаются все разработчики — отправке приложения на проверку в AppStore.

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

Первая проверка нового приложения — процесс небыстрый. Официально никакого временного регламента нет, но как показывает практика, лучше закладывать на это около 7 дней. Перед отправкой оцените обстановку — если впереди праздники, например, как сейчас близится Новый Год и Рождество, будьте готовы к увеличению срока. Обычно об этом в App Store Connect заранее появляется сообщение.

Повторные проверки и проверки обновлений уже опубликованного приложения проходят значительно быстрее — обычно в течение 1-2 суток. Но опять же на праздники срок может растянуться.

Теперь поговорим о том, на что стоит обратить внимание при подготовке:

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

Стабильность
Приложение не должно вылетать — это важно не только для положительного пользовательского опыта, но и для проверки. Если какие-то сценарии вызовут краш вашего приложения при проверке, сборка точно будет отклонена.

Отсутствие вывода отладочной информации
Перед публикацией стоит почистить все вызовы методов вывода отладочной информации — print, debugPrint.

Разрешения
Особое внимание уделяется всем разрешениям, которые запрашивает приложение. Во-первых, приложение не должно запрашивать неиспользуемые разрешения. А во-вторых, каждое разрешение обязательно должно иметь четкое обоснование, прописанное в Info.plist. Это описание будет отображено пользователю в нативном окне. Если App Store посчитает формулировку недостаточно информативной, сборка может быть отклонена.

Нативные интеграции
Если вы добавляете в свой проект платформенные функции, требующие специфичной нативной настройки, обязательно обратите особое внимание на соблюдение всех этапов подключения, а также досконально проверьте работоспособность. Это относится, например, к push-уведомлениям и in-app покупкам.

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

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

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

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

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

🐱А вы сталкивались с проблемами при прохождении проверки в AppStore? Делитесь своим опытом в комментариях.

Обновление дизайна от Apple с активным использованием glass effect вызвало у многих споры: кому-то понравилось, а кто-то был просто в ужасе. Чуть позже к этому тренду подтянулись и другие продукты, и в итоге мы внезапно оказались в мире стеклянных интерфейсов🐈

А теперь давайте представим, что мы ТОЖЕ ХОТИМ ТАК ЖЕ! Как же быть?
Есть 2 решения: воспользоваться готовыми библиотеками или реализовать все самостоятельно.

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

Именно поэтому BackdropFilter почти всегда используют вместе с ClipRRect или ClipPath. Без него фильтр применится ко всей области экрана, а не только к нужному участку.

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

Простейшая реализация может выглядеть так:

class GlassContainer extends StatelessWidget {
  final double width;
  final double height;
  final Widget child;

  const GlassContainer({
    Key? key,
    required this.width,
    required this.height,
    required this.child,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return ClipRRect(
      borderRadius: BorderRadius.circular(25),
      child: BackdropFilter(
        filter: ImageFilter.blur(sigmaX: 18, sigmaY: 18),
        child: Container(
          width: width,
          height: height,
          decoration: BoxDecoration(
            color: Colors.white.withOpacity(0.15),
            borderRadius: BorderRadius.circular(25),
            border: Border.all(
              color: Colors.white.withOpacity(0.2),
              width: 1.2,
            ),
          ),
          child: child,
        ),
      ),
    );
  }
}

Если хочется воспользоваться готовыми решениями, можно присмотреться, например, к пакету glass_kit — внутри он более глубоко работает с BackdropFilter и помогает добиться аккуратного эффекта размытия.

При работе с glassmorphic-дизайном важно помнить о нескольких нюансах. Размытие стоит использовать умеренно – его избыток быстро утомляет, а мы этого не хотим! Кроме того, BackdropFilter не самый дешевый в отрисовке виджет, поэтому лучше избегать большого количества перекрывающихся размытых элементов.

В следующей статье можем разобрать liquid glass эффект. Его часто считают разновидностью glassmorphism, но это не совсем так. В отличие от классического glass effect с размытием фона, liquid glass добавляет ощущение движения, текучести и визуальных искажений.

А какие библиотеки для работы с glassmorphism или готовые реализации вы используете?

Привет, я Катя, Friflex Flutter Dev. Сегодня расскажу о GenUI SDK для Flutter — инструменте, который помогает собирать динамические пользовательские интерфейсы с помощью генеративного ИИ.

Что такое GenUI SDK
GenUI SDK для Flutter — это альфа-версия SDK на pub.dev. Она предлагает другой подход к взаимодействию с пользователем: вместо текстового ответа чат-бота вы можете показывать адаптивные визуальные компоненты.

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

⭐️ Вопрос к размышлению: как часто вы сталкивались с тем, что чат-бот перечисляет товары текстом, хотя удобнее было бы сразу увидеть карточки с кнопками?

Как работает GenUI
Процесс устроен как интерактивный цикл. Пользователь вводит запрос (например: «помоги спланировать поездку в Токио»), а приложение отправляет его ИИ-агенту вместе с описанием доступных виджетов.

Дальше ИИ-агент генерирует не только текст, но и описание интерфейса с помощью инструментов GenUI SDK. Обычно это структура в формате JSON (JavaScript Object Notation), которую приложение десериализует и превращает в соответствующие Flutter-виджеты.

SDK может отрисовывать стандартные компоненты постепенно, по мере генерации ответа большой языковой моделью (LLM). Так интерфейс появляется быстрее, и пользователю не нужно ждать, пока придет ответ целиком.

Что GenUI SDK умеет
🔴Генерировать UI из структурированных данных
🔴Работать с настраиваемым каталогом виджетов
🔴Обрабатывать события и поддерживать интерактивный диалог

Каталог виджетов задает словарь Flutter-компонентов, которые ИИ может использовать. Каждый CatalogItem содержит имя виджета, JSON-схему его свойств и builder-функцию для рендеринга.

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

⭐️Попробуйте представить: какие компоненты вашего приложения могли бы генерироваться на основе запросов пользователей?

Практическое применение
GenUI SDK подходит для AI-нативных приложений. Например, вместо текстового списка продуктов можно показать кликабельную карусель, а при планировании поездки — сгенерировать форму с полями ввода и слайдерами.

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

Подробнее — в блоге Flutter: Rich and dynamic user interfaces with Flutter and generative UI.

P.S. SDK пока в альфа-версии, но уже доступен на pub.dev для экспериментов. Делитесь опытом в комментариях!

💠Привет! Это Анна, Flutter Team Lead.

Сегодня поговорим про версионирование Futter-приложений. Тема простая, но часто вызывает вопросы у начинающих разработчиков.

Наверняка вы знаете, что во Flutter-приложениях версия указывается в pubspec.yaml с ключом vesion. Выглядит это так:

version: 1.2.3+4

Для удобства восприятия возьмем буквенное представление:

version: A.B.C+D

Сочетание A.B.C отвечает за версию приложения. Значение под буквой D — за версию сборки.

Когда повышать каждый уровень версии приложения?

A — отвечает за мажорные изменения.
Повышать этот уровень точно нужно, если ваше приложение сильно менялось. Например, если вы:
✔️Полностью изменили дизайн
✔️Переработали пользовательские пути
✔️Радикально изменили или удалили ключевые функции
✔️Загрузили полностью новое приложение

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

B — минорные изменения.
Сюда обычно относятся:
✔️Новый функционал и масштабирование старого
✔️Новые пользовательские пути без критичного изменения старых

Если приложение выросло, получило новые фичи, но при этом сохранило свой предыдущий вид — нужно увеличивать уровень B.

C — мелкие фиксы и доработки.
Стоит повысить уровень С, когда вы:
✔️Вносите правки по багам или верстке
✔️Повышаете производительность приложения
✔️Выполняете рефакторинг или обновление зависимостей без влияния на ранее реализованные функции

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

А что с версией сборки?

D — версия конкретного билда.
Стандартно это значение инкрементируется в каждый новый билд вашего приложения. Независимо от изменений внутри.

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

❤️— если было полезно