Ныряем в холодные потоки Kotlin Flow

Лето — лучшее время для сплава. Поэтому, если вы пока не в отпуске, давайте устроим короткий сплав по асинхронным потокам данных.

Статья: https://habr.com/ru/articles/922962/
Платформа: Android

Как Blinkit решил загадку производительности Android-приложения с помощью Droid Dex

Представьте себе: ваше приложение работает плавно на Pixel 7 Pro, но выдает ошибки ANR на Redmi Note 4. А пользователям Fold 6 приходится сталкиваться с теми же некрасивыми переходами, что и на устройстве за 6000 рублей. Звучит знакомо?

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

Это история о том, как Blinkit решил самую печально известную проблему Android - умную адаптацию производительности в реальном времени.

Статья: https://apptractor.ru/info/articles/droid-dex.html
Платформа: Android

SwiftUI + AlarmKit: клонируем стандартное приложение «Будильник» от Apple

AlarmKit был представлен на WWDC 2025. Насколько прост будет переход от идеи к рабочему приложению с AlarmKit?

Что уже умеет фреймворк:

• Хранит запланированные, активные, повторяющиеся и одноразовые будильники через единый daemon-store.
• Предоставляет готовый UI для Live Activities (отображение на Lock Screen и в Dynamic Island).
• Работает на основе WidgetKit, ActivityKit и AppIntents — всё уже сделано за нас, но надо разобраться

Что автор называет проблемным:

• Нет «истории» сработавших будильников — нужно хранить самому.
• Alarm‑объект содержит только id, расписание и длительность — ни названий, ни метаданных, ни времени срабатывания .
• Синхронизацию UI на главном экране приходится делать вручную — например, с помощью кастомных объектов и dynamicMemberLookup

AlarmKit — мощный и перспективный фреймворк, но требует своих костылей для полноценного приложения-замены. Автор справляется с ним смело: дизайн не идеальный, поэтому туториал — must-read для всех, кто хочет попробовать новые механизмы в iOS 26.

Статья: https://levelup.gitconnected.com/swiftui-alarm-app-copycat-with-alarmkit-wwdc-2025-part-1-27fad3186791
Платформа: iOS

ComponentsKit - библиотека с красивыми компонентами UIKit и SwiftUI для более быстрой разработки iOS-приложений. Библиотека помогает вам быстрее создавать красивые, функциональные интерфейсы — без необходимости каждый раз заново изобретать общие элементы пользовательского интерфейса. Независимо от того, работаете ли вы над новым проектом или улучшаете существующее приложение, ComponentsKit предоставляет вам набор готовых компонентов, которые легко интегрировать, настраивать и обслуживать. Благодаря единому API, легкой архитектуре и поддержке тем и конфигурации ComponentsKit разработан для плавного встраивания в любую кодовую базу iOS.

ComponentsKit на GitHub: https://github.com/componentskit/ComponentsKit
Платформа: iOS
⭐️: 51

Автоматическое отслеживание изменений в UIKit и AppKit: функция, о которой Apple забыла упомянуть

Помните, когда вышел SwiftUI, мы все удивлялись тому, как автоматически обновляются представления при изменении @Published свойств? Что ж, Apple тихо работает над тем, чтобы привнести эту же магию в UIKit и AppKit. А что самое лучшее? Она уже появилась в iOS 18/macOS 15, но о ней вряд ли кто-то знает. Вам даже не нужен Xcode 26, достаточно одной простой записи plist. Включите его с помощью ключа, и ваши представления волшебным образом обновятся при изменении ваших @Observable моделей. Больше никаких ручных вызовов setNeedsDisplay()!

Статья: https://apptractor.ru/info/articles/observation-tracking.html
Платформа: iOS

Новый навык в ИИ — не промпт, а контекст инжиниринг

Контекстная инженерия (контекст инжиниринг, Context Engineering) — это новый термин, набирающий популярность в мире ИИ. Разговор переходит от "промпт инжиниринга" к более широкой и мощной концепции - "контекст инжинирингу". Тоби Лютке описывает его как «искусство предоставления всего контекста для задачи, которая может быть правдоподобно решена LLM», и он прав.

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

Статья: https://apptractor.ru/info/articles/context-engineering.html
Платформа: разработка

Есть ли «потолок» в [Android] разработке - обсуждение на Reddit

Я уже некоторое время работаю в роли разработчика мобильных приложений (Android) и не могу отделаться от ощущения, что это короткий карьерный путь. После 6–9 лет в этой роли есть ли куда двигаться?

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

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

