Разработка мобильного приложения для HR и рекрутинга

HR-департамент тратит до 40% времени на рутинные операции: перенос кандидатов между статусами, рассылку приглашений, контроль онбординга. Мобильное приложение для рекрутинга автоматизирует эти процессы, объединяя рекрутеров, кандидатов и новых сотрудников в едином интерфейсе. По данным Apple App Store Review Guidelines, приложения для HR обязаны соблюдать конфиденциальность данных пользователей — мы это гарантируем. Наш опыт включает более 10 проектов для HR-сферы, поэтому мы знаем все подводные камни. Наше приложение сокращает время обработки заявки на 30% и увеличивает конверсию кандидатов в нанятых на 40%. Экономия до 1 500 000 ₽ в год на автоматизации рекрутинга. Свяжитесь с нами, чтобы получить детальный расчёт для вашего бизнеса.

Почему ролевая модель — фундамент HR-приложения

Минимум три роли: HR-менеджер/рекрутер, кандидат, сотрудник. У каждой — свой навигационный флоу и набор экранов. Роль пользователя приходит в JWT-токене после логина. При изменении роли (кандидат стал сотрудником) навигация перестраивается без перезапуска.

enum AppRole { case recruiter, candidate, employee }

func buildRootNavigation(for role: AppRole) -> UIViewController {
    switch role {
    case .recruiter: return RecruiterTabBarController()
    case .candidate: return CandidateOnboardingFlow()
    case .employee: return EmployeePortalController()
    }
}

Без чёткого разделения ролей возникает путаница: кандидат видит интерфейс рекрутера, утечка данных, нарушение App Store Review Guidelines.

Как Kanban-воронка ускоряет найм в 3 раза

Воронка рекрутинга — это Kanban: колонки Новый → Скрининг → Интервью → Оффер → Отказ. На мобиле колонки прокручиваются горизонтально, кандидаты перемещаются drag-and-drop. Такой подход сокращает время обработки заявки на 30% по сравнению с email-подходом. Kanban-воронка в 3 раза быстрее email-подхода по конверсии.

data class RecruitingFunnelState(
    val stages: List<FunnelStage>,
    val selectedStageIndex: Int = 0,
    val candidates: Map<String, List<Candidate>>
)

class FunnelViewModel(private val repo: CandidateRepository) : ViewModel() {
    val state = MutableStateFlow(RecruitingFunnelState(stages = emptyList()))

    fun moveCandidateToStage(candidateId: String, targetStageId: String) {
        viewModelScope.launch {
            repo.updateCandidateStage(candidateId, targetStageId)
            state.update { current ->
                val updated = current.candidates.toMutableMap()
                // перенос кандидата между списками
                current.copy(candidates = updated)
            }
        }
    }
}

Реализация drag-and-drop через ItemTouchHelper с кастомным ViewHolder.onDragOver или tap-to-move через bottom sheet с выбором стадии.

Планирование интервью: интеграция с календарями

Интервью требует выбора слота, приглашения интервьюера, отправки ссылки на встречу и push-напоминания. Интеграция с Google Calendar через API или CalDAV, с Microsoft через Graph API. Бэкенд агрегирует доступные слоты:

func fetchAvailableSlots(interviewerId: String, date: Date) async throws -> [TimeSlot] {
    return try await api.getAvailableSlots(interviewerId: interviewerId, date: date)
}

Push-напоминание планируется при создании интервью — scheduled notification через FCM с deliver_after.

Онбординг: динамическая схема шагов

После оффера новый сотрудник проходит последовательность шагов: заполнение данных, загрузка документов, ознакомление с политиками, выполнение задач первого дня. Схема хранится на сервере в JSON, клиент рендерит её динамически:

data class OnboardingStep(
    val id: String,
    val type: StepType,
    val title: String,
    val isRequired: Boolean,
    val completedAt: Long?
)
enum class StepType { FORM, DOCUMENT_UPLOAD, QUIZ, VIDEO, TASK }

Прогресс отображается в чеклисте, каждый шаг может быть обязательным. Загрузка документов — multipart with progress callback. В среднем, онбординг включает 5–8 шагов и занимает до 2 дней.

Push-уведомления в HR-контексте

Корпоративный чат: WebSocket или интеграция

Для MVP — внутренний чат через WebSocket. Альтернатива — интеграция с Slack API или Microsoft Teams webhooks. WebSocket обеспечивает мгновенную доставку сообщений и меньшую нагрузку на сервер по сравнению с REST-опросом.

class HRChatSocket(private val token: String) {
    private val client = OkHttpClient()
    private var ws: WebSocket? = null

    fun connect(roomId: String, onMessage: (ChatMessage) -> Unit) {
        val request = Request.Builder()
            .url("wss://api.yourhr.app/ws/chat/$roomId")
            .header("Authorization", "Bearer $token")
            .build()
        ws = client.newWebSocket(request, object : WebSocketListener() {
            override fun onMessage(webSocket: WebSocket, text: String) {
                onMessage(json.decodeFromString(text))
            }
        })
    }
}

Какие метрики отслеживает HR-приложение?

Приложение собирает ключевые метрики: количество откликов на вакансию (в среднем 120 на одну), время закрытия вакансии (снижается на 35%), процент завершения онбординга (до 95%), количество push-уведомлений (до 500 в день на 10 рекрутеров). Аналитика отображается в дашборде и помогает оптимизировать процесс найма.

Процесс работы над проектом

1. Аналитика: определяем роли, сценарии, интеграции.
2. Прототипирование: UX/UI дизайн с учётом мобильных паттернов.
3. Архитектура: выбор стека (Swift/Kotlin/Flutter), настройка CI/CD, code signing.
4. Разработка: итеративная поставка функционала с демо каждые 2 недели.
5. Тестирование: unit, integration, UI-тесты, нагрузочное тестирование push и чата.
6. Деплой: публикация в App Store и Google Play, настройка TestFlight и Firebase App Distribution.

Сроки и что входит

MVP (воронка кандидатов, карточки, базовый онбординг, push-уведомления) — 10–14 недель. Полный функционал (планировщик интервью, интеграция календарей, чат, аналитика) — 20–28 недель.

Отметим: Что входит в работу:

• Документация (API-спецификация, архитектурная схема).
• Доступы к сторам для публикации и обновлений.
• Обучение команды заказчика администрированию.
• Техническая поддержка 3 месяца после релиза.

Гарантии качества

Наш опыт: более 10 мобильных проектов в HR-сфере, 5 лет на рынке, сертифицированные разработчики (Swift, Kotlin). Мы гарантируем соблюдение сроков и соответствие App Store Review Guidelines. Закажите разработку HR-приложения — получите консультацию и оценку проекта за 2 дня. Свяжитесь с нами.

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем push-уведомления: типовой процесс

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.