Первое с чем вы сталкиваетесь при написании мобильного приложения, это переходы с одного экрана на другой и обратно (в случае простого приложения), а так же многоуровневые переходы и моментальный возврат на первый экран (back to root view). Всё это мы разберём на примерах в данной статье, ну а для начала немного углубимся в теорию.

Что такое NavigationView?

Представьте, что перед вами коробка (NavigationView) в которой много мячиков (View) и эти мячики могут соприкасаться друг с другом (переход с View на View) только в рамках этой коробки. 

Но есть так же и случаи, когда внутри коробки, помимо шариков, есть ещё одна коробка поменьше, которая содержит другие маленькие шарики (история про .sheet и .fullScreenCover - модальные окна). Это так же разберём ниже в статье.

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

Но предел моих мечтаний, конечно – менеджер, который Всё Унифицировал. Тот, у которого Единый Процесс. Самый Лучший, разумеется. Или даже Единственно Верный.

Я тоже хотел стать таким, честно. Придумаю, бывало, какую-нибудь методику, или в книжке вычитаю – и леплю без разбора на всех. Начитаюсь или наслушаюсь, как надо проекты делать – и поскакали. Но со временем я понял, что не прав.

Не прав именно я, не дорос ещё. Рано мне уверенно утверждать, что правильно, а что нет. Я должен пройти Путь, который, наверняка, прошли программисты, тимлиды, проджекты и менеджеры моей мечты.

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

Ключевая проблема конкуренции – сравнение результатов в сопоставимых системах координат. Бывает ведь смотришь на людей – ну прям молодцы. Но стоит их выдернуть из привычного контекста, как вся «молодцеватость» куда-то исчезает. Программист, который был звездой на одном проекте, оказывается худшим звеном на другом. Тимлид, получивший престижную премию «Проект года», садится в лужу на следующем проекте. Контекст разный.

Думал-думал я, и придумал. Не надо притягивать за уши контекст. Надо устроить конкуренцию внутри одного контекста. Внутри одной компании. Даже – внутри одного отдела. Благо, у меня есть отдел.

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

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

Поэтому я стал эволюцию подпинывать. Как? Ну, как учёные в лабораториях с крысами. Проактивно, по собственному желанию.

@available(iOS 13.0, OSX 10.15, tvOS 13.0, *)
@available(watchOS, unavailable)
public struct NavigationView<Content> : View where Content : View {

    public init(@ViewBuilder content: () -> Content)

    //....
}

struct OrderButtonExperimentDTO: Decodable {
   let buttonTitle: String
   let estimationMinute: Int
}

Я всегда думал: "А зачем нужно писать свой copy-on-write? Ведь круто, когда есть структуры и они такие быстрые, что всё делают за тебя."

Но все это не нужно, пока не начинаешь писать свои типы и не подсаживаешься на LinkedList'ы.

Что такое этот связанный список и какие у него преимущества?

Многие iOS разработчики не задумываются как работает механизм отрисовки элементов, установки и обновлении constraints в Auto Layout'e. В этой статье я пробую подробно заглянуть внутрь работы the Layout Engine

Проверка кода (code review) — отличный инструмент для повышения качества кода, но он не учитывает один факт: отправляют и просматривают код люди, а они устают, теряют сосредоточенность, ленятся, да и просто испытывают эмоции в самые неожиданные моменты.

Поэтому хочу представить свое видение хороших и плохих практик код ревью с учётом человеческих особенностей.

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

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

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

Кроме того, обслуживание или изменение проекта в будущем станет легким. Таким образом, вы в конечном итоге сэкономите деньги, время и ресурсы. Если вы хотите, чтобы проект развивался более плавно, то рекомендуется жить по этим законам.

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

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

В основном идея использования 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.

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

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

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

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