Производительность Flutter-приложения напрямую зависит от качества написанного кода: лишние перестроения UI, тяжёлые операции в основном потоке, неправильная работа со списками и изображениями — всё это ведёт к фризам, падению FPS и ухудшению пользовательского опыта.
В данной статье мы собрали наиболее распространённые ошибки, которые снижают производительность Flutter-приложений, и показали, как их избежать на практике.
Проведя аудит GitHub, я обнаружил, что полноценных реализаций Gemini-клиента с глубокой проработкой архитектуры практически нет. Я решил стать первым, кто выложит в открытый доступ не просто обертку над API, а готовую архитектурную базу с точным повторением UI оригинального Gemini.
Казалось бы, Apple — компания, которая возвела пользовательский опыт в культ. Но ровно до того момента, пока вы не решите стать частью их экосистемы как разработчик. Если вы думали, что самое сложное в iOS-деве — это разобраться с делегатами или SwiftData, то спешу вас расстроить: настоящий босс ждёт на этапе энроллмента.
Ситуация абсурдна до боли: ты стоишь с карточкой в руках, готовый отдать заветные $99, но официальное приложение Apple Developer превращается в глухую стену. На этапе «I agree» вместо приветственного письма ты получаешь в лицо типичный корпоративный «от ворот поворот»: Unknown Error. Please try again.
Меня зовут [неважно], я бизнес-аналитик. Моя работа — писать ТЗ, рисовать процессы в BPMN, ругаться с разработчиками из-за неправильно понятых требований и пить кофе на стендапах. За 5 лет в профессии я не написал ни одной строчки кода. Ни одной. Даже Hello World.
В начале 2026-го я поймал себя на мысли, которая наверняка посещала каждого бизнес-аналитика: «Я точно знаю, что нужно сделать. Я подробно описываю как это должно работать. Единственное, чего я не могу — написать код». А потом я прочитал очередной пост про то, как кто-то с помощью ИИ создал приложение за выходные, и подумал: а что если моя профессия — это и есть идеальная подготовка к работе с ИИ-ассистентами?
Спойлер: через 2 недели у меня было 2 приложения в RuStore, 0 рублей затрат и 14 скачиваний. Да, четырнадцать. Но обо всём по порядку.
При разработке мобильных приложений на Flutter рано или поздно сталкиваешься с необходимостью проверить, как твой интерфейс выглядит на разных устройствах. Держать под рукой десяток телефонов и планшетов — нереально, а постоянно переключаться между эмуляторами — долго и неудобно.
Для решения этой проблемы я написал пакет yx_virtual_device, который позволяет симулировать экраны различных устройств прямо во время разработки, не выходя из запущенного приложения. В этой статье — о том, что умеет этот пакет, как с ним работать, а также почему было сложно подружить его с Flutter и как в итоге это удалось сделать.
Хабр, привет! Меня зовут Никита Евдокимов, я работаю старшим разработчиком в «Лаборатории Касперского», а также являюсь мейнтейнером репозитория Kaspresso. Это наш фреймворк для тестирования пользовательских интерфейсов на Android, основанный на Kakao, Espresso и UI Automator.
Недавно в нем появилась новая функция: сравнение скриншотов. С ней можно записывать скриншоты приложения, а на последующих прогонах автотестов сравнивать их с новыми скриншотами и отслеживать изменения в интерфейсе. В статье я пошагово покажу, как с ней работать, со скриншотами и примерами кода.
Материал подойдет для как опытных, так и начинающих специалистов в области автотестирования, а также для дизайнеров: функция облегчает автоматическое тестирование, с ней быстрее и проще проверять, соответствует ли разработанное приложение макету.
Всем привет! Я Данила Горячкин — iOS-инженер в команде Performance в Авито. Занимаюсь оптимизацией производительности iOS‑приложений и менторингом разработчиков.
В этой статье последовательно разберем, как Swift управляет памятью: от базовых понятий вроде ARC, Copy‑on‑Write, экзистенциальных контейнеров до нетипичных задач с «зомби»-объектами и non-frozen типами. Материал основан на документации Swift, докладах WWDC и практических примерах. Статья рассчитана на middle- iOS‑разработчиков, которые хотят лучше понимать, что происходит с их кодом на уровне памяти и почему одни решения оказываются дороже других.
Эта статья выйдет в двух частях: в первой разберем теорию, а во второй — практические примеры с кодом.
В этой статье я собираюсь показать вам Android фичу, представленную в 2012 году, и попробую написать для неё UI на Compose.
Изучая недра Android, я наткнулся на один Service, который привлек моё внимание. Класс, который я обнаружил, не только заинтриговал меня своим названием, но и снова удивил интересными возможностями, скрытыми внутри Android.
В новом дайджесте сетевой слой в iOS и сериализация Kotlin, 10 ошибок, которые Android-разработчиков и сожаление о выборе профессии, что происходит с подписочной моделью в приложениях, как перестать бояться Claude Code и научить его не ломать проекты, и многое другое. Заходите!
Если вы хотите сделать мобильное приложение для Северной Европы, то предлагаю узнать, что было драйверами самых успешных приложений в 2025 году.
Перевод отраслевого исследования группы компаний продуктовой разработки Framna.
Методология
Мы провели это исследование, используя модель App Pulse — многомерный подход, разработанный для оценки успеха приложений в различных рынках, отраслях и демографических группах. Данный отчет представляет собой основанный на данных ориентир для оценки эффективности приложений, помогая понять, что способствует их долгосрочному успеху. Исследование мобильных приложений в Северной Европе основано на данных 600 приложений и 9000 пользователей.
Итак, продолжу рассказ о том, как в один прекрасный день, оказавшись на задворках блокировок мессенджеров, я решил создать свой собственный. Изначально проект задумывался как простое средство коммуникации с родными и партнерами по бизнесу. Но вот во что это вылилось спустя всего 4 месяца... Ранее писал о том как всё это начиналось [тут] и [тут]
Аудитория и первые стресс-тесты
На текущий момент у мессенджера уже появилась своя постоянная аудитория, причем многие из этих людей мне совершенно незнакомы! Регистрации идут каждый день, что дает отличный фидбэк, но вместе с тем устраивает настоящий стресс-тест для систем.
Большое внимание пришлось уделить группам. Изначально они были задуманы максимально примитивно, но с ростом числа пользователей и пониманием их потребностей фокус сместился на серьезную доработку групповых чатов:
В программах, которыми мы пользуемся, важное значение имеют функции, позволяющие нам выполнять все действия быстро и эффективно. Но помимо этого всегда приятно, когда приложение, которое мы видим каждый день, было красивым. Мы решили в этот раз не только предложить новые функции, но и добавить немного шарма в браузер. Готовы? Поехали.
Я просто хотел выложить мобильное приложение и начать зарабатывать. В итоге – блокировка Google-аккаунта, несколько кругов ада с тестированием и квест с выводом денег. Рассказываю, как это было и почему это оказалось сложнее, чем написать само приложение
Тема сериализации данных является базой для любого мобильного разработчика, поскольку используется для работы с сетью, файловой системой и коммуникацией между основными компонентами. Но есть в этом вопросе особенность, с которой я столкнулся впервые за 7 лет.
Именно об этом открытии и пойдет речь в статье — о смеси двух методов сериализации, — а также о том, почему для решения этой задачи важно разбираться в работе разных видов classLoader. Информация из статьи поможет вам постепенно мигрировать на Parcelable в нужных местах, не переписывая сразу все классы на новую технологию.
Перевод статьи Лорелея Уитмен, RevenueCat
Ключевые выводы из крупнейшего в мире набора данных о подписочных приложениях
Краткое содержание
Рынок подписочных приложений быстро меняется. Старые приложения по-прежнему доминируют по доле выручки, но новые каждый день наводняют cторы. ИИ-приложения «умирают» быстрее, чем успевают выходить, а зона безопасной выручки для среднего приложения стремительно исчезает. «Выживания» больше нет: либо процветаешь, либо выгораешь.
Каждый год наш отчёт «Состояние подписочных приложений» ставит целью понять, что меняется в индустрии: что нового, что ушло в прошлое и что нас ждёт. В этом году наш набор данных снова вырос: более 115 000 приложений, представляющих более 16 миллиардов долларов выручки. И мы проанализировали данные по всем 115 тысячам из них.
Если вы думали, что прошлогодний отчёт был исполином, отвернитесь сейчас. В этом году мы подготовили 338 страниц, готовых дать вам любую метрику, ориентир или тренд, который только может понадобиться.
Если перефразировать слова Дэвида Барнарда: «Есть много приложений, которые зарабатывают много денег».
Но если у вас (как это ни удивительно) нет времени читать каждую страницу полного отчета, то этот краткий обзор для вас. Начнем!
В статье проектируется с нуля мобильное устройство для измерение емкости на микроконтроллере ATmega8.
Привет, Хабр! Я Александр, занимаюсь Flutter разработкой продукта Свой бизнес и Дизайн-системы в команде РСХБ.Цифра. РСХБ это не только банк топ 5* по размеру активов, но и огромная экосистема Своё со множеством мобильных приложений разной тематики: банкинг, туризм, жильё, маркетплейс фермерских продуктов, поиск работы в агропромышленном комплексе и другие .
Когда продукты завершают взрывной рост и появляется необходимость в единстве дизайна и согласованности компонентов, в действие вступает единая дизайн-система. В этой статье рассмотрим инструмент Widgetbook для проектов на Flutter, а именно, как он позволяет ускорить проектирование, контролировать качество компонентов и замыкать единый процесс взаимодействия дизайнеров и разработчиков.
Привет, Хабр! Меня зовут Андрей Юрин, я мобильный разработчик в онлайн-кинотеатре «КИОН». Недавно у нас произошел ребрендинг, который коснулся всех платформ, но ресурсов на весь идейный план не хватало. Было решено все делать в мини-команде супергероев из дизайнеров и разработчиков. Я был в зоне отвественности за Android TV и хочу поделиться, с какими проблемами пришлось столкнуться и как проходит ребрендинг в большой компании.
Всем привет! Меня зовут Дмитрий Воронцов и я хочу кратко рассказать о своей новой low-code платформе NodaLogic, построении решений с помощью узлов(нодов) и свое видение будущего. Я автор мобильного фреймворка SimpleUI которому скоро исполняется 7 лет и в этой статье будут некоторые пересечения с ним – я хочу рассказать, зачем я сделал отдельную архитектуру, а не стал продолжать SimpleUI.
7 лет назад, когда я начинал Simple я хотел сделать LowCode фреймворк на котором разработчик может быстро разработать мобильное решение, как дополнение к своей учетной системе. Тогда еще не было LLM. Но ориентиры во все времена одинаковые – чтобы решение было легко поддерживать и развивать, масштабировать – оно должно быть простым, компактным, читаемым. Объем кода может быть и не точный показатель, но когда на один и тот же функционал требуется в 10 (а то и в 100) раз больше/меньше строчек это сигнал. Этот ориентир у меня остался и для новой системы, как важнейший. Ведь не важно, что теперь разработчику не нужно писать, но ему нужно «читать решение», анализировать что ему нагенерила нейросеть, чтобы направлять ее. И понятно, что можно взять любой стек и язык программирования и сгенерировать решение на нем, но будет ли при этом достигнут тот уровень простоты и читаемости как в LowCode фреймворке?
Платформа позволяет делать клиент-серверные решения с мобильными самостоятельными оффлайн/онлайн фронтами-приложениями (Android) веб-клиентами и серверами. Естественно, единая семантика на веб и на мобильную платформу. Также можно делать и чисто мобильные фронты, мобильные приложения без сервера.
Привет, Хабр.
Я работаю учителем математики и информатики в солнечном Таиланде. Во время школьных каникул, вместо регулярных путешествий по Азии я решил развлечь себя изучением синтаксиса JavaScript.
Когда-то, мы с моей замечательной (но ныне бывшей) женой фанатели от нестандартных судоку со знаками «больше-меньше», мы сами печатали себе уникальные сетки, а иногда, я даже рисовал их руками на основе готовых шаблонов из интернета.
В этой статье я хочу рассказать об эволюции моего математического движка генерации сеток судоку: от наивного перетаскивания массивов к строгой комбинаторике и факториальной системе счисления.