Полезные материалы для
начинающих
iOS разработчиков

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

Общие рекомендации по обучению

Наши рекомендации для того, чтобы обучение iOS проходило эффективнее и было приближено к разработке реального проекта:

  • Эффективнее отрабатывать полученные знания на собственном проекте, а не только на академических примерах. Подумайте, что вам интересно и начните свой pet-проект.
  • Работайте с макетами в Figma. Для этого есть публичные Figma файлы, которые можно использовать для тренировки. Кроме того, вы там можете найти классные идеи для своего приложения.
  • Изучайте и перечитывайте гайдлайны Apple Human Interface Guidelines, применяйте их в разработке своих pet-проектов. Пробуйте добавлять различные контролы в своем приложении.
  • Ищите интересные вам API и учитесь делать запросы от простых к сложным, создавайте для себя все более комплексные ситуации (ошибки, параллельные запросы, пагинация и т. д.).
  • Используйте в работе над pet-проектами git (например, храните свои проекты на GitHub). Для изучения работы с git может пригодится интерактивное онлайн руководство и книга Pro Git, написанная Скоттом Чаконом и Беном Штраубом, на русском языке.
  • Концентрируйте свое внимание не только на написании логики, но и следите за красотой кода с помощью кодстайла — например, от kodeco (ex-raywenderlich). А для того, чтобы вам в этом помогал еще и компилятор — используйте линтер.

Книги

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

  • Clean Code / Чистый код. Роберт Мартин
  • The Clean Coder / Идеальный программист. Роберт Мартин
  • Code Complete / Совершенный код. Стив Макконел
  • The Pragmatic Programmer / Программист-прагматик. Энди Хант, Дейв Томас
  • Introduction to Algorithms / Алгоритмы: построение и анализ. Томас Кормен, Чарльз Эрик Лейзерсон, Рональд Линн Ривест, Клиффорд Штайн

Статьи и другие материалы

Архитектура

Разбор MV(x) архитектур на русском языке можно найти в статье на Хабре от Badoo. На английском языке тоже есть вариант на Medium.

Для более подробного понимания тонкостей той или иной архитектуры стоит переходить на более глубокие статьи по конкретной архитектуре. Большой список статей по описанным выше архитектурам (и не только) можно найти на github.

Кодстайл

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

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

Если вы не пользуетесь каким-то конкретным кодстайлом, стоит выбрать один из публичных популярных кодстайлов, например от raywenderlich, и стараться писать код именно в этом одном конкретном стиле.

Помочь придерживаться выбранного стиля может линтер — инструмент, который будет проверять код на соответствие некоторому набору правил. Для swift таким инструментом является swiftlint. Также можно прочитать довольно подробную статью на Хабре от Тинькофф про его использование. Наиболее эффективным с точки зрения обучения вариантом будет использование строгого набора правил с учетом выбранного кодстайла.

Платформа

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

Для понимания, что такое локализация и как ее настроить, можно почитать статью от Alconost на Хабре, материал от Пола Хадсона и подборку информации по локализации в документации от Apple.

Отметим, что совершенно не обязательно оставлять работу с локализацией (и в целом с ресурсами) в том виде, который предлагает Apple — для этого тоже есть более удобные инструменты.

Для работы с текстами такой инструмент — библиотека R.swift. Для понимания, как использовать эту библиотеку, достаточно прочитать документацию в readme.

Dependency Injection

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

Для начала стоит понять, что такое DI и для чего оно используется. Для этого можно посмотреть серию статей на Хабре про DI. Узнать подробнее про DI в контексте iOS разработки можно прочитав эту статью от Тинькофф.

Стоит понимать, что применение DI возможно без каких-либо сторонних библиотек, но сторонние библиотеки, как правило, просто упрощают работу с кодом и позволяют вынести настройку DI в отдельный слой. Самая популярная библиотека на iOS для DI на текущий момент — Swinject, поэтому будет удобно начать знакомство именно с нее.

В этой статье на Хабре пытаются раскрыть то, зачем нужен DI с небольшим примером как раз на Swinject. Еще есть неплохой туториал по DI от raywenderlich на примере Swinject — но он уже обновлен для SwiftUI, поэтому может быть не очень понятен, если вы знаете только UIKit. В приведенной выше статье от Тинькофф есть сравнение различных фреймворков, а также дополнительные полезные материалы по теме.
Не стесняйтесь делиться этой страничкой с друзьями и коллегами, если считаете её полезной. Если у вас будет какой-то фидбек по этой страничке — напишите нам на почту .
Не стесняйтесь делиться этой страничкой с друзьями и коллегами, если считаете её полезной. Если у вас будет
какой-то фидбек по этой страничке — напишите нам на почту.