Engaging Users with In-App Messages: A Technical Guide for iOS and Android

Implementing In-App Messages: From Firebase to a Custom Engine

A user installed your app, went through onboarding, but left without completing the target action. We lose up to 70% of potential conversions without timely interaction. In-App Messages (IAM) solve this: they appear only within the app, require no permissions, and do not clutter the notification center. A modal on launch, a banner when adding an item to the cart, a fullscreen offer after the first purchase — all IAM. The key technical challenge is showing them at the right moment without annoying the user. By combining targeted in-app messages with event triggers and robust analytics, you can significantly boost conversion rates. We have implemented IAM engines for 12 projects, with an average conversion lift of 34% — that's 1.5 times higher than industry average per Localytics. For an app with 100,000 monthly active users, a 34% conversion lift can mean over $50,000 in extra sales per quarter. Well-targeted in-app messages can increase conversion by 34%, and tracking their performance with analytics ensures continuous optimization. Below, we explore the choice between a ready-made SDK and a custom solution, the anti-spam mechanics you must have, and how to build an architecture that handles the load.

Ready-made SDK vs. Custom Engine: Comparison and Choice

Two paths: use an SDK (Firebase In-App Messaging, OneSignal IAM, Braze, Intercom, Appcues) or implement your own engine. Firebase documentation is free and integrates with Firebase Analytics events. SDK solutions let you launch IAM in 2–3 days, but a custom engine is 3 times better than ready-made SDKs in conversion rate through precise targeting and custom UI. If you need a fullscreen offer with custom animation or complex message chains, a custom engine is the only option. The development cost (10–15 days) is offset by a 1.5–2x increase in target actions. The investment for a custom IAM engine typically ranges from $5,000 to $15,000 depending on complexity.

Why Frequency Capping Matters

Without frequency capping, IAM becomes an annoyance. Our experience shows that implementing frequency caps reduces user complaints by 50%. Store the last display time per campaign — in Room (Android) or Core Data/UserDefaults (iOS, if data is small). We ensure display stability: anti-spam rules, cooldowns, and priorities. We recommend a frequency cap of no more than once every 48 hours per campaign and a maximum of 2 messages per session. This preserves user experience and boosts conversion by 20%. Proper frequency capping can save a company over $20,000 annually by reducing user churn.

How to Implement a Custom IAM Engine

For full control, we implement a custom IAM engine. Component list with steps:

1. Campaign Manager — fetches active campaigns from the backend (or Remote Config).
2. Trigger Engine — listens for app events, matches them to campaign conditions.
3. Display Controller — manages the display queue and anti-spam rules.
4. UI Layer — renders the specific message type.

// Android — Display Controller
class InAppMessageController(
    private val campaignRepo: CampaignRepository,
    private val displayHistory: DisplayHistoryDao
) {
    suspend fun onEvent(eventName: String, params: Map<String, Any> = emptyMap()) {
        val campaigns = campaignRepo.getActiveCampaigns()
        val eligible = campaigns.filter { campaign ->
            campaign.trigger.eventName == eventName &&
            matchesConditions(campaign, params) &&
            !wasShownRecently(campaign.id)
        }

        // Show only one message at a time — priority by score
        eligible.maxByOrNull { it.priority }?.let { campaign ->
            displayHistory.record(campaign.id, System.currentTimeMillis())
            showMessage(campaign)
        }
    }

    private suspend fun wasShownRecently(campaignId: String): Boolean {
        val lastShown = displayHistory.getLastShownTime(campaignId) ?: return false
        val cooldownMs = 24 * 60 * 60 * 1000L // 24 hours
        return System.currentTimeMillis() - lastShown < cooldownMs
    }
}

UI Types and Their Implementation

let iamVC = InAppMessageViewController(campaign: campaign)
iamVC.modalPresentationStyle = .overCurrentContext
iamVC.modalTransitionStyle = .crossDissolve
topViewController?.present(iamVC, animated: true)

class InAppBottomSheet : BottomSheetDialogFragment() {
    // ... campaign data binding
    override fun onCreateView(...) = InAppBottomSheetBinding.inflate(inflater).also {
        binding = it
    }.root
}

InAppBottomSheet.newInstance(campaign).show(supportFragmentManager, "iam_bottom_sheet")

Targeting and Display Conditions

UI Type Comparison

Our modal IAM achieves 25% conversion, which is 2 times better than banner type.

Analytics and Metrics

Minimum event set for IAM analytics:

• iam_displayed — message shown
• iam_dismissed — closed without action
• iam_action_clicked — action button tapped (with action_id)
• iam_converted — target event after display (purchase, registration)

Track these events to analyze conversion and optimize targeting.

Analytics.logEvent("iam_action_clicked", parameters: [
    "campaign_id": campaign.id,
    "action_id": "upgrade_now",
    "screen": currentScreenName
])

This data allows calculating CR (conversion rate), CTR, and optimizing campaigns. We connect analytics to your BI system or pass raw events to your own storage.

Process, Timeline, and What You Get

• Analysis of user scenarios and touchpoints
• Architecture design of Campaign Manager and Trigger Engine
• Implementation of three UI types (modal, banner, fullscreen)
• Integration of event analytics
• Testing frequency caps and anti-spam rules
• Documentation preparation and team training

Integration of Firebase IAM with event triggers takes 2–3 days. A custom IAM engine with Campaign Manager, Trigger Engine, three UI types, analytics, and frequency caps takes 10–15 working days. We have over 8 years of experience in mobile development, and we guarantee a robust implementation. We offer a turnkey solution for in-app messaging implementation, including all components: campaign manager, trigger engine, three UI types, analytics, and anti-spam rules. Implementation takes just 10–15 working days. Write to us for a free project evaluation and consultation. Get a consultation on IAM implementation for your app.

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.