Всем привет!

В этой статье мы хотим поговорить о нативной разработке мобильных игр на iOS. А точнее познакомить вас с игровым движком SpriteKit. Разберём, что он умеет, зачем он нужен и как начать с ним работать. Вместе создадим простую игровую сцену, добавим персонажа, подключим физику и поэкспериментируем с гравитацией.

Начало пути

Мы с командой решили воссоздать классическую Flappy Bird — простую, но затягивающую игру, где игрок управляет птичкой, избегая столкновений с трубами. Несмотря на кажущуюся простоту, такая игра требует продуманной архитектуры: нужно обеспечить стабильную производительность и чёткое разделение логики. Важно было реализовать управление состояниями (меню, игра, проигрыш), физику столкновений, бесконечную прокрутку фона и генерацию труб.

Читая абзац выше, может показаться, что мы отлично разбираемся в теме и всё у нас под контролем. Но на деле всё было иначе. Опыт? Впервые. План? Почти. Время на отрицание, гнев, торг и депрессию? Не завезли. Сразу «принятие» — и поехали делать игру.

К счастью, Apple предоставляет из коробки мощный инструмент для таких задач — SpriteKit. Именно он стал нашим проводником в мир 2D-геймдева на iOS.

Что такое SpriteKit?

SpriteKit — это фреймворк от Apple, который помогает создавать 2D-игры и анимации на iOS, macOS, tvOS и iPadOS. Проще говоря, это набор инструментов, позволяющий рисовать спрайты, двигать их, наделять физикой, проигрывать звуки и управлять столкновениями.

В SpriteKit все игровые элементы, такие как персонажи, враги, фоны и прочее называются спрайтами (sprites). Эти спрайты размещаются на сцене (scene), которая служит основным контейнером для всей игровой логики и визуальных объектов.

Рассмотрим основные компоненты фреймворка:

• SKScene — сцена, на которой разворачивается игра;
• SKSpriteNode — графический элемент (например, персонаж или фон);
• SKLabelNode — текст на экране;
• SKAction — анимации и действия (движение, вращение и прочее);
• SKPhysicsBody — физическое тело для гравитации и столкновений.

Настройка Scene

В SpriteKit все игровые объекты размещаются на сцене. Это специальный класс (SKScene), который управляет логикой игры, обрабатывает события (например, касания) и настраивает физику. Именно с неё начинается построение любой игры.

Давайте же перейдем к коду и создадим простую сцену.

Шаг 1: Создание сцены

В Xcode выбираем New File From Template → SpriteKit Scene.
Этот шаблон создаст .sks-файл, визуальный редактор сцены, и вы сможете на нём размещать объекты.

Шаг 2: Указание кастомного класса

Открываем созданный .sks-файл и в инспекторе справа и указываем имя вашего собственного класса сцены в поле Custom Class — например, GameScene.

Шаг 3: Реализация класса сцены

Теперь создаём Swift-файл с соответствующим именем (например, GameScene.swift) и реализуйте свой класс, унаследовав его от SKScene.

final class GameScene: SKScene {

    /// Вызывается один раз, когда сцена загружена из файла или кода.
    /// Здесь можно инициализировать свойства, подготовить объекты, которые не зависят от view.
    override func sceneDidLoad() {
        super.sceneDidLoad()
    }

    /// Вызывается, когда пользователь прикасается к экрану.
    /// Здесь можно обрабатывать начало касания — например, заставить персонажа прыгнуть.
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        super.touchesBegan(touches, with: event)
    }

    /// Вызывается каждый кадр (обычно 60 раз в секунду).
    /// Здесь можно обновлять положение объектов, проверять столкновения, изменять состояние игры.
    override func update(_ currentTime: TimeInterval) {
        super.update(currentTime)
    }
}

Шаг 4: Контроллер запуска игры

Затем нам необходимо создать обычный UIViewController и переопределить наше дефолтное view, на SKView

Затем нам необходимо создать UIViewController, и переопределить у него view, чтобы она стала SKView.

class GameViewController: UIViewController {

    override func loadView() {
        super.loadView()
        view = SKView()
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        startScene()
    }

    func startScene() {
        guard let scene = SKScene(fileNamed: "GameScene") as? GameScene else { return }
        let skView = view as! SKView
        skView.presentScene(scene)
        skView.showsFPS = true
    }
}

Готово! Базовая настройка позади. Теперь можно запустить проект и посмотреть, что у нас получилось.

Скорее всего, вы увидите пустой экран. Не слишком вдохновляет, правда? Но если в правом нижнем углу появился индикатор FPS — значит всё подключено правильно и сцена действительно загружается. Поздравляю, это первый шаг!

На самом деле вы можете убрать этот индикатор, если вам он мешает. Для этого просто удалите следующую строку: skView.showsFPS = true .

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

Добавляем объект на сцену

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

Выбор изображения

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

Создаём собственный спрайт

Чтобы добавить объект на сцену и наделить его физическими свойствами, создадим отдельный класс, унаследованный от SKSpriteNode. Это позволит нам:

• задать текстуру (изображение);
• управлять поведением объекта;
• добавить физику: столкновения, гравитацию, вращение и т.д.

class PlayerNode: SKSpriteNode {

    convenience init(with image: UIImage) {
        let texture = SKTexture(image: image)
        self.init(texture: texture)
    }
}

Как мы видим ничего сложного. Здесь мы просто создаём спрайт на основе картинки и используем её как текстуру.

Добавляем объект на сцену

Теперь перейдём в нашу сцену и обновим её:

final class GameScene: SKScene {
    
    private var player: PlayerNode!

    override func didMove(to view: SKView) {
        super.didMove(to: view)
        createPlayer()
    }

