Cocoapods считается наиболее популярным менеджером зависимостей для iOS. Последние годы Apple работает над развитием своего нативного менеджера зависимостей Swift Package Manager (SPM).

Изначально его использование было возможно только для server-side Swift или приложений для терминала. На таких приложениях обкатывали и дорабатывали SPM, комьюнити знакомилось с его работой, а команда Apple получила бета тестеров.

С релизом Xcode 11 SPM начал приходить и в мир разработки под iOS. Сейчас это уже полноценный инструмент, который можно использовать, но пока с ограничениями.

Вступление

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

Я езжу в офис на электричке — нужно проехать одну станцию, и я буду почти на месте.

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

Это когда ты бежишь на поезд, а тебе говорят «Что-то пошло не так» и списывают деньги, а билет не дают. Возврат приходит тут же, но поезд-то уже ушел. Такое происходит пару раз в месяц, вне зависимости от качества интернета. Ни о каких -пэях и говорить не приходится.



В этот момент задумываешься — а может, есть способ проще? Ну, чтобы вообще без вебвью, красиво и нативно. И да, такой способ есть. Подробности под катом.

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



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

Apple имеет несколько API, которые помогут защитить ваши приложения, и вы изучите их при работе с Keychain. Кроме того, вы будете использовать CryptoSwift — хорошо изучите и просмотрите библиотеку с открытым исходным кодом, которая реализует криптографические алгоритмы.

Многие сталкивались с проблемой реализации красивого отображения кнопок для UITableViewCell при сдвиге влево. Некоторые использовали стандартный функционал «из коробки», другие заморачивались над собственной реализацией, а кто-то обошелся Unicode-символами. В этой статье я расскажу как добиться максимальной кастомизации UITableViewRowAction.

Мобильная разработка — это особая кухня, и в ней есть свои нюансы. Именно поэтому собеседования с кандидатами в отдел разработки под iOS должны проходить с определенным уклоном. Сегодня мы расскажем, как проходит прием в штат мобильных разработчиков Acronis, и какие курьезы бывают на собеседованиях, когда соискатель считает, что достаточно запомнить несколько умных слов, а потом «разберемся на месте».

Как избежать проблем с производительностью с помощью пресета Core Animation, что использовать для трассировки участков кода и с помощью каких функций сократить долю вычислительных операций в приложении с 26% до 0.6% — читай во второй части статьи по материалам доклада Люка Пархэма на прошлогодней конференции MBLT DEV. Первая часть статьи доступна здесь.

Под катом не только полезные советы, но и последние early bird билеты на MBLT DEV 2018 — купить их можно только сегодня.

Есть разные приёмы и хитрости, которые помогают оптимизировать работу iOS-приложений, когда одна задача должна выполняться за 16,67 миллисекунд. Рассказываем, как разгрузить main thread и какие инструменты лучше подходят для отслеживания стека вызовов в нём.

«Ребята, давайте представим, что вы сможете сократить время запуска на 10 секунд. Умножив это на 5 миллионов пользователей, ежедневно у нас будет 50 миллионов секунд. За год это составит порядка десяти человеческих жизней. Поэтому, если вы сделаете первичную загрузку на 10 секунд быстрее, вы спасёте несколько десятков жизней. Это действительно стоит того, не правда ли?»

Стив Джобс о производительности (времени запуска компьютера Apple II).

Статья основана на докладе iOS-разрабочика из Fyusion Люка Пархема, с которым он выступил на Международной конференции мобильных разработчиков MBLT DEV в прошлом году.

Формат JSON приобрел большую популярность, именно он обычно используется для передачи данных и выполнения запросов в клиент-серверных приложениях. Для парсинга JSON требуются инструменты кодирования/декодирования данного формата, и компания Apple не так давно провела их обновление. В данной статье мы рассмотрим методы парсинга JSON с применением протокола Decodable, сравним новый протокол Codable с предшественником NSCoding, оценим преимущества и недостатки, разберем все на конкретных примерах, а также рассмотрим некоторые особенности, встречающиеся при реализации протоколов.

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

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

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

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

