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

State — фундаментальное понятие в SwiftUI и Redux. В нашем случае это не только модное слово, но и сущность, которая связывает их и позволяет им очень хорошо работать вместе. В этой статье я постараюсь показать, что приведенный выше тезис правдив, поэтому давайте начнем!

Перед тем как мы погрузимся в написания кода, давайте для начала разберемся, что такое Redux и из чего он состоит.

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

В этой статье мы узнаем, как профилировать сборку в Xcode и получать метрики. В следующей статье я расскажу о методах устранения узких мест и ускорения сборки проекта. Следует также упомянуть, что мы будем использовать проект Kickstarter iOS, который можно найти на Github. Так что давайте начнем!

Что мы измеряем?

Первое, что мы должны сделать, — определить, что мы пытаемся измерить и оптимизировать. Можно рассмотреть два варианта:

• Clean build — clean и сборки проекта. Часто clean сборка выполняется на CI для проверки нового pull request и выполнения юнит тестов.
• Incremental build — сборки проекта после значительных правок исходного кода. Эта сборка создается разработчиком во время работы над новой функциональностью.

В большинстве случаев уменьшение времени при Clean сборке должно также ускорить Incremental сборку. Оптимальным вариантом было бы создание метрик для обоих типов сборок и отслеживание их. Мы будем измерять время сборки, используя Debug конфигурацию только потому, что она используются большую часть времени и оказывают большее влияние на разработку.

Привет всем! В этой статье я хотел бы показать вам, как создать Flutter приложение, используя Redux. Если вы не знаете, что такое Flutter, то это — SDK с открытым исходным кодом для создания мобильных приложений от компании Google. Он используется для разработки приложений под Android и iOS, а также это пока единственный способ разработки приложений под Google Fuchsia.

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

Но перед тем как мы приступим к написанию самого приложения. Давайте немного познакомимся с теорией, давайте начнем с объяснения, что такое Redux.

На прошлой неделе я увидел, что сообщество пытается перенести наработаные шаблоны разработки c UIKit в SwiftUI. Но я уверен, что лучший способ написать эффективный код используя SwiftUI — это забыть все об UIKit и полностью изменить свое мышление с точки зрения разработки пользовательского интерфейса. На этой неделе я расскажу основные отличия между разработкой используя UIKit и SwiftUI.

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

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

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

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

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

Новая игрушка

Мы продолжаем знакомиться с новым материалом от Apple, представленным на WWDC. На этот раз рассмотрим MetricKit, это абсолютно новый фреймворк, который служит инструментом для мониторинга производительности приложений.

На этой неделе я хочу поговорить о моделировании слоя данных в SwiftUI. Я уже закончил работу над своим самым первым приложением, которое я создаю используя только SwiftUI. Теперь я могу поделиться способом создания слоя модели с использованием объектов Store, которые я использовал при разработке приложения NapBot.

Объект Store

Объекты Store, отвечают за сохранение состояния и предоставлении действии по его изменению. У вас может быть столько объектов Store, сколько вам необходимо, желательно чтобы они были простыми и отвечали за небольшую часть состояния вашего приложения. Например, у вас может быть SettingsStore для сохранения состояния пользовательских настроек и TodoStore для сохранения пользовательских задач.

MVC был давним стандартом в паттернах проектирования, используемых для написания iOS приложений. Структура iOS приложений, которые создавались ранее, была основана на одном базовом компоненте, который присутствует везде, и называется он — Controller. На WWDC19 был представлен SwiftUI, который не имеет такого компонента.

Проблема с так называемыми massive view-controllers должна быть решена в SwiftUI. Так, необходимо найти новый способ правильной декомпозиции кода. Давайте посмотрим на текущее состояние платформы и подумаем, какие парадигмы мы можем использовать при разработке для iOS13 и более поздних версий.

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

Но теперь все это имеет смысл, после использования из в разработки на React в течение нескольких недель, я теперь не могу вернуться к своим старым способам разработки под iOS. Я не буду переходить на javascript (AKA React Native) для разработки мобильных приложений, но вот кое-что, чему я научился.


Вернувшись к разработке под iOS, я создал новый проект и начал исследовать ReSwift, это реализация паттерна Flux и Redux в Swift. И это довольно просто работает, я несколько раз клонировал архитектуру JavaScript приложении, теперь у меня есть глобальное состояние, и мои контроллеры просто слушают это состояние. Сами контроллеры состоят из различных компонентов представления, которые инкапсулируют очень специфическое поведение.

Во время проведения WWDC 2019, одним из самым больших и захватывающих моментом был анонс релиза SwiftUI. SwiftUI — это совершенно новый фреймворк, который позволяет проектировать и разрабатывать пользовательские интерфейсы с написанием меньшего количества кода, декларативным способом.

В отличие от UIKit, который обычно использовался в сочетании с storyboards, SwiftUI полностью основан на программном коде. Тем не менее, синтаксис очень прост для понимания и проект можно быстро просмотреть с помощью Automatic Preview.

Поскольку SwiftUI использует язык Swift, он позволяет создавать приложения той же сложности с гораздо меньшим количеством кода. Более того, использование SwiftUI автоматически позволяет приложению использовать такие функции, как Dynamic Type, Dark Mode, Localization и Accessibility. Кроме того, он доступен на всех платформах, включая macOS, iOS, iPadOS, watchOS и tvOS. Итак, теперь ваш код пользовательского интерфейса может быть синхронизирован на всех платформах, что дает больше времени для того, чтобы сосредоточиться на второстепенном платформо-зависимом коде.

Мы пишем множество юнит тестов, разрабатывая приложение SoundCloud под iOS. Юнит тесты выглядят вполне великолепно. Они короткие, (надеюсь) читабельны, и они дают нам уверенность в том, что код, который мы пишем, работает так, как и ожидается. Но юнит тесты, как следует из их названия, охватывают только один блок кода, чаще всего функцию или класс. Итак, как отловить ошибки, которые существуют во взаимодействиях между классами — ошибки, такие как утечки памяти?

Создание анимаций это здорово. Они являются важной частью iOS Human Interface Guidelines. Анимации помогают привлечь внимание пользователя к важным вещам или попросту делают приложение не таким скучным.

Существует несколько способов реализовать анимацию в iOS. Вероятно, самым популярным способом является использование UIView.animate(withDuration: animations:). Вы можете анимировать слой изображения с помощью CABasicAnimation. Кроме того, UIKit позволяет настроить кастомную анимацию для отображения контроллера с помощью UIViewControllerTransitioningDelegate.

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

В этой статье про HealthKit вы узнаете, как запрашивать разрешение на доступ к данным HealthKit, а также считывать и записывать данные в центральный репозиторий HealthKit. В статье используется Swift 4, iOS 11, Xcode 9 версии.

HealthKit — это API, которое было представлено в iOS 8. HealthKit служит как центральный репозиторий для всех данных, связанных со здоровьем, позволяя пользователям создавать биологический профиль и хранить данные о тренировках.

По ходу прочтения статьи о HealthKit, вы создадите простейшее приложение для отслеживания тренировок и узнаете:

• Как запросить разрешение и получить доступ к данным HealthKit
• Как читать данные HealthKit и отображать их в UITableView
• Как записать данные в центральный репозиторий HealthKit

Готовы начать знакомство с HealthKit? Читайте дальше!

Хотел бы поделиться с вами некоторыми советами и трюками, которые я использовал на этом примере.

Скачайте Swift Playground со всем кодом из этой статьи:



Codable представлен в Swift 4 с целью заменить старый NSCoding API. В отличие от NSCoding у Codable есть поддержка JSON первого класса, что делает его перспективным вариантом для использования API JSON.

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

Со временем языки программирования постоянно изменяются и развиваются из-за появления новых технологий, современных требований или простого желания освежить стиль написания кода. Реактивное программирование можно реализовать с помощью различных фреймворков, таких как Reactive Cocoa. Он изменяет рамки императивного стиля языка Objective-C и у такого подхода к программированию есть что предложить стандартной парадигме. Это, безусловно, и привлекает внимание iOS разработчиков.

ReactiveCocoa привносит декларативный стиль в Objective-C. Что мы подразумеваем под этим? Традиционный императивный стиль, который используют такие языки как: C, С++, Objective-C, и Java и т. д. можно описать так: Вы пишете директивы для компьютерной программы, которые должны быть выполнены определенным способом. Другими словами, вы говорите «как сделать» что-то. В то время как декларативное программирование позволяет описать поток управления как последовательность действий, «что сделать», не определяя, «как делать».

Несколько лет назад команда Apple опубликовала интересную статью Повышение производительности за счет сокращения динамической отправки. Эта статья довольно интересна для прочтения, в которой выделяются тонкие аспекты языка Swift и его компилятора.

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

После прочтения данной статьи, вы сможете использовать Quick и Nimble в своих проектах!


Написание прекрасных работоспособных приложений — одно дело, но написание хороших тестов, которые подтверждают ожидаемое поведение вашего приложения, — задача намного сложнее. В этой статье мы рассмотрим один из доступных подходов тестирования приложений, behavior-driven testing, используя два чрезвычайно популярных фреймворка под названием Quick и Nimble.

Вы узнаете о behavior-driven testing: изучите что это такое, почему это чрезвычайно мощная концепция и насколько легко писать читабельные тесты с помощью фреймворков Quick и Nimble.

Вы будете писать тесты для удивительно простой и забавной игры под названием AppTacToe, в которой вы играете в игру Tic Tac Toe против компьютера, изображая iOS персонажа, играющего против злого Android игрока!