    private func createPlayer() {
        player = PlayerNode(with: UIImage(named: "asyq-sprite")!)
        player.position = CGPoint(x: size.width / 2, y: size.height / 2)
        addChild(player)
    }
}

В функции createPlayer() мы создаём объект, передаём ему изображение, а затем устанавливаем позицию относительно центра экрана.

Вызов происходит из didMove(to view: SKView) — это метод жизненного цикла, аналогичный viewDidLoad() в контроллере. Именно здесь обычно размещают начальные элементы сцены.

Собираем и запускаем проект...

Ну что ж, пока выглядит скромно, но всё работает!

Добавляем физику

Предлагаю немного поиграться с возможностями движка и попробовать немного оживить нашу сцену при помощи физики. Вернёмся в PlayerNode и расширим его функциональность:

final class PlayerNode: SKSpriteNode {

    convenience init(with image: UIImage) {
        let texture = SKTexture(image: image)
        self.init(texture: texture)
        configureNode()
    }

    private func configureNode() {
        physicsBody = SKPhysicsBody()
    }
}

И попробуем запустить наш проект снова и посмотрим что изменилось.

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

Откуда берётся движение?

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

Нас сейчас интересует его свойство: physicsWorld.gravity. По умолчанию значение равно CGVector(dx: 0, dy: -9.8) . Это примерное значение земного притяжения, объект начинает падать вниз по оси y, имитируя свободное падение на Земле (~9,8 м/с²). Именно поэтому наш объект сразу падает вниз относительно оси координат.

Попробуем поиграться с этим значением и изменим поведение. Например, сделаем так, будто объект падает не в воздухе, а в воде:

override func didMove(to view: SKView) {
    super.didMove(to: view)
    physicsWorld.gravity = CGVector(dx: 0, dy: -1.0)
    createPlayer()
}

Теперь падение стало заметно медленнее, создаётся ощущение вязкой среды.

Взаимодействие с объектом

Теперь хочется как-то взаимодействовать с нашим объектом. Например, чтобы он взлетал вверх при тапе по экрану. Для этого воспользуемся методом touchesBegan, который уже есть в SKScene:

override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
    super.touchesBegan(touches, with: event)
    player!.physicsBody!.applyImpulse(CGVector(dx: 0, dy: 45))
}

При касании вызывается метод touchesBegan , где мы придаем импульс нашему объекту по оси y.

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

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

Заключение

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

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

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

Спасибо за внимание и до встречи в следующих статьях!🤘

Полезные ссылки:

• Документация по SpriteKit для работы с 2D
• Документацией по RealityKit для работы с 3D

Telegram-канал Теплица

Обратная связь

Всем привет, дорогие друзья!

Совсем недавно у нас в команде проводился небольшой workshop, посвященный навигации при deep linking. Из него родилась идея подготовить статью по этой теме. Давайте начнем!

Deep link

Согласно официальной документации, deep link в Android — это URI-ссылка, которая может быть использована для навигации к конкретному месту внутри приложения, минуя стартовый экран.

Назначение deep linking

Поддержка маркетинговых активностей

В рамках рекламных кампаний deep linking помогает привлекать пользователей к конкретным акциям, продуктам или функциям приложения.

Связь с внешними сервисами

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

URI

URI (Uniform Resource Identifier) — это строка, которая идентифицирует ресурс в сети.

При этом URI может указывать как на местоположение ресурса (URL), так и на его имя (URN). А может содержать и то и другое. То есть URL и URN — это частные случаи URI.

Правила построения URI закреплены в RFC 3986.

URI состоит из обязательных компонентов:

• scheme — определяет контекст / смысл идентификатора. Если схема зарегистрирована в IANA, то она считается официальной;
• path — иерархические данные для идентификации ресурса.

И опциональных:

• userinfo — информация о том, кто взаимодействует с ресурсом;
• host — адрес расположения ресурса;
• port — точка взаимодействия с host;
• query — неиерархические данные для идентификации ресурса;
• fragment — идентификация вторичного ресурса внутри исходного ресурса (якорь).

Web link

Web link — это deep link, использующий схемы HTTP и HTTPS.

В Android 12+ при нажатии на обычный web link содержимое всегда отображается в веб-браузере.

Если версия Android ниже 12, и приложения, установленные на устройстве, могут обрабатывать web link, пользователи, вместо перехода в браузер, увидят disambiguation dialog.

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

В нем отображается список приложений-кандидатов для обработки перехода по ссылке. Список формируется в зависимости от ссылки и Intent-Filter, установленных в приложениях.

Android app link

С Android 6.0 появилась возможность привязки веб-домена к приложению и верификации домена на стороне сервера.

В случае успешной верификации, система автоматически открывала приложение, минуя disambiguation dialog.

Именно с этой версии появилась поддержка Android app link.

Android app link — это deep link, который также как и web link использует HTTP и HTTPS, но дополнительно содержит атрибут autoVerify.

Этот атрибут позволяет приложению назначить себя обработчиком по умолчанию для данного типа ссылки. Это позволяет открывать ссылку без вызова disambiguation dialog.

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

Верификация домена для Android app link (если на проекте не используется AppsFlyer)

Шаг 1. Добавить Intent-Filter в AndroidManifest.xml с флагом autoVerify и указанием информации оhttps-ссылке, которую необходимо обрабатывать:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:scheme="https"
        android:host="your.domain.com"
        android:pathPrefix="/yourpreffix" />
</intent-filter>

Шаг 2. Сгенерировать файл ассоциации assetlinks.json. Для этого требуется доступ в Google Play Console.

В разделе Привлечение пользователей имеется подраздел Ссылки на контент.

После перехода в подраздел необходимо нажать на Добавить домен для открытия диалогового окна генерации assetlinks.json.

В открывшемся окне указывается domain, который ранее был указан в AndroidManifest.xml.

После этого будет сгененирован файл ассоциации.

Важно разместить данный файл согласно указанному адресу: {your domain}/.well-known/assetlinks.json. В противном случае, связь между приложением и доменом установлена не будет.

Верификация домена для Android app link (если на проекте используется AppsFlyer)

Если на проекте используется AppsFlyer и для deep link используется домен формата yourbrand.onelink.me, то assetlinks.json контролирует AppsFlyer. В этом случае, последовательность действий будет немного другой.

Шаг 1. Собрать все SHA-256 отпечатки подписи приложения, для которого требуется настройка Android app link.

Шаг 2. Выбрать в AppsFlyer Dashboard нужное приложение для настройки на странице Apps. Затем, в левой навигационной панели необходимо выбрать пункт OneLink Management. На открывшейся странице нужно выбрать Edit OneLink template.

Шаг 3. На экране редактирования шаблона кликнуть на Launch the app using App Links и указать все раннее собранные SHA-256.

Шаг 4. Сохранить изменения, внесенные в шаблон.

Шаг 5. Скопировать на странице Edit template, полученный Intent-Filter и вставить в AndroidManifest.xml.

Шаг 6. Добавить OneLink API ключ в приложение. Как правило, данный ключ запрашивается у администратора AppsFlyer Dashboard.

На этом установка связи между приложением, использующим AppsFlyer и доменом, завершена.

Deferred deep link

В завершении статьи стоит упомянуть о deferred deep linking. Это механизм, который позволяет открыть нужный экран внутри приложения, даже если приложение на момент клика по ссылке еще не установлено.

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

Good coding and happy day!🤘

Полезные ссылки:

• RFC 3986
• Зарегистрированные схемы URI в IANA
• Документация от Google
• Документация от AppsFlyer

Telegram-канал Теплица

Обратная связь

Всем привет, дорогие друзья!

Недавно Google представил новое API, которое позволяет получать текущее реальное время напрямую с NTP-серверов Google, не используя системные часы устройства. В этой статье я хочу не просто показать, как его подключить, но и подробнее рассказать, что такое NTP, как работает этот протокол и что такое timestamp и clock drift.

NTP

Network Time Protocol (NTP) — это сетевой протокол, предназначенный для синхронизации времени между устройствами.

Он работает по модели клиент-сервер: NTP-клиенты запрашивают актуальное время у NTP-серверов, которые получают его от высокоточных источников, таких как атомные часы или GPS. Затем сервер передаёт точные данные клиенту, который обновляет своё время.

Для передачи используется протокол User Datagram Protocol (UDP), который обеспечивает быструю отправку данных без установления соединения. Соответственно, запрос на получение точного времени можно отправить через стандартные IP-сети.

Вся система NTP организована в иерархическую структуру с уровнями (stratum), где каждый уровень определяет степень удалённости от эталонного источника времени.

Clock drift

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

Это явление называется clock drift – расхождение системных часов устройства с точным временем из-за аппаратных или программных факторов.
Для исправления данной проблемы производится синхронизация с эталонными источниками времени при помощи NTP.

Timestamp

При разработке функционала, где мы реализуем отображение времени заказа или операции, мы часто работаем с timestamp (временной меткой).

Timestamp — это числовое значение, указывающее на конкретный момент времени, зафиксированный с определенной точностью.

Данное значение обычно является количеством секунд или миллисекунд, прошедших с определенной даты отсчёта. Чаще всего в работе встречается Unix Timestamp, где отсчёт начинается с 1 января 1970 года 00:00:00 UTC.

Timestamp может иметь различную точность: до секунды, миллисекунды, микросекунды или наносекунды. Поэтому, важно заранее обсудить точность с backend-разработчиком. Например, если вы разрабатываете чат поддержки и имеете разную точность с сервером, то могут встречаться ситуации с дублированием информации или некорректной сортировкой.

Для чего нужен TrustedTime API

Локальное время подвержено изменениям: в стране могут ввести или отменить перевод на летнее время, изменить часовой пояс для какой-то местности (или вовсе объединить в один часовой пояс всю страну).

Для владельцев устройств с Android версией ниже 10 такие изменения могут стать серьезной проблемой. До Android 10 обновления данных о часовых поясах зависели от системных обновлений, и чем старше устройство, тем ниже вероятность получения актуальной информации. В некоторых случаях, пользователи могут обновить часовые зоны вручную, но для этого часто требуется ROOT-доступ.

В итоге многие пользователи начинают вручную корректировать системное время, что делает его ненадёжным источником.

TrustedTime API позволяет приложениям получать точное и защищенное время (Unix Timestamp), даже если системные часы устройства не являются достоверными.

Подключение TrustedTime API

Ниже будет приведён упрощённый вариант реализации логики.
Для начала необходимо добавить зависимость в build.gradle:

dependencies {
    implementation("com.google.android.gms:play-services-time:{version}")
}

Далее, можно создать интерфейс и его реализацию, которые позволят инкапсулировать логику создания TrustedTimeClient и получения времени:

interface TimeService {

    suspend fun getCurrentTimeMillisOrNull(): Long?
}

class DefaultTimeService(private val context: Context) : TimeService {

    @Volatile
    private var trustedTimeClient: TrustedTimeClient? = null

    override suspend fun getCurrentTimeMillisOrNull(): Long? {
        val client = trustedTimeClient ?: createClient()

        return client.computeCurrentUnixEpochMillis()
    }

