Руководство по миграции на Swift 6

Swift 6 появился на WWDC 2024, и все мы, конечно, поспешили перенести на него все наши приложения. Ну, не совсем все и не поспешили… На WWDC 2021 мы уже получили блестящий новый структурированный фреймворк параллелизма Swift 5.5, который помог нам писать безопасный код быстрее с async/await и акторами. Swift 6, казалось, сломал все, и было бы неплохо немного подождать. Год спустя путь миграции выглядит намного более гладким, с большим количеством ориентиров. В этом руководстве от Kodeco разбираются все аспекты скорого переезда на шестую версию.

Туториал: https://www.kodeco.com/48297451-migrating-to-swift-6-tutorial
Платформа: iOS

FoundationChat: создание ИИ-чата с использованием Foundation Models в iOS 26

Продолжаем исследовать Foundation Models. Разработчик демонстрирует, как с помощью нового фреймворка можно создать полноценный чат‑бот, работающий полностью на устройстве без обмена данными с облаком. Представленный проект – это приложение на SwiftUI с поддержкой iOS 26 и Apple Intelligence, использующее приватную on‑device модель (~3 млрд параметров). В интерфейсе реализованы многопоточность, хранение диалогов через SwiftData, потоковая генерация ответов, автосуммирование переписки и извлечение метаданных из веб‑страниц. Ключевая особенность проекта – использование @Generable макроса, позволяющего описывать структуру сообщений как Swift‑структуры, что делает вывод модели строго типобезопасным и упрощает обработку ответов. Кроме того показано, как с помощью Tool API встроить анализ веб‑страниц, извлекая заголовки, превью и описания прямо в чат. Это превращает FoundationChat в движок для гибких AI‑фич, работающих офлайн и сохраняющих приватность.

Статья: https://dimillian.medium.com/foundationchat-building-an-ai-chat-app-with-ios-26s-on-device-models-a3230df8d989 (©)
Код: https://github.com/roy3210/FoundationChat
Платформа: iOS

SwiftCrossUI - кроссплатформенный декларативный UI-фреймворк, вдохновленный SwiftUI. SwiftCrossUI позволяет вам использовать базовые концепции SwiftUI для создания кроссплатформенных (macOS, Linux, Windows, iOS и tvOS) десктопных приложений. SwiftCrossUI предоставляет вашим пользователям нативный опыт на каждой платформе с помощью набора бэкэндов, созданных поверх различных фреймворков пользовательского интерфейса.

SwiftCrossUI на GitHub: https://github.com/stackotter/swift-cross-ui
Платформа: iOS/кроссплатформа
⭐️: 5

Расширяем возможности VK DeviceHub: как мы добавляли поддержку iOS для собственной фермы мобильных устройств

Изначально DeviceHub мог работать только с Android-устройствами. Но теперь, после обновления, инструмент поддерживает и iOS-устройства. Расскажу в статье, для чего нам понадобилась поддержка iOS и с чем мы столкнулись при внедрении новых возможностей.

Статья: https://habr.com/ru/companies/vk/articles/921058/
Платформа: iOS

Незаметное ограничение Android 15

О чем речь: если приложение в фоне, то теперь не получится сделать сетевой запрос вне WorkManager или Foreground Service, иначе запрос упадет с UnknownHostException. Я проверил на своем устройстве с недавно прилетевшим Android 15 и выставленным targetSdk = 35 и это действительно так.

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

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

Store на GitHub: https://github.com/MobileNativeFoundation/Store
Платформа: Android/кроссплатформа
⭐️: 3.3K

Ныряем в холодные потоки 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
Платформа: разработка