Читаемость кода упрощает как процесс написания программ, так и последующие действия – от отладки и оптимизации до тестирования и сопровождения.

Один из эффективных способов для понимания кода – применение функциональной парадигмы программирования. Основная идея функционального программирования состоит в представлении процесса вычислений как последовательного изменения состояний без хранения где-либо самих состояний. В качестве примера системы, в которой хорошо реализован функциональный подход, часто приводят Haskell, а также Erlang или Scala. Внедряя такой подход в распространенные языки, такие как JS или Swift, можно добиться как улучшения читаемости, так и тестируемости.

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

Всем привет, меня зовут Виталий, я основатель Adapty. Подписки — один из способов монетизировать приложение. С их помощью вы можете дать пользователю возможность получить постоянный доступ к обновляемому контенту в приложении или же к предоставляемому сервису. В отличие от обычных покупок, где Apple берет себе 30% комиссию, на подписках эта комиссия сокращена до 15% в случае, если пользователь подписан в течение 1 года и более. Важный момент: если пользователь отменит подписку, то данный счетчик сбросится через 60 дней.

Мы выпускаем цикл статей, закрывающих все вопросы добавления встроенных покупок в iOS:

1. iOS in-app purchases, часть 1: конфигурация и добавление в проект. — Вы тут.
2. iOS in-app purchases, часть 2: Инициализация и обработка покупок.
3. iOS in-app purchases, часть 3: Серверная валидация покупки.
4. iOS in-app purchases, часть 4: Локальное тестирование покупок в XCode.
5. iOS in-app purchases, часть 5: Обработка ошибок SKErrors.

​​В этой части мы научимся:

• cоздавать покупки в App Store Connect;
• конфигурировать подписки — указывать длительность, стоимость, пробные периоды;
• получать список покупок в приложении

Небольшая предыстория

Вступление

SwiftUI — это современный UI framework, который позволяет разработчикам быстро и легко создавать собственные приложения на всех платформах Apple.

Используя простой, понятный декларативный стиль, разработчики могут создавать потрясающие пользовательские интерфейсы с плавной анимацией. SwiftUI экономит время разработчиков, предоставляя огромное количество готовых решений, включая Interface Layout, Dark Mode, Accessibility, интернационализацию и многое другое. Приложения SwiftUI работают нативно и невероятно быстро. А поскольку SwiftUI — это один и тот же API, встроенный в iOS, iPadOS, macOS, watchOS и tvOS, разработчики могут быстрее и проще создавать отличные нативные приложения для всех платформ Apple.

Звучит amazing, не правда ли?

Введение

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

• почему View это структура, а не класс
• что такое @State
• что такое Function Builders и кто такой @ViewBuilder

а сразу перейдем к практике и сделаем достаточно стандартную в повседневной жизни задачу — создание горизонтального списка.

Будет очень много кода и мало комментариев, впрочем, все как мы любим.

При работе с UITableView хотелось избежать написания шаблонного кода, который еще больше усложняется, если нужно обновлять состояние таблицы анимировано. Apple представила свое решение этой проблемы на WWDC 2019, но оно работает только с iOS 13. А у нас, как у студии разработки мобильных приложений, нет такой роскоши в выборе минимальной версии iOS.

Поэтому мы реализовали наше видение data-driven подхода для работы с таблицами, попутно упростив настройку ячеек. И добавили анимированное обновление таблицы, которое основано на автоматическом подсчете различий между старыми и новыми данными за линейное время O(n). Все это мы оформили в небольшую библиотеку, которую назвали TableAdapter.

О том, что у нас получилось и как мы к этому пришли, и пойдет речь в статье.

Multiple trailing closures

import Foundation

func load(url: String, success: (Data) -> Void, failure: (Error) -> Void) {
    
}

// old  version

load(url: "someURL", success: { data in }, failure: { error in })

// new multiple trailing closures

load(url: "someURL") { (data) in
    // do smth
} failure: { (error) in
    // do smth
}

Multi-Pattern Catch Clauses

Темная тема

static let darkStart = Color(red: 50 / 255, green: 60 / 255, blue: 65 / 255)
static let darkEnd = Color(red: 25 / 255, green: 25 / 255, blue: 30 / 255)

var body: some View {
    ZStack {
        LinearGradient(Color.darkStart, Color.darkEnd)

Привет, Хабр! Представляю вашему вниманию перевод статьи "Testing Your RxSwift Code" автора Shai Mishali с сайта raywenderlich.com.

Написание реактивных приложений с помощью RxSwift концептуально отличается от написания приложений "обычным путем". Оно отличается в том смысле, что объекты в вашем приложении обычно не будут иметь четкого значения, вместо этого они будут представлены потоком значений на оси времени, известным в RxSwift как Observable. Эта статья даст вам ключ к тестированию RxSwift кода.

Observable — мощный механизм, который позволяет вам, как разработчику, реагировать на изменения и быть уверенным что состояние вашего приложения всегда актуально. Вместе со всеми преимуществами которые это дает, тестирование Observable — не такая тривиальная задача, как простое использование XCTAssert для обычных значений. Но не переживайте — эта статья наставит вас на путь становления экспертом в тестировании RxSwift!

Эта статья научит вас создавать unit тесты для Observable потоков. Вы научитесь некоторым доступным техникам для тестирования RxSwift кода, а также некоторым советам. Давайте начнем.

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

Идея

На WWDC 2019 была представлена SwiftUI — технология коренным образом влияющая на создание UI в приложениях для экосистемы Apple. Нам в Distillery стало интересно в ней разобраться чуть глубже, чем это подано в примерах от Apple. В идеале нужно было запилить какой-нибудь полезный для iOS команды и сообщества UI компонент. С идеями по этому поводу оказалось туго, поэтому решили пилить что-то просто забавное. Вдохновил вот этот концепт:

Особенно интересным показалось обилие нетривиальной анимации. Таким образом, по ходу реализации хотелось проверить, насколько SwiftUI удобен и приспособлен для чего-то более сложного, чем почти статический UI из примеров WWDC 2019.

При разработке мобильных приложений мы так или иначе сталкиваемся с необходимостью парсинга серверных данных во внутренние модели приложения. В подавляющем большинстве случаев эти данные приходят в формате JSON. Начиная со Swift 4 основным инструментом для парсинга JSON является использование протокола Decodable и объекта JSONDecoder.

Данный подход значительно упростил процесс парсинга данных и сократил количество boilerplate кода. В большинстве случаев достаточно просто создать модели со свойствами, названными также как и поля в JSON объекте и всю остальную работу JSONDecoder сделает за вас. Минимум кода, максимум пользы. Однако этот подход имеет один недостаток, а именно, крайне низкую лояльность парсера. Поясню. При любом несоответствии внутренней модели данных (Decodable объектов) тому, что пришло в JSON, JSONDecoder бросает ошибку и мы теряем весь объект целиком. Возможно, в некоторых ситуациях такая модель поведения предпочтительна, особенно, если речь идет, например, о финансовых операциях. Но во многих случаях было бы полезно сделать процесс парсинга более лояльным. В этой статье я бы хотел поделиться своим опытом и рассказать об основных способах повышения этой самой лояльности.

Проблема

Переходя в мир Swift из ObjC/C++, я столкнулся с проблемой при написании юнит-тестов: отсутствием инструментов для создания Mock-объектов.

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

Погуглив, я нашел несколько фреймворков Swift Mocking на github. Но ни один из них не явился мне ясным и очевидным в использовании (по одной или нескольким причинам):

• имеет тучу зависимостей
• не имеет интуитивного синтаксиса
• требуется кодогенерация / написание вручную большого количества вспомогательного кода
• не интегрирован с XCTest (позволяет мокать, но не тестировать)
• иметь много возможностей, сваленых в кучу одного фреймворка (неразбериха что и зачем)
• должен использоваться с ограниченным количеством предопределенных/встроенных типов

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

• каждый раз разные (изобретаем велосипед)
• или каждый раз одинаковые (копипаст)
• неочевидные в использовании

Решение

В мире C ++ существует популярный и чудесный фреймворк gTest / gMock (от Google).
Он позволяет создавать Mock-объекты очень наглядно и компактно. Также он имеет интуитивно понятный синтаксис, который позволяет просто «читать» (не изучать) написанный тестовый код.

Если вам по какой-то причине не нравится процесс создания coreData-модели с помощью графического интерфейса XCode, или вы такой же ненормальный программист как я и хотите, чтобы ваше приложение избавилось от .XCDataModel файлов и запускалось чуть быстрее, тогда добро пожаловать под кат.