Разработка мобильной игры на SceneKit (iOS) — под ключ

Мы специализируемся на разработке 3D-игр для iOS с использованием нативного фреймворка SceneKit. Часто клиенты приходят с готовой идеей, но не знают, какой технологический стек выбрать между Unity, Unreal и SceneKit. SceneKit — не Unity и не Unreal: нет визуального редактора pipeline, нет Asset Store, меньше готовых решений. Но это и не сырой Metal: физический движок, анимации, shader модификаторы, AR-интеграция через ARKit — всё входит в SDK без сторонних зависимостей. Для iOS-эксклюзивных 3D-игр средней сложности это вполне рабочий вариант, особенно если команда глубоко в Swift/Objective-C.

Сцена, ноды, рендеринг

Базовая единица — SCNNode. Сцена — дерево нодов: корень SCNScene.rootNode, к нодам прикреплены геометрия (SCNGeometry), свет (SCNLight), камера (SCNCamera), физическое тело (SCNPhysicsBody). Отличие от SpriteKit в том, что SceneKit работает в 3D-пространстве с координатами SCNVector3, а трансформации задаются через simd_float4x4 (или удобные свойства position, eulerAngles, simdTransform).

Загрузка сцены из .scn-файла (редактируется прямо в Xcode Scene Editor):

let scene = SCNScene(named: "GameLevel.scn")!
let scnView = SCNView(frame: view.bounds)
scnView.scene = scene
scnView.allowsCameraControl = false
scnView.rendersContinuously = true // важно для анимаций
view.addSubview(scnView)

rendersContinuously = true — если не выставить, SCNView рендерит только при изменении сцены. Для игр с постоянным движением нужен постоянный рендер. Обратная сторона — потребление батареи. Для меню с редкими изменениями оставляем false.

Физика и коллизии в 3D

SCNPhysicsBody трёх типов: .static (неподвижные объекты, коллайдер не движется), .dynamic (под управлением физики), .kinematic (движется кодом, игнорирует силы, но участвует в коллизиях). Персонаж игрока обычно kinematic — мы двигаем его через код, но стены и пол его останавливают.

Форма коллайдера влияет на производительность сильнее, чем в 2D. Используйте капсулу для персонажа, а не сложную геометрию:

let capsule = SCNCapsule(capRadius: 0.3, height: 1.8)
let physicsShape = SCNPhysicsShape(geometry: capsule, options: nil)
player.physicsBody = SCNPhysicsBody(type: .kinematic, shape: physicsShape)

Коллизии обрабатываются через SCNPhysicsContactDelegate. Настраивайте categoryBitMask, collisionBitMask, contactTestBitMask — только для нужных пар, чтобы не перегружать didBegin.

Анимации: CAAnimation и SCNAnimationPlayer

Скелетная анимация импортируется из .dae (Collada). Переключение между idle, run, jump делаем с blendInDuration для плавности:

func transition(to key: String, blendDuration: CGFloat = 0.3) {
    let player = characterNode.animationPlayer(forKey: key)!
    player.blendInDuration = blendDuration
    player.play()
    currentAnimationKey.flatMap { 
        characterNode.animationPlayer(forKey: $0)?.stop(blendOutDuration: blendDuration)
    }
    currentAnimationKey = key
}

Без blendInDuration персонаж «прыгает» между позами — это первое, что замечает игрок.

Шейдеры и постэффекты

SceneKit позволяет подключать GLSL/Metal шейдеры через SCNMaterial.shaderModifiers. Типичное применение — растворение объекта при смерти:

let dissolveShader = """
#pragma transparent
#pragma body
float threshold = u_dissolveAmount;
float noise = ... // шум по координатам
if (noise < threshold) discard_fragment();
_output.color.a = smoothstep(threshold - 0.05, threshold, noise);
"""
material.shaderModifiers = [.fragment: dissolveShader]

SCNTechnique — для постобработки всего экрана (bloom, outline, depth of field). Конфигурируется через plist-словарь.

ARKit интеграция

SceneKit — первый и основной renderer для ARKit:

let arView = ARSCNView(frame: view.bounds)
let config = ARWorldTrackingConfiguration()
config.planeDetection = [.horizontal, .vertical]
arView.session.run(config)

ARSCNView автоматически синхронизирует SCNScene с AR-координатным пространством. Это основа для AR-игр — маркет ARKit + SceneKit хорошо закрыт примерами Apple.

Как оптимизировать производительность SceneKit?

SCNView по умолчанию использует Metal на iOS 9+. Несколько правил, которые реально влияют на fps.

Batching: SceneKit автоматически объединяет draw calls для нодов с одинаковым материалом. Поэтому 1000 деревьев с одним материалом гораздо дешевле, чем 100 деревьев с 100 разными материалами. Используй SCNMaterial инстансы, не создавай новый объект материала для каждого нода.

Level of Detail через SCNLevelOfDetail: для объектов на расстоянии более 20 метров можно показывать упрощённую геометрию. Это снижает нагрузку на GPU.

