Swift *

С каждый днем все больше разработчиков IOS стремятся свои новые проекты начинать с использованием SwiftUI. И здесь перед ними возникает проблемы в виде реализации устоявшихся представлений о навигации в iOS. Предлагаемые решения от Apple работают весьма часто довольно криво. Это понимают и в самой Apple. По мере развития SwiftUI основной компонент навигации NavigationView был заменен на NavigationStack. И это не просто переименование. Те кто уже использовал NavigationView не готовы от него отказаться, так как его реализация лежала через боль и слезы. Те же кто только входит в мир SUI либо наталкиваются на рекомендации создавать кастомную навигацию, либо смотрят на статьи как разруливать проблемы NavigationView. Новая альтернатива не всем пришлась по-душе, так как на WWDC не продемонстрировали его с лучшей стороны. А она есть. И это хорошая новость! Apple, наконец, освоила паттерн Navigator, которым конкуренты пользовались более 10 лет!

В чем суть: теперь навигация становится возможной даже при помощи передачи пути для навигации. Те кто пользовался DeepLink или UniversalLink возрадуются. Теперь и на их улице будет праздник. Оговорюсь – это не значит что раньше это было невозможно, но теперь не приходится для этого устраивать танцы с бубном.

Чтоб продемонстрировать идею, был набросан минимальный проект, включающий пять экранов, с незамысловатыми названиями: first, second, third и fourh. Эти экраны были объединены следующей схемой переходов:

Алгоритмы сортировки в Swift. Краткое пособие для подготовки к собеседованию для начинающего разработчика на Swift.

Всем привет! Я хочу поделится своим опытом реализации кастомных переходов между экранами в iOS. Несмотря на то, что тема эта достаточно популярная, и очень многие дизайнеры хотят привнести в процесс перехода какую-то свою изюминку (затемнение, параллакс и т. п.), реализация этих вещей не очень тривиальна. Я попробую разложить все по полочкам. Рассмотрим сначала стандартное решение, которое не особо гибкое, но зачастую достаточное для многих проектов. Затем реализуем полностью кастомное и контролируемое исключительно нами решение.

Всем привет, меня зовут Валерия Рублевская и я iOS-разработчик на проекте онлайн-кинотеатра KION в МТС Digital. Это третья часть рассказа о фиче Autoplay и сегодня мы поговорим о нюансах ее реализации на tvOS.

Хотите подробностей? Добро пожаловать под кат!

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

Ограничение(constraint) - это правило, позволяющее операционной системе размещать ваш компонент пользовательского интерфейса. В UIKit есть 2 основных способа установки ограничений:  StoryBoard и кодом. В данной статье рассмотрим только подход кодом.

В последних версиях Windows можно переключаться между окнами с помощью свайпа тремя пальцами, а между рабочими столами - четыремя. Зато в macOS всё по-другому: переключение свайпом (тремя пальцами по-умолчанию) доступно только между рабочими столами или полноэкранными приложениями. А ведь так не хочется тянуться до клавиатуры или ползти курсором в Dock, чтобы переключить приложение! Тут на помощь приходит Touch-Tab.

В серии статей я поделюсь своим представлением о DI и попробую решить основную проблему библиотечных решений для DI: нам нужно точно знать, что экран соберётся, зависимости подтянутся, а все ошибки мы отловим на этапе компиляции

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

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

Если вы готовы, погнали! 🏎

В первой статье рассказали, почему нам потребовалась автоматическая кодогенерация свифтового интерфейса для C++ в Mobile SDK. Описали инструменты, которые есть в нашем распоряжении, и сделали вывод: лучший промежуточный слой для преобразования на сегодняшний день — это C. 

Во второй части рассказываем о собственном инструменте, который поддерживает и Swift, и Kotlin — мы называем его Codegen (да :)).

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

WWDC 2022 привнесла много изменений и улучшений в SwiftUI, и обновленный протокол Layout — одно из самых значимых. Об особенностях работы с новыми инструментами компоновки элементов, анонсированными в iOS 16.0, рассказывает iOS-разработчик студии CleverPumpkin Даниил Апальков.

Одно из самых проблемных мест SwiftUI — работа с навигацией. Отсутствие доступа к стеку навигации, невозможность разделить UI-слой и слой навигации, сложность создания диплинков — всё это затрудняло работу многим разработчикам, использующим SwiftUI в своих проектах.

В iOS 16 появился совершенно новый API для работы с навигацией. Разбираемся, стало ли удобнее.

Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики. Очень часто я видел статьи или новости, где одна команда мобильных разработчиков ждет другую, чтобы выкатить релиз. И если с мобильными версиями более-менее все понятно и есть решения, то что делать с браузером? Очень часто логику работы приложения нужно поддержать и там.

Что делать, если хочется писать нативный код и при этом не иметь дублей реализации — на этот вопрос я постараюсь ответить подробно в данной статье. В процессе чтения можно будет познакомиться с технологией Kotlin Multiplatform и создать полноценный проект всем известной игры «Крестики-нолики» на трех самых популярных платформах Browser (JS), iOS (Swift) и Android (Java) с общей логикой на Kotlin.

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

В мобильных приложениях используется Authorization Code Flow with Proof Key for Code Exchange (PKCE). Подробнее о выборе flow читайте в нашей предыдущей статье. Эта статья является продолжением.

Сегодня мы рассмотрим вариант реализации OAuth-авторизации с помощью библиотеки AppAuth-iOS. Она одна из самых популярных и довольна проста в использовании. Весь код из статьи доступен в Github.

Всем привет! Мы продолжаем разбираться в асинхронном Swift! В рамках этой статьи мы познакомимся с тем, как писать зависящие друг от друга асинхронные задачи, познакомимся с Task поближе и разберем несколько интересных  примеров

В далекие – далекие времена, когда iOS была совсем маленькой, разработчики, гордо именуемые iOS-девелоперами, задумались о кастомизации навигационного стека. Не то что навигационный стек был плох – он отлично вписывался в картину мира Apple, но вот навигационная панель часто была «бельмом в глазу» для пользователей и дизайнеров. Поэтому разработчики применяли простой трюк – скрывали панель в приложении, а вместо нее показывали свою собственную панель, со своим собственным дизайном интерфейса, управляющие элементы которого были привязаны все к тем же методам push и pop доступных им из коробки.

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

Swift Package Manager существует уже довольно давно, его популярность растёт, как и количество модулей, доступных для использования. Если вы работаете над своим SPM модулем, будет здорово расширить число разработчиков и проектов, которые могут его использовать, путём добавления локализации.

Обычно чтобы создать одну точную и реалистичную 3D-модель предмета реального мира средней сложности требуется несколько часов работы профессионального художника. Тем временем, с развитием AR и VR сильно растет запрос на быстрое и недорогое создание качественных моделей. Для этих целей в macOS Monterey в составе RealityKit был представлен Object Capture API, который позволяет автоматизировать этот процесс. Object Capture использует алгоритмы фотограмметрии и может преобразовать серию фотографий в высококачественную 3D-модель оптимизированную для дополненной реальности всего за несколько минут. API появился год назад, но про него мало писали, поэтому я предлагаю рассмотреть данный инструмент подробнее.

Мы продолжаем сражаться с шаблонным кодом в табличных экранах iOS-приложений. 

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

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

В этой статье рассмотрим, как избавиться и от такого кода. 

Наверняка, каждый разработчик, которому необходимо было программировать сетевой слой приложения решал задачу передачи параметров запроса. В большинстве случаев это несложная задача, которая решается стандартными средствами, которые предоставляет нативный sdk либо язык программирования. Но если рассматривать ситуацию в контексте платформы iOS и языка программирования Swift, то тут же станет ясно, что компилятор выдает ошибку при попытке сериализации параметров в виде словаря [String: Any]. Однако, благодаря нововведениям, которые появились в iOS 15.4 и Swift 5.6 сериализация словаря сильно упростилась.

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