iOS

Airbnb написал про свой опыт улучшения производительности SwiftUI. В целом, они абстрагировались от алгоритм сравнения на основе рефлексии и написали свое решение на основе Equatable. Макрос @Equatable генерирует реализацию Equatable, которая сравнивает все сохраненные свойства экземпляра представления, исключая свойства с обертками свойств SwiftUI, такими как @State и @Environment, которые запускают обновления представления через другие механизмы. Свойства, которые не являются Equatable и не влияют на отрисовку тела представления, можно пометить с помощью @SkipEquatable, чтобы исключить их из сгенерированной реализации. Это позволяет продолжать использовать обработчики действий на основе замыканий из библиотеки однонаправленного потока данных, не влияя на процесс диффинга SwiftUI.

• Понимаем и улучшаем производительность SwiftUI
• Why I Stopped Using Structs for Everything in Swift
• SwiftUI Search API (Searchable): All We Need to Know All In One
• Grouping Liquid Glass components using glassEffectUnion on iOS 26
• Designing custom UI with Liquid Glass on iOS 26

Android

Исследуя проблемы с медленной сборкой Kotlin/Native, автор статьи погружается в мир Klib-файлов, IR (Intermediate Representation) и двух ключевых стадий компиляции: сборки IR и финального линкования. Оказывается, .klib содержит сериализованный IR-код, а не нативный бинарный, и только при сборке итогового фреймворка происходит полноценная компиляция в машинный код. Это объясняет, почему задача linkReleaseFrameworkIosArm64 может занимать до 18 минут — линковка просто не кэшируется и всегда запускается заново. В статье также раскрываются нюансы кроссплатформенных библиотек, влияние статических и динамических фреймворков, и то, почему в мобильной разработке предпочтительнее использовать статические библиотеки. Хотя линковка остаётся узким местом в сборке, понимание архитектуры K/N и устройства Klib-файлов даёт разработчику контроль над процессом и помогает принять обоснованные решения при оптимизации сборки.

• Meta присоединилась к Kotlin Foundation
• Kizzy — менеджер Rich Presence для Discord на Kotlin
• Best Practices of Retrofit and OkHttp in Android Development
• Context parameters in Kotlin 2.2
• Exploring Kotlin (native) compilation

Instabug оценил возможности AI‑ассистентов (включая GitHub Copilot, Cursor, Claude Code и SmartResolve) автоматически устранять сбои в мобильных приложениях на iOS и Android. Тесты проводились на реальных крашах, а ассистенты видели всю кодовую базу и стек‑трейсы. Критерии оценки включали корректность (40 %), схожесть с человеческими исправлениями (30 %), ясность, глубину и релевантность, что позволило получить общий показатель точности. Результаты показали, что на iOS лидирует SmartResolve с точностью 66.8%, в то время как на Android Cursor оказался лучшим с 73.9%, а SmartResolve и Copilot были близко. Однако общая производительность на Android оказалась выше, чем на iOS, за счёт более ровного распределения оценок. При этом схожесть с решениями разработчиков была заметно ниже, что подчёркивает необходимость ревью человеком. Итог: AI‑ассистенты ускоряют первые шаги по устранению крашей, но для сложных случаев, соответствия архитектуре и поддерживаемости кода критически важен контроль разработчиков.

Разработка

• Что такое топологическая сортировка и где она применяется
• Открытый и опасный: как снизить риски open-source в приложениях
• BDUI: эволюция динамических интерфейсов
• Benchmarking AI Coding Assistants for Mobile App Crash Resolution
• Clean Architecture Is the Big Lie We Keep Falling For

Кроссплатформа

• StringBuffer (Technique of the Week)
• Kotlin’s Funeral Has Been Announced? Apple’s Master Plan Behind Swift for Android

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

На Reddit новое обсуждение:

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

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

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

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

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

Вот что ему отвечают:

