Як ми прискорили розробку на iOS за допомогою Cursor AI
Всім привіт! Мене звати Сергій. Я працюю iOS Tech Lead у Futurra Group, де відповідаю за розробку мобільних рішень та приймаю ключові технічні рішення й вибудовую процеси, які допомагають команді стабільно доставляти якісний продукт швидше.
В цій статті я розповім, як ми змінили Xcode на Cursor і чому це стало одним із найпомітніших «левел-апів» у нашому iOS-workflow. Якщо коротко, Cursor — це своєрідний форк VSCode, доповнений інтелектуальними функціями, які допомагають швидше писати й редагувати код.
Ми перейшли на Cursor відносно нещодавно, але вже встигли відчути помітний приріст у швидкості розробки. Нижче я покажу, як ми його налаштували під iOS і які фічі використовуємо найчастіше, щоб ви могли оцінити, наскільки цей підхід зайде у вашому workflow.
Коли в Xcode 26 нарешті з’явилась вбудована AI-інтеграція (ChatGPT in Xcode), ми реально зраділи: менше контекст-світчингу, усе «в одному місці», звучить як мрія. Але на практиці виявився нюанс: на момент написання статті ця інтеграція крутиться навколо моделі GPT-5 (включно з «Reasoning» варіантом), і цього часто не вистачає для швидкої, стабільної роботи з реальним продакшн-кодом.
Паралельно Cursor вже підхопив GPT-5.2, і різниця відчувається майже одразу: менше «тертя» в діалогах, краще тримається контекст, швидше виходимо на коректні правки без нескінченних уточнень і переробок. Саме цей розрив між «AI є» і «AI реально прискорює» став тригером, чому ми почали системно мігрувати свій процес у Cursor.
Практичний приклад: Figma → SwiftUI у Cursor + перевірка в Xcode Preview
У цьому прикладі ми покажемо повний сценарій «дизайн → готовий SwiftUI-екран»: беремо посилання на екран у Figma (де намальований список планів), вставляємо його в промпт у Cursor, і просимо згенерувати верстку на SwiftUI з підключенням реальних даних із JSON-файла в проєкті. Після цього відкриємо результат у коді, а фінальну перевірку зробимо в Xcode через SwiftUI Preview, щоб наочно побачити, як екран відображається в застосунку.
Крок 1
Створюємо новий проєкт.

Крок 2
Відкриваємо макет екрана зі списком планів у Figma та копіюємо посилання на потрібний фрейм/артборд (Copy link to selection).
Мета: передати Cursor точний дизайн, щоб він міг зчитати структуру, стилі та відступи.

Крок 3
У Cursor відкриваємо чат і вставляємо посилання на Figma. Далі описуємо задачу: «зверстати цей екран на SwiftUI» та вказуємо, що дані потрібно брати з локального JSON у проєкті.

Крок 4
Формуємо промпт так, щоб Cursor:
- підтягнув дизайн з Figma через MCP;
- знайшов у репозиторії JSON з даними;
- згенерував SwiftUI-екран і потрібні моделі/мапінг;
- зробив компоненти максимально близько до структури макета (тексти, іконки, spacing, стани).
Крок 5
Cursor отримує контекст із Figma: бачить фрейми, компоненти, типографіку, кольори та layout. На основі цього він пропонує структуру SwiftUI: контейнерний екран + список + рядок плану + допоміжні в’ю.
Крок 6
Далі Cursor знаходить JSON-файл з даними для цього екрана і підключає його як datasource:
- описує модель (Decodable);
- додає loader (наприклад, з bundle);
- будує binding у ViewModel/State;
- щоб список планів рендерився з реальних даних, а не з «хардкоду».
Крок 7
На цьому кроці ми бачимо результат: Cursor створив потрібні файли (SwiftUI view + моделі + loader/VM) і відтворив екран відповідно до дизайну. Важливо, що код одразу інтегрований у структуру проєкту й готовий до запуску.

Крок 8
Переходимо в Xcode, відкриваємо згенерований SwiftUI-екран і перевіряємо, що все збирається без помилок та коректно підтягує дані з JSON.

На весь цей приклад у нас пішло приблизно 30 хвилин. Якщо робити те саме вручну — підігнати верстку під дизайн, рознести компоненти, підключити JSON і довести все до робочого Preview — це зайняло б суттєво більше часу і точно більше «контекст-перемикань».
Далі я покажу, як налаштувати Cursor для iOS-розробки та підключити MCP-сервери, щоб ви могли повторити цей сценарій у своєму проєкті.
Налаштування Cursor під iOS development
Спочатку потрібно встановити Cursor. Він має безплатний тариф, але частина можливостей, які я покажу далі, потребує підписки за $20. Я нічого не «продаю» — просто опишу, як це працює, а чи варто платити, вирішите самі. Безплатної версії цілком достатньо, щоб спробувати редактор у справі.
Також у налаштуваннях можна підключити власні API-ключі (OpenAI / Claude / Gemini), якщо ви вже окремо оплачуєте ці сервіси.
🛠️ Базове налаштування
Після інсталяції Cursor варто додати кілька залежностей — тоді інтеграція з iOS-проєктом буде повноцінною (нормальна індексація, підказки, навігація по коду).
У терміналі встановіть Xcode Build Server:
brew install xcode-build-server
Це дозволить SourceKit-LSP працювати поза межами Xcode й давати ті самі базові можливості: перехід до визначення, пошук усіх посилань, аналіз call tree та інші інструменти навігації по коду. Фактично, більшість того, до чого ви звикли в Xcode, стане доступним і в Cursor.

Редактор коду Cursor із запущеним Xcode Build Server
Далі встановіть xcbeautify:
brew install xcbeautify
xcbeautify перетворює вивід xcodebuild у терміналі Cursor на значно зручніший і читабельніший формат — так простіше швидко знаходити помилки та попередження і краще бачити, що саме пішло не так.

Термінал Cursor під час білду з xcpretty
Також встановіть SwiftFormat, якщо у вас його ще немає.
brew install swiftformat
Після встановлення всіх потрібних залежностей запустіть Cursor, відкрийте вкладку Extensions і додайте:

- Swift Language Support — Це розширення відповідає за коректну підсвітку синтаксису Swift і дає базові можливості, потрібні для комфортної розробки. GitHub: github.com/swiftlang/vscode-swift
- SweetPad — ключовий інструмент, який дозволяє працювати з iOS-проєктом поза звичним інтерфейсом Xcode. На сторінці розширення є детальний опис усіх можливостей, гарячих клавіш і принципів роботи. У цій статті я зачеплю лише найпрактичніші моменти SweetPad, а решту нюансів можна легко знайти там. GitHub: github.com/sweetpad-dev/sweetpad

Список можливостей розширення SweetPad.
SweetPad додає зручний шар команд і гарячих клавіш поверх стандартного xcodebuild. По суті, він переносить у Cursor те, до чого звикли в Xcode: можна переглядати всі targets/schemes, обирати destination (симулятор або реальний пристрій), збирати проєкт і запускати застосунок — майже так само, як у Xcode, але без виходу з редактора.
Окремий плюс: SweetPad автоматично готує проєкт до роботи з Xcode Build Server, тож ви отримуєте повноцінні Swift-фічі редактора (навігацію по коду, references тощо), про які говорили вище.
Після встановлення SweetPad натисніть CMD + SHIFT + P, відкрийте меню команд і виберіть:
SweetPad: Generate Build Server Config

Після цього в корені проєкту буде створено файл buildServer.json — саме він підключає Xcode Build Server до вашої директорії з проєктом і дає змогу коректно працювати з індексацією та Swift tooling у Cursor.

Коли конфігураційний файл уже створений, запустіть Build & Run — або через меню команд, або з панелі SweetPad у Cursor (я зазвичай закріплюю її, щоб була під рукою). Там ви побачите всі свої targets/schemes і зможете зібрати та запустити будь-який із них у кілька кліків.

Крім цього, в Cursor можна й дебажити застосунок. Для цього створіть launch configuration для режиму відладки — коли Cursor попросить вибрати провайдер, оберіть SweetPad.
Далі є два зручні сценарії:
- спочатку запустити застосунок через Build & Run, а потім перейти в Run & Debug;
- або одразу у вкладці Run & Debug вибрати Attach to running app і під’єднатися до вже запущеного процесу.
Це покриває більшість щоденних задач: брейкпоїнти, стек викликів, змінні, логіка в рантаймі — без постійних стрибків назад у Xcode.

Cursor із запущеним дебагером: виконання зупинено на breakpoint’і
Ви отримаєте майже все, до чого звикли в Xcode (а подекуди й більше): breakpoints, перегляд call stack, інспекція та print змінних, step over/step into, перехід по рядках виконання тощо — усе в одному інтерфейсі Cursor.
Ваш файл ./vscode/launch.json має виглядати приблизно так:
{
"version": "0.2.0",
"configurations": [
{
"type": "sweetpad-lldb",
"request": "launch",
"name": "SweetPad: Build and Run (Wait for debugger)",
"preLaunchTask": "sweetpad: debugging-launch"
}
]
}
📦 Налаштування MCP-сервера через Docker
Практичний гайд із запуску сервера Model Context Protocol (MCP) у Docker. Це дозволяє AI-асистенту підключатися до ваших локальних інструментів, файлів і API у безпечному контейнеризованому середовищі — з контрольованими доступами та без «прямого» втручання в систему.
Ми будемо використовувати Docker MCP Toolkit — він закриває три критичні проблеми, з якими найчастіше стикаються розробники під час побудови AI-агентів:
Нульова складність конфігурації. Класичне підключення MCP зазвичай вимагає вручну ставити залежності, налаштовувати environment variables і уважно слідкувати за версіями. Натомість MCP Catalog від Docker дає вже підготовлені контейнери, які стартують «з коробки»: кілька кліків — і сервер запущено.
Універсальна сумісність. Неважливо, що ви використовуєте: Cursor, Claude Desktop чи VS Code + GitHub Copilot — Docker MCP gateway виступає єдиною точкою підключення. Ваші AI-агенти отримують доступ до всіх встановлених MCP-серверів через стандартизований інтерфейс — незалежно від обраної LLM або IDE.
Безпека рівня «enterprise». Кожен MCP-сервер працює в ізольованому контейнері з ресурсними лімітами (за замовчуванням 1 CPU і 2 GB RAM), із підписаними image’ами від перевірених Docker-видавців та з автоматичним secret detection, яке блокує витік чутливих даних. OAuth tokens і API keys залишаються захищеними у своїх контейнерах.
Налаштування MCP-серверів
Для старту з Docker MCP Toolkit потрібен Docker Desktop 4.40+ (macOS). Далі — спрощений план:
Увімкнення MCP Toolkit:
- Відкрийте Docker Desktop → Settings.
- У розділі Beta features увімкніть «Docker MCP Toolkit».
- Натисніть Apply & Restart.
Це активує MCP gateway і відкриє інтерфейс каталогу, через який можна встановлювати та керувати MCP-серверами.

Ми використовуємо такі MCP-сервери:
- Fetch — MCP-сервер для отримання контенту з вебсторінок. Дозволяє LLM підтягувати вміст із URL, діставати потрібні фрагменти та конвертувати HTML у Markdown, щоб моделі було простіше «їсти» текст і працювати з ним.
- Memory — базова реалізація персистентної пам’яті на основі локального knowledge graph. Завдяки цьому асистент може зберігати важливі факти про користувача та контекст і використовувати їх між різними чатами.
- Sequential Thinking — MCP-сервер, який додає інструмент для структурованого мислення: розбивка задачі на кроки, рефлексивний аналіз, перевірка гіпотез і більш керований процес розв’язання складних проблем.
Щоб Cursor міг читати структуру макетів у Figma і допомагати «верстати» UI (SwiftUI / UIKit) максимально близько до дизайну, спочатку потрібно увімкнути MCP server у Figma.
Увімкнення MCP Server у Figma
- Відкрийте Figma.
- Натисніть CMD + K (Command Palette).
- У пошуку введіть «MCP server».
- Оберіть відповідний пункт і увімкніть MCP Server.
Після цього Figma стане «джерелом контексту» для Cursor: асистент зможе отримувати дані про фрейми, компоненти, текстові стилі, кольори, spacing тощо — і на їх основі генерувати код UI більш точно, ніж з описів «на словах».

Тепер потрібно підключити MCP-сервери в Cursor — для цього створюємо конфіг і вмикаємо потрібні інтеграції.
Додаємо MCP servers у Cursor
- У Cursor відкрийте Settings → Tools & MCP.
- Натисніть Add custom MCP — Cursor створить файл mcp.json.
- Далі в mcp.json додаємо конфіг для кожного MCP-сервера, який будемо використовувати.
У мене конфіг виглядає так:
{
"mcpServers": {
"Figma": {
"url": "http://127.0.0.1:3845/mcp"
},
"Context7": {
"url": "https://mcp.context7.com/mcp",
"headers": {}
},
"sequentialthinking": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"mcp/sequentialthinking"
]
},
"memory": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
"/Users/SergeyZhuravel/mcp-data/data",
"mcp/memory"
]
},
"fetch": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"mcp/fetch"
]
}
}
}
Кілька практичних деталей, які економлять час:
- Для Docker-based серверів параметр -i важливий — це режим STDIO, через який Cursor спілкується з MCP-контейнером.
- Для memory я відразу додаю volume (-v ...) — так памʼять переживає перезапуск контейнера і не «скидається» кожного разу.
Збережіть mcp.json, поверніться в Settings → Tools & MCP і увімкніть всі потрібні MCP-сервери.
Після цього Cursor підхопить інструменти (tools) з кожного сервера — і ви зможете прямо в чаті просити, наприклад: підтягнути дані з Figma, витягнути контент із вебсторінки через Fetch, або вирішити задачу «крок за кроком» через Sequential Thinking.

Налаштування моделей
Тепер налаштуємо моделі. Відкрийте Settings → Models і в списку увімкніть ті, з якими плануєте працювати. На момент написання цієї статті ми використовуємо дві основні:
- GPT-5.2 — як «універсальну» модель для складних задач: аналізу, планування, архітектурних рішень, рев’ю великих змін.
- GPT-5.1-Codex — як модель «під код»: швидкі правки, рефакторинг, генерація типового boilerplate, правки по файлах і дрібні таски без зайвих розмов.
Практичний підхід простий: Codex — для рутинного coding-flow, GPT-5.2 — коли потрібно думати ширше (або коли задача «не влізає в один файл»).

Перший запуск проєкту та базові правила для AI
Після цього відкрийте свій проєкт у Cursor і можна починати працювати з чатом/Composer. Але щоб AI-агент орієнтувався в репозиторії швидко й не «плавав» у здогадках, дуже раджу одразу зробити дві речі:
- Згенерувати коротку документацію про проєкт (що це, як зібрати/запустити, структура модулів, ключові флоу).
- Заповнити Cursor Rules (структура, принципи, архітектура, конвенції) — тоді більшість відповідей і правок будуть одразу у вашому стилі.
Ось приклад промпта, який ми використовуємо:
Промпт (template):
Проаналізуй репозиторій і створи документацію в папці docs/ у Markdown.
Вимоги до docs:
- docs/README.md: короткий опис проєкту, вимоги, як запустити (build/run/test), як працює конфіг, де що лежить.
- docs/architecture.md: архітектура (модулі/шари), залежності, ключові патерни (Swift Concurrency, DI, навігація), типові флоу.
- docs/conventions.md: code style, naming, структура папок, правила для SwiftUI/UIViewController, підходи до тестів.
- створи підпапку docs/api/. Якщо в проєкті є API-клієнт/ендпоїнти — опиши їх і згенеруй OpenAPI YAML у docs/api/openapi.yaml (базуючись на реальних ендпоїнтах у коді).
Додатково: заповни Cursor Rules (або .cursorrules), де зафіксуй структуру проєкту та основні принципи: що можна/не можна міняти, preferred patterns, вимоги до PR (маленькі дифи, тести для критичних змін), і як ми називаємо файли/типи.
Висновок
Cursor чудово закриває рутинні задачі в iOS-розробці: написання тестів, рефакторинг, оновлення API, дрібні правки по проєкту та швидке генерування boilerplate. Найприємніше — значно менше контекст-світчингу: багато відповідей і правок ви отримуєте прямо в редакторі, без постійних походів у браузер чи сторонні інструменти.
Але є важливі нюанси:
- Cursor не замінює глибоку діагностику. Пошук витоків пам’яті, складний дебаг, профілювання — це все ще зона, де Xcode почувається сильніше.
- AI не робить «самостійне problem solving» за вас. Він може запропонувати рішення, але перевірка гіпотез, розуміння контексту й відповідальність за зміни залишаються на інженері.
- Немає Xcode-інструментів на кшталт Memory Graph чи View Hierarchy. Для таких задач ми все одно повертаємось в Xcode.
Тож Cursor — не ідеальний і точно не «вбивця Xcode». Але як помічник він уже зараз економить години рутини й пришвидшує доставку фіч — особливо там, де потрібні швидкі правки, робота з кількома файлами та підтримка контексту.
Happy Coding!
Також запрошую до мого Telegram-каналу про iOS-розробку, де вже понад рік ділюся цікавими матеріалами та практичними інсайтами.
Зв’язатися зі мною можна через LinkedIn.
Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.

42 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів