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

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

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

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

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

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

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

Нужно брать с клиента столько, чтобы он не отвалился.
Где потом найдёшь другого? Лучше зря не рисковать!
Совершай скорее сделку, не продумывай деталей,
Время — деньги, пусть другие тратят время на расчёт.

Одним из самых трудных вопросов, с которыми я столкнулся на фрилансе, стал «Сколько денег взять за эту работу?» Первым клиентом волей случая оказалась компания Telphin, оператор VoIP-телефонии, довольно крупный на 2008 год. От меня требовалось спроектировать новую версию интерфейса кабинета пользователя.

Тогда в оценке я руководствовался такими понятиями, как «сколько бы мне попросить, чтобы клиент не отвалился?», «сколько вообще люди берут за подобную работу?», «за какую сумму я сам готов работать?» Тогда я назвал что-то порядка 30 000 рублей. Для студента невероятно большая сумма…

Привет, Хабр! Всем нравятся отзывчивые приложения. Ещё лучше, когда в них есть уместные анимации. В этой статье я расскажу и покажу со всем «мясом», как правильно показывать, скрывать, крутить, вертеть и делать всякое с всплывающими экранами.

С релизом Xcode 14.3 Apple убирает поддержку Rosetta и почти прямым текстом говорит разработчикам, что откладывать адаптацию своих проектов под Apple Silicon дальше уже некуда. Сегодня я поделюсь историей про то, с какими сложностями мы столкнулись в нашем основном приложении Циан, и какое стороннее решение помогло нам избавиться от Rosetta.

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

Добрый день! Я — Иваев Зафар, iOS разработчик в компании Usetech. В этой статье мы узнаем как фреймворк Combine помогает нам разрабатывать функционал приложения с помощью встроенных функций — операторов. В этой статье, мы покроем следующие типы операторов:

1. Последовательные операторы

2. Объединяющие операторы

Сегодня я хотел бы показать вам, как создать свой собственный Publisher в новом фреймворке от Apple Combine.

Apple представила свой фреймворк Combine на WWDC 2019 вместе с iOS 13, macOS 10.15 и, возможно, что самое главное, SwiftUI. В то время мы все были очень взволнованы тем, что Apple предоставила нам собственное решение для реактивного программирования.

Год спустя, в октябре 2020 года, на форумах Swift появились первые роадмапы Swift Concurrency. И на следующем WWDC в 2021 году у нас уже был первый полный релиз Swift Concurrency… и никаких значимых обновлений для Combine. Перенесемся еще на год вперед к WWDC 2022 и снова никаких серьезных обновлений Combine. В результате всей этой эпопеи разработчики небезосновательно начали размышлять о том, мертв ли ​​Combine, забросила ли его Apple в угоду Swift Concurrency.

‍- Итак, мертв ли Combine? Мы так не думаем!
- Полагаемся ли мы на Combine в нашей кодовой базе все больше и больше? Да!
- Используем ли мы при этом Swift Concurrency? Да!
- Приведет ли это впоследствии к архитектурным проблемам, о которых мы будем очень сильно сожалеть? Надеюсь, что нет!

Привет, Хабр! Меня зовут Сергей, я iOS-разработчик в компании SimbirSoft.

Уже наступил 2023 год, а обсуждения на тему выбора инструмента для обработки асинхронных событий не утихают. На сцене привычные колбэки, нотификейшн-центры с «бородатыми» Objective-C-селекторами, разные фреймворки для реактивной разработки, а не так давно Apple представила модный Swift Concurrency.

Combine все больше набирает популярность в продакшене. За счет нативного происхождения у него хороший уровень оптимизации, его легко «склеивать» как с существующими легаси-инструментами, так и с новыми — SwiftUI или async/await.

Пестрый «зоопарк» заставляет задуматься: что выбрать для нового проекта, а что для приложения с многолетней историей?

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

Это первая часть статьи, где мы познакомимся с Combine, сравним его с RxSwift. Материал будет полезен для тех, кто до этого не сталкивался с реактивщиной, а также тем, кто успел поработать с аналогичными инструментами.

Как Параллелизм в Swift предотвращает взрывы потоков?

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

Это заставило меня задуматься… Так ли это на самом деле? Как это работает за кулисами? Можем ли мы как-то обмануть систему, чтобы она создавала больше потоков, чем ядер ЦП?

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

Run Loop (цикл исполнения) является механизмом, который позволяет потокам обрабатывать события (events) бесконечно в любое время.

Run Loop представляет из себя объект, который управляет событиями и сообщениями, обрабатывает их, и предоставляет функцию точки входа для выполнения логики события.