🍏 🏋️ 🪟 Мое приложение для планирования и концентрации - TaskFocus.

В начале 2022 года я решил разработать приложение TaskFocus - планировщик задач со встроенным фокусированием. Мне нужен был единый инструмент, который бы работал на всех моих устройствах и помогал не только фокусироваться на задачах, но и учитывать затраченное на них время.

⏰ В приложении TaskFocus можно легко создавать задачи, фиксировать заметки, использовать таймер фокусировки с фоновыми звуками и анализировать свою продуктивность с помощью наглядной статистики.


Разработка:

Изначально разработка планировалась под iOS, но для охвата всех пользователей я принял решение выбрать кроссплатформенный фреймворк Flutter. Это позволило выпустить приложение одновременно на iOS, Android, macOS и Windows. Серверную часть для синхронизации данных также разрабатывал самостоятельно на PHP.


Ключевые возможности:

🔵Задач с настройкой отображения списка.
🔵Возможность добавления заметок к задаче.
🔵Удобный поиск по дате и тексту задач или заметок.
🔵Режим фокусировки с выбором фоновых звуков для концентрации.
🔵Детальная статистика по выполнению задач и затраченному времени.
🔵Синхронизация данных и настроек между устройствами.
🔵Экспорт задач и статистики в Excel.
🔵Выбор темы оформления.
🔵Возможность подключения премиум подписки.


📊 На данный момент приложение имеет более 19 тысяч скачиваний в магазинах приложений.

📱 📱 📱 Приложение доступно в магазинах приложений


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Swift: как defer наконец-то подружился с асинхронностью.

Иногда самые полезные изменения в языке - не громкие нововведения, а устранение небольших, но раздражающих неудобств. Те, что заставляют писать лишний код, нарушать логику или искать обходные пути. Именно таким изменением стало принятие SE-0493, которое разрешает использовать await внутри defer. На первый взгляд это техническая деталь. На деле - значимое упрощение для написания чистого и надежного асинхронного кода.

Это небольшое, но важное изменение устраняет давнюю проблему: раньше defer не позволял делать await, что мешало писать чистый и надежный асинхронный код для гарантированной очистки ресурсов.


Что изменилось:

Теперь в async-функции вы можете писать так:

func loadData() async throws {
  let resource = try await acquireResource()
  defer {
    await resource.release()
  }
  try await work(with: resource)
}

Как это работает:

Ключевая механика defer сохраняется, но теперь с поддержкой асинхронности:

🔵Гарантия выполнения: блок defer выполнится при любом выходе из функции (успех, ошибка, возврат).

🔵Ожидание завершения: если внутри defer есть await, функция дождется его завершения, прежде чем вернуть управление.

🔵Ограничение: использовать await в defer можно только внутри async-контекста.


Почему это важно:

Раньше для асинхронной очистки приходилось либо дублировать код на всех путях выхода, либо использовать Task { }, который не гарантировал завершения операции. Теперь очистка ресурсов (закрытие сетевых соединений, сброс состояния, отмена операций) становится такой же простой и надежной, как и в синхронном коде.


🔗 Ссылка на документацию


💡 Вывод:

Принятие SE-0493 - это пример зрелой эволюции языка. Вместо введения сложных новых концепций, Swift устраняет конкретное, давно назревшее несоответствие между синхронными конструкциями языка и его асинхронной парадигмой. Это изменение делает асинхронный код не только безопаснее, но и чище.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 iOS 26: официальный способ прикрепить плавающие View над TabBar.

Многие годы разработчики iOS испытывали смешанные чувства при виде таких интерфейсов, как мини-плеер в приложении Apple Music или постоянная панель действий в Podcasts. С одной стороны - это удобный и интуитивный паттерн, с другой - его реализация всегда была головной болью, требующей неочевидных трюков с safeAreaInsets и ручной подгонкой размеров. С выходом iOS 26 эта эпоха подошла к концу. Apple официально представила API для создания нижних аксессуаров в UITabBarController, и это одно из тех изменений, которое кардинально упрощает жизнь.


Прощайте, костыли. Здравствуй, декларативность:

До iOS 26 интеграция любого статичного или плавающего элемента поверх таббара была упражнением в нетривиальной геометрии. Разработчики были вынуждены вручную управлять additionalSafeAreaInsets, отслеживать повороты устройства, адаптировать layout под разные состояния навигации (например, появление клавиатуры) и гарантировать, что кастомная вью не перекроет таббар и его элементы. Новый API bottomAccessory решает эту проблему радикально простым и элегантным способом. Все что требуется - это создать экземпляр UITabAccessory, передав ему ваше кастомное представление, и установить его в свойство контроллера.

let miniPlayerView = MiniPlayerView() // Кастомная вью
let accessory = UITabAccessory(contentView: miniPlayerView)
tabBarController.bottomAccessory = accessory

Система берет на себя всю ответственность за позиционирование, анимации при появлении/скрытии (через метод setBottomAccessory(_:animated:)) и корректное взаимодействие с жестами. Это переход от императивного «как это разместить» к декларативному «что я хочу показать».


Гармония с поведением таббара - новый уровень интеграции:

Инновация не ограничивается простым добавлением вью. Apple обеспечила глубокую интеграцию аксессуара с обновленным поведением самого UITabBar. Теперь таббар может автоматически сворачиваться в компактный вид (например, при скролле контента), и аксессуар реагирует на это изменение согласованно. Поведением управляет свойство tabBarMinimizeBehavior, которое предлагает гибкие опции: от автоматического решения системой до явных триггеров вроде скролла вниз или вверх.


Адаптивный интерфейс через tabAccessoryEnvironment:

Одной из самых тонких проблем при создании подобных элементов была адаптация их внешнего вида к разным состояниям. Нужно ли показывать полный заголовок трека или только иконку? Как изменить layout при компактном таббаре? Для этого Apple ввела новый trait - UITabAccessory.Environment. Теперь вью может запросить у traitCollection текущее окружение (.regular, .inline, .none) и кардинально изменить свой вид или внутреннюю композицию.


contentLayoutGuide - надежный фундамент для контента:

Чтобы окончательно устранить ручные расчеты отступов, Apple добавила в UITabBarController новый UILayoutGuide - contentLayoutGuide. Привязка контента основного вью-контроллера к этому guide, автоматически гарантирует, что он всегда будет располагаться в корректной области: выше системных элементов нижней части интерфейса. Этот guide динамически обновляет свои размеры при изменениях состояния таббара, появлении клавиатуры или изменении ориентации.


🔗 Ссылка на подробную статью


💡 Вывод:

Введение bottomAccessory в iOS 26 - это не просто добавление еще одного свойства в API. Это значительный шаг вперед в философии UI-разработки под iOS. Apple признает популярные пользовательские паттерны и предоставляет для них первоклассные, системные инструменты, заменяя годы накопленных хаков и обходных приемов. Это снижает порог входа для создания сложных интерфейсов, повышает стабильность приложений и позволяет разработчикам сосредоточиться на логике и дизайне, а не на борьбе с фреймворком.


➡️ Подписаться на канал
Мобильный трудоголик

🔨 Xcode - это не среда разработки, это квест на выживание.

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


Иллюзия контроля:

Современная разработка строится на предсказуемости: четких ошибках, логичном рабочем процессе, последовательной документации. Xcode систематически нарушает этот контракт. Возьмем классическую ошибку SwiftUI: «The compiler is unable to type-check this expression in reasonable time». Это не ошибка в вашем коде- это капитуляция системы. Компилятор не говорит, где проблема; он предлагает вам угадывать, разбивая выражения наугад. Это эквивалент того, как если бы строительный кран останавливался со словами «что-то тяжело», не указывая на проблемную балку.


Архитектура как наследие:

Погружение в структуру проекта - это путешествие в прошлое. Файл project.pbxproj - это не просто конфигурация, это артефакт эпохи, когда понятия «человеческий формат» считались роскошью. Merge-конфликты в этом файле - это квест, где наградой становится возможность просто открыть проект. Существование инструментов вроде xcodegen - не доказательство гибкости экосистемы, а молчаливое признание провала.


Церемония подписи кода:

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


Документация как мираж:

Попытка следовать официальным руководствам - это часто путь через зеркало. Sandbox-аккаунт для тестирования покупок должен появляться в настройках симулятора, но его нет. Вы вводите пароль снова и получаете загадочное «Password reuse not available for account». Форумы разработчиков разделены: половина утверждает, что в симуляторе это не работает, другая половина - что работает. Правда где-то посередине, но ее приходится устанавливать методом проб и ошибок, а не чтением документации.


Закрытость как система:

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


Монополия на инструменты:

Отсутствие реальных альтернатив - ключевой момент. AppCode от JetBrains был похоронен, а настройка Neovim с xcode-build-server остается увлечением для энтузиастов. CLI-инструменты плохо документированы, что делает автоматизацию и CI/CD не естественным процессом, а подвигом. Fastlane существует не для расширения возможностей, а для преодоления фундаментальных недостатков.


🔗 Ссылка на подробную статью


💡 Вывод:

Xcode - это не просто IDE. Это культурный код, который формирует мышление разработчика. Он учит не углубляться в суть проблем, а выполнять ритуалы: перезагрузить, очистить Derived Data, пересоздать проект. Опасность такого подхода в том, что он формирует поколение разработчиков, которые воспринимают непредсказуемость как норму. Apple создала выдающиеся продукты, но инструменты для их создания остаются парадоксом: они одновременно и мост и барьер.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Захват ссылок в Swift: когда [weak self] становится ловушкой.

Всем привет! Наткнулся на интересную статью об отладке памяти в iOS. Автор разбирает реальный кейс, где мелкий UI-баг оказался верхушкой айсберга серьезной проблемы.

С чего все началось:

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


Расследование по шагам:

Автор методично искал причину. Сначала: классические print-ы по всему стеку вызовов. Оказалось, что обработчик deep link вызывался дважды, и что важнее: от двух разных экземпляров координатора в памяти.

Ключевая зацепка: проблема воспроизводилась только после выхода и повторного входа в аккаунт. Это намекало, что старые объекты не убирались из памяти.


Масштаб проблемы:

Используя Memory Graph Debugger, автор обнаружил шокирующую вещь: в системе оставались жить целые копии части приложения, со всеми координаторами, сервисами и вью-моделями. Каждый перелогин добавлял новый слой в память.


Найденный виновник:

Проблема скрывалась в, казалось бы, корректном коде:

.sink(receiveValue: {
  Task { [weak self] in  // weak здесь не спасает!
    // логика
  }
})

Ошибка была в том, что [weak self] стоял во внутреннем замыкании Task, в то время как внешнее замыкание .sink захватывало self сильно по умолчанию.


Решение в одну строку:

Исправление оказалось минимальным, но критически важным:

.sink(receiveValue: { [weak self] in  // weak должен быть здесь!
  Task {
    // логика
  }
})

💡 Вывод:

Эта история наглядно показывает, как механическая, но невнимательная расстановка [weak self] может создать иллюзию безопасности, скрывая реальную утечку памяти. Мы часто действуем по шаблону, добавляя слабый захват в асинхронные блоки, забывая, что корень проблемы может находиться уровнем выше - в замыкании, которое инициирует эту асинхронную операцию. Ключевой урок здесь в том, что борьба с retain cycles требует не ритуала, а понимания полного контекста захвата, особенно при работе с цепочками и вложенными замыканиями.


