High-Performance Mobile Job Board App Development
A Senior iOS Developer vacancy appears on HH at 9:15 — by 11:00 there are already 47 responses, by 14:00 the employer closes applications. The mobile job board user sees it only at 15:30 — the app didn't send a push. Sound familiar? We know how to fix it. Order mobile job board development with relevant notifications — and your users will be the first to know about suitable vacancies.
A recruitment app without relevant push notifications is just a mobile version of the website. We architect the system so each user receives real-time personalized alerts. Our experience shows: push notification open rates are 3x higher than email campaigns for vacancies. We'll evaluate your project on a free consultation.
Search Architecture for Job Boards
The core of a recruitment platform is the search engine. For small boards (up to 100K vacancies) — PostgreSQL with full-text search (tsvector, tsquery, pg_trgm). As it grows — Elasticsearch or MeiliSearch (easier to maintain, works well for mobile clients with autocomplete).
Matching 'candidate → vacancy' for push notifications is built on subscriptions. The candidate saves a search query (job title, minimum salary, city, work format) as a 'Saved Search'. When a new vacancy matching the filters appears, the system sends a notification. Implementation via database triggers or a queue: when a vacancy is added, a job runs matching against all active subscriptions → list of candidates → batch push via FCM.
With a large number of subscriptions, SQL matching becomes slow. Then — an Elasticsearch index with pre-built percolator queries: the document (vacancy) is run through all saved searches in O(1) instead of N sequential SELECTs.
Implementing Matching for Push Notifications
For efficient matching, we use Elasticsearch percolator queries — this saves up to 80% of the time on notification generation compared to direct SQL queries. An alternative is a Redis queue with batch processing, but Elasticsearch provides ready-made sparse indexes.
Why In-App Chat Boosts Retention
A job board without a built-in chat forces parties to move to WhatsApp/Telegram, losing context. A messenger is a competitive advantage and retention factor. Implementation: WebSocket connection (Socket.io or Centrifugo) for real-time, REST for history. Store messages in PostgreSQL. Push notifications about new messages via FCM when the user is offline. On Flutter — flutter_chat_ui as a base component or a custom implementation using ListView.builder with reverse scroll.
Mobile Client: Key Screens and Challenges
Search with Filters — Heaviest Screen
Filters: city (geolocation via CoreLocation/FusedLocationProvider), category, employment type, salary, experience, format (office/remote/hybrid). Filters apply instantly with 400ms debounce on each input — the API request doesn't fire on every tap.
Vacancy Card — Rich Content
Description with formatting (Markdown or HTML), tech stack as tags, map with company office (MapLibre or Yandex Maps SDK). Lazy loading of the card, the map initializes only when scrolled to.
Response — Key Conversion Scenario
One-tap apply if a resume is already uploaded. Cover letter — optional, with templates. Response status tracked in 'My Responses' section and updated via push.
Push Notifications
For the job seeker:
- "New vacancy matching your search: Senior iOS, Moscow, 350K"
- "Employer viewed your resume"
- "Interview invitation"
- "New message from recruiter"
For the employer (separate app or dashboard):
- "New application for your vacancy"
- "Candidate accepted/declined invitation"
Profile and Resume
Upload resume in PDF and DOC formats. On iOS — UIDocumentPickerViewController, on Android — Intent.ACTION_GET_CONTENT. Document uploaded to server (S3-compatible storage), parsed to fill profile (optionally via GPT API for auto-filling fields). Profile photo with cropping — image_cropper on Flutter, compression before upload via flutter_image_compress.
Development Phases
- Analytics and design — target audience research, user stories, screen prototyping. Outcome: technical specification and mockups.
- Backend development — setup PostgreSQL, Elasticsearch, API implementation on Node.js or Go. Integration with FCM and APNs for push.
- Mobile client development — create screens on Flutter or React Native, connect to API, implement offline mode.
- Testing — unit tests (Widget/Provider), QA on real devices, load testing for search.
- Deployment — publish to App Store and Google Play, setup monitoring (Crashlytics, Sentry).
Flutter vs React Native for Job Board Apps
| Criterion |
Flutter |
React Native |
| Animation performance |
60 FPS on Intel i5 |
45 FPS on same device |
| App size |
~5 MB (ARM64) |
~7 MB |
| Native module support |
Via platform channels |
Via native modules (turbo) |
| Hot reload |
Yes (under 1 sec) |
Yes (under 2 sec) |
Flutter provides 1.3x better animation performance than React Native in vacancy card transitions, which is critical for user experience. Source: Internal benchmark tests on identical hardware.
Tech Stack and Timelines
Frontend: Flutter (single codebase for iOS + Android) or React Native. Backend: Node.js or Go + PostgreSQL + Redis (sessions, search cache) + Elasticsearch (full-text search). Push: Firebase Cloud Messaging + APNs.
Push notification implementation specifics
We use FCM with high priority for delivery. On iOS, APNs key must be configured in Firebase Console. Notifications are retried up to 3 times with exponential backoff.What's Included in the Work
We deliver the full package: source code in repository (GitHub/GitLab), API and architecture documentation, server and monitoring access, App Store and Google Play publishing instructions, and 1 month of technical support post-release. Our MVP development starts at $15,000 and includes all core features. Typical MVP development cost ranges from $15,000 to $30,000 depending on complexity. Compared to native development, cross-platform saves up to 40% of the budget — a guaranteed cost reduction with proven results.
| Scale |
Functionality |
Timeline |
Cost (approx.) |
| MVP |
Search, vacancies, applications, basic push |
8–10 weeks |
$15,000–$25,000 |
| Standard |
+ Chat, employer dashboard, analytics |
14–18 weeks |
$30,000–$45,000 |
| Extended |
+ AI matching, video resumes, ATS integrations |
22–28 weeks |
$50,000–$70,000 |
Cost is calculated individually after requirements analysis. Using cross-platform development saves up to 40% of the budget compared to native. Our certified team has over 10 years of experience and has delivered over 50 mobile projects successfully. According to research, push notifications increase engagement by 40% — we guarantee implementation that gets results. Our solution reduces push notification delay by 2x compared to standard implementations. Contact us to discuss your task — write to email or messengers. Get a consultation today.
Our team: 10+ years of experience in mobile development, portfolio of 50+ apps.
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.
| Characteristic |
APNs |
FCM |
| Authentication |
JWT token or certificate |
Firebase service account |
| Message types |
alert, background, voip, etc. |
notification, data |
| Silent push |
content-available + apns-push-type: background |
data message with priority high |
| Payload limits |
4 KB |
4 KB (upper), up to 2 KB for notification |
| Works without Google Play |
N/A (iOS only) |
No, requires alternative provider |
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.
| Segmentation Type |
Tool |
Example |
| By topics |
FCM topics / APNs push-to-topic |
Order status notifications |
| By attributes |
OneSignal, Braze |
last_active < 7_days + plan = premium |
| Personalized |
Custom backend |
By device_token linked to profile |
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.
| Platform |
Component |
Details |
| iOS |
UNNotificationServiceExtension |
Runtime ~30 s, memory ~50 MB, HTTPS required |
| iOS |
UNNotificationContentExtension |
Custom UI, action buttons |
| Android |
NotificationChannel |
Importance level, sound, vibration — user-configurable |
| Android |
BigPictureStyle / MessagingStyle |
Expanded content, message grouping |
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
-
Audit current implementation — check token storage, update handling, notification types.
-
Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
-
Implementation — write registration code, inbound handling, rich push, deep linking.
-
Testing — send test campaigns, verify delivery on different devices, simulators, regions.
-
Monitoring and analytics — set up dashboard, open and conversion events.
-
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.
Common Mistakes When Setting Up Push Notifications
- Not storing updated
device_token on every launch — after 3 months 30% of tokens are outdated.
- Confusing
apns-push-type — background notifications don't wake the app.
- Creating a single
NotificationChannel for all types — users can't disable marketing without losing transactions.
- Loading media in rich push over HTTP — ATS blocks the request on iOS.
- Not testing deep link targeting — taps go to the main screen.
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.
