Всем привет! Меня зовут Юра, я iOS-разработчик в core-команде. В этой статье расскажу, как мы работаем с многомодульностью в наших iOS-приложениях. Поговорим про окружение и структуру нашего проекта, затронем тему скорости компиляции и разберем немного кодогенерации. 

Часто бывает так, что нам нужно скопировать объект, изменив некоторые его свойства, но сохранив остальные неизменными. Для этой задачи существует функция copy().

Это отрывок описания метода copy() из документации Kotlin. На нашем родном языке Swift это означает примерно такую возможность:

struct User {
    let id: Int
    let name: String
    let age: Int
}

let steve = User(id: 1, name: "Steve", age: 21)

// Копируем экземпляр, изменив свойства `name` и `age`
let steveJobs = steve.changing { newUser in
    newUser.name = "Steve Jobs"
    newUser.age = 41
}

Выглядит вкусно, не так ли?

Увы, в Swift отсутствует подобный функционал "из коробки". Это небольшое руководство поможет реализовать его самостоятельно.

Статические и динамические фреймворки на iOS - обсуждение с ChatGPT

Как и большинство людей в мире технологий, мы экспериментировали с ChatGPT и хотели посмотреть, как он справится с низкоуровневыми техническими деталями. Мы попросили ChatGPT написать блог о статических и динамических фреймворках в iOS. Здесь - его ответ, а также то, что он сделал правильно, а что нет.

Обычно тесты не популярны в СНГ. Многие считают их дорогими и тормозящими разработку. Часто это говорят те, кто за разработку принимает написание кода сразу в прод и забывают о нем навсегда

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

Мы в iOS команде Vivid Money стремимся глубже понимать инструменты, которыми пользуемся каждый день. Один из таких – это язык программирования Swift. Он состоит из нескольких частей: компилятора, стандартной библиотеки и рантайма. Компилятор преобразует код понятный для человека в код понятный компьютеру. Стандартная библиотека предоставляет разработчикам готовые структуры данных, оптимизированные для применения в боевых проектах. А вот рантайм – это, поистине, сердце языка. В нем происходит выделение памяти, динамическое приведение типов и подсчет ссылок. И нам стало интересно, как реализован подсчет ссылок в рантайме. И  вот мы вдохновились публикациями легендарного Майка Эша (Mike Ash), собрали компилятор и начали исследовать. Посмотрели на работу алгоритма подсчета ссылок и в этой статье расскажем вам о нём.

Стандартное представление Xcode-проекта сложно назвать комфортным для командной работы. Даже в небольших проектах часто возникают merge-конфликты после изменения состава исходников в разных ветках.

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

Да, ограничения Xcode можно победить, но решением в основном является "винегрет" из сторонних инструментов, заправленный собственными Shell или Ruby скриптами, в которых мало кто разбирается.

Но есть куда более изящное и комплексное решение — Tuist. С ним мы и познакомимся в этой статье.

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

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

В этой статье я расскажу:

— как мы не потерялись в сложном графе зависимостей;

— как спасли CI от чрезмерной нагрузки;

— что делать, если с каждым новым модулем приложение запускается всё медленнее;

— мониторинг каких показателей стоит предусмотреть и почему это необходимо.

В iOS-разработке Badoo мы уже несколько лет занимаемся созданием модулей, и большая часть нового кода разрабатывается вне кодовой базы приложений. Сейчас у нас более 100 модулей для Badoo и Bumble. В этой статье я расскажу о нашем опыте и отвечу на самые популярные вопросы о модуляризации: 

— по какому принципу выделять модули; 

— как организовать связи между ними; 

— достаточно ли для фичи одного фреймворка; 

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

— зачем в этом процессе мониторинг;

— можно ли автоматизировать создание новых модулей и так далее. 

Мой коллега, лид команды iOS-разработки и Core-команды Артем Лоенко, в начале года говорил об этом на митапе FunCorp в докладе «Катастрофически полезные последствия модуляризации». Я приведу более подробный разбор процесса модуляризации и некоторых опущенных в его рассказе деталей.

Об управление памятью в iOS ходят много слухов, поэтому я собрал все самые интересные в интернете и попробовал их структурировать в один большой

В основном идея использования CI/CD для iOS, да и для других платформ, — это автоматизация рутинной работы. Когда мы работаем над одним приложением, можем вручную собирать небольшой проект. Но команда растёт, хочется тратить время эффективнее, чем вручную собирать проект или объяснять новичкам, что же там с Code-signing нужно делать.

Пожалуй, самое рутинное и самое важное занятие, которое берёт на себя CI, — это прогон тестов. Нет зелёных тестов? В master не попадёшь. А с ростом команды вероятность того, что кто-то вольёт в master нерабочий код, будет только увеличиваться. Нужна автоматизация.

В этой статье я хочу подробно рассказать о пути настройки Gitlab CI + Fastlane + Firebase + Testflight. Примеры приводятся на основе одного проекта, в котором участвовали 10 разработчиков. В конце будут описаны проблемы, с которыми мы сталкивались, и их решения.

Для кого будет полезен этот опыт? Для всех, кому нужен CI/CD и кто сидит на Gitlab. Для Github будет другая связка, например с Travis, — остальные компоненты неизменны. В нашей команде все используют Gitlab CI, Fastlane вместо голого xcodebuild для быстроты и удобства разработки, Firebase и Testflight.

Если у нас бесплатный Gitlab и мы укладываемся в лимит Firebase, то получаем бесплатное решение по настройке CI/CD.

Write once, run anywhere

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

Каждый iOS разработчик в своей жизни уходил с собеседования в расстроенных чувствах и мыслью “это что еще за новая аббревиатура?” Архитектурами пугают и джунов, и миддлов, и синьоров (и наверное даже синьорит). Важно не просто знать что стоит за названием, но ещё и в каком случае какую использовать. Литературы по этому вопросу преступно мало, редкие обсуждения в интернете ограничиваются собственным опытом и какими-то поделками на гитхабе.

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

Первая часть посвящена MV(X) паттернам: самым известным и распространенным практикам в индустрии.

Примечание от переводчика: при словах «мобильные приложения Netflix» вспоминаются их основные приложения для просмотра видеоконтента, но компания ведёт и «киностудийную» разработку — для тех, кто этот контент создаёт. И их пост посвящён использованию Kotlin Multiplatform во втором случае.

В последние годы Netflix разрабатывает сервис Prodicle для индустрии производства телесериалов и фильмов. Мир съёмок живёт на высоких скоростях, а его запросы существенно различаются в разных странах, регионах и даже проектах. Его специфика означает, что мы делаем софт с упором на запись, в распределённом окружении, причём на съёмочной площадке интернет-соединение окажется очень надёжным менее чем в трети случаев, а право на ошибку у нас ограничено. Поэтому мы, будучи маленькой инженерной командой, обнаружили, что оптимизация надёжности и скорости выпуска продукта просто необходима нам, чтобы успешно отвечать растущим запросам наших клиентов.

Поскольку сетевое соединение часто оказывается ненадёжным, мы обратились к мобильным решениям для персистентности на клиентской стороне и поддержки офлайна. А потребность выпускать быстро привела к экспериментам с мультиплатформенной архитектурой. И теперь мы зашли тут ещё на шаг дальше, использовав Kotlin Multiplatform, чтобы писать платформонезависимую бизнес-логику один раз на Kotlin и компилировать её в Kotlin-библиотеку для Android и нативный Universal Framework для iOS с помощью Kotlin/Native.

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

Немного общей теории

Если вы хорошо осведомлены, смело пролистывайте непосредственно к анимации.