Поэтому я задаюсь вопросом — это все? Люди просто продолжают делать одно и то же в течение 10–15 лет, пока их не заменят более молодые разработчики, которые могут сделать ту же работу дешевле? Или есть естественный путь перехода (в бэкенд, продукт или что-то еще), который действительно имеет смысл?

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

Обсуждение: https://www.reddit.com/r/androiddev/comments/1lnxex4/is_mobile_development_a_deadend_after_69_years/
Платформа: разработка

Kizzy - редактор статусов (Rich Presence) для Discord, написанный полностью на Kotlin и Material You. Может обнаруживать запущенные приложения/игры, музыку, кастомные статусы и т.п. и постить их в профиль в Discord.

Kizzy на GitHub: https://github.com/dead8309/Kizzy
Платформа: Android
⭐️: 3.3K

Управление состоянием в навигации в Jetpack Compose

Статья Дмитрия Глазунова посвящена грамотному управлению состоянием в приложениях на Jetpack Compose при использовании навигации. Автор показывает, какие проблемы могут возникать — например, потеря данных при возвращении назад или сложности с передачей аргументов между экранами — и объясняет, почему важно правильно распределять ответственность между ViewModel, SavedStateHandle, rememberSaveable и CompositionLocal.

Главная мысль статьи — не существует универсального решения для всех случаев. Состояние, связанное с бизнес-логикой и жизненным циклом экрана, должно храниться во ViewModel; данные интерфейса — в rememberSaveable; а контекстно-общие значения — через CompositionLocal. Для сложных пользовательских потоков стоит использовать общие ViewModel на navGraph-уровне. Такой подход делает архитектуру приложения предсказуемой, модульной и устойчивой к изменениям.

Статья: https://proandroiddev.com/managing-state-across-navigation-in-jetpack-compose-7ff5a9f49864
Платформа: Android

VIPER против TCA: что на самом деле используют большие iOS-команды

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

В то же время на сцену всё активнее выходит TCA — The Composable Architecture. Это более современный подход, особенно хорошо сочетающийся со SwiftUI. Он предлагает мощные инструменты для управления состоянием и построения экранов с минимальным количеством шаблонного кода. Разработчики отмечают, что с TCA быстрее удаётся запускать новые фичи, упрощается навигация и появляется больше гибкости. Однако этот подход требует определённой архитектурной дисциплины и может быть непростым для новичков.

Интересно, что на практике команды часто не выбирают строго один путь. Некоторые начинают с VIPER, когда проект находится на ранней стадии и важно задать чёткие рамки. А затем постепенно переходят на TCA, особенно при внедрении SwiftUI и желании ускорить разработку пользовательского интерфейса. Таким образом, обе архитектуры находят своё место: VIPER остаётся надёжным фундаментом для больших кодовых баз, а TCA — инструментом для новых, динамичных компонентов.

Авторы статьи подчёркивают, что VIPER не так плох, как о нём говорят, если важна структура, а TCA действительно мощный, если использовать его грамотно. Идеального выбора нет — важно понимать контекст и потребности проекта. В крупных командах можно встретить и ту, и другую архитектуру, а иногда — и их сочетание.

Статья: https://medium.com/ios-journeys/viper-vs-tca-what-large-ios-teams-actually-use-0d44887cb0ba (как читать ©)
Платформа: iOS

Понимаем и улучшаем производительность SwiftUI

Airbnb впервые внедрил SwiftUI в 2022 году, начав с отдельных компонентов, а затем расширив его до целых экранов и функций. Мы увидели значительные улучшения производительности инженеров благодаря его декларативной, гибкой и компонуемой архитектуре. Однако внедрение SwiftUI принесло новые проблемы, связанные с производительностью. Например, в SwiftUI есть много общих шаблонов кода, которые могут быть неэффективными, и множество небольших проблем могут в совокупности привести к большому кумулятивному снижению производительности. Чтобы начать решать некоторые из этих проблем в масштабе, мы создали новый инструментарий для упреждающего выявления этих случаев и статической проверки правильности исправлений.

Статья: https://apptractor.ru/info/articles/ponimaem-i-uluchshaem-proizvoditelnost-swiftui.html
Платформа: iOS

OAuthKit - это современный, event-driven пакет Swift, который использует Observation Framework для реализации шаблона проектирования Наблюдатель и публикации событий OAuth 2.0. Это позволяет разработчикам приложений без усилий настраивать OAuth провайдеров и концентрироваться на разработке исключительных приложений, а не беспокоиться о тонкостях потоков авторизации.

OAuthKit на GitHub: https://github.com/codefiesta/OAuthKit
Платформа: iOS
⭐️: 19

Бенчмарк ИИ-помощников в устранении сбоев мобильных приложений

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

В этом отчете со сравнительным анализом мы оцениваем производительность GitHub Copilot, Cursor, Claude Code и SmartResolve (внутренний инструмент самого Instabug) при автоматической генерации исправлений для сбоев мобильных приложений как на iOS, так и на Android.

Статья: https://apptractor.ru/measure/crash-analytics-bug-tracking/benchmark-ii-pomoschnikov-v-ustranenii-sboev-mobilnyh-prilozheniy.html
Платформа: разработка

Чистая архитектура — это большая ложь, в которую мы продолжаем верить

Чистая архитектура, как ее проповедуют в каждой второй статье на Medium и в руководствах на YouTube, часто является скорее религией, чем разумным подходом. Особенно во Flutter, где разработчики тратят недели на настройку «идеальных слоев» только для того, чтобы создавать TODO-приложения. Пришло время поговорить о мифе чистой архитектуры и о том, почему слепое следование ей может навредить вашему коду, вашей команде и вашему продукту.

Статья: https://apptractor.ru/info/articles/chistaya-arhitektura-eto-bolshaya-lozh-v-kotoruyu-my-prodolzhaem-verit.html
Платформа: разработка

Jetpack Android Starter - надежный, готовый для реальной работы шаблон для современного Android-приложения, который избавит вас от боли при настройке нового проекта. Созданный на основе архитектуры Now In Android, этот шаблон предоставляет всеобъемлющую отправную точку как для новых, так и для опытных Android-разработчиков.

Внутри есть: аутентификация на основе Firebase, чистая архитектура, современный стек разработки (Jetpack Compose, Material3, Hilt, корутины, Retrofit, Coil, Timber, Lottie, ktlint и т.д.), типобезопасная навигация, надежное хранение данных с Room и DataStore, интеграция с Firebase (Firestore, Analytics и Crashlytics), фоновая синхронизация на основе WorkManager, локализация, CI/CD на основе GitHub Actions.

Jetpack Android Starter на GitHub: https://github.com/atick-faisal/Jetpack-Android-Starter
Платформа: Android
⭐️: 131

Diarization (или Speaker Diarization) — это процесс автоматического определения, кто говорит когда в аудиозаписи. Грубо говоря, система делит аудиофайл на сегменты по разным говорящим.

FluidAudio — Swift Speaker Diarization на CoreML. Это высокопроизводительный фреймворк Swift для диаризации на устройстве и обработки звука, разработанный для соответствия самым высоким стандартам. Цель — максимизировать производительность, используя исключительно модели CoreML. Все модели были вручную преобразованы командой разработчиков из вариантов с открытым исходным кодом и доступны на Hugging Face.

FluidAudio на GitHub: https://github.com/FluidInference/FluidAudio
Платформа: iOS
⭐️: 156

Пишем 3D-игру для ретро-устройств весом в 600Кб…

Иногда у меня лежит душа просто взять и написать какую-нибудь небольшую игрушку с нуля, без использования готовых движков. В процессе разработки я ставлю перед собой интересные задачки: игра должна весить как можно меньше, работать на как можно большем числе платформ и использовать нетипичный для меня архитектурный паттерн. Недавно я начал писать ремейк классических «танчиков» и в рамках серии статей готов рассказать о всех деталях разработки трёхмерной игры с нуля в 2025 году. Если вам интересно узнать, как работают небольшие 3D-демки «под капотом» от написания фреймворка до разработки геймплея — прочитайте статью!

Статья: https://habr.com/ru/companies/timeweb/articles/924472/
Платформа: Android

Решаем проблему скелетных загрузчиков и создаем иллюзию скорости без перекомпозиции

Cкелетные загрузчики (Skeleton loader) играют важную роль в современном пользовательском опыте. Имитируя структуру контента, пока он еще загружается, они убеждают пользователей, что приложение работает, и помогают сократить воспринимаемое время ожидания. Но, несмотря на то, что они кажутся простым визуальным заполнителем, скелетные загрузчики часто под капотом скрывают тонкие и раздражающие проблемы.

Статья: https://apptractor.ru/info/articles/skeleton-loaders.html
Платформа: Android

Почему я перестал использовать структуры для всего в Swift

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

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

Вот почему я перестал использовать структуры для всего в Swift — и почему вы тоже можете захотеть переосмыслить это.

Статья: https://apptractor.ru/info/articles/struct.html
Платформа: iOS/Swift