• Это не совсем верно в больших компаниях. Множество людей делают большие дела в приложениях Android, в производительности, в библиотеках. Они находятся на уровне L7+ (senior персонал), зарабатывают большие 6-значные суммы, в некоторых случаях 1 М+.
• Я работаю нативным Android-разработчиком уже более 11 лет, первые 3 или 4 года казались легкой работой, в основном UI/UX, как здесь упоминается, но когда у меня появилась возможность поработать над другими проектами, связанными с BLE и IoT, мои взгляды изменились, затем я на время переключился на гибридную разработку. По моему мнению, сложность моих приложений варьируется, и я получаю больше удовольствия, когда работаю над сложными транспортными слоями и сложной бизнес-логикой.
• Это касается не только мобильной разработки, учитывая, что область применения и масштаб могут быть разными. Будь то веб-разработка, бэкенд-разработка, в какой-то момент они достигнут стабильной зрелости и станут повторяющимися и просто будут поддерживать существующую систему.
• Сейчас я (в основном) вышел на пенсию после долгой и счастливой карьеры в области разработки программного обеспечения. Позвольте мне рассказать вам секрет: любая работа в области компьютерных наук становится тупиковой после 6-9 лет. Главное — не допустить этого.

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

• Если текущий стек вам не подходит: выберите альтернативный. Просто хочу отметить, что, вероятно, есть много разработчиков бэкенда, которые тоже достигли своего предела и готовы попробовать что-то еще, например, мобильные приложения ;)

iOS

Автор статьи делится опытом внедрения Redux-подобной архитектуры в SwiftUI-проекте, чтобы решить проблему рассинхронизации данных между экранами. Он показывает, как паттерн с единым хранилищем состояния, action’ами и reducer’ом хорошо вписывается в декларативный стиль SwiftUI и помогает справляться со сложной бизнес-логикой. Однако подход не идеален: обработку асинхронных действий и управление памятью приходится реализовывать вручную. Тем не менее, в крупных приложениях с множеством экранов Redux делает состояние предсказуемым и улучшает совместную разработку.

• OAuthKit — event-driven авторизация на Swift
• My App Crashed Only in Production
• Schedule a countdown timer with AlarmKit
• Redux in SwiftUI: When Web Patterns Meet Apple’s Declarative World
• SwiftUI State Machines Explained: Manage Complex UI States the Right Way
• Creating Custom Property Wrappers in Swift: Reduce Boilerplate Code
• SwiftUI Shimmer Loading Animation: Complete Implementation Guide

Android

Виталий из Альфа-Банка на Хабре продолжает исследовать тонкости Kotlin Contracs. Подробно исследует внутренности компилятора и показывает, что контракты можно применять не только к функциям, но и, например, к аксессорам свойств — хоть это и не отражено в официальной документации. Он изучает исходники компилятора, объясняет, как устроен анализ контрактов в FIR-дереве, и делится практическими наблюдениями, которые могут быть полезны для продвинутых Kotlin-разработчиков. Ничего непонятно, но очень интересно (С)

• Есть ли «потолок» в [Android] разработке — обсуждение на Reddit
• Что не пишут в документации Kotlin Contracts: тёмные закоулки и пасхалки
• Migrating to Jetpack Compose Navigation 3
• Android Studio Narwhal Feature Drop
• SIGSEGV to SIGBUS: The Truth Behind Android’s Scariest Native Crashes
• How I Built Seamless Watch ↔️ Phone Handover in Wear OS

Сохам-гейт - лучше в IT-найме уже не будет. Индийский разработчик Сохам Парех оказался в центре скандала после того, как сразу несколько основателей стартапов из США обвинили его в  «многостаночности» — одновременной работе в 3–4 компаниях, включая проекты с поддержкой Y Combinator (впрочем, еще несколько признались, что почти сразу выперли его с работы, когда поняли его подход). Несмотря на блестящие интервью и впечатляющее резюме, Сохам фактически дублировал рабочие процессы, не сообщая работодателям о параллельной занятости. Его бывшие наниматели признают: он действительно умен и обаятелен, но использовать эти качества он предпочёл не ради команды, а ради получения зарплат из разных источников. История вызвала бурную дискуссию в стартап-среде: как защищаться от таких случаев, насколько эффективны технические и кадровые проверки, и почему формат удалёнки делает такие схемы особенно лёгкими. Сам Парех, осознав масштабы разоблачения, признал в личной переписке, что «возможно, полностью разрушил свою карьеру».

Разработка

• Чистая архитектура — это большая ложь, в которую мы продолжаем верить
• Бенчмарк ИИ-помощников в устранении сбоев мобильных приложений
• Indian techie Soham Parekh accused by at least 5 US CEOs of moonlighting

Маркетинг

• Самые скачиваемые и зарабатывающие приложения в России в июне 2025
• Squad Busters 2.0 and mo.co: What We Learned from Supercell’s Experimental Era

Кроссплатформа

• 2D-скролл во Flutter
• Вы не поняли extension types в Dart
• “Expect Actual” Mechanism in Kotlin Multiplatform Explained
• Secrets, Certificates, Local Storage: The Three Risks Every App Ships With

Улучшаем потолок разработки

Новая подборка всех материалов за неделю. Понимаем и улучшаем производительность SwiftUI, решаем проблему «деградации» YouTube на Android, определяем потолок в разработке, разбираем большую ложь чистой архитектуры, смотрим на рост цифровой веры и многое другое. Заходите!

iOS

Диаризация - это процесс автоматического определения, кто и когда говорит в аудиозаписи. Грубо говоря, система делит аудиофайл на сегменты по разным говорящим. Не знаю. зачем вам это знание, но так же знайте, что в open source реализовали систему диризации на  CoreML. Так что если вам нужно выделить спикеров - используйте готовый фреймворк.

• Почему я перестал использовать структуры для всего в Swift
• FluidAudio — фреймворк диаризации на CoreML
• Glassifying toolbars in SwiftUI
• Responding to gestures: Dragging
• Using WebKit to load web content in SwiftUI
• How to make ScrollView content fill available space

Android

Кирилл (@android_broadcast) уже, кажется, разбирал фоновую работу в Android, но если вы хотите освежить свои знания - на Хабре от Облака Mail вышла статья, в которой рассматривается вся история изменений.

• Решаем проблему скелетных загрузчиков и создаем иллюзию скорости без перекомпозиции
• Сеньоры с LinkedIn или доверяй, но проверяй. Как мы докатились до такого?
• Как мы случайно ускорили релизную сборку в два раза
• Эталонный пример Android приложения от Google
• Jetpack Android Starter — шаблон современного Android-приложения
• Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 1
• Хроника изменений API фоновой работы в Android
• Функциональное программирование в Android. Теория категорий и DI
• Deep Dive into Jetpack Compose Text Views : The Secret Life of Composable
• Don't use Type-safe Project Accessors with Kotlin Gradle DSL
• Curious case of missing Bottom Sheet Previews
• Is this a first nail in the ViewModel’s coffin?

А вот Артем из Membrana Kids пишет о том, как внедряли KMP в свой iOS-проект. Всего за два спринта. Пишут, что довольны - переход снизил трудозатраты на новые функции и устранил рассинхронизацию логики между платформами, особенно критичную в проектах с быстрыми изменениями и параллельной разработкой.

Разработка

• Применение KISS для архитектуры автотестов
• Что такое Фильтр Блума
• Будущее инструментов разработки и опенсорса
• Вычисления на GPU — CUDA, NVidia, AMD
• Интеграция Flutter Mobile SDK в ОС Аврора
• You're all CTO now

Маркетинг

• Доход Cluely удвоился за неделю, но конкуренты наступают

Кроссплатформа

• Демо-интервью по Flutter с Middle-разработчиком
• Как Android-разработчик в iOS погружался: мой опыт внедрения Kotlin Multiplatform
• Часть 2. GoForm — как не страдать с формами во Flutter
• Alarmee: Schedule Local and Push Notifications in KMP
• Cross-Platform Apps Done Right: My Experience with Kotlin + Compose Multiplatform

iOS

С мест докладывают, что топ-менеджер Apple, курирующий внутренние модели ИИ, покидает компанию и переходит в корпорацию на M. Как сообщает Bloomberg, Руоминг Панг переезжает в Менло-Парк и присоединяется к звездной группе M*** Superintelligence Labs Марка Цукерберга. Панг перешел в Apple из Google в 2021 году и руководил командой из примерно 100 человек, стоящей за моделями, которые поддерживают функции Apple Intelligence, такие как Genmoji, Priority Notifications и текстовое резюме на устройстве. Его уход наносит еще один удар по усилиям Apple по созданию конкурентоспособных моделей ИИ внутри компании. «Уход Пана может стать началом череды уходов из группы Apple Foundation Models, и несколько инженеров сообщили коллегам, что планируют уйти в ближайшем будущем. Том Гантер, главный заместитель Пана, покинул Apple в прошлом месяце».

• Реагирование на жесты в SwiftUI: перетаскивание
• Глава Foundation Models ушел из Apple
• Swift Actors: What Are They For?
• Swift Protocols Every Developer Should Know: Equatable, Hashable, Identifiable, Comparable
• How to Write Thread-Safe Code in Swift?
• Grouping elements within a Glass Effect Container in SwiftUI
• Real-time systems with Combine and WebSockets
• Building Redux from Scratch in SwiftUI: Production-Ready Implementation

Android

В Kotlin object гарантирует синглтон — один экземпляр на всё приложение. Но это работает только до тех пор, пока не вмешиваются библиотеки сериализации. Например, Gson при десериализации создаёт новый экземпляр объекта, нарушая сравнение === и ломая логику, завязанную на глобальное состояние. Moshi вообще не поддерживает object без кастомного адаптера, а вот kotlinx.serialization корректно обрабатывает такие случаи, возвращая оригинальный экземпляр. Если вы используете object для хранения состояния или как синглтон в архитектуре, важно понимать, как с ним работают сторонние библиотеки. Чтобы сохранить гарантию единственного экземпляра — используйте kotlinx.serialization или пишите собственные адаптеры для других библиотек.

• Alarmee — будильники, локальные и push-уведомления на Android и iOS
• Рулим светодиодом по UDP и ESP8266
• Basic Guide to Animation in Jetpack Compose
• When Kotlin object Stops Being a Singleton
• SnapshotFlow or collectAsState? How to pick the right tool for Jetpack Compose
• It’s All About (Accessibility) Focus And Compose

Сначала это кажется магией: вы пишете пару подсказок — и ИИ сам пишет код, строит архитектуру, решает рутину. Вы больше не разработчик — вы менеджер агентов. Продуктивность на максимуме, и всё летает. Но потом приходит пустота. Вы больше не мучаетесь с зависимостями, не ночуете в дебаггере, не проходите этот бесконечный путь проб и боли. Зато пропадает дофамин — тот самый кайф от «я сам всё сделал». Вам больше не нужно страдать — и именно в этом проблема. Разработка превращается в управление. Всё больше инженерной работы — это orchestration. Вы не пишете код — вы его планируете. Не решаете задачу — вы её декомпозируете. Даже не дебажите — вы объясняете ИИ, что и где не так. Ваши навыки уходят в тень. Руки помнят, но уже не летают по коду, как раньше. Вы ещё можете «спасти проект», но уже не как автор, а как "спасетль-парашютист", брошенный в незнакомый ландшафт, сгенерированный ИИ. Выгорание становится тише, но глубже. Нет острой боли — но нет и яркой радости. Вы чувствуете, что делаете много — но чувствуете ли вы, что сделали что-то? Кем вы будете через 5 лет? Точно ли вы пришли в индустрию, чтобы писать "правильные подсказки"?

Разработка

• Теперь мы все CTO
• Джек Дорси работает над Bluetooth-мессенджером Bitchat
• Lokilizer — бесплатный инструмент для перевода приложений с двух языков на любые другие
• I Tried Google’s New Gemini CLI. It’s the Most Powerful Open-Source Dev Tool

Кроссплатформа

• 10 Must-Have Libraries for Compose Multiplatform Projects — With Code & Use Cases
• Building a Complete Flutter Maps App with Ola Maps: Beyond the Basic Package

iOS

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

• Акторы в Swift — для чего они нужны?
• StoreKitTheKit — простые покупки поверх StoreKit2
• VStack in SwiftUI: Advanced Features & Hidden Secrets
• Apple Container Usage In Details
• How to Detect Text Truncation in SwiftUI?
• Tuist Server is Now Source Availabl
• Introducing Animatable macro in SwiftUI

Android

Если вы всегда хотели написать свой VPN-клиент, то вот на Хабре "дневник разработки" - как человек создал свое приложение. История о пути, граблях и открытиях, которая будет полезна тем, кто тоже решит заглянуть под капот VPN-технологий на Android.

• Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 2
• Я написал свой VPN-клиент для Android. Зачем, если их сотни, и что скрывается под капотом?
• Why Retrofit 3.0.0 Matters (Even if 2.9.0 Still Works)
• Code That Disappears in Production: A Gradle Pattern Every Android Developer Must Know
• MVI vs MVVM in Android: A Balanced Take with Code Snippets