Occlusion culling: SceneKit делает frustum culling автоматически, но occlusion culling (скрытие объектов за другими объектами) — нет. Для сложных сцен это нужно делать вручную через isHidden = true по результатам ray cast или логики уровня.

Инструмент для профилирования: Xcode → Metal System Trace + Render Graph. Цель — не более 30–50 draw calls для игры с стабильными 60 fps на iPhone X.

Когда стоит отказаться от SceneKit?

Мультиплатформа (iOS + Android + PC) — Unity или Godot. Сложная физика тел с деформацией — Unity с Havok. Массивные открытые миры — тоже Unity/Unreal. SceneKit хорош для iOS-эксклюзива с умеренной 3D-сложностью, AR-приложений и игр, где важна нативная интеграция (Game Center, CloudKit).

Процесс работы

1. Аудит ТЗ: тип игры, нужен ли AR, целевые устройства, минимальная версия iOS, ассеты.
2. Прототип игровой механики: движение, физика, базовая камера — 1–2 недели.
3. Core gameplay: уровни, враги/препятствия, UI (SwiftUI поверх SCNView).
4. Аудио: AVAudioEngine для 3D-звука.
5. Интеграция Game Center, IAP, ARKit.
6. Полировка производительности, тестирование на слабых устройствах.

Что входит в работу

• Исходный код с комментариями
• Документация по архитектуре и сборке
• Тестовый билд через TestFlight
• Публикация в App Store (аккаунт разработчика предоставляется клиентом)
• Гарантийная поддержка 30 дней после релиза

Ориентиры по срокам

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

Наш опыт: реализовали более 10 3D-проектов на SceneKit, включая AR-приложения с высокой производительностью. Все проекты прошли модерацию App Store без отклонений.

Пишите — оценим ваш проект за 1 рабочий день. Разработка под ключ с нуля до публикации. Официальная документация Apple по SceneKit.

Почему нативная разработка iOS — лучший выбор для сложных приложений

Приложение крашит на cold start — EXC_BAD_ACCESS в момент инициализации синглтона, который обращается к другому синглтону, который ещё не инициализирован. Или: ViewController утечёт в памяти, потому что closure захватывает self без [weak self], и этот ViewController висит в памяти через два перехода после того, как пользователь его покинул. Это не гипотетические сценарии — это два самых частых класса проблем на iOS-проектах, которые приходят к нам после другой команды.

Мы занимаемся iOS-разработкой более 5 лет, реализовали 40+ проектов разной сложности — от стартапов до enterprise-решений с миллионами пользователей. Каждый проект проходит через 3 этапа Code Review, собственный набор UI-тестов (в среднем 150+ тест-кейсов) и обязательный прогон через Xcode Instruments до релиза.

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

Почему нативная разработка iOS на Swift — выбор для enterprise-приложений?

Нативный код даёт гарантию совместимости с новыми API Apple в день их выхода, а не через месяцы адаптации в кроссплатформенных фреймворках. Для приложений с чувствительной к задержкам логикой (финансовые терминалы, медицинские мониторы, AR-навигация) это критично. Swift с ARC и строгой типизацией позволяет держать crash-free rate на уровне 99.9% при правильной архитектуре.

SwiftUI или UIKit: что выбрать для нативной разработки iOS

К настоящему времени SwiftUI покрывает подавляющее большинство production-задач. Но UIKit не устарел и не исчезнет — Apple не deprecate-ит его, а продолжает добавлять API. Реальная картина на крупных проектах: гибридный подход. SwiftUI для большинства экранов, UIKit там, где SwiftUI упирается в ограничения.

Какие сценарии SwiftUI выигрывает безоговорочно

Декларативный синтаксис SwiftUI сокращает код UI в 3–5 раз по сравнению с UIKit. Экран настроек с List, Toggle, Picker — это 40 строк SwiftUI против 200 строк UIKit с делегатами UITableViewDataSource. Экономия времени на UI-разработку достигает 60%[Apple рекомендует начинать новые проекты на SwiftUI (Human Interface Guidelines)]. При среднем бюджете проекта в 5 миллионов рублей экономия может составить до 3 миллионов рублей только на UI-слое.

@State, @Binding, @ObservableObject (а с iOS 17 — макрос @Observable) создают реактивную связь между данными и UI без ручного reloadData(). Измение @State-переменной автоматически перерисовывает затронутую часть иерархии. Это работает правильно, если понимать, как SwiftUI вычисляет diff — через Equatable и id в ForEach.

AsyncImage, NavigationStack с типобезопасным роутингом через NavigationPath, searchable, refreshable — это готовые паттерны, которые UIKit требует реализовывать вручную.

Когда UIKit остаётся необходимым

UICollectionView с compositional layout и diffable data source — сложные сетки с разными типами ячеек, горизонтальными секциями внутри вертикального скролла, динамическими размерами ячеек. SwiftUI LazyVGrid / LazyHGrid не дают такого контроля.