    private suspend fun createClient(): TrustedTimeClient {
        return suspendCancellableCoroutine { continuation ->
            TrustedTime.createClient(context)
                .addOnSuccessListener { client ->
                    trustedTimeClient = client
                    continuation.resume(client)
                }
                .addOnFailureListener { exception ->
                    continuation.resumeWithException(exception)
                }
        }
    }
}

Я использовала Koin при создании примера кода, поэтому файл DI может выглядеть следующим образом:

val appModule = module {
    single<TimeService> {
        DefaultTimeService(
            context = androidContext(),
        )
    }

    viewModel {
        MainViewModel(
            timeService = get(),
        )
    }
}

Класс Application в таком случае может выглядеть так:

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApplication)
            modules(appModule)
        }
    }
}

Не забываем указать Application в AndroidManifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application
        android:name=".MyApplication"
        //...

Теперь можно подключать сервис и использовать его. Например, так:

class MainViewModel(
    private val timeService: TimeService,
) : ViewModel() {
    private val _currentTime = MutableStateFlow<Long?>(null)
    val currentTime: StateFlow<Long?> = _currentTime.asStateFlow()

    fun updateCurrentTime() {
       viewModelScope.launch {
           _currentTime.update {
               timeService.getCurrentTimeMillisOrNull()
           }
       }
    }
}

Работа на устройствах без GMS

Если ваше приложение распространяется в Huawei AppGallery и может использоваться на устройствах без GMS, то стоит учитывать, что TrustedTime API не будет работать на таких устройствах.

При попытке создать TrustedTimeClient вы получите исключение ApiException с кодом 17. Я рекомендую добавить метод проверки наличия GMS на устройстве:

private fun Context.isGooglePlayServicesAvailable(): Boolean {
    return GoogleApiAvailability
        .getInstance()
        .isGooglePlayServicesAvailable(this) == ConnectionResult.SUCCESS
}

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

Какие ещё методы есть у TrustedTimeClient

К сожалению, доступных методов на момент написания статьи не так много. Нам доступны:

• getLatestTimeSignal() — возвращает последний полученный TimeSignal или null, если внешний сигнал времени отсутствует. Позволяет получить информацию об ошибках в измерении времени и проследить погрешность;
• computeCurrentUnixEpochMillis() — данный метод рассматривался ранее в статье. Является заменой System.currentTimeMillis(), но без влияния системных часов устройства. Возвращает значение в миллисекундах с начала Unix-эпохи, основываясь на доверенном внешнем источнике, или возвращает null, если сигнал недоступен;
• computeCurrentInstant() — вычисляет Instant на основе последнего точного временного сигнала от внешнего источника или возвращает null, если сигнал недоступен. Является заменой для Instant.now() без влияния системных часов устройства;
• addTimeSignalListener(listener: OnNewTimeSignalAvailableListener) — метод для регистрации слушателя сигналов времени. После регистрации слушатель сразу получает последний сигнал времени, если он доступен. Стоит отметить, что повторная регистрация слушателя не будет выполняться, если слушатель в клиенте уже зарегистрирован;
• removeTimeSignalListener(listener: OnNewTimeSignalAvailableListener) — метод для удаления ранее зарегистрированного слушателя. В случае, если слушатель зарегистрирован не был, то вызов метода не порождает исключений;
• dispose() — позволят освободить ресурсы клиента, когда он становится ненужным и отменяет регистрацию всех слушателей.

На этом наш пост подошёл к концу. Good coding and happy day!🤘

Полезные ссылки:

• Анонс TrustedTime API
• Документация по библиотеке time
• Правила часового пояса Android

Telegram-канал Теплица

Обратная связь

Всем привет, дорогие друзья!

Сегодня хотелось бы поговорить о преимуществах async/await, в сравнении с привычными нами способами работы с асинхронным кодом. async/await был представлен Apple на сессии WWDC 21, но к сожалению, не во всех проектах решаются перейти на данную технологию. Давайте узнаем как сделать наш код более читаемым, безопасным и надежным.

Что такое async/await?

async/await – это современный способ работы с асинхронным кодом в Swift. Он делает код более читаемым, безопасным и удобным, заменяя сложные вложенные completion handlers или DispatchGroup.

Механизм async/await основан на принципе структурированного параллелизма. Это означает, что асинхронный код выполняется последовательно в рамках своей области видимости, в отличие от замыканий, которые могут разрывать поток выполнения и усложнять его отслеживание.

Пример асинхронного запроса через completion handler:

 // Service Layer
 		func fetchState(callback: @escaping (Result<GameShakeStateDataResponseModel, NetworkError>) -> Void) {
        let router = GameShakeRequestFactory.getState
        networkService.performRequest(router: router) {(result: Result<GameShakeStateDataResponseModel, NetworkError>) in
            switch result {
            case .success(let model):
                callback(.success(model))
            case .failure(let error):
                callback(.failure(error))
            }
        }
    }
    
  // Presenter Layer
    func fetchState() {
        service.fetchState() { [weak self] result in
            guard let self else { return }
            switch result {
            case let .success(response):
                updateView(with: response.data)
            case let .failure(error):
                view?.showErrorToast(with: error.title)
            }
        }
    }

Если переписать код на async/await:

 // Service Layer 
 		func fetchState() async throws -> GameShakeStateDataResponseModel {
        try await networkService.performRequestAsync(router: GameShakeRequestFactory.getState)
    }
        
  // Presenter Layer
    func fetchState() {
        Task {
            do {
                let offer = try await service.fetchState()
                // handle updateView
            } catch {
                // handle error
            }
        }
    }

Основные составляющие кода:

• async — объявляет асинхронную функцию;
• await — приостанавливает выполнение функций до завершения задачи;
• throws — указывает, что функция может выбрасывать ошибки;
• Task — запускает асинхронную операцию в синхронном коде.

Читаемость и простота кода

