Розробка мобільного додатку для цифрової візитівки (vCard)

Цифрова візитівка перестала бути просто електронним аналогом паперової картки. Сучасний користувач очікує, що додаток дозволить обмінятися контактами одним дотиком через NFC, відсканувати QR, зберегти візитівку в адресну книгу без зайвих кліків і при цьому залишатися в брендовому стилі компанії. Ми вирішуємо ці завдання комбінацією нативних технологій: генерація vCard 3.0/4.0, робота з CoreNFC та AVFoundation, налаштування deep link'ів та збір аналітики. За понад 5 років ми запустили більше 20 мобільних проєктів у сфері цифрових контактів, включаючи інтеграції з CRM та корпоративними системами. Гарантуємо коректну роботу на всіх пристроях під керуванням iOS 15+ та Android 10+. Отримайте консультацію щодо вашого проєкту.

Як генерувати vCard та імпортувати в контакти?

vCard — відкритий стандарт обміну контактними даними, підтримуваний всіма сучасними ОС. На iOS використовуємо CNMutableContact + CNContactVCardSerialization, на Android — ContactsContract або ручну генерацію рядка. Приклад vCard для профілю:

BEGIN:VCARD
VERSION:3.0
FN:Іван Петров
ORG:Назва компанії
TEL;TYPE=CELL:+79001234567
EMAIL:[email protected]
URL:https://mycard.app/ivan
PHOTO;ENCODING=b;TYPE=JPEG:/9j/...base64...
END:VCARD

Імпорт в системні контакти: iOS — виклик CNContactStore.add(_:toContainerWithIdentifier:) із запитом дозволу Contacts; Android — Intent(ContactsContract.Intents.Insert.ACTION) з попередньо заповненими полями (без дозволів — користувач підтверджує). Важливо: на iOS запит доступу відбувається лише один раз, тому обробляємо відмову через налаштування.

Чому vCard-файл кращий за пряме посилання?

Пряме посилання відкриває веб-сторінку або додаток, але не зберігає контакт автоматично. vCard можна завантажити одним натисканням, і він одразу потрапляє в адресну книгу. Для кроссплатформової передачі використовуємо vCard 4.0 з підтримкою фото та декількох телефонів. При цьому посилання на профіль також генерується — воно використовується в QR та NFC.

Як реалізувати QR-код?

Генерація QR з URL профілю — вбудованими засобами: CIFilter.qrCodeGenerator на iOS (без залежностей), ZXing або QRose на Android, qr_flutter у Flutter. Розмір QR в UI — мінімум 200x200 dp. Важливо: QR має вести на HTTPS-посилання з deeplink, а не на vCard-файл — інакше сканування стандартною камерою не відкриє додаток. Сканування реалізовано через AVFoundation на iOS та CameraX + ML Kit BarcodeScanning на Android. Дозвіл — тільки NSCameraUsageDescription на iOS. При скануванні вилучаємо посилання, перевіряємо редирект на deep link додатку.

NFC-шеринг: коли одного дотику достатньо

NFC забезпечує обмін одним дотиком без камери — достатньо піднести пристрої. На iOS використовуємо CoreNFC з NDEF-записом. Приклад запису URI:

let session = NFCNDEFReaderSession(delegate: self, queue: nil, invalidateAfterFirstRead: false)
session.begin()
// У delegate:
func readerSession(_ session: NFCNDEFReaderSession, didDetect tags: [NFCNDEFTag]) {
    let payload = NFCNDEFPayload.wellKnownTypeURIPayload(url: URL(string: "https://mycard.app/ivan")!)!
    let message = NFCNDEFMessage(records: [payload])
    tags.first?.writeNDEF(message) { error in ... }
}

Читання — аналогічна сесія. Обмеження: запис доступний з iPhone 7 (iOS 13+), фонове читання з універсальними посиланнями — з iOS 14+. На Android — NfcAdapter, NdefMessage, NdefRecord.createUri. Android Beam (deprecated) і прямий запис на фізичні теги NTAG213/215. P2P-обмін між двома Android через setNdefPushMessage. Докладніше див. CoreNFC.

Порівняємо способи обміну:

Порівняємо версії vCard:

Профіль та редактор візитівки