Кастомные переходы между экранами. UIViewControllerAnimatedTransitioning и UIViewControllerInteractiveTransitioning — интерактивный pop gesture с частичным прогрессом, кастомный hero-переход с точным управлением frame. SwiftUI matchedGeometryEffect покрывает часть случаев, но не все.

UITextView с TextKit 2. Богатый редактор текста, кастомные атрибуты, кастомный рендеринг — TextKit 2 (доступен с iOS 16) перешёл на async layout, что решило проблемы с производительностью на длинных документах. SwiftUI TextEditor — это обёртка вокруг UITextView без прямого доступа к TextKit.

UIScrollView с кастомным поведением. scrollViewDidScroll, parallax-эффекты, sticky headers с кастомной логикой, pull-to-refresh с кастомным индикатором. SwiftUI ScrollView с scrollPosition и onScrollGeometryChange (iOS 17) закрывает часть случаев, но не все.

Как мы интегрируем SwiftUI и UIKit: шаг за шагом

1. Идентифицируем экраны, где SwiftUI даёт максимальный выигрыш (списки, формы, настройки) — обычно 70-80% экранов.
2. Для критичных к производительности участков (сложные коллекции, кастомные анимации) оставляем UIKit.
3. Используем UIHostingController для встраивания SwiftUI-вью в UIKit navigation stack.
4. Для обратной совместимости оборачиваем UIKit-компоненты через UIViewRepresentable.
5. Coordinator pattern (UIKit) управляет навигацией на уровне флоу, экраны реализованы на SwiftUI.

Один паттерн, который мы используем на проектах: UIKit-координатор управляет навигацией, а сами экраны на SwiftUI. Координатор создаёт UIHostingController, передаёт ViewModel через инициализатор или @EnvironmentObject, управляет переходами. Это даёт чистое разделение: SwiftUI занимается UI, Coordinator — навигацией.

Как async/await и Combine работают вместе

До Swift 5.5 асинхронный код на iOS строился на Combine или callback-цепочках. С появлением async/await и Actor модель конкурентности стала частью языка. На новых проектах мы используем async/await как основной инструмент для сетевых вызовов и бизнес-логики, Combine — для реактивной привязки UI-состояния.

// Правильно — @MainActor гарантирует UI-обновления на main thread
@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

    func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userService.fetch(id: id)
        } catch {
            // handle error
        }
    }
}

Combine остаётся незаменимым для дебаунсинга ввода, объединения нескольких Publishers (CombineLatest, Zip) и функциональной обработки потока значений (map, flatMap, filter). На практике 80% проектов используют оба подхода, выбирая инструмент под задачу.

Архитектура iOS-приложения

MVVM — базовый паттерн. ViewModel содержит логику и @Published-состояние, SwiftUI View подписывается через @ObservedObject или @StateObject. Правило одно: View не знает об URLSession, CoreData, UserDefaults.

Clean Architecture добавляет слои Repository и UseCase. UserRepository абстрагирует источник данных (сеть vs кеш). FetchUserUseCase содержит бизнес-правило. UserViewModel вызывает UseCase и управляет UI-состоянием.

TCA (The Composable Architecture) — более строгий паттерн от Point-Free. State, Action, Reducer, Effect — всё явное, всё тестируемое, composable через Scope. Хорошо работает в больших командах (5+ iOS-разработчиков), где важна предсказуемость поведения.

Что входит в разработку iOS-приложения

Инструменты, без которых не обходится ни один релиз

Xcode Instruments. Time Profiler показывает, где CPU тратит время. Allocations — утечки памяти и excessive allocations. Leaks — объекты, которые не освобождаются. Перед каждым релизом — обязательный прогон.

Firebase Crashlytics. Crash-free rate, группировка по stack trace, breadcrumbs событий до крэша. Настраивается за 30 минут, даёт картину по всему парку устройств. В среднем crash-free rate на наших проектах — 99.8%.

Fastlane match. Управление сертификатами и provisioning profiles через зашифрованный git-репозиторий. Устраняет «у меня локально собирается, а на CI нет» раз и навсегда. Экономит до 4 часов на каждую сборку при ручном подписывании.

XCTest + XCUITest. Unit-тесты для ViewModel и UseCase, UI-тесты для критичных флоу (онбординг, оплата, авторизация). В среднем код покрыт на 75%.

Процесс и сроки

Стоимость рассчитывается индивидуально после анализа ТЗ и дизайна. Обычно первые 2 недели уходят на проектирование, после чего мы фиксируем сроки и бюджет. Средний бюджет на разработку среднего iOS-приложения — от 4 до 7 миллионов рублей в зависимости от сложности интеграций.

Закажите разработку под ключ — мы оценим ваш проект за 2 рабочих дня и предложим оптимальную архитектуру. Свяжитесь с нами, чтобы обсудить вашу задачу: гарантируем качество кода, соблюдение App Store Review Guidelines и опыт работы с проектами любого масштаба. Получите консультацию — мы поможем выбрать правильный стек и избежать типичных ошибок на старте.