Что хорошо во вложенности в async/await- это то что ее нет.

В то время как в completion handler одна из главных проблем — глубокая вложенность, также известная как callback hell. Когда одна асинхронная операция зависит от другой, completion вложены друг в друга, усложняя чтение и поддержку.

Пример:

fetchData { result in
    switch result {
    case .success(let data):
        process(data) { processedData in
            save(processedData) { success in
                if success {
                    print("Data saved")
                }
            }
        }
    case .failure(let error):
        print("Error: \\(error)")
    }
}

С async/await код остается линейным и чистым:

• Отсутствует вложенность;
• do-catch охватывает все ошибки.

Task {
    do {
        let data = try await fetchData()
        let processedData = try await process(data)
        try await save(processedData)
        print("Data saved")
    } catch {
        print("Error: \\(error)")
    }
}

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

Безопасность потоков

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

  	func fetchState() async throws -> GameShakeStateDataResponseModel {
        try await networkService.performRequestAsync(router: GameShakeRequestFactory.getState)
    }
        
    func fetchState() {
        Task {
            do {
                let offer = try await service.fetchState()
                self.view?.updateUI(with: offer) // CRASH!!! (Background thread)
            } catch {
                // handle error
            }
        }
    }

Использование @MainActor гарантирует безопасность при работе с асинхронным кодом. Что также помогает вам избежать проблем с потоками.

func fetchState() {
        Task {
            do {
                let offer = try await service.fetchState()
                await MainActor.run {
                   view?.updateUI(with: offer)
                }
            } catch {
                // handle error
            }
        }
 }

Обработка ошибок

В completion handler ошибки передаются через Result<T, Error> или отдельный параметр Error?. Однако, если забыть вызвать completion, вызывающий код может зависнуть. Это приведет к бесконечной загрузке счетчика или неопределенному состоянию пользовательского интерфейса.

В async/await ошибки всегда требуют обработки:

• Если функция объявлена как throws, компилятор не позволит пропустить обработку;
• Исключение сразу указывает на источник проблемы.

Параллельность и производительность

async/await в Swift работает быстрее, чем старые подходы (замыкания, DispatchGroup, OperationQueue), потому как эффективнее управляет потоками и использует кооперативную многозадачность.

• Нет необходимости вручную управлять потоками или задачами, что предотвращает создание лишних потоков;
• Обеспечена параллельная работа задач без блокировки главного потока. Например, когда операция ожидает завершения при запросах в сети или в работе с диском, остальные операции могут продолжать выполняться;
• Минимизированы накладные расходы на переключение контекста.

Говоря о параллельном выполнений задач, async/await предлагает ряд инструментов (async let, TaskGroup,Task.detached). В данной статье мы остановимся на async let , в сравнений с DispatchGroup.

Вспомним как выглядит код с DispatchGroup:

    func fetchOffers() {
        let dispatchGroup = DispatchGroup()
        dispatchGroup.enter()
        forYouService.fetch() { [weak self] result in
            // ...
            dispatchGroup.leave()
        }
        dispatchGroup.enter()
        loyaltyStateService.fetchLoyaltyState() { [weak self] result in
            // ...
            dispatchGroup.leave()
        }
        
        dispatchGroup.enter()
        gameShakeService.fetchGameRules { [weak self] result in
             // ...
		         dispatchGroup.leave()
        }
        
        dispatchGroup.notify(queue: .main) { [weak self] in
            // handle result
        }
    }

DispatchGroup требует:

• Явного вызова enter() и leave(), что потенциально повышает вероятность ошибок (например, забыв вызвать leave());
• Отслеживания завершения через notify(), что добавляет дополнительные элементы синхронизации;
• Ручной обработки ошибок в каждом замыкании.

async let — это способ параллельного выполнения асинхронных операций.

Он позволяет запустить несколько независимых задач одновременно и затем дождаться их завершения без блокировки. Пример кода:

 Task {
	 async let forYouData = fetchForYou()
   async let loyaltyStateData = fetchLoyaltyState()
   async let gameRulesData = fetchGameRules()

   let (forYouResponse, loyaltyStateResponse, gameRulesResponse) = await (forYouData, loyaltyStateData, gameRulesData)
   // handle result
 }

async let упрощает работу:

• Синхронизация скрывается за механизмами асинхронных задач;
• Система сама управляет потоками;
• Ошибки можно обрабатывать централизованно через do-catch;
• Код остается лаконичным и удобным для поддержки.

Итоги

Подводя итоги, хочется отметить следующие преимущества:

• Мы получаем простой и линейный код, где отсутствуют вложенность;
• Мы получаем асинхронный код, который выглядит как синхронный, за счет чего упрощается понимание и дебагинг кода;
• У нас есть четкое разделение между потоками, что снижает количество возникаемых проблем с многопоточностью;
• У нас есть надежная отладка ошибок;
• Также async/await дает современные способы работы с параллельными задачами.

В результате мы получаем чистый, надежный и безопасный код.

Полезные ссылки:

• Презентация async/await на WWDC 21
• Текстовая версия WWDC записи
• Cтатья с описание адаптаций async/await в проекте
• Эволюция async/await

Telegram-канал Теплица

Обратная связь

Всем привет, дорогие друзья!

Итак, 2024 год подходит к концу. Пришло время подведения итогов, финальных релизов и обновления иконки для праздничного настроения. Стоит отметить, что наша команда не раз задумывалась о динамическом изменении иконки, независимо от релизного поезда. Мы реализовали данный подход, набили шишек и решили поделиться своим опытом.

О чём статья:

• Постановка задачи
• Реализация динамического переключения иконки на iOS
• Реализация динамического переключения иконки на Android
• На что опираться для переключения иконки