Поля: ім'я, посада, компанія, декілька телефонів, email, сайт, соцмережі, аватар, фон картки. Аватар завантажується через presigned S3 URL, зберігається в CDN. На картці відображається через URLSession/Coil/CachedNetworkImage з placeholder. Дизайн — шаблони з вибором теми/кольору або кастомний редактор (окрема задача на 3–5 днів).

Що входить в розробку під ключ

• Мобільний додаток під iOS та Android (нативні або React Native/Flutter)
• Серверна частина: генерація посилань, аналітика (перегляди, завантаження vCard)
• Інтеграція NFC-запису та читання, генерація QR
• Налаштування deep link'ів (Universal Links / App Links) та Open Graph тегів
• Підготовка до публікації в App Store та Google Play (з урахуванням App Store Review Guidelines)
• Документація з експлуатації та навчання команди
• Гарантійна підтримка після запуску

Строки та вартість

Базовий додаток (профіль, QR, посилання, експорт в контакти) — від 3 до 5 днів. З NFC-записом та читанням — плюс 1–2 дні. Повний цикл з кастомним дизайном та серверною аналітикою — від 2 тижнів. Вартість розраховується індивідуально після аналізу вимог. Зв'яжіться з нами для оцінки проєкту — підберемо оптимальне рішення за 1 день. Замовте демо-версію додатку для тестування.

Розробка чатів та соціальних функцій: чат, VoIP, стрічка та реакції

Ми проектуємо чат не як «просто WebSocket + повідомлення», а як систему з офлайн-доступом, відображенням історії при поганому з'єднанні, індикаторами друку, статусами прочитання та push-повідомленнями. Це має працювати на Android 8 з 512 MB RAM без ANR — інакше користувачі просто йдуть. Ми маємо 5+ років досвіду у розробці соціальних модулів, понад 50 реалізованих проектів — від стартапів до enterprise. Розробка чатів — наш ключовий напрям.

Як ми підходимо до розробки чатів?

Вибір протоколу та сховища — перша точка, де помиляються. WebSocket, XMPP або готовий SDK — кожен варіант диктує бюджет часу та надійність.

Як обрати протокол для чату?

• Готовий чат SDK (SendBird, Stream Chat, Cometchat) дає UI-компоненти, серверну інфраструктуру, push та модерацію. Швидко, надійно, але vendor lock-in та recurrent costs. Для MVP — оптимально. Ліцензія SendBird для проекту з 10К користувачів — ~$400/міс.
• Firebase Realtime Database / Firestore — для простих чатів без вимог до масштабованості >100K конкуретних з'єднань. Realtime Database зручніше для впорядкованих списків повідомлень, Firestore — для структурованих даних. Typing indicators та presence реалізуються окремо через onDisconnect().
• Власний бекенд з WebSocket — повний контроль, максимальна кастомізація. Стек: Node.js + socket.io або Phoenix Channels (Elixir), PostgreSQL + Redis для pub/sub. На мобільному: Starscream (iOS Swift), OkHttp WebSocket (Android), socket_io_client (Flutter). Час розробки в 2–3× більше, але zero vendor risk. Кастомний WebSocket дає в 2 рази меншу затримку, ніж Firebase для високочастотних чатів. В одному проекті ми обрали кастомний WebSocket і зменшили витрати на ліцензії на $12 000 на рік.

Чому важливо продумувати офлайн-режим заздалегідь?

Офлайн-режим — найтрудомісткіша частина чату. Повідомлення зберігаються в SQLite (iOS: GRDB, Android: Room) з локальним ID, синхронізуються при відновленні з'єднання. Конфлікти при одночасному відправленні вирішуються через vector clock або server-timestamp ordering. Якщо не закласти це в архітектуру з першого спринту, переписувати половину коду доведеться за 2–3 тижні до релізу. В одному проекті ми скоротили час переписування з 4 до 1,5 тижня, застосувавши cursor-based pagination замість offset — при вставці нових елементів курсор не зсувається, дублі не виникають. Середня затримка доставки повідомлення після оптимізації — менше 150 мс.

VoIP: CallKit, ConnectionService та WebRTC

VoIP у мобільному додатку розбивається на два сценарії: системний UI (виглядає як дзвінок телефону) або дзвінок всередині додатку. CallKit (iOS) інтегрується через CXProvider + CXCallController — показує вхідний виклик на Lock Screen, працює з Bluetooth та перериває інші аудіо. Додаток запускається через VoIP push (PKPushKit) навіть коли вбито.

На Android аналог — ConnectionService API. Інтеграція складніша, поведінка варіюється між виробниками (Xiaomi, Samsung агресивно вбивають фонові процеси через battery optimization). WebRTC — транспорт для P2P медіа. Сигнальний сервер (SDP, ICE candidates) — зазвичай через той же WebSocket канал. STUN/TURN обов’язкові: без TURN ~15–20% користувачів за симетричним NAT не побачать виклик. coturn — open source рішення, Twilio NTS та Metered TURN — managed.

Стрічка та реакції

Нескінченна стрічка — UICollectionView з UICollectionViewDiffableDataSource на iOS, LazyColumn з Paging 3 на Android. Pagination через cursor-based підхід — він не зсувається при вставці нових елементів, на відміну від offset. Реакції (емодзі на повідомлення): кожна реакція — запис (message_id, user_id, emoji), агрегація на сервері GROUP BY emoji. WebSocket-подія reaction_added оновлює лічильник у реальному часі. Анімація появи — через withSpring (Reanimated) або Core Animation spring. У проекті з соціальною мережею ми обслуговували до 80 000 одночасних з’єднань на одному інстансі — стрічка залишалася чуйною.

Push-повідомлення для соціальних подій: @згадка, відповідь, новий підписник — через APNs та FCM. Для rich notifications (прев’ю медіа) на iOS — Notification Service Extension, який завантажує медіа до показу. Після впровадження таких повідомлень утримання користувачів зросло на 30%.

Що входить в роботу: повний список deliverables

Ми постачаємо не тільки код — ось повний перелік того, що ви отримуєте:

1. Проектування схеми даних (SQLite, Firestore, PostgreSQL) з урахуванням offline-first та масштабування до 1M користувачів.
2. Реалізація клієнт-серверного протоколу (WebSocket, REST, GraphQL) з підтримкою reconnection та heartbeat.
3. Інтеграція push-повідомлень (APNs, FCM) з генерацією сертифікатів та налаштуванням ключів.
4. Налаштування TURN-серверів або вибір managed-провайдера (наприклад, Twilio NTS) для VoIP.
5. Документація API та схема міграцій (включаючи rollback-план).
6. Доступ до репозиторію, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
7. Навчання команди (code review перших 2 спринтів) та передача знань.
8. On-call підтримка протягом 2 тижнів після релізу.

Типові помилки при розробці чатів та як їх уникнути

• Відсутність reconnection стратегії. Клієнт просто відключається без черги невідправлених повідомлень. Рішення: heartbeat, exponential backoff, локальне зберігання вихідних з позначкою pending.
• Offset пагінація в стрічці. При вставці нових постів користувач бачить дублі. Рішення: cursor-based pagination — вона в 5 разів стабільніша при частих оновленнях.
• Ігнорування battery optimization на Android. ConnectionService не доживає до вхідного виклику. Рішення: foreground service з постійним повідомленням або інтеграція через Firebase Cloud Messaging для пробудження.
• Голий WebSocket без протоколу поверх. Це винахід велосипеда. Використовуйте platform-agnostic JSON або MessagePack з type-флагом.

Стек технологій, що використовується в типовому проекті:

• iOS: Swift 5.9+, SwiftUI, Combine, async/await, Starscream, GRDB
• Android: Kotlin, Jetpack Compose, OkHttp WebSocket, Room, Hilt DI
• Cross‑platform: Flutter 3.x (Dart) або React Native (TypeScript)
• Backend: Node.js + socket.io або Phoenix (Elixir) + PostgreSQL + Redis
• Push: APNs / FCM з сертифікатами та ключами
• VoIP: WebRTC + coturn TURN server

⏱ Терміни орієнтовно

Вартість розраховується індивідуально після аналізу вашого технічного завдання та існуючої архітектури. Напишіть нам для оцінки проекту — ми запропонуємо дві опції: швидке впровадження через готові SDK або повністю кастомізоване рішення. Отримайте консультацію та точний кошторис протягом 2 робочих днів. Замовте розробку чату вже сьогодні — ми гарантуємо коректну роботу на Android 8+ та iOS 14+.