Ми розробляємо нативні iOS-застосунки на Objective-C. Ця мова — не legacy у сенсі «застаріла й не працює». Це production-ready мова з повною підтримкою Apple SDK, яка компілюється в ті самі бінарники, що й Swift.
Різниця в тому, що нові API виходять із Swift-first анотаціями, а деякі concurrency-фічі (наприклад, async/await) недоступні.
Для підтримки наявних ObjC-кодових баз або особливих вимог замовника (інтеграція з C++ через Objective-C++, робота з аудіо/відео кодеками) — це цілком робочий шлях під ключ.
Середня вартість підтримки legacy-коду на ObjC на 25–30% нижча за повну міграцію на Swift, що підтверджується нашою практикою за 5+ років і 20+ проєктами.
Objective-C залишається основною мовою для багатьох великих iOS-проєктів завдяки стабільності та зворотній сумісності (Wikipedia).
Коли варто обрати Objective-C?
Основний сценарій: велика кодова база на Objective-C, яку недоцільно повністю мігрувати. Додавання нового функціоналу на ObjC підтримує однаковість, знижує ризик помилок на межі Swift/ObjC і спрощує рев'ю для команди.
Другий сценарій: інтеграція C/C++. Objective-C++ (файли .mm) дозволяє напряму змішувати C++ і ObjC код — це затребувано в embedded, audio, game-рушіях, де core library написана на C++. Swift викликає C++ через bridging header, але це складніше й менш прозоро.
Які типові проблеми трапляються в ObjC-проєктах?
EXC_BAD_ACCESS на nil-dereference трапляється рідше через те, що повідомлення nil в ObjC повертає 0/nil замість крашу — але це ж маскує логічні помилки.
NSZombies (Edit Scheme → Diagnostics → Enable Zombie Objects) допомагає ловити звернення до звільнених об'єктів у Debug-збірках.
Category collision: два різних pod'и додають категорію на NSString з однаковим ім'ям методу — undefined behavior. Проявляється як випадковий краш або неочікувана поведінка. Рішення: namespace-префікси методів категорій (my_trimmed замість trimmed).
Retain cycle в ObjC block — self захоплюється неявно, потрібен __weak typeof(self) weakSelf = self + __strong typeof(weakSelf) strongSelf = weakSelf всередині блоку.
Як зазначено в Apple Memory Management Programming Guide, грамотне використання ARC і weak-посилань знижує ймовірність утечок на 90%.
Приклад із практики: рефакторинг legacy-коду з категоріями
В одному проєкті ми знайшли category collision між двома бібліотеками: обидві перевизначали `-description` у `NSManagedObject`. Довелося перейменувати методи й додати префікс `app\_`. Витрати часу — 2 дні на діагностику та виправлення, економія — усунення нерегулярних крашів у 15% користувачів.Як мігрувати частину коду з Objective-C на Swift?
Поетапна міграція: додаємо Swift-файли в проєкт, використовуємо bridging header для взаємодії. Починаємо з ізольованих модулів без залежностей від ObjC. Поступово замінюємо ObjC-класи Swift-аналогами, залишаючи ObjC для частин з інтеграцією C++.
Важливо: не мігрувати все одразу — це збільшує ризик регресій. В одному проєкті ми мігрували 30% коду за 3 місяці, зберігши 99.9% стабільності.
Чому ObjC досі використовується у production?
Основна причина — стабільність і величезна кодова база. Багато застосунків із мільйонами користувачів (наприклад, банківські або корпоративні) написані на ObjC, і їхня підтримка дешевша та безпечніша, ніж повний перехід на Swift.
Середній бюджет розробки такого застосунку — вартість розраховується після аудиту, залежно від складності.
Архітектура та патерни
MVC — стандарт UIKit, але в ObjC він особливо схильний перетворюватися на Massive View Controller. Делегуємо логіку в окремі класи: нащадки NSObject як service layer, NSOperation/NSOperationQueue для керованої конкурентності, NSNotificationCenter для слабкозв'язаних подій.
Для мережевого шару використовуємо NSURLSession з completion handlers або Alamofire (через bridging). JSON-парсинг — NSJSONSerialization або Mantle.
Враховуємо специфіку iOS: push-повідомлення (APNs) вимагають реєстрації та обробки токенів, deep linking (Universal Links) — налаштування apple-app-site-association, in-app purchase (StoreKit 2) — перевірку коду підписки.
Налаштування code signing і provisioning profile — обов'язковий етап деплою, що автоматизується через Fastlane.
Процес розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз ТЗ | 1-2 дні | Документація, кошторис |
| Проєктування архітектури | 2-3 дні | Діаграми, опис |
| Розробка | 2-6 тижнів | Робочий код |
| Тестування | 1-2 тижні | Звіт, виправлення багів |
| Деплой в App Store | 3-5 днів | Застосунок у магазині |
Що входить у роботу
- Повний цикл розробки: від аналізу до публікації.
- Вихідний код і документація.
- Доступи до репозиторію та CI/CD.
- Навчання вашої команди (опціонально).
- Підтримка після запуску (2 тижні безкоштовно).
Ми дбаємо про ваш проєкт: 5+ років досвіду, 20+ реалізованих проєктів, сертифіковані інженери. Гарантуємо якість і дотримання термінів. Для оцінки вашого legacy-проєкту зв'яжіться з нашими інженерами — ми запропонуємо оптимальне рішення під ключ за 2 дні. Замовте розробку iOS-додатку на Objective-C і отримайте консультацію щодо міграції.
