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

2-5 iOS разработчиков

Менеджер

Дизайнер

Тестировщик

Как видите, в списке нет DevOps, поэтому наш CI был полностью в нашем распоряжении и мы могли настраивать как нам удобно. Когда я присоединился к командам, то на CI уже всё было настроено по классике:

Mac Studio в подвале

Запуск Unit тестов

Запуск UI тестов

Сборки различных версий приложения (Firebase, TestFlight)

Всё работало как часы, я туда если честно не лазил (сначала), из разговора коллег, сама настройка CI им досталась от первых разработчиков проекта, которые больше уже не в команде и они там фундаментально после них ничего не меняли.

Время шло, задачи закрывались, релизы выпускались, в свободное время от задач расчищали беклог - в общем скукота. Так как мне нравится ковырять в носу xcodebuild через терминал, то иногда я стал замечать, что, например, тесты на CI и локально работают по-разному в плане скорости, локально вроде всё очень быстро, но на CI реально иногда надолго всё залипало - 5, 10, иногда 20 минут, хотя локально из консоли до двух раз быстрее.

После очередного закрытого спринта досрочно, осталось время на беклог, у меня закралась мысль, что что-то не так с нашим CI. Так как я знаю, что у нас на CI стоит Mac Studio, которая точно, хоть и немного, но шустрее моей машины, но по времени выполнения задач этого не скажешь.

Решил в итоге открыть ящик пондоры Fastfile и посмотреть, что же там и как это работает.

История, как я докатился до измерения скорости iOS xml парсеров в 2026 году.

Имеется один пет проект, где на старте приложения происходит скачивание большого xml файла на 500 тыс. строк (вес файла 65 Мб) и потом парсинг, на результате которого строится UI приложения. Так как я не люблю тянуть зависимости без лишней необходимости, то написал простой парсер на базе Foundation.XMLParser в паре с его делегатом XMLParserDelegate. Результат мне выдал 15 секунд ожидания на старте приложения, именно столько времени требовалось чтобы парсить пару String и пару Date типов полей. Думал на тот момент 500К строк и 15 секунд, наверное, пойдет для пет проекта, быстрее наврятли сделать, потому что визуально по коду парсер уже не улучшить, так как сделал кеширование ключ-значение и еще микро-хаки. И так прошло 3 года, приложением пользуюсь каждый день, уже привык к 15 секундам на старте, всегда думал, можно улучшить только поиском более быстрого xml парсера, но было лень для каждого парсера изучать API и руками писать бенчмарк, так и оставил до лучших времен.

Лучшие времена настали и дальше история, как ИИ мне помог сделать бенчмарк, который я откладывал 3 года. И какой отчасти низкосортный одноразовый код приложения он мне сгенерировал.

На дворе 2026, все пишут на SwiftUI и менеджерят зависимости через SwiftPM, но речь пойдет о Carthage - менеджере зависимостей для приложений под Apple платформу которому уже примерно 10 лет, то есть появился почти сразу после выхода языка Swift.

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

Давайте разбираться с самого начала.

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

Всё началось как обычно, а что если ...

Являясь не Android разработчиком, но имея хорошие базовые знания в Java, мне выпала небольшая research задача под Android платформу, для решения которой нужно было интегрировать стороннюю с/c++ библиотеку в Android Studio проект. В данном статье будет:

• пошаговое описание как собрать c/c++ проект, который корректно настроен под CMake систему сборки
• интеграция полученной библиотеки в Android проект через Android Studio

Введение

Поиск по ключевым словам в русскоязычном сегменте интернета на удивление дал мало результатов на данную тему. Но нашлась единственная довольно подробная статья на хабре https://habr.com/ru/company/e-Legion/blog/487046/, с которой вы заметите как сходства, так и различия. Для сравнения подходов решил так же для примера использовать проект с открытым исходным кодом https://opus-codec.org, что и в указанной статье. Система на которой будут выполняться все эксперименты MacOS Big Sur имея на борту cmake версии 3.19.3.

Сразу хочу отметить, что не являюсь экспертом по CMake и Android. Все действия, описанные в статье, вы делаете на свой страх и риск и автор не несет никакой ответственности за ваше потраченное время.

git checkout develop
git merge bug_fix_#999
git checkout master && git merge develop --no-ff ....
git push ....

Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.company.bob”) were found.

Немного общей информации о будущем релизе

time swiftc -Onone file.swift

Вступление

• соберем приложение и запустим на симуляторе
• соберем ipa и запустим на реальном девайсе
• соберем ipa для выкладки на маркет
• немного подэбажим ошибки сборки