Чтобы в итоге собеседование не выглядело для соискателя как:


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

И добро пожаловать под кат.

Меня зовут Максим, и я алкоголик занимаюсь iOS разработкой уже более 7 лет.

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

Среди кандидатов попадаются кадры, которые курят кальян прямо на Skype собеседовании, пытаются гуглить вопросы на ходу, хотят ЗП 180к за 3 месяца опыта, ведут себя так, как будто гоп-стопнули меня на улице (с соответствующей терминологией) и так далее.

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

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

(Если лень читать, то прилагается видео)

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Представьте, что вы — IT компания. Может большая или нет, но так получилось, что вам потребовался стажер. Ведь пора, наконец, растить новое поколение в духе вашей идеологии.

Но вот незадача — стажеры такие животные, которые не обладают навыками. И ранее ничего полезного они не делали. Как же не ошибиться в выборе? Что ж, это довольно просто. Если нельзя оценить по результату, то следует искать предпосылки к достижению этого результата…

Статья о серьезной проблеме рекрутинга, которую все почему-то считают нормой.

Вскоре после публикации исходного кода Swift, я написал статью о том как реализованы слабые ссылки. Время не стоит на месте и всё меняется, реализация слабых ссылок в Swift тоже. Сегодня я расскажу о новой реализации и сравню ее со старой. Спасибо Guillaume Lessard за идею для поста.

Старая реализация

Для тех из вас кто не помнит старую реализацию и кому лень пробежаться по предыдущей статье я кратко опишу ее здесь.

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

Когда слабая ссылка загружается, среда времени выполнения (runtime) проверяет является ли объект “зомби”. Если он “зомби” то runtime обнуляет слабую ссылку и уменьшает счетчик слабых ссылок на 1. Когда счетчик слабых ссылок достигает 0 — память освобождается (deallocated). Это означает, что полностью объект удаляется только тогда, когда все слабые ссылки на него обнуляются.

Мне нравилась простота этой реализации, но были у нее и недостатки:

Если вы хотите добиться UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI).

В текущей версии Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).

Один из них использует GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.

Код для этой статьи можно посмотреть на Github.

Надо сказать, что многопоточность (сoncurrency) в iOS всегда входит в вопросы, задаваемые на интервью разработчикам iOS приложений, а также в число топ ошибок, которые делают программисты при разработке iOS приложений. Поэтому так важно владеть этим инструментом в совершенстве.
Итак, у вас есть приложение, оно работает на main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию».



Как можно изменить архитектуру приложения, чтобы таких проблем не возникало? В этом случае на помощь приходит многопоточность (сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.

Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.

Для повышения отзывчивости приложения необходимо грамотно разбивать выполнение задач на несколько потоков. Набор технологий в руках iOS-разработчика представляет из себя следующее. Способы представлены по возрастанию уровня абстракции.

• Pthreads, или потоки POSIX. Библиотека для низкоуровневой работы с многопоточностью. Определена как набор типов и функций на языке C. Подробнее можно ознакомиться тут.
• Background selectors. Это отправка сообщения объекту, которое будет исполнено на указанном потоке. В коде это селектор с названием performSelector и различными параметрами (например, performSelectorOnMainThread:withObject:waitUntilDone:). Документация
• NSThread. Представлены как базовые средства для работы с потоками. Ознакомьтесь с концептуальным документом по работе с потоками и документацией.
• Grand Central Dispatch. Библиотека, основанная на блоках — анонимных участках кода, иначе замыканиях. Рабочее название — libdispatch.
• NSOperation. Построен на основе GCD. Стоит заметить, что сама операция является абстрактной сущностью и на практике стоит использовать NSInvocationOperation и NSBlockOperation.

В этой статье поговорим о вопросах GCD.