➡️ Подписаться на канал
Мобильный трудоголик

🔨 Xcodebuild, Swift Build и Swift-Build: как устроен конвейер сборки в Swift.

Когда вы запускаете сборку проекта, под капотом запускается не один инструмент, а целый конвейер. Многие разработчики воспринимают сборку как нечто монолитное, но в современной экосистеме Swift она разделена на четкие слои абстракции. Понимание того, как xcodebuild, swift build и swift-build взаимодействуют - это ключ к эффективной отладке сложных проблем со сборкой, созданию кастомных инструментов и глубокому пониманию того, как ваши проекты превращаются в исполняемый код.


Абстрактный сердцевинный движок: swift-build как единый планировщик задач:

В основе всего лежит swift-build - низкоуровневый движок, построенный на llbuild. Его задача - не понимать Swift, Xcode-проекты или манифесты пакетов. Его задача - эффективно планировать и исполнять граф зависимостей задач. Он работает с абстрактным промежуточным представлением проекта - PIF (Project Intermediate Format). PIF - это, по сути, универсальный язык, на котором можно описать любую задачу сборки: компиляцию .swift файла, линковку библиотеки, копирование ресурсов. swift-build получает этот граф задач и решает, что, когда и как выполнять, оптимизируя параллелизацию и инкрементальные сборки.


Трансляторы - как swift build и xcodebuild говорят с движком:

Здесь начинается специализация. Ни swift build (система сборки Swift Package Manager), ни xcodebuild не компилируют код сами. Они - трансляторы или фронтенды.

🔵swift build (SwiftPM): его мир - это Package.swift. Он парсит манимуфест, анализирует зависимости, разрешает версии и строит граф таргетов специфичный для пакетов. Затем он транслирует этот граф в универсальный PIF и передает его на выполнение движку swift-build с флагом --build-system=swiftbuild.

🔵xcodebuild: его вселенная - это .xcodeproj с кучей настроек (Build Settings), схем (Schemes) и конфигураций. Он считывает этот комплексный проект, разрешает все переменные, обрабатывает зависимости (включая те же Swift-пакеты через XCFrameworks) и транслирует всю эту информацию в тот же самый PIF. Затем он передает PIF тому же самому движку swift-build.


Ключевое преимущество - разделение ответственности и совместимость:

Польза от такого гениального решения:

🔵Единый кэш и инкрементальность: независимо от того, собираете ли вы пакет через SwiftPM или проект через Xcode, движок swift-build один. Это значит, что кэш объектов (DerivedData) и механизм инкрементальной сборки унифицированы и работают согласованно.

🔵Снижение сложности: движку сборки не нужно знать сотни Build Settings Xcode. Ему говорят: «скомпилируй этот файл с этими флагами». А xcodebuild уже сам разбирается, как из настроек SWIFT_OPTIMIZATION_LEVEL и OTHER_SWIFT_FLAGS сформировать итоговый вызов компилятора.

🔵Возможность для сторонних инструментов: такие проекты, как Tuist или XcodeGen, используют эту же схему. Они не изобретают свой компилятор. Они генерируют .xcodeproj (или даже сразу PIF), а затем используют стандартный xcodebuild или напрямую swift-build для сборки. Это обеспечивает стабильность и совместимость.


Где прячется swiftc? Роль компилятора в этой цепочке:

Компилятор swiftc - это просто еще одна задача в графе, который строит движок swift-build. Когда движок видит в PIF задачу типа «скомпилировать Swift-файл», он вызывает swiftc с конкретным набором аргументов, которые были подготовлены для него фронтендом (xcodebuild или swift build). swiftc не имеет состояния между вызовами и ничего не знает о проекте в целом, он просто компилирует то, что ему передали.


💡 Вывод:

Сборка в экосистеме Swift - это не монолит, а пайплайн с четкими интерфейсами: фронтенд (xcodebuild/swift build) отвечает за понимание формата проекта и генерацию абстрактного плана, а бэкенд (swift-build) - за оптимальное исполнение этого плана через вызов низкоуровневых инструментов вроде swiftc.

Такое разделение позволяет Apple независимо развивать удобные инструменты для разработчиков (Xcode, SwiftPM) и высокопроизводительный движок сборки.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 MetricKit: мониторинг производительности iOS-приложений на проде.

В iOS-разработке есть один недооцененный инструмент, который дает доступ к метрикам, обычно скрытым от нас. Речь о MetricKit - фреймворке Apple для сбора системной диагностики с устройств пользователей. Это не просто альтернатива краш-репортам, а принципиально другой уровень понимания того, как приложение ведет себя в реальных условиях.

Стандартные инструменты показывают, что упало. MetricKit показывает, почему это произошло. Не только краши, но и зависания, энергопотребление, временя запуска и десятком других, системных параметров. Это данные, которые ОС собирает сама, без участия пользователя и с минимальным влиянием на производительность.


Особенности:

MetricKit раскрывает три слоя проблем, которые иначе остаются невидимыми:

🔵Системные завершения приложения: вместо общего «приложение закрыто» вы получаете конкретную причину: нехватка памяти, превышение лимита CPU, Out Of Memory (OOM) или фоновая активность. Это позволяет отличать баги от системных ограничений.

🔵Ресурсные метрики в контексте: энергопотребление разбивается по компонентам (CPU, дисплей, сеть), I/O операции показываются с объемами и временем выполнения, а зависания детектируются автоматически с полным стек-трейсом.

🔵Агрегированные данные для трендов: MetricKit не сыплет событиями, он присылает агрегированные отчеты раз в 24 часа. Это идеально для анализа трендов: как изменилось время запуска после обновления, выросло ли энергопотребление новой фичи, снизилось ли количество OOM после оптимизации.


🔗 Ссылка на подробную статью


💡 Вывод:

MetricKit меняет подход к качеству приложений с реактивного на проактивный. Вместо того чтобы ждать жалоб из App Store, вы видите проблемы до того, как они станут массовыми. Это инструмент для команд, которые хотят не просто исправлять баги, а понимать фундаментальные причины проблем производительности.

Главное преимущество - объективность. Вы получаете не субъективные оценки, а точные системные метрики. Это позволяет принимать архитектурные решения на основе данных, а не предположений. Для серьезных проектов внедрение MetricKit должно быть не опцией, а стандартом разработки.


➡️ Подписаться на канал
Мобильный трудоголик

🎄 Друзья, с наступающим Новым годом!

С мая я каждый день старался радовать вас полезными постами и искренне надеюсь, что они принесли вам не только новые знания, но и реальный профессиональный рост.

Я очень благодарен за ваше внимание и активность. Сейчас я ухожу на заслуженные выходные, но в январе вернусь с новыми идеями.


Желаю вам в 2026 году:

🎉 Освоить технологии, которые сделают вас ценнее на рынке.

🎉 Найти проекты, от которых горят глаза.

🎉 Получать не только опыт, но и достойное вознаграждение.

🎉 И никогда не переставать удивляться возможностям кода.


Пусть новый год будет полон открытий и достижений!
С Новым годом! 🎉

🔨 Не все краши одинаковы. Системный подход к отладке падений iOS-приложений.

Всем привет! Сегодня разберем системный подход к работе с крашами iOS-приложений. Частая ошибка - пытаться сразу лезть в код, не поняв, какой именно сбой произошел. Это как лечить температуру, не зная, грипп это или воспаление легких. Каждый тип краша - это сигнал от системы, который указывает на определенный класс проблем. Когда приложение падает, операционная система отправляет сигнал (signal) о причине прекращения работы. Этот сигнал - ключ к быстрой диагностике.


Шесть основных сигналов и методы их исправления:


🔵Сигнал 1: EXC_BAD_ACCESS:

Приложение попыталось обратиться к участку памяти, который уже освобожден или никогда не принадлежал ему. Причиной могут быть объекты, на которые остались ссылки после их удаления (dangling pointers), некорректное использование weak / unowned, ошибки в коде на C / Objective-C. Включите Zombie Objects в схеме запуска Xcode. Этот режим превращает освобожденные объекты в «зомби» и логирует попытки доступа к ним, четко указывая на проблемный объект. Также используйте Address Sanitizer для выявления более тонких ошибок работы с памятью.


🔵Сигнал 2: SIGSEGV:

Попытка чтения или записи в область памяти, доступ к которой запрещен. Низкоуровневая и опасная ошибка. Причиной может быть работа с Unsafe указателями в Swift, ошибки в нативном коде (C / C++ / Obj-C), порча памяти (memory corruption). Тщательно рецензируйте весь код, использующий UnsafeRawPointer и аналоги. Запустите приложение с Address Sanitizer. Установите символьные точки останова на функции работы с памятью.


🔵Сигнал 3: EXC_CRASH / SIGABRT:

Приложение само вызвало аварийное завершение. Это самый прозрачный тип краша. Причиной может быть срабатывание fatalError(), принудительное извлечение опционала (!), неудачное выполнение assert() или precondition, ошибки валидации в Core Data. Внимательно читайте сообщение в консоли, оно часто напрямую указывает на причину. Изучите верхушку стек-трейса, чтобы найти строку вашего кода, которая инициировала остановку. Замените force unwrap на безопасные конструкции (if let, guard let).


🔵Сигнал 4: SIGTRAP / SIGILL:

Выполнение недопустимой инструкции процессора или срабатывание контрольной точки (trap). Причиной может быть срабатывание assertionFailure в релизной сборке, дебаг-проверки, которые сработали не в той среде, ошибки в условиях precondition. Проверьте, не активны ли строгие проверки (assert) в релизной сборке. Сравните поведение Debug и Release версий. Убедитесь, что все предположения о данных, защищенные precondition, корректны.


🔵Сигнал 5: Out of Memory, OOM:

Приложение превысило лимит памяти, выделенный системой и было завершено. Причиной может быть кэширование больших изображений без ограничений, утечки памяти (retain cycles), удержание в памяти огромных массивов данных. Запустите Memory Graph Debugger (кнопка с тремя кругами в Xcode) для визуализации графа объектов и поиска циклов сильных ссылок. Используйте Allocations Instrument для отслеживания роста потребления памяти во времени. Внедряйте инструменты для снижения давления памяти (например, NSCache вместо словаря для изображений).


🔵Сигнал 6: Watchdog Termination, код 0x8BADF00D:

Система усыпила приложение за блокировку главного потока более чем на несколько секунд. Причиной могут быть синхронные сетевые запросы на главном потоке, декодирование большого JSON, тяжелые вычисления в SwiftUI.body. Используйте инструментарий Time Profiler для записи и анализа активности потоков. Найдите операции, блокирующие main thread. Выносите длительные задачи с Main Actor с помощью Task.detached или фоновых очередей.


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 @Observable в SwiftUI: почему это больше, чем замена ObservableObject.

SwiftUI продолжает эволюционировать, и одним из самых значимых изменений за последнее время стало появление макроса @Observable. Многие разработчики до сих пор используют привычный ObservableObject, не до конца понимая, что новый подход - это не просто синтаксический сахар, а фундаментальное улучшение в философии управления состоянием. Если вы все еще заставляете свои модели подчиняться протоколу ObservableObject и разбрасываете @Published, самое время разобраться, как @Observable делает код не только чище, но и эффективнее на системном уровне.


Философский сдвиг - от ручного объявления к автоматическому обнаружению изменений:

Ключевое различие между двумя подходами лежит в парадигме. ObservableObject требует от вас явного объявления намерений. Вы помечаете класс протоколом, а каждое свойство, которое должно публиковать изменения - модификатором @Published. Это императивный подход: «Я, разработчик, говорю системе, за чем именно нужно следить».

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


Технические отличия - Runtime vs Compile-time наблюдение:

Этот философский сдвиг имеет прямые технические последствия для производительности и поведения.

🔵ObservableObject (Runtime Observation): работает через механизм Combine и объект ObservableObjectPublisher. Когда изменяется свойство с @Published, оно через objectWillChange.send() асинхронно уведомляет всех подписчиков (ваши View) о том, что что-то в этом объекте поменялось. View затем вынуждены пересчитать свое тело, чтобы понять, изменились ли конкретные данные, которые они отображают. Это приводит к потенциально избыточным перерисовкам.

🔵@Observable (Compile-time Observation): макрос раскрывается в код, который реализует гранулярное отслеживание доступа. SwiftUI на этапе компиляции строит точные связи между конкретными свойствами модели и конкретными View, которые их используют. Когда свойство изменяется, система точно знает, какие именно View зависят от этого конкретного свойства и обновляет только их. Это устраняет лишние перерисовки и повышает производительность.


🔗 Ссылка на документацию Apple


💡 Вывод:

Появление @Observable - это не просто замена одного модификатора другим. Это шаг SwiftUI к более зрелой, эффективной и декларативной модели реактивности. Он переносит нагрузку с разработчика (которому больше не нужно вручную расставлять флажки для системы) на компилятор, который может оптимизировать наблюдение за состоянием с недоступной ранее точностью.

ObservableObject выполнил свою историческую роль, заложив основы реактивного программирования в SwiftUI. @Observable - это его логическое и технологическое развитие, предлагающее тот же результат с меньшими усилиями и большей эффективностью.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Как добавить текстовый ввод прямо в push-уведомления iOS.

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

Большинство приложений используют уведомления как односторонний канал: показали сообщение -> нажали -> перешли в приложение. Но iOS уже несколько лет позволяет превращать пуши в интерактивные интерфейсы. Помимо стандартных кнопок, система поддерживает поле для ввода текста - идеально для быстрых ответов, подтверждений или простых команд.


Философия категорий:

Ключевое понятие здесь: категория уведомлений (UNNotificationCategory). Это не просто техническая группировка, а смысловая. Категория определяет, какие действия доступны для конкретного типа уведомлений. Чат, напоминание, системное событие - у каждого свой набор возможных реакций.

// Определяем действие с текстовым полем
let quickReplyAction = UNTextInputNotificationAction(
  identifier: "QUICK_REPLY",
  noscript: "Ответить",
  options: [],
  textInputButtonTitle: "Отправить",
  textInputPlaceholder: "Ваш ответ"
)

// Создаем категорию для сообщений чата
let chatCategory = UNNotificationCategory(
  identifier: "CHAT_MESSAGE",
  actions: [quickReplyAction],
  intentIdentifiers: [],
  options: []
)

// Регистрируем категорию в системе
UNUserNotificationCenter.current().setNotificationCategories([chatCategory])

Как сообщить системе, какое уведомление показать:

Категория - это шаблон. Чтобы она сработала, нужно указать ее идентификатор при создании самого уведомления:

let content = UNMutableNotificationContent()
content.noscript = "Новое сообщение"
content.body = "Привет! Как дела?"
content.categoryIdentifier = "CHAT_MESSAGE" // Ключевая связка

Теперь, когда это уведомление появится, система автоматически добавит к нему кнопку «Ответить» с текстовым полем.


Обработка введенного текста:

func userNotificationCenter(
  _ center: UNUserNotificationCenter, 
  didReceive response: UNNotificationResponse, 
  withCompletionHandler completionHandler: @escaping () -> Void
) {
  if response.actionIdentifier == "QUICK_REPLY", let textResponse = response as? UNTextInputNotificationResponse {
    let userText = textResponse.userText
    // Отправляем текст на сервер, сохраняем локально и т.д.
    processQuickReply(userText)
  }
  
  completionHandler()
}

Ограничения и особенности:

🔵Нельзя кастомизировать UI: поле ввода и кнопка - системные, их внешний вид определяется iOS.

🔵Требуется разрешение на уведомления: без requestAuthorization функция не работает.

🔵Работает только с категориями: простые уведомления без categoryIdentifier не поддерживают текстовый ввод.

🔵Лимит на количество действий: вместе с текстовым можно добавить еще до 3 обычных действий.

🔵Фокус на кратковременные сценарии: система не предназначена для длинных текстов - это инструмент для быстрых реакций.


🔗 Ссылка на подробную статью


💡 Вывод:

Добавление текстового ввода в уведомления - это шаг к тому, чтобы сделать пуши не просто напоминаниями, а полноценными точками взаимодействия. Это меняет парадигму: вместо «уведомить и ждать открытия приложения» мы получаем «уведомить и сразу получить ответ».

UNTextInputNotificationAction - это не просто техническая деталь, а инструмент для сокращения пути пользователя к цели. В мире, где внимание - самый ценный ресурс, возможность быстро выполнить действие в один тап может стать реальным конкурентным преимуществом.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Как Group в SwiftUI обманывает ваши ожидания и делает код непредсказуемым.

Сегодня разберем одну из самых коварных конструкций в SwiftUI, которая выглядит безобидно, но может стать источником трудноуловимых багов. Речь о модификаторе Group. Многие используют его для группировки представлений, не понимая, что на самом деле происходит под капотом. Group - это не layout-контейнер вроде VStack или HStack, а особый механизм, который меняет правила применения модификаторов к дочерним представлениям.

Основная проблема в том, что Group ведет себя непрозрачно. Вы применяете модификатор к группе, думая, что он применяется один раз, а на самом деле SwiftUI может применить его к каждому дочернему элементу отдельно. Это особенно опасно с модификаторами жизненного цикла, такими как onAppear и task.


Сценарий-ловушка - двойной вызов логики:

struct ContentView: View {
  @State private var isLoading = true
  
  var body: some View {
    Group {
      if isLoading {
        ProgressView()
      } else {
        DataView()
      }
    }
    .onAppear {
      loadData() // Опасно! Может вызваться несколько раз
    }
  }
  
  private func loadData() {
    // Загрузка данных
    isLoading = false
  }
}

Интуиция подсказывает: onAppear сработает один раз, когда появится Group. Реальность SwiftUI может быть другой. В зависимости от версии iOS и контекста (особенно внутри List), модификатор onAppear может быть применен к каждому дочернему представлению, что может привести к дублирующим сетевым запросам или нарушению бизнес-логики.


Почему это происходит:

Group в SwiftUI - это не самостоятельное представление с собственной областью видимости модификаторов. Это скорее помощник, который передает модификаторы своим детям. Когда вы пишете .onAppear для Group, система может интерпретировать это как «применить onAppear ко всем элементам внутри».


Что лучше использовать вместо Group:


🔹 Явные layout-контейнеры:

Если нужно расположить элементы - используйте предназначенные для этого инструменты:

// Вместо Group для вертикального расположения
VStack {
  Text("Заголовок")
  Text("Описание")
}

// Вместо Group для горизонтального
HStack {
  IconView()
  TextView()
}

// Для наложения
ZStack {
  BackgroundView()
  ContentView()
}

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


🔹 Вынос в отдельные View:

Если Group добавляется для логической группировки - это верный признак, что пора создать отдельное представление:

// Вместо
Group {
  UserAvatarView()
  UserNameView()
  UserStatusView()
}
.padding()

// Создаем
struct UserHeaderView: View {
  var body: some View {
    VStack {
      UserAvatarView()
      UserNameView()
      UserStatusView()
    }
    .padding()
  }
}

Преимущества:

🔵Читаемость кода улучшается.

🔵Возможность повторного использования.

🔵Изоляция модификаторов и логики.

🔵Упрощение тестирования.


🔹 ViewBuilder для сложных условий:

Для сложных условных конструкций можно использовать @ViewBuilder:

@ViewBuilder
var conditionalContent: some View {
  if conditionA {
    ViewA()
  } else if conditionB {
    ViewB()
  } else {
    DefaultView()
  }
}

var body: some View {
  VStack {
    conditionalContent
  }
  .onAppear {
    // Безопасно: применяется к VStack, а не к каждому условию
  }
}

🔗 Ссылка на подробную статью


💡 Вывод:

SwiftUI - это декларативный фреймворк, где явность и предсказуемость должны быть приоритетом. Group нарушает этот принцип, создавая неочевидные связи и поведение.

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Невидимый тормоз: как Codable съедает производительность вашего приложения.

Если вы пишете на Swift, вы почти наверняка используете Codable. Это элегантное решение для сериализации, ставшее стандартом де-факто. Но за кажущейся простотой скрывается сложный механизм, производительность которого в реальных сценариях часто далека от идеала.

Сегодня обсудим главные тезисы из статьи, в которой рассказывается как Codable ведет себя в условиях большого приложения с сотнями моделей и тысячью строк JSON на старте. Ребята обнаружили, что JSONDecoder и JSONEncoder могут тратить сотни миллисекунд на, казалось бы, простые операции, и нашли способы ускорить их работу в разы. Результатом этой работы стал Pull Request в репозиторий swift-foundation.


Где искать настоящие проблемы, а не синтетические цифры:

Первая ошибка - измерять производительность Codable в вакууме, декодируя один и тот же объект миллион раз в цикле. В реальности приложение при старте часто парсит множество разных моделей данных, и каждая из них встречается впервые. Именно в этот момент проявляются издержки динамической природы Swift Runtime.

Ключевой метод, который становится узким местом - swift_conformsToProtocolMaybeInstantiateSuperclasses. Он ищет, соответствует ли тип требуемому протоколу. В приложении с обширной кодовой базой таких соответствий может быть сотни или тысячи. Линейный поиск по этому массиву при каждом первом обращении к новому Codable-типу - дорогая операция.


Первый пример из кода Foundation:

// Пример из старой реализации JSONDecoder
func unwrap<T: Decodable>(...) throws -> T {
  ...
  
  if T.self is _JSONStringDictionaryDecodableMarker.Type {
    return try self.unwrapDictionary(...)
  }
}

Оператор is здесь запускает поиск соответствия типа T протоколу _JSONStringDictionaryDecodableMarker. Это происходит даже когда в этом нет необходимости (например при стандартной стратегии преобразования ключей).

Что изменили: Добавили проверку флага keyDecodingStrategy.isDefault. Каст к специальному протоколу теперь выполняется только тогда, когда это действительно нужно. Аналогичную оптимизацию применили и для JSONEncoder.


Скрытая цена CodingKey:

Каждый автоматически сгенерированный enum CodingKeys - это не просто перечисление. Это полноценный тип, который реализует протоколы CodingKey, Hashable, Equatable, CustomStringConvertible, CustomDebugStringConvertible. Каждое такое соответствие добавляет запись в тот самый массив, по которому работает медленный поиск.


Проблема усугубляется в generic-контейнерах:

// Объявление из стандартной библиотеки
public struct KeyedDecodingContainer<K: CodingKey>

При создании такого контейнера (а он создается для каждой модели в container(keyedBy:)) Runtime снова ищет соответствие вашего конкретного CodingKeys.self протоколу CodingKey. При 6000 уникальных моделей в приложении это 6000 лишних поисков при первом запуске.

Новый подход: Максимальный отказ от уникальных CodingKeys в пользу общего типа, например, String или специальной структуры AnyCodingKey. Это дает двойной выигрыш:

🔵Резко сокращает количество вызовов тяжелого метода.

🔵Уменьшает размер бинарного файла приложения (каждый CodingKeys добавляет ~1.8 КБ кода).


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Революция в подходах к безопасной многопоточности в Swift 6.

С выходом Swift 6 разработчики получили строгие гарантии защиты от состояний гонки (data-race safety) в многопоточном коде. Однако эти гарантии принесли и новые сложности - система стала предъявлять требования даже к тому коду, который выполняется последовательно. В новом видении команда Swift Evolution предлагает сделать модель безопасности более гибкой и дружелюбной, особенно для однопоточных приложений и плавной миграции.


Суть проблемы - безопасность там, где угрозы нет:

Текущая модель Swift 6 по умолчанию предполагает, что любой код может выполняться в нескольких потоках одновременно. Это приводит к избыточным требованиям в сценариях, где реальной многопоточности нет.

// Пример ложного срабатывания
class AppSettings {
  static let current = AppSettings() // Ошибка: небезопасно для параллельного доступа
}

Хотя если всё приложение работает в основном потоке, состояние гонки здесь невозможно.


Новый подход - контекстные умолчания:

Основная идея - позволить системе различать контекст выполнения. Для модулей приложений и скриптов предлагается устанавливать изоляцию к @MainActor по умолчанию, отражая их фактическое однопоточное поведение.

// Будущее: умолчание для модуля приложения
// module.moduleconfig: default-isolation = main-actor

class DataCache {
  static let shared = DataCache() // Теперь корректно
  var items: [String] = []
}

class ViewModel { // Неявно @MainActor
  func load() {
    DataCache.shared.items.append("data") // Работает без аннотаций
  }
}

Изолированные реализации протоколов:

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

protocol Serializable {
  func serialize() -> Data
}

@MainActor
class UserProfile: Serializable {
  private var data: [String: Any] = [:]
  
  // Изолированная реализация протокола
  func serialize() -> Data {
    return try! JSONSerialization.data(withJSONObject: data)
  }
}

Переосмысление async-поведения:

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


Что это значит для разработчиков:

🔵Меньше рутинных аннотаций @MainActor в UI-коде.

🔵Упрощение миграции legacy-проектов.

🔵Более понятные ошибки компиляции.

🔵Сохранение строгой безопасности там, где она действительно нужна.


🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Swift-интервью: как одна архитектурная ошибка стоила кандидату работы.

Привет, друзья! Сегодня разберем реальный кейс технического собеседования на позицию Swift-разработчика из данной статьи. История интересна не столько кодом, сколько глубинным пониманием системного дизайна, которое часто отделяет просто разработчика от того, кто способен проектировать библиотеки уровня Apple.


Задача, которая оказалась ловушкой:

Кандидату в команду SwiftUI для macOS дали задачу: реализовать метод adjacentPairs(), возвращающий последовательные пары элементов. Базовую функциональность он реализовал успешно, создав ленивую последовательность. Однако интервьюер задал каверзный вопрос о производительности цепочки .adjacentPairs().reversed().prefix(2). Именно здесь и проявился недостаток глубины решения.


Слепое следование паттерну вместо анализа:

Кандидат взял за образец реализацию uniqued() из Swift Algorithms. Это логично, но критично - он не проанализировал, подходит ли этот шаблон для его задачи. uniqued() должен хранить историю уникальных элементов в Set, что делает обратную итерацию очень затратной. Его же алгоритм adjacentPairs() работал только с соседними индексами и не требовал накопления состояния.


Последствие - неоптимальная производительность:

Из-за поддержки только протокола Sequence операция .reversed() не могла работать лениво, ей приходилось сначала пройти всю последовательность до конца. Если бы кандидат добавил поддержку протокола BidirectionalCollection для соответствующих базовых типов, reversed() остался бы ленивой операцией.

// Ключевое улучшение - условная поддержка протоколов
extension AdjacentPairsSequence: BidirectionalCollection
  where Base: BidirectionalCollection {
  // Эффективная обратная итерация без материализации
}

Что на самом деле проверяли:

Интервью оценивал способность проектировать API, а не просто писать код:

🔵Понимание модели данных: осознает ли кандидат, какие возможности дают разные протоколы коллекций?

🔵Мыслит ли системно: как его решение поведет себя в комбинации с другими стандартными операциями?

🔵Способность к оптимизации: может ли он увидеть потенциал для улучшения архитектуры?


💡 Вывод:

История с этим собеседованием прекрасно иллюстрирует разницу между подходом прикладного и системного разработчика. Прикладной разработчик спрашивает: «Работает ли мой код?» Системный: «Оптимален ли мой дизайн API в контексте всей экосистемы?»

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

Этот случай - важное напоминание: при проектировании любых абстракций, особенно в языке типа Swift, критически важно оценивать не только их непосредственную функцию, но и то, какие возможности они открывают (или закрывают) для будущих комбинаций и оптимизаций. Умение видеть эту картину целиком и отличает разработчика, который пишет код, от того, кто создает инструменты.


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Финансовый рычаг: как Apple будет взыскивать неоплаченную комиссию.

Лицензионное соглашение Apple для разработчиков - документ, который большинство просматривает по диагонали, ставя галочку в конце. Но в декабре 2025 года в нем появились изменения, которые могут напрямую повлиять на финансовые потоки тысяч разработчиков по всему миру. Речь идет не о новых API или технических требованиях, а о перераспределении финансовых полномочий между платформой и теми, кто создает для нее приложения. Эти правки - тихая революция в отношениях платформа-разработчик, происходящая в мелком шрифте юридического документа.


Юридический механизм, который меняет баланс сил:

В разделах 3.4 Приложений 2 и 3 появилась формулировка, дающая Apple право «зачитывать или возмещать суммы, причитающиеся Apple». На обычном языке это означает: если Apple считает, что вы должны ей денег за комиссии, сборы или налоги - она может просто взять эти деньги с вашего счета разработчика без отдельного уведомления или согласования.


Цепная реакция ответственности:

Еще более значимое изменение: расширение ответственности на аффилированных лиц, материнских или дочерних компаний. На практике это создает прецедент групповой ответственности.

Представьте сценарий: небольшая студия разрабатывает нишевое приложение, которое использует альтернативные платежи. У студии есть материнская компания, которая выпускает другое, более популярное приложение через App Store. Если студия задолжает Apple по комиссиям, Apple получает право взыскать эти деньги с доходов материнской компании от другого приложения.

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


Зачем это Apple сейчас?

Эти изменения нельзя рассматривать изолированно. Они происходят на фоне:

🔵Регуляторного давления в ЕС: DMA вынудила Apple допустить альтернативные платежные системы, но компания ищет способы сохранить контроль над денежными потоками.

🔵Судебных баталий в США: решение о возможности взимания комиссий (хоть и не полных 27%) создало прецедент, который нужно юридически закрепить.

🔵Экспансии в Японию: новые правила для японского рынка требуют унификации механизмов взимания платежей.

🔵Перехода от CTF к CTC в январе 2026: более сложная процентная модель комиссий требует более гибких инструментов взыскания.

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


Побочные изменения - не только про деньги:

В том же обновлении есть и другие значимые правки:

🔵Запрет на скрытую запись: формулировка «без ведома пользователей» может осложнить жизнь инструментам аналитики и отладки, которые используют запись сессий.

🔵Требования к голосовым помощникам: активация через боковую кнопку iPhone теперь регулируется отдельно, что указывает на стратегический интерес Apple к голосовым интерфейсам.

🔵API для возраста и контента: усиление контроля над возрастными рейтингами и тематикой приложений.

Эти изменения рисуют картину платформы, которая усиливает контроль сразу по нескольким фронтам: финансовому, этическому, технологическому.


💡 Вывод:

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

Для разработчиков это означает новую реальность: финансовая прозрачность становится двусторонней улицей. Если раньше вы отчитывались перед Apple о своих доходах, то теперь Apple получает право самостоятельно определять, сколько вы должны, и взыскивать эту сумму наиболее удобным для себя способом.


➡️ Подписаться на канал
Мобильный трудоголик

🔨 Один пакет для всех тестов: радикальный подход к ускорению CI.

Представьте CI-пайплайн, где каждый пул-реквест собирается 30 минут. Разработчики теряют фокус, контекст переключается, а поток работы прерывается. Теперь представьте тот же пайплайн, но работающий за 2.5 минуты. Это не фантастика, а реальная история оптимизации, которая началась с трех Mac mini и закончилась архитектурным прорывом в организации сборок Xcode.


Когда рост становится проблемой:

Все начиналось невинно: добавили тесты для первого пакета, создали конфигурацию. Потом подключили второй пакет - добавили еще одну конфигурацию. К третьему пакету шаблон был очевиден. Через несколько месяцев в проекте оказалось 91 отдельная конфигурация для сборки и тестирования.

Казалось логичным: изменили код в пакете А - запустились только его тесты. Но реальность оказалась сложнее. Основное приложение собиралось 12 минут - это был физический предел скорости. Остальное время уходило на дублирование работы: двадцать разных процессов могли одновременно пересобирать одни и те же зависимости, потому что каждый начинал с нуля.


Миф о портативном кэше:

Первая мысль любого инженера при оптимизации сборок - кэширование. С Xcode эта идея разбивается о суровую реальность.

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

Попытка использовать стандартный механизм кэширования GitHub тоже провалилась: 20 гигабайт данных нужно было скачивать перед каждой сборкой. На обычном интернет-соединении это занимало больше времени, чем полная пересборка проекта.

Но самая глубокая проблема обнаружилась дальше: Xcode принципиально не делится артефактами между разными типами целей. Приложение и Swift Package, даже если они используют один и тот же код, компилируются независимо. Два разных пакета в одном рабочем процессе тоже не могут использовать общие промежуточные файлы. Получался абсурд: изменение в одной библиотеке запускало двадцать параллельных процессов, каждый из которых компилировал одни и те же исходники с нуля.


Архитектурное решение - два мира, два кэша:

Прорыв пришел с парадоксальной идеей: а что если на время CI временно объединить все 89 Swift-пакетов в один гигантский пакет?

Такой подход дает лучшее из двух миров: максимальное повторное использование скомпилированного кода для тестирования и строгий контроль зависимостей для продакшен-сборки.


Система слотов - стабильность через постоянство:

Ключевое открытие оказалось удивительно простым: единственный способ заставить Xcode надежно использовать кэш - никогда не перемещать его. Директория DerivedData должна оставаться на одном и том же месте всегда.

Так родилась концепция «слотов» - фиксированных рабочих каталогов, которые процессы CI не копируют, а используют напрямую.


Интеллектуальный отбор тестов:

Объединение 91 конфигурации в единую систему потребовало умного алгоритма определения того, что действительно нужно проверить. На практике это выглядит так: изменили одну строку в библиотеке - автоматически запустились 12 связанных тестовых наборов и 3 сборки приложений. 61 несвязанный тест был пропущен. В сочетании с предварительно подготовленными кэшами большинство проверок затрагивают менее 20% кодовой базы.


💡 Вывод:

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

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


➡️ Подписаться на канал
Мобильный трудоголик