Я уже некоторое время использую Claude Code в своём процессе iOS-разработки и постоянно замечаю одну и ту же закономерность: разработчики либо воспринимают его как продвинутое автодополнение кода, либо вообще не используют, потому что:
Он не понимает мою кодовую базу.
Обе группы упускают очень многое.
Claude Code не заменяет знание Swift и глубокое понимание UIKit и SwiftUI. На самом деле всё наоборот: чем лучше вы понимаете платформу, тем точнее можете направлять Claude Code и тем быстрее он работает.
Думайте о нём не как о junior-разработчике, который пишет код за вас, а скорее как о senior-разработчике, который уже познал весь Apple SDK и ждёт, когда сможет помочь вам продумать задачу.
Эта статья о том, как действительно эффективно использовать Claude Code в iOS-разработке.
Не про универсальные советы в духе «пишите запросы конкретнее».
А про реальные шаблоны работы, которые помогают при создании настоящих приложений.
1. Сначала дайте Claude Code контекст проекта
Самая большая ошибка, которую я вижу, — запускать Claude Code «с нуля»: без контекста, просто с вопросом.
В ответ вы получаете общие рекомендации, которые могли бы подойти любому iOS-проекту, но не обязательно вашему.
Прежде всего нужно объяснить ему устройство проекта.
# From your project root, let Claude Code read your structure claude "Read the project structure and key files so you understand the codebase before I ask anything"
Или подойдите к этому более обдуманно:
claude " Here's the context for this project: - SwiftUI app targeting iOS 17+ - MVVM with @Observable macro (not ObservableObject) - Uses Swift Concurrency everywhere (async/await, no Combine) - Dependency injection via a DependencyContainer singleton - SwiftData for local persistence, custom API layer for networking - No third-party UI libraries — everything is native SwiftUI Keep this in mind for everything I ask from this point forward. "
Теперь каждый следующий вопрос будет получать ответы, которые соответствуют вашей реальной архитектуре, а не универсальному шаблону MVVM с @StateObject, хотя вы уже перешли на @Observable.
2. Используйте его для шаблонного кода, который вам слишком скучно писать правильно
Есть категория iOS-кода, которую каждый разработчик умеет писать, но которая настолько утомительна, что иногда хочется срезать угол.
Это реализации Codable с кастомными ключами, билдеры NSPredicate, конструкторы URLRequest, настройка наблюдателей NotificationCenter, шаблонный код для запросов к Core Data.
Именно здесь Claude Code быстрее всего начинает окупать своё использование.
claude "
Create a Codable struct for this API response. Use camelCase property names and
map from snake_case JSON keys automatically.
{
'user_id': 'abc-123',
'display_name': 'Ahmad',
'created_at': '2026-01-01T00:00:00Z',
'is_premium': true,
'profile_image_url': 'https://cdn.example.com/img.jpg',
'task_count': 42
}
Also write a DateDecodingStrategy extension to handle ISO8601 dates.
"
Вы сами написали бы это за пять минут. Claude Code сделает то же самое за пять секунд и правильно заполнит все случаи в CodingKeys без единой опечатки.
Экономия времени в каждом отдельном случае небольшая. Но в проекте с 30 моделями для API она становится уже заметной.
3. Просите его писать тесты, а не только код
Большинство разработчиков используют Claude Code для написания основной реализации. Более разумный подход — просить его писать тесты для кода, который вы уже написали.
Это полезно по двум причинам.
Во-первых, это быстрее, чем писать тесты вручную.
Во-вторых — и это важнее — Claude Code часто задаёт вопросы или делает предположения, которые выявляют пробелы в вашем собственном понимании ожидаемого поведения функции.
claude " Write XCTest unit tests for this ViewModel. Cover: - Happy path (successful data load) - Empty state (API returns empty array) - Error state (network failure) - The filter logic for each Filter enum case - That toggling a task correctly updates the local state Use async/await for all async tests. Mock the use cases with protocol-based fakes, not mocks libraries. Here's the ViewModel: [paste code] "
Инструкция про фейковые реализации на основе протоколов здесь важна. Объясняйте не только что нужно тестировать, но и как именно вы хотите это тестировать. Claude Code будет следовать вашим соглашениям, если вы явно их опишете.
4. Используйте его как резиновую уточку для обсуждения архитектурных решений
Именно этот сценарий удивил меня больше всего. Прежде чем окончательно принять архитектурное решение, опишите проблему Claude Code и попросите его возразить вам.
claude " I'm designing the navigation architecture for a SwiftUI app. The app has 5 main tabs, each with their own navigation stack. Some flows need to navigate across tabs (e.g., tapping a notification opens a detail view in a different tab). I'm considering using a Coordinator pattern with a root coordinator managing tab state. But I've also seen people use NavigationPath stored in an @Observable class per tab. What are the real trade-offs between these two approaches for an app at this scale? What would break first as the app grows? What would you do and why? "
Вы не просите его писать код. Вы используете его для проверки своих идей на прочность, прежде чем написать хотя бы одну строчку.
Вот где действительно полезно иметь инструмент, который прочитал тысячи кодовых баз iOS.
5. Предоставьте ему сообщение об ошибке, файл и контекст одновременно
При отладке качество помощи Claude Code прямо пропорционально тому, сколько контекста вы ему предоставляете. Большинство людей просто вставляют сообщение об ошибке. Это наименее полезная вещь, которую вы можете ему предоставить.
Предоставьте ему все сразу:
claude " I'm getting this crash at runtime: [paste full crash log / stack trace] Here's the file where the crash is happening: [paste the relevant file] Here's how this code gets called: [paste the call site] The crash only happens when the user navigates back from the detail screen while a network request is in flight. It doesn't happen in the simulator, only on device. "
Деталь «с устройства», момент перехода по навигации, активный сетевой запрос — всё это важно.
Чем конкретнее вы описываете ситуацию, тем меньше дополнительных уточнений потребуется и тем выше вероятность, что первый ответ Claude Code действительно решит проблему.
6. Позволяйте ему выполнять рефакторинг, но проверяйте каждую строку
Claude Code отлично справляется с рефакторингом. Он может взять ViewController на 200 строк, определить зоны ответственности и разделить его на нормальную связку ViewModel и View. Он может переименовать все вхождения определённого шаблона сразу в нескольких файлах. Он может вынести повторяющийся код в переиспользуемый модификатор.
Правило простое: никогда не принимайте рефакторинг, не прочитав каждую изменённую строку.
claude " Refactor this ViewController to MVVM. Rules: - ViewModel uses @Observable (not ObservableObject) - All network calls move to the ViewModel using async/await - View only contains UI code — no business logic - Keep the existing error handling behavior exactly as-is - Do NOT change the public interface — other parts of the codebase depend on the completion handlers currently exposed "
Последние два ограничения особенно важны. Claude Code не знает, от каких решений зависит остальная часть вашей кодовой базы. А вы знаете.
Когда вы явно указываете, что нужно сохранить, это не даёт ему «отрефакторить» важную деталь и случайно сломать функцию на три экрана дальше.
Всегда запускайте полный набор тестов после рефакторинга, выполненного Claude Code, даже если код выглядит корректным.
7. Используйте CLAUDE.md, чтобы зафиксировать соглашения вашей команды
Если вы используете Claude Code в командном проекте или просто хотите получать согласованное поведение между разными сессиями, создайте файл CLAUDE.md в корне проекта.
Claude Code автоматически читает этот файл и использует его содержимое как постоянный контекст.
# CLAUDE.md
## Project: MyApp iOS
### Swift conventions
- Use @Observable macro, never ObservableObject
- Prefer async/await over completion handlers for all async code
- Use Swift concurrency structured tasks — avoid unstructured Task { } unless necessary
- All network errors must be typed (no generic Error throws)
- Never force unwrap — use guard let or if let
### Architecture
- Feature-based folder structure: Features/FeatureName/{View, ViewModel, Model}
- Use cases live in Core/Domain/UseCases/
- Repository pattern for all data access
- DependencyContainer.shared is the composition root
### SwiftUI patterns
- Views are dumb — no business logic, only layout and user actions
- Use ViewModels initialized in the View's init via @State
- Prefer native SwiftUI components before reaching for custom implementations
- All lists use LazyVStack or List, never ScrollView + ForEach for large datasets
### Testing
- Unit tests for all ViewModels and UseCases
- Use protocol-based fakes, not mock frameworks
- UI tests only for critical user flows (onboarding, checkout, auth)
### What to avoid
- Singleton state outside DependencyContainer
- NotificationCenter for cross-module communication — use delegates or callbacks
- DispatchQueue.main.async — use MainActor instead
Теперь каждая сессия Claude Code в этом проекте начинается с уже загруженных правил. Вам не нужно повторяться каждый раз.
8. Запросите у него объяснение API Apple, прежде чем использовать их
Это вариант использования, о котором большинство iOS-разработчиков не задумываются: использование Claude Code в качестве подробного объяснения незнакомых API, прежде чем начать писать код.
claude " I need to implement background app refresh for syncing tasks while the app is not running. Explain how UIApplication.shared.setMinimumBackgroundFetchInterval works, what BGTaskScheduler does differently, which one I should use for iOS 17+, and what the actual gotchas are that Apple's documentation glosses over. "
Или когда вы собираетесь использовать что-то, что уже использовали раньше, но хотите перепроверить:
claude " I'm about to use URLSession with a background configuration for file downloads. What are the behaviors that will catch me off guard — specifically around how the delegate callbacks work when the app is terminated and relaunched, and how to handle the completion handler that iOS gives back to the app delegate. "
Это быстрее, чем читать документацию, быстрее, чем Stack Overflow, и ответ адаптирован к вашему конкретному контексту, а не к чьему-то вопросу 2019 года.
9. Используйте его для генерации реалистичных моковых данных
Одна из самых утомительных частей разработки iOS — создание реалистичных тестовых данных.
Claude Code очень хорошо подходит для генерации предварительных просмотров SwiftUI, фикстур XCTest и моковых данных, которые действительно напоминают реальный контент.
claude "
Generate 10 realistic TaskItem mock objects for SwiftUI previews and unit tests.
Use real-sounding task titles — not 'Task 1', 'Task 2'. Mix priorities,
some with due dates (some overdue, some today, some upcoming),
some completed, some not. A few should have reminderDates set.
Return them as a static array in a PreviewData.swift file using
the #if DEBUG guard.
"
// What you get back — actually usable in previews
#if DEBUG
extension TaskItem {
static let mockTasks: [TaskItem] = [
TaskItem(
id: UUID(),
title: "Review Q2 design specs with product team",
description: "Go through Figma file and leave comments before Thursday standup",
dueDate: Calendar.current.date(byAdding: .day, value: -1, to: Date()),
priority: .high,
isCompleted: false,
createdAt: Date(),
updatedAt: Date(),
reminderDate: Calendar.current.date(byAdding: .hour, value: -2, to: Date())
),
// ... 9 more realistic entries
]
}
#endif
Реалистичные данные для предварительного просмотра действительно помогают заранее находить проблемы в пользовательском интерфейсе.
Если названия задач всегда выглядят как Task 1 и Task 2, проблемы с компоновкой легко не заметить, потому что содержимое всегда имеет одинаковую длину.
10. Каждый раз проверяйте то, что он создаёт
Это самый важный совет из всех. Claude Code работает быстро и обычно выдаёт правильный результат. Но не всегда.
Он может сгенерировать код, который компилируется, запускается и даже проходит тесты, но всё равно оказывается слегка неправильным именно для вашей ситуации.
Он может использовать устаревший программный интерфейс, который пока работает, но будет удалён в одной из будущих версий iOS.
Он может корректно обработать основной сценарий, но пропустить граничный случай, который вы не описали.
Он может написать код, который архитектурно не соответствует остальной кодовой базе, причём это не сразу будет очевидно.
Правило простое: относитесь к каждому результату Claude Code так же, как относились бы к запросу на слияние от разработчика, которого уважаете, но с которым раньше не работали.
Прочитайте код. Разберитесь в нём. Задавайте вопросы, если что-то кажется непонятным. Не сливайте изменения, пока не сможете объяснить, зачем нужна каждая строка.
# Good prompt pattern — ask it to explain its own choices claude " Here's the code you wrote for the sync manager. Explain: - Why you chose this concurrency pattern over the alternative - What happens if two sync operations are triggered simultaneously - What the failure mode is if the remote API is unreachable mid-sync - Whether there's any state that could get stuck if the app is backgrounded during sync "
Если Claude Code не может дать хороший ответ на эти вопросы, значит, код, скорее всего, нужно переосмыслить. Неважно, написал его Claude Code или вы сами.
Разработчики, которые получают от Claude Code максимум пользы, — это не те, кто быстрее всех принимает его результат. Это те, кто использует его, чтобы двигаться быстрее, но при этом продолжает внимательно думать.
Искусственный интеллект берёт на себя утомительные части работы. Всё остальное остаётся за вашим инженерным суждением.
Собираем всё вместе
Claude Code меняет представление о том, что действительно стоит делать вручную. Шаблонный код, на который раньше ушло бы 20 минут, теперь превращается в запрос на 30 секунд. Покрытие тестами, которое раньше могли бы пропустить из-за жёстких сроков, теперь становится реалистичным. Архитектурные вопросы, для обсуждения которых раньше понадобилась бы консультация старшего разработчика, теперь можно исследовать за несколько минут.
Но Claude Code не меняет сути хорошей iOS-разработки. Она по-прежнему требует глубокого знания Swift, понимания ограничений платформ Apple, написания тестов, продуманного подхода к архитектуре и строгой проверки кода.
Лучше всего думать об этом так: Claude Code повышает нижнюю планку того, что вы можете сделать за один день. А вот что именно вы создадите с этим дополнительным ресурсом — по-прежнему полностью зависит от вас.