Изменение иконки приложения без обновления версии приложения в сторах

С таким заголовком задачи встретилась наша команда в начале спринта. Основная идея состояла в отрыве зависимости от релизного поезда.

Гипотеза заключалась в том, что это позволит снизить риски отсутствия обновления иконки перед каким-либо значимым праздником или событием:

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

Если вы столкнулись с такой задачей или вас посещала мысль о воплощении такой идеи, но лапки так и не дошли, то делимся своим опытом и шагами для реализации.

Реализация динамического переключения иконки на iOS

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

Шаг 1: Подготовка иконок

Для начала подготовьте альтернативные иконки в двух размерах: 120px и

180px. Назовите их следующим образом:

• IconName@2x для 120px иконки;
• IconName@3x для 180px иконки.

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

Шаг 2: Настройка Info.plist

Добавьте в ваш Info.plist ключ CFBundleIcons и его под-ключ CFBundleAlternateIcons. Пример конфигурации:

Здесь мы добавили две альтернативные иконки: Winter и Spring. Чтобы обращаться к ним, используйте значение ключа key. Название иконки должно совпадать с именем файла, но без суффиксов @2x и @3x .

Шаг 3: Создание AppIconManager

Для удобной работы создадим синглтон AppIconManager. Пример реализации:

Разберем ключевые моменты:

1. supportsAlternateIcons — проверяет, поддерживает ли приложение смену иконок;
2. alternateIconName — возвращает текущую альтернативную иконку;
3. setAlternateIconName — устанавливает новую иконку, используя название ключа key из Info.plist.

Примечание: Если вы хотите вернуть стандартную иконку, передайте nil в параметр setAlternateIconName.

Шаг 4: Использование AppIconManager

Теперь достаточно одной строки кода, чтобы сменить иконку:

Результат

Как убрать системное уведомление при смене иконки

По умолчанию, iOS уведомляет пользователя о смене иконки. Apple не предоставляет официального способа отключить это сообщение, но есть способ его обойти. Для этого обновим функцию setAppIcon:

ВАЖНО! Почему такой вариант небезопасен?

Не рекомендуем использовать данное решение как минимум по трем причинам:

1. Данное решение противоречит релизной политике Apple и может быть отклонено тестировщиком на этапе проверки в AppStoreConnect;
2. Небезопасный вызов метода. unsafeBitCast предполагает, что сигнатура функции совпадает с setAlternateIconName. Если есть расхождение, это может привести к повреждению памяти или сбоям;
3. Поскольку _setAlternateIconName:completionHandler: не документирован, его поведение может измениться в будущих версиях iOS. Это может привести в лучшем случае к некорректному выполнению функции, в худшем к крашу приложения.

Поэтому используйте это решение на свой страх и риск 😅

Реализация динамического переключения иконки на Android

В Android иконка приложения указывается в файле AndroidManifest.xml и для её переопределения лучше использовать activity-alias, который служит для создания "ссылок" на существующую Activity.

Шаг 1: Подготовка иконок

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

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

Шаг 2: Настройка activity-alias в AndroidManifest.xml

Ключевыми атрибутами activity-alias являются:

• android:name — имя alias-компонента;
• android:targetActivity — целевая Activity, которую можно открыть через alias;
• android:enabled — флаг позволяющий управлять состоянием alias;
• android:icon — задаёт иконку для alias;
• android:label — задаёт название для alias.

В AndroidManifest.xml связываем alias каждого типа с Activity, которая позволяет открыть приложение:

Шаг 3: Добавим немного красоты

Для удобства на следующем шаге, можно вынести имя alias-компонентов в отдельный файл, создав классы Activity с идентичным именем из AndroidManifest.xml:

После, подготовить enum-класс с типами:

Шаг 4: Измените активный activity-alias с помощью PackageManager

Создаём метод, который включает нужный alias и отключает остальные.

Результат

Подводные камни

Настоятельно рекомендуем заранее продумать и предложить дизайнеру отобразить AlertDialog или BottomSheet по аналогии с iOS, чтобы предупредить пользователя о смене иконки приложения. Это связано с тем, что приложение будет закрыто на Android 13 и выше, несмотря на указанный PackageManager.DONT_KILL_APP.

Реализация AlertDialog или BottomSheet позволит создать безопасную обвязку для поставленной задачи и не вызывать метод смены конфигурации в onStop. Выполнение логики смены конфигурации в методах жизненного цикла может повлечь за собой баги.

Например, для SingleActivity приложений при смене языка потребуется осуществить пересоздание Activity, тем самым вызвав onStop , что приведёт к уничтожению экземпляра приложения, если иконка не соответствует ожидаемой.

На что опираться для переключения иконки

Здесь возможны различные варианты.

Если в вашей компании существует механизм feature-toggle и соответствующее API - оно может подойти для данной задачи.

Если такого механизма нет, можно обратить внимание на Firebase Remote Config.

На этом наш пост подошёл к концу. Всем праздничного настроения и высокого Crash-free во время выходных. Good coding and happy day!🤘

Полезные ссылки:

• Документация по альтернативным иконкам для iOS
• Документация по AndroidManifest.xml
• Документация по activity-alias
• Документация по Firebase Remote Config

Telegram-канал Теплица

Обратная связь

Всем привет дорогие друзья!

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

Типы клавиатур

В Android доступно несколько типов клавиатуры для осуществления первичной фильтрации вводимых данных. Ниже будут приведены типы, доступные для Jetpack Compose.

Буквенные клавиатуры

К буквенным можно отнести клавиатуры с типом:

• Text (стандартная текстовая клавиатура);
• Ascii (клавиатура позволяет ограничить ввод только ASCII символов);
• Password (клавиатура позволяет вводить различные знаки препинания и цифры, при открытии клавиатура переключится на латинский алфавит);
• Email (клавиатура для ввода электронного адреса, имеет вспомогательные кнопки в нижнем ряду для ускорения ввода данных);
• Uri (клавиатура для ввода URI, имеет вспомогательные кнопки в нижнем ряду для ускорения ввода данных).

Числовые клавиатуры

К числовым можно отнести клавиатуры с типом:

• Number (клавиатура для ввода цифр и ряда символов);
• NumberPassword (клавиатура для ввода цифровых паролей, в отличие от Number не позволяет ввести ничего кроме цифр);
• Phone (клавиатура для ввода номера телефона и USSD-команд);
• Decimal (клавиатура для ввода десятичных дробей).

Указание типа клавиатуры в Jetpack Compose

Указать тип клавиатуры для поля ввода можно при помощи класса KeyboardOptions.

TextField(
    keyboardOptions = KeyboardOptions.Default.copy(
            keyboardType = KeyboardType.Text, // Указываем тип клавиатуры    
    ),    
    ...
)

Помимо типа клавиатуры класс KeyboardOptions позволяет настраивать такие параметры как:

• capitalization - сообщает клавиатуре, следует ли автоматически использовать заглавные буквы в словах и предложениях;
• autoCorrect - сообщает клавиатуре, следует ли выполнять автоисправление для введёного текста;
• imeAction - сообщает клавиатуре о необходимости изменить внешний вид вспомогательной кнопки на клавиатуре. Об этом поговорим чуть позднее, в рамках данной статьи.

Пароли и типы клавиатур

Если вы когда-нибудь видели поведение клавиатуры при записи экрана на iOS, во время ввода пароля, то для Android стоит снизить ожидания.

При использовании XML для полей ввода указывался параметр android:inputType="textPassword", который включал маску для вводимых символов.

При использовании Jetpack Compose это работает по другому. Для создания маски-пароля требуется передать PasswordVisualTransformation() в visualTransformation. Установка keyboardType в этом случае лишь подготовит клавиатуру к вводу пароля.

TextField(
    visualTransformation = PasswordVisualTransformation(), // Указываем маску для поля ввода пароля    
    keyboardOptions = KeyboardOptions.Default.copy(
            keyboardType = KeyboardType.Password, // Указываем тип клавиатуры    
    ),    
   ...
)

Однако, если требуется повысить уровень безопасности экрана ввода пароля, рекомендуется использовать SECURE_FLAG. Данный флаг предотвратит запись видео или создание скриншота на экране.

Типы действий на клавиатуре

На клавиатуре имеется кнопка действия (ImeAction).

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

Default

Система самостоятельно выберет действие для клавиатуры. Как правило это None или Done.

None

При клике на данное действие курсор перейдёт на новую строку.

Go

При клике на действие предполагается переход куда-либо. Например, переход по введенному URL.

Search

При клике на действие предполагается выполнение поискового запроса по введённому значению.

Send

При клике на действие предполагается отправка текста.

Previous

При клике на действие предполагается перевод фокуса на предыдущее поле ввода, если оно есть.

Next

При клике на действие предполагается перевод фокуса на следующее поле ввода, если оно есть.

Done

При клике на действие предполагается выполнение какого-либо завершающего действия (закрытие клавиатуры/отображение прогресса и отправка запроса).

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

Указание ImeAction в Jetpack Compose

Указание ImeAction, как говорилось ранее, осуществляется с помощью класса KeyboardOptions.

TextField(
    keyboardOptions = KeyboardOptions.Default.copy(       
            imeAction = ImeAction.Search, // Указываем тип кнопки действия    
    ),    
    keyboardActions = KeyboardActions {
            // Указываем код, который требуется выполнить при клике на ImeAction    
    },    
    ...
)

Размещение контента над клавиатурой и другие проблемы, связанные с этим вопросом

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

Перекрытие контента прижатой к низу кнопкой при открытой клавиатуре

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

В данном случае мы рекомендуем установить значение adjustResize для параметра windowSoftInputMode для Activity. Например, через Manifest.
Если в проекте используется BottomSheetDialogFragment, для него значение устанавливается отдельно через тему, так как данный класс имеет свой Window. Дополнительно, стоит указывать метод imePadding , который добавляет Spacer равный размеру клавиатуры для корректного подъема контента.

Верстка с использованием Jetpack Compose при этом может выглядеть следующим образом:

Box(modifier = Modifier.fillMaxSize()) {
    Column(modifier = Modifier.fillMaxSize()) {
            SomeHeader()        
            SomeBody()    
    }
        
    OverlayFooter()
}

Деформация контента при использовании adjustResize

Помните, что когда вы работаете с adjustResize, при недостатке места на экране вёрстка может начать деформироваться.

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

При необходимости добавляйте для контейнера возможность вертикального скролла. Это позволит избежать деформации верстки при недостатке экранного пространства.

Поднятие контента над клавиатурой в BottomSheetDialogFragment

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

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

Однако для некоторых устройств Huawei для кнопки стоит указать параметр BringIntoViewRequester, который позволит проскролить контент до элемента, тем самым поднимет кнопку над клавиатурой.

val bringIntoViewRequester = remember { BringIntoViewRequester() }
val isFocused = remember { mutableStateOf(false) }
TextField(
    modifier = Modifier
            .fillMaxWidth()        
            .onFocusChanged{ isFocused.value = it.isFocused },
    ...        
)

Button(
    onClick = { 
           // Выполнить действие по клику    
    },    
    modifier = Modifier
            .fillMaxWidth()
            .bringIntoViewRequester(bringIntoViewRequester),
    ) {
        Text(text = "Отправить")
      }
)
      
LaunchedEffect(key1 = isFocused.value) {
    if (isFocused.value) {
            bringIntoViewRequester.bringIntoView()    
    }
}

Некорректная позиция handle в полях ввода внутри BottomSheetDialogFragment

Капелька, которая появляется при выделении или фокусе на тексте называется handle. Если вы встречались с поведением, как на скриншоте ниже, то у меня есть для вас крутая новость - это можно пофиксить.

Данный баг связан с некорректной передачей координат местоположения поля ввода на экране в метод отрисовки handle.

Данное поведение можно исправить разместив контент боттомшита внутри Box:

Box(
    modifier = Modifier.fillMaxSize(),
    contentAlignment = Alignment.BottomCenter,
) {
    // Контент боттомшита
}

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

Good coding and happy day!🤘

Полезные ссылки:

• Страница об ImeAction
• Страница о KeyboardType
• Документация по обработке системной клавиатуры

Telegram-канал Теплица

Обратная связь

Что такое XCMetrics?

XCMetrics — инструмент, разработанный инженерами Spotify, предназначенный для обработки и отправки метрик сборок Xcode.

По своей сути, XCMetrics является «оберткой» над XCLogParser, который анализирует логи Xcode и xcodebuild, представленные в формате xcactivitylog.

Для чего нужен XCMetrics?

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

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

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

Как интегрировать XCMetrics в проект?

Интеграцию XCMetrics условно можно разделить на 3 этапа:

• Разворачивание backend-части
• Интеграция в iOS проекте
• Подключение плагинов в backstage

Интеграция XCMetrics в iOS проекте

Подготовка executable файлов

Для начала необходимо склонить XCMetrics проект. Далее компилируем executable файл XCMetrics. Для этого в терминале переходим в склоненный проект и запускаем команду

swift build --product XCMetrics -c release

Скомпилировнный файл будет находится по пути XCMetrics/.build/arm64-apple-macosx/release и будет наименован как XCMetrics

Альтернативный вариант - скачать готовые скомпилированные executable файлы.

Далее копируем скомпилированный файл, а также файл XCMetricsLauncher из root-папки XСMetrics и вставляем в root-папку вашего проекта.

На этом предварительная работа закончена. Теперь можем внести изменения в самом Xcode.

Внесение изменений в Xcode

Для того, чтобы после каждого билда вашего проекта отправлялись метрики необходимо добавить post action скрипт. Выбираем нужную вам схему в Xcode → Edit Scheme → Build → Post-Actions.

Сюда добавляем следующий скрипт:

../XCMetrics/XCMetricsLauncher ../XCMetrics/XCMetrics --name `Наименование вашей схемы` --buildDir ${BUILD_DIR} --serviceURL `https://example.com`

Давайте разберем содержание скрипта:

• ../XCMetrics/XCMetricsLauncher ../XCMetrics/XCMetrics — путь до файлов XCMetrics и XCMetricsLauncher
• --name — сюда вставляем наименование вашей схемы, либо название проекта
• --buildDir ${BUILD_DIR} — путь до логов ваших билдов в Derived Data
• --serviceURL https://example.com — адрес, по которому будут отправляться метрики

Помимо этого существуют и другие дополнительные параметры, с которыми можно ознакомиться в документации XCMetrics. На этом работа с XCMetrics в Xcode закончена и теперь после каждого билда вашего проекта соответствующие логи будут передаваться на ваш сервер.

Локальный Backend и тестирование

В рамках XCMetrics, инженеры Spotify предлагают готовый Docker образ XCMetrics. С помощью него мы сможем развернуть backend составляющую локально и протестировать отправку метрик.

• Для начала необходимо установить Docker.
• В проекте XCMetrics (который вы ранее склонили) имеется готовый конфигурационный файл docker-compose, необходимый для развертывания инстансов Redis и Postgres. Запускаем команду и получаем готовый к работе backend XCMetrics. docker-compose -f docker-compose-local.yml up

Так как теперь мы имеем полностью готовый к использованию локальный backend, можно приступить к тестированию отправки метрик. Заменяем —serviceUrl **** в ранее добавленном в Xcode post-action скрипте на http://localhost:8080/v1/metrics Можно билдить проект и тестировать отправку метрик.

Запросы XCMetrics можно отследить используя различные снифферы, наподобие Proxyman.

Проанализировать содержание метрик можно используя инструменты для работы с PostgreSQL, наподобие Postico. Креды для работы с базой Postgres XCMetrics хранятся в файле docker-compose-local.yml.

XCMetrics и Fastlane

XCMetrics является отличным решеним для отправки метрик в рамках CI. Для этого достаточно добавить в ваш lane вызов sh-скрипта. Пример скрипта использующийся в проектах Tele2/Altel.

sh("../XCMetrics/XCMetricsLauncher ../XCMetrics/XCMetrics --name 'Название вашей схемы' --buildDir '#{ENV["PWD"]}/DerivedData/Logs/Build' --isCI true --serviceURL <https://example.com>")

Давайте разберем отличия от post-action скрипта в Xcode:

• Изменен параметр —buildDir, т.к. в рамках CI мы используем кастомные пути для DerivedData. Файлы c расширением .xcactivitylog хранятся именно в DerivedData/Logs/Build.
• Добавлен параметр —isCI true для разграничения метрик в backstage.

Backstage

При подключении плагинов Xcmetrics к вашему Backstage - вы сможете видеть наглядно информацию по вашим сборкам с инфографикой и детальной информацией по каждой отдельной сборке

Полезные ссылки:

• Документация XCMetrics
• Документация по backend XCMetrics
• Доклад инженеров Spotify на iOS Conf

Telegram-канал Теплица

Обратная связь