Objective C *

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

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

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

Довольно долгое время в своих проектах при написании когда я использовал тип Any, например при обработке JSON данных. Но также я знал что есть и второй тип — AnyObject. И недавно я задумался о разнице между этими двумя типами.

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

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

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

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

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

В StackOverflow по-прежнему появляется много вопросов о валидации App Store чеков, поэтому мы решили написать статью на эту тему в формате вопросов и ответов.

(Прим.перев.: автор оригинального материала — пользователь github и twitter Thomas @tclementdev. Ниже в переводе сохранено повествование от первого лица, которое использует автор.)

Думаю, что большинство разработчиков использует libdispatch неэффективно из-за того как её представили сообществу, а также из-за запутанной документации и API. Я пришел к этой мысли после чтения обсуждения «concurrency» в рассылке посвященной развитию Swift (swift-evolution). Особенно просвещают сообщения от Пьера Хабузит (Pierre Habouzit — занимается поддержкой libdispatch в Apple):

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. Итак, теперь ваш код пользовательского интерфейса может быть синхронизирован на всех платформах, что дает больше времени для того, чтобы сосредоточиться на второстепенном платформо-зависимом коде.

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

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

Протокол UIAppearance появился в iOS 5 в 2011 году, в те далёкие времена, когда у Instagram не было приложения под Android, а сериальному Неду Старку ещё не отрубили голову.

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

Новогодние праздники прошли, а мое стремление писать полезные и не очень статьи — нет! Сегодня поговорим о UITableView, работе с UITableViewDataSource и переиспользовании ячеек. Затронем как установить рут контроллер без сториборда, ошибки при работе с таблицей, лейаут и большой заголовок для UINavigationBar.

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

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

— “Ааастановите, пожалуйста, вот у магазина” — прокричал герой российского сериала.

В целом, дорогой друг, ты прав. Будут и дробные числа, и куча строчек кода. Но будет намного проще. Интересно? Давай к делу.

Большинство iOS-проектов частично или полностью переходят на Swift. Swift — замечательный язык, и за ним будущее разработки под iOS. Но язык нераздельно связан с инструментарием, а в инструментарии Swift есть недостатки.

В компиляторе Swift по-прежнему находятся баги, которые приводят к его падению или генерации неправильного кода. У Swift нет стабильного ABI. И, что очень важно, проекты на Swift собираются слишком долго.

В связи с этим существующим проектам может быть выгоднее продолжать разработку на Objective-C. А Objective-C уже не тот, что был раньше!

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

— “Какая-то библиотека, кто-то обновил… Хейтер тут причем? Почему мне, отличному разработчику, нужно тратить время на эту статью?”

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

Принято считать, что Wallet – не самый популярный сервис в СНГ. Но уже во втором проекте подряд заказчик ставит задачу «Сделать интеграцию с Wallet». Поэтому я решил написать эту статью, чтобы рассказать о сервисе в целом и показать, как интегрировать в него свой продукт.

Что такое Wallet? Он позволяет держать в телефоне различного вида карты (билеты, скидочные карты и т.п.), облегчая жизнь пользователям продукта. Более того, есть возможность актуализировать информацию о карте посредством push-уведомлений, но это тема для отдельной статьи. Но если у вас есть карта/билет/абонемент, которые можно интегрировать в телефон, то для этого есть решение! Как это сделать – читайте ниже.

Сегодня мы открываем цикл статей о том, о чём обычно не говорят на технических конференциях и митапах. Этот и последующие посты расскажут, как устроен механизм монетизации в популярном в США развлекательном iOS-приложении iFunny, разработкой которого мы занимаемся.

В этом выпуске: больше новых рефакторингов, лучше автодополнение, поддержка баз данных из DataGrip и даже поддержка Touch Bar. Более подробно — под катом.