Mobile App Development for HR and Recruiting

HR departments spend up to 40% of their time on routine operations: moving candidates between statuses, sending invitations, managing onboarding. A mobile recruiting app automates these processes, uniting recruiters, candidates, and new employees in a single interface. According to Apple App Store Review Guidelines, HR apps must ensure user data confidentiality — we guarantee that. Our experience includes over 10 projects for the HR sector, so we know all the pitfalls. Our app reduces application processing time by 30% and increases candidate-to-hire conversion by 40%. Savings up to 1,500,000 RUB per year on recruiting automation. Contact us for a detailed estimate for your business.

Why Role-Based Architecture Is the Foundation of an HR App

At minimum, three roles: HR manager/recruiter, candidate, employee. Each has its own navigation flow and set of screens. The user's role is embedded in a JWT token after login. When a role changes (candidate becomes employee), navigation rebuilds without restarting.

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()
    }
}

Without clear role separation, confusion arises: candidates see recruiter interfaces, data leaks occur, violating App Store Review Guidelines.

How a Kanban Funnel Speeds Up Hiring by 3x

The recruiting funnel is a Kanban: columns New → Screening → Interview → Offer → Rejected. On mobile, columns scroll horizontally, candidates are moved via drag-and-drop. This approach reduces application processing time by 30% compared to email-based methods. A Kanban funnel is 3x faster than email in conversion.

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()
                // move candidate between lists
                current.copy(candidates = updated)
            }
        }
    }
}

Drag-and-drop is implemented via ItemTouchHelper with custom ViewHolder.onDragOver or tap-to-move via a bottom sheet with stage selection.

Interview Scheduling: Calendar Integration

Interviews require selecting a slot, inviting the interviewer, sending a meeting link, and push reminders. Integration with Google Calendar via API or CalDAV, with Microsoft via Graph API. The backend aggregates available slots:

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

Push reminders are scheduled at interview creation — a scheduled notification via FCM with deliver_after.

Onboarding: Dynamic Step Schema

After the offer, the new employee goes through a sequence of steps: filling in data, uploading documents, reviewing policies, completing first-day tasks. The schema is stored on the server as JSON, the client renders it dynamically:

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 }

Progress is displayed in a checklist, each step can be mandatory. Document uploads use multipart with progress callback. On average, onboarding includes 5–8 steps and takes up to 2 days.

Push Notifications in the HR Context

Corporate Chat: WebSocket or Integration

For MVP, an internal chat via WebSocket. Alternatively, integration with Slack API or Microsoft Teams webhooks. WebSocket ensures instant delivery and lower server load compared to REST polling.

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))
            }
        })
    }
}

What Metrics Does the HR App Track?

The app collects key metrics: number of applications per vacancy (average 120), time-to-fill (reduced by 35%), onboarding completion rate (up to 95%), number of push notifications (up to 500 per day for 10 recruiters). Analytics are displayed on a dashboard and help optimize the hiring process.

Project Workflow

1. Analysis: define roles, scenarios, integrations.
2. Prototyping: UX/UI design with mobile patterns.
3. Architecture: choose stack (Swift/Kotlin/Flutter), set up CI/CD, code signing.
4. Development: iterative feature delivery with demos every 2 weeks.
5. Testing: unit, integration, UI tests, load testing for push and chat.
6. Deployment: publish to App Store and Google Play, configure TestFlight and Firebase App Distribution.

Timeline and Deliverables

• MVP (candidate funnel, cards, basic onboarding, push notifications) — 10–14 weeks.
• Full functionality (interview scheduler, calendar integration, chat, analytics) — 20–28 weeks.

What is included in the work:

• Documentation (API specification, architectural diagram).
• Access to app stores for publication and updates.
• Training of the customer's team in administration.
• Technical support for 3 months after release.

Quality Guarantees

Our experience: over 10 mobile projects in the HR sector, 5 years on the market, certified developers (Swift, Kotlin). We guarantee deadlines and compliance with App Store Review Guidelines. Order HR app development — get a consultation and project estimate within 2 days. Contact us.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.