Есть ли «потолок» в [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

Что такое топологическая сортировка и где она применяется

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

Статья: https://apptractor.ru/info/articles/chto-takoe-topologicheskaya-sortirovka-i-gde-ona-primenyaetsya.html
Платформа: алгоритмы

Alarmee — это библиотека Kotlin/Compose Multiplatform, разработанная для упрощения планирования будильников и уведомлений на платформах Android и iOS. С Alarmee вы можете планировать одноразовые или повторяющиеся будильники, отображать уведомления, специфичные для платформы, а кроме того она поддерживает push-уведомления с использованием Firebase Cloud Messaging (Android) и службы Apple Push Notification (iOS).

Alarmee на GitHub: https://github.com/Tweener/alarmee
Платформа: Android/кроссплатформа
⭐️: 168

Как Android-разработчик в iOS погружался: мой опыт внедрения Kotlin Multiplatform

Продукт создавали нативно на каждую платформу, без пересечения кода. В начале года у нас ушло несколько iOS-разработчиков, из-за чего замедлилась поставка новых функций на обеих платформах. Мы решили, что это повод внедрить наконец кроссплатформенную разработку и выровнять поставку фич на обеих платформах. В этом материале расскажу, почему мы остановились на KMP, как погружались в iOS c опытом в Android и как прошло внедрение этого фреймворка. Спойлер: быстрее и проще, чем мы думали.

Статья: https://habr.com/ru/companies/ru_mts/articles/923366/
Платформа: кроссплатформа

Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 1

Юзкейс (Use Case) — это основной элемент в философии «Чистой» архитектуры (Clean Architecture). Он представляет собой отдельную операцию с единственной ответственностью в рамках вашего приложения.

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

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

Реагирование на жесты в SwiftUI: перетаскивание

Узнайте, как реализовать жесты перетаскивания в SwiftUI для создания плавных и интуитивно понятных перетаскиваемых элементов интерфейса.

Статья: https://apptractor.ru/info/articles/reagirovanie-na-zhesty-v-swiftui-peretaskivanie.html
Платформа: iOS

Теперь мы все CTO

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

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

Одно это делает роль “парашютиста” особенно трудной. Это одна из причин, по которой сложно быть даже техническим директором, потому что, почти по определению, все проблемы, с которыми я сталкиваюсь, - это сложные проблемы с незнакомым мне кодом и навыками, которые я не оттачиваю.

Добро пожаловать на вашу новую должность. Я надеюсь, вы будете счастливы.

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