Мы в hh очень любим UI-тесты, ими покрывается практически вся функциональность наших приложений, и даже backend-разработчики прогоняют тесты мобильных платформ перед развертыванием своих фич. Однако наши механизмы UI-тестирования разрабатывались более 8 лет назад и с тех пор почти не изменились.

Кто-то скажет, что старые решения прошли проверку временем и что «работает — не трогай»... Возможно, и так. Но сейчас мы внедряем новую дизайн-систему, а новые компоненты требуют адаптации всех тестов — не лучшее ли время для перемен?

Поэтому мы пересмотрели наши подходы к UI-тестированию и теперь готовы поделиться наработками с сообществом в виде open-source проекта — Rafinad. В этой статье расскажем, что он умеет и как им пользоваться.

Год назад мы пересмотрели свою реализацию роутинга в iOS-приложениях hh.ru. Тогда она больше походила на простой слой сборки экранов, чем на роутинг как таковой. Смирившись с этим печальным фактом, мы принялись исследовать тему навигации: пересмотрели много подходов в iOS, примерили каждое в песочнице нашего проекта и даже дошли до Cicerone из мира Android.

Взяв лучшее из всех изученных решений, мы переработали всё это дело в собственную реализацию, которая теперь идеально подходит под наши требования к навигации. Недавно мы начали выносить свои наработки в отдельный open-source проект — Nivelir. Эта статья поможет в нём разобраться и покажет, как устроен роутинг в наших проектах.

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

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

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

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

Часто бывает так, что нам нужно скопировать объект, изменив некоторые его свойства, но сохранив остальные неизменными. Для этой задачи существует функция 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 отсутствует подобный функционал "из коробки". Это небольшое руководство поможет реализовать его самостоятельно.

Представьте, что вам необходимо сохранить идентификатор пользователя в UserDefaults. Каким будет первый шаг?

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

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

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

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

Дело в том, что в hh для проектирования UI используется небезызвестный сервис Figma, который, кроме прочих своих плюсов, имеет открытый API. А это в свою очередь открывает широкие возможности для разработчиков, чем мы и решили воспользоваться.

Так родилась идея проекта FigmaGen - инструмента, который синхронизирует код с библиотекой компонентов в Figma. Сначала он выглядел, как эксперимент, специфичный только для нашего продукта, но получилось более универсальное решение, и в этой статье мы поделимся первыми плодами своей разработки.