Android

Blinkit делится решением вечной головоломки Android — адаптивной производительностью в реальном времени. Компания строит свою систему – Droid Dex – так, чтобы она адаптировала настройки под конкретное устройство, основываясь на пяти ключевых показателях: CPU, память, сеть, хранилище, батарея. У каждого измерения есть четыре уровня — от отличного до низкого — и важный момент: разработчики могут задать веса для разных контекстов. Например, для загрузки изображений приоритет даётся сети и памяти, а для видео — CPU и батарее . Такой подход позволяет приложениям действительно адаптироваться под условия пользователя, а не просто работать «на усреднённой мощности». Droid Dex показал себя на миллионах реальных пользователей, снизил количество падений и ANR, а также улучшил вовлечённость и удовлетворённость. Более того, проект открытый и хорошо документирован — вся система доступна на GitHub, и Blinkit активно принимает фидбэк и улучшения.

Поставьте 👍, если хотите эту статью на русском.

• Klyx — легковесный редактор кода для Android
• Команда Swift объявила о создании рабочей группы Android
• Настраиваем CI/CD Android-проекта, часть 2. Запуск Android-тестов
• Незаметное ограничение Android 15
• How Blinkit Cracked Android's Performance Puzzle with Droid Dex
• How to Create a Word-by-Word Animation in Jetpack Compose
• Android Interview Questions for Mid-Level Developers (3–6 Years)

А вот я к вас с новым дейтингом. Sitch стремится более вдумчиво подходить к процессу регистрации и использует большие языковые модели, чтобы привнести опыт человека-свахи в приложение для знакомств, помогая людям находить потенциальных партнеров без свайпов. По сути, приложение это версия со-основательницы-свахи на основе искусственного интеллекта, которая помогает пользователям вступить в игру, задавая им подробные вопросы (более 50), на которые они могут ответить текстом или голосом. После настройки профиля пользователя ИИ-сваха отображает предлагаемые совпадения. Если оба пользователя соглашаются на совпадение друг с другом, бот добавляет их в групповой чат с ИИ. В любой момент времени — даже после реальных свиданий — пользователи могут предоставить отзыв о своих совпадениях, чтобы улучшить персонализацию. Примечательно, что продает Sitch матчи - три стоят 90 долларов, восемь 160. Причем заплатить за них надо авансом, как настоящей свахе. В настоящее время Sitch предлагает свои услуги только в Нью-Йорке, но планирует открыть представительства в большем количестве городов в этом году.

Разработка

• Anthropic позволяет создавать приложения прямо в Claude
• Google Gemini CLI — ИИ-инструмент для терминалов
• Радиобаттон Авито с функцией чекмарка: спорный паттерн или гениальное решение?
• The Importance of Kindness in Engineering

Маркетинг

• Sitch объединяет человеческий подход к подбору пар и искусственный интеллект
• Маркетологи в мобайле: Никита Кулаков (Head of Performance, Яндекс Браузер)

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

• Is Apple Trying to Kill Flutter with iOS 26?
• Apple’s Liquid Glass Threatens Hybrid Apps

Добавляем поддержку палочек

Новый дайджест за неделю со всеми материалами - эксплоиты ядра iOS и палочки на Android, рабочая группа Swift для Android и незаметные ограничения, смерть резюме, ТВ-пульты как многомиллионный бизнес в магазинах приложений, Gemini для роботов и многое другое. Заходите!

iOS

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

Поставьте 👍, если хотите эту статью на русском

• Молот и наковальня iOS-разработчика
• Apple объявляет о масштабных изменениях в App Store в ЕС
• SwiftCrossUI — кроссплатформенный декларативный UI-фреймворк, вдохновленный SwiftUI
• How to support Dynamic Type accessibility in SwiftUI
• Sparkle: Distribution apps in- and out of the Mac App Store
• Adding Icon Composer icons to Xcode
• Apple’s On-Device Foundation Model Is Here.. But Is It Any Good?
• Automatic Observation Tracking in UIKit and AppKit: The Feature Apple Forgot to Mention
• Embedding Godot games in iOS apps is easy now
• Decoding Swift types that require additional data

Android

NoDPI представляет собой асинхронный прокси-сервер на базе библиотеки asyncio Он перехватывает tls-рукопожатия (handshake) исходящих соединений и отправляет их на фрагментацию. Если домен присутствует в списке заблоченных, программа разбивает пэйлоад на несколько кусков случайного количества и случайной длины, и склеивает с байтовой последовательностью \x16\x03\x04 (+ data). Т. е. одна tls запись превращается в несколько записей разной длины. После этого они объединяются и отправляются как один пакет. Пока у DPI нет мощностей, чтобы разбираться с таким хаосом в пакетах, и все это благополучно следует к пункту назначения, а мы, довольные, смотрим YouTube. История разработки приложения - в статье на Хабре. Правда, в комментариях там же пишут, что не работает.

• Как Blinkit решил загадку производительности Android-приложения с помощью Droid Dex
• Store — решение для работы с данными на Kotlin Multiplatform
• Что не так с Android разработкой?
• Эти фичи Kotlin меняют правила игры
• NoDPI4Android. Решаем проблему «деградации» YouTube теперь и на Android
• Boost Android Development with Gemini CLI in 5 Minutes
• Passkeys & Credential Manager in Android
• Initial exploration of using Koog for developing Kotlin based AI agents
• Top announcements to know from Google Play at I/O ‘25
• Get ready for the next generation of gameplay powered by Play Games Services
• Reducing App Size: Proguard, R8, App Bundles & Resource Shrinking
• Is mobile development a dead-end after 6-9 years?

Рост цифровой веры

Индийский стартап, стоящий за индуистским религиозным приложением Sri Mandir, привлек $20 млн в новом раунде — всего через девять месяцев после получения $18 млн. Приложение собрало более 40 миллионов загрузок с момента запуска. За последние 12 месяцев оно позволило 1.2 миллиона верующих совершать онлайн-молитвы и делать подношения в более чем 70 храмах по всей Индии.

В настоящее время у Sri Mandir около 3.5 миллионов активных пользователей в месяц, в том числе около 90,000 из-за пределов Индии. Хотя база пользователей приложения остается в основном внутренней, ARPU за рубежом значительно выше — около 81 доллара по сравнению с 7–9 долларами в Индии. Примечательно, что почти 20% дохода платформы поступает от индийской диаспоры в США, Великобритании, ОАЭ, Канаде, Австралии и Новой Зеландии.

В начале 2025 года оборот Sri Mandir превысил 12 миллионов долларов. Приложение также имеет шестимесячный уровень удержания около 55%, что означает, что более половины его пользователей остаются активными через шесть месяцев после регистрации.

В мире 10 лучших религиозных приложений показали 15% рост ежемесячно активных пользователей в течение первой половины 2025 года, даже при снижении загрузок на 2% (посмотрите еще пример Bible Chat). Рынок религиозных приложений Индии опередил эту мировую тенденцию: 10 лучших приложений зафиксировали 60% рост числа активных пользователей в месяц и 50% рост числа загрузок. На Индию пришлось 15% от общего объема мировых инвестиций в религиозные технологии с 2020 года, что сделало ее вторым по величине рынком после США по объему финансирования.

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

iOS

Перевел вчерашнюю статью про фреймворк Observation. Конечно, про основное там умолчали - работает это все с iOS 18. Так что если вы поддерживаете что-то старше, то хрен вам, а не автоматическое отслеживание изменений. Но, надо признать, сделали все красиво и удобно. Так что через пару лет можно будет пользоваться.

• Автоматическое отслеживание изменений в UIKit и AppKit: функция, о которой Apple забыла упомянуть
• Крупные автопроизводители отказываются от CarPlay Ultra
• ComponentsKit — набор красивых компонентов UIKit и SwiftUI
• VIPER vs TCA: What Large iOS Teams Actually Use
• Understanding and Improving SwiftUI Performance
• Sendable in Swift: The Silent Killer of Race Conditions

Android

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

• Kotlin : 6 Advanced Flow Features You Must know
• Everyday Challenges of an Android Developer — Skeleton Loaders: The Illusion of Speed
• How I Optimize My Android App from 15MB to under 2MB
• Managing state across navigation in Jetpack Compose
• Custom Scene Strategy in Navigation 3 — Make Your App Flow Your Way

Если вы только освоили промпт-инжиниринг, то у меня для вас плохая новость. Все прогрессивное человечество уже переходит на контекст инжиниринг. Описывают его как "искусство предоставления всего контекста для задачи". Сюда входит начальный набор инструкций, задача или вопрос от пользователя, текущее состоянии и история, база знаний, извлеченная информация (RAG), описание инструментов и т.п. Говорят, что секрет создания по-настоящему эффективных ИИ-агентов не столько связан со сложностью кода, который вы пишете, сколько с качеством контекста, который вы предоставляете. Так что совсем скоро вместо программистов, занимающихся кодом, будут программисты, занимающиеся контекстом. Отдельные языки будут для Gemini, ChatGPT и прочих...

Разработка

• Новый навык в ИИ — не промпты, а контекст инжиниринг
• When a PM takes over engineering
• Challenging projects every programmer should try
• 14 logic-driven UI design tips to improve any interface
• Saying bye to 4px spacing and hello to Fibonacci

Маркетинг

• Sri Mandir получает новые инвестиции по мере роста цифровой веры

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

• Flutter’s Biggest Problems: What Google Doesn’t Want You to Know
• Why Cross-Platform Teams Are Shifting to Native — With Case Studies That Might Surprise You

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