Привет, Habr! Меня зовут Алексей, я iOS Developer в компании FINCH. Скоро Новый год — самое время чтобы начать жить по-другому, а поможет в этом такая классная штука как SwiftLint. В статье я расскажу, почему ее обязательно нужно внедрять во все проекты, включая legacy и pet-проекты, а также покажу как выжать из этого инструмента максимум, используя регулярные строки.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Swift 5.0: How to migrate your project and frameworks» автора Antoine Van Der Lee.

Swift 5.0 был выпущен в марте 2019 года и является первым стабильным выпуском ABI Swift. Несмотря на то, что многие ресурсы освещают новые возможности Swift 5.0, они не часто рассказывают вам о том, что вам нужно сделать, чтобы обновить свой проект до Swift 5.0.

В этом посте я рассмотрю шаги, которые вы можете предпринять, чтобы обновить существующий проект до Swift 5.0.

Проверьте, что ваш проект уже перенесен в Swift 4.2.

Не удивлюсь, если эта статья поможет убедить вашего продакт-менеджера спланировать время для перехода.

Code review может быть большой болью для команды, которая только начинает его внедрять. Вы в любом случае наступите на много граблей: будете проводить ревью дольше, чем пишете код, устраивать смертельные споры про расположение скобочек и разбираться, можно ли сливать ветку в master до аппрува команды или нет. Я собрал ряд практик, которые помогут вам сделать процесс адаптации чуть менее болезненным — по крайней мере, мне они точно помогли.
 
Этот материал — краткая выжимка моего опыта, накопленного за несколько лет работы в крупных командах мобильной разработки. Опыт по большей части в мобильной разработке, что оказало влияние на используемые примеры и ссылки. Для тех, кто предпочитает не читать, а смотреть, в течение пары месяцев должно появиться видео с конференции Mobius, где я рассказываю доклад на эту же тему, но с кучей подробных практических примеров.
 

Приглашаем вас в iThink — уже пятое сообщество от NIX Solutions! Впереди первая конференция, и мы приглашаем как начинающих, так и опытных разработчиков присоединиться к нашему iOS-комьюнити. На встрече вы сможете познакомиться и пообщаться с четырьмя экспертами iOS-разработки, прокачаться в трех актуальных темах, узнать много нового и устроить себе насыщенный вечер пятницы.

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

Interface Builder в Xcode с некоторого времени экономит мне много времени в работе по стандартному лайауту элементов интерфейса и иногда помогает в задаче прототипирования. С версии 6 в Xcode добавили возможность рендера кастомных вьюшек, помеченных атрибутом IBDesignable, а также отображение в билдере полей класса, помеченных атрибутом IBInspectable.

С версии Xcode 7 этой фичей стало более-менее возможно пользоваться, поэтому мне захотелось проверить её возможности.

Почитать про IBDesignable/IBInspectable можно тут и тут.

Данный текст представляет собой перевод статьи NSUserDefaults In Practice. Автором оригинала является Дэвид Смит (David Smith). Перевод выполнен с любезного разрешения автора.

Что такое NSUserDefaults?

Комментарий с которого начинается заголовочный файл «NSUserDefaults.h» вполне хорошо описывает класс. Этим комментарием я и воспользуюсь, чтобы начать:

NSUserDefaults являются:

1) иерархическим
2) постоянным (персистентным)
3) межпроцессным
4) и в некоторых случаях распределенным
хранилищем вида ключ-значение. NSUserDefaults оптимизированы для хранения пользовательских настроек.

Содержание:

Часть 0. Синглтон-Одиночка
Часть 1. Стратегия
Часть 2. Наблюдатель

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

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

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

Естественно, iOS версия создавалась на классическом, рекомендуемом самим Apple, паттерне MVC.

У меня была View: "любимый" сториборд, в котором было over9000 довольно много экранов, и который был похож на это:

Коллекции

Разработчики, перешедшие на Swift с Objective-C, не могли не заметить удобнейший функционал, который предоставляет Swift для работы с коллекциями. Использование диапазонов в индексах

let slice = array[1..<10]

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

Filter

Самой часто используемой функцией для коллекций, пожалуй, является filter

let alex = Person(name: "Alex", age: 23)
let jenny = Person(name: "Jenny", age: 20)
let jason = Person(name: "Jason", age: 35)
let persons = [alex, jenny, jason]
let jNamedPersons = persons.filter { $0.name.hasPrefix("J") } // [jenny, jason]

Reduce

Реже используемой, но при этом крайне выразительной и удобной является функция reduce

let ages = persons.map{ Float($0.age) }
let average = ages.reduce(0, +) / Float(persons.count)

Можно писать свои функции высшего порядка и это довольно увлекательно:

func divisible(by numbers: Int...) -> (Int) -> Bool {
    return { input -> Bool in
        return numbers.reduce(true) { divisible, number in
            divisible && input % number == 0
        }
    }
}

let items = [6, 12, 24, 13]
let result = items.filter(divisible(by: 2, 3, 4)) // [12, 24]

Map

Функциональные понятия функторов и монад пришли к нам из языка Haskell. Говорят, невозможно просто взять и понять, что такое монада, а уж тем более невозможно это объяснить. Тем не менее мы можем временно отбросить все сложности и объяснить себе только то, что действительно необходимо, а те, кто захочет закопаться поглубже, могут начать с изучения Haskell.

Итак, для простоты мы можем считать, что функтор это контейнер, к которому применима функция map, а монада это функтор, к которому применима функция flatMap.

Поскольку коллекции это контейнеры, и в Swift для них определена функция map, они могут выступать в роли функторов:
для того, чтобы трансформировать коллекцию одного типа в коллекцию другого типа, возьмем наш массив persons и получим из него массив возрастов типа [Int]

let ages = array.map{ $0.age } // [23, 20, 35]

FlatMap

И в роли монад:
для того, чтобы из массива oprtional типов вернуть массив не опциональных значений

let optionalStrings: [String?] = ["a", nil, "b", "c", nil]
let strings = optionalStrings.flatMap { $0 } // ["a", "b", "c"]

для того, чтобы расширить первоначальную коллекцию

let odds = [1,3,5,7,9]
let evensAndOdds = odds.flatMap { [$0, $0 + 1] } // [1,2,3,4,5,6,7,8,9,10]

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

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

Возьмём за основу статью Знакомьтесь, Swift!, где показано как сделать простое приложение на Swift, и добавим туда такие известные и полезные штуки как pull to refresh и infinite scrolling используя встроенные возможности языка. Чтобы было еще интереснее, добавим немного асинхронности, иначе приложение будет каждый раз замирать на время обновления.

Последние 10 лет для ведения проектов мы пользовались такими системами как YouTrack, Jira, Asana, Slack, SmartSheet, BaseCamp, Trello и даже белой доской, а также постоянно тестировали что-то новое. По нашему мнению, главная проблема всех систем управления в том, что люди в компании попросту забивают на её использование. А было бы здорово, если информация на все отделы распространялась из одной системы и вся команда сама активно постоянно ей пользовалась.

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

Для начала хотели реализовать 2 вещи:

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

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

Этот пост является вольным переводом статьи How to highlight your TODOs, FIXMEs, & ERRORs in Xcode by Hector Matos

Это был самый обычный день: я писал код, устранял баги и вообще все было прекрасно. Именно тогда я написал блок кода, к которому нужно было вернуться позже. Это обычный случай, с которым вы тоже вероятно сталкивались: нужно было взаимодействовать с API который еще не был готов. Я знал общую структуру объекта, который получу по API, но я еще не мог протестировать работу с ним. Как и любой другой разработчик, я написал комментарий, который выглядит так:

В этот момент я хотел бы создать предупреждение в Xcode, такое же как мы привыкли делать в Objective-C с помощью директив компилятора:

Но увы, так не получилось и я загрустил.

Я почув і забув.
Я записав і запам'ятав.
Я зробив і зрозумів.
Я навчив іншого, тепер я майстер.
(В. В. Бублик)

Небольшое вступление.

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

И именно эти слова и сподвигли меня на написание данной серии постов. Дело в том, что я — начинающий iOS разработчик, и я очень хочу разобраться в паттернах проектирования. И я не придумал лучшего способа, чем взять книгу "Паттерны проектирования" Эрика и Элизабет Фримен, и написать примеры каждого паттерна на Objective-C и Swift. Таким образом я смогу лучше понять суть каждого паттерна, а также особенности обоих языков.

Содержание:

Часть 0. Синглтон-Одиночка
Часть 1. Стратегия
Часть 2. Наблюдатель

Итак, начнем с самого простого на мой взгляд паттерна.

Этот пост является вольным переводом статьи Xcode: A Better Way to Deal with Storyboards by Stan Ostrovskiy

Некоторые примеры кода в оригинальной статье устарели (ввиду выхода Swift 3) и в переводе были изменены.

Советы и рекомендации по работе с Interface Builder.

Apple серьезно улучшили Interface Builder в новом Xcode 8. Использование size classes стало более интуитивным, возможность масштабирования сториборда — очень удобной, а полное превью прям в Interface Builder — просто великолепным. Для тех у кого были сомнения насчет использования Interface Builder, это может стать хорошими плюсами.

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

В этой статье я поделюсь некоторыми из лучших практик для работы со сторибордами в вашем проекте. Вы уже пользуетесь Interface Builder, или только делаете первые шаги в этом направлении? — в любом случае, эти советы будут полезны для вас.

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

В вашем проекте есть один файл main.storyboard, который выглядит вот так?

С точки зрения дизайнера, все хорошо: полностью видно UI и навигацию. И это именно то, для чего Interface Builder и был создан.

Но для разработчика это несет множество проблем: