Setting Up Watchdog Termination Monitoring in iOS Apps

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Setting Up Watchdog Termination Monitoring in iOS Apps
Medium
from 4 hours to 2 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

Your iOS app crashes without a crash log? Users complain, but Crashlytics stays silent. You've likely encountered Watchdog Termination — a system mechanism that forcibly terminates the app if the main thread hangs beyond a threshold (about 8 seconds on older iOS versions, ~4 seconds on newer ones). We configure detection for such incidents so you get full diagnostics and can eliminate the root cause. Over the years, we've identified dozens of projects where Watchdog Terminations went unnoticed, despite accounting for 2–3% of all sessions. Our basic Sentry setup costs $500–$1,000 with setup in 4–8 hours, and can save up to 5 hours per week on incident analysis. With 6+ years of iOS development experience and over 60 monitoring projects, we guarantee a quality setup.

Why standard crash reporters miss Watchdog Termination

Firebase Crashlytics does not register Watchdog Termination — it's neither an exception nor a signal. Sentry since version 8.0 can detect it via flags in UserDefaults (enable enableWatchdogTerminationTracking). MetricKit provides accurate data but with a delay of up to a day. The choice of method depends on your priorities: speed vs. accuracy. Apple Documentation: MXHangDiagnostic is the only official source for an accurate main thread stack trace at the time of the hang.

Method Speed of retrieval Stack accuracy Additional costs
MetricKit up to 24 hours High (callStackTree) Free (built into iOS)
Sentry minutes Medium (flag + main thread stack) Subscription to sentry.io
Custom detector real-time High (BSBacktraceLogger) Development and maintenance

For effective iOS force termination tracking, combine MetricKit and Sentry to monitor main thread hang.

How to choose a monitoring method?

If you need maximum accuracy for deep analysis, use MetricKit. It's free, but data arrives with a delay, making it unsuitable for quick response. If speed matters, Sentry provides information within minutes with sufficient accuracy. When you need real-time monitoring and a low trigger threshold (2–3 seconds), we build a custom detector based on DispatchQueue.main.async with feedback via BSBacktraceLogger. Sentry is 2 times faster than MetricKit in data retrieval, but stack accuracy is lower due to the absence of callStackTree.

How we set up monitoring: a real-world case

Our client from the fintech sector faced mass Watchdog Terminations after an app update. Engineers connected Sentry with a threshold of appHangTimeoutInterval = 2.5 seconds and discovered that in 70% of cases, the hang occurred in the processTransaction method on the main thread due to a synchronous CoreData write. We moved the write to a background context — the incident frequency dropped by 90%. We additionally configured MetricKit for confirmation — the data matched.

Recommendations for choosing the trigger threshold

For apps with heavy interfaces (e.g., animations), the threshold should be lowered to 2–3 seconds. For financial apps, where every millisecond counts, 1–2 seconds. Use A/B testing before rolling out.

Implementing a custom detector (if you need speed)

final class WatchdogDetector {
    private let queue = DispatchQueue(label: "watchdog.monitor", qos: .utility)
    private var pingTime: Date = Date()
    private let threshold: TimeInterval = 3.0

    func start() {
        scheduleMainThreadPing()
        scheduleBackgroundCheck()
    }

    private func scheduleMainThreadPing() {
        DispatchQueue.main.async { [weak self] in
            self?.pingTime = Date()
            self?.scheduleMainThreadPing()
        }
    }

    private func scheduleBackgroundCheck() {
        queue.asyncAfter(deadline: .now() + 1.0) { [weak self] in
            guard let self = self else { return }
            let elapsed = Date().timeIntervalSince(self.pingTime)
            if elapsed > self.threshold {
                self.captureHang(duration: elapsed)
            }
            self.scheduleBackgroundCheck()
        }
    }

    private func captureHang(duration: TimeInterval) {
        // Use BSBacktraceLogger to capture main thread stack trace
        BacktraceLogger.backtrace(for: .main) { frames in
            SentrySDK.capture(error: NSError(
                domain: "WatchdogHang",
                code: Int(duration * 1000),
                userInfo: [
                    NSLocalizedDescriptionKey: "Main thread hung for \(duration)s",
                    "stackFrames": frames
                ]
            ))
        }
    }
}

Thread.callStackSymbols captures the stack trace of only the current thread. For the main thread, use BSBacktraceLogger or PLCrashReporter.

What the setup includes (deliverables)

  • Installation and configuration of a MetricKit subscriber to receive MXHangDiagnostic
  • Integration of Sentry with enableWatchdogTerminationTracking enabled and optimized threshold
  • If needed, development of a custom detector with a low threshold (from 2 seconds)
  • Setting up alerts in Sentry or your monitoring system for a rise in Watchdog Termination Rate
  • Analysis of callStackTree and identification of bottlenecks (synchronous operations on the main thread)
  • Documentation of the monitoring setup and integration instructions
  • Access to monitoring dashboards and configuration
  • Training session for your team (up to 2 hours)
  • Support for 1 month post-deployment

Typical sources of Watchdog Termination (and what to do about them)

Problem Solution
Synchronous CoreData fetch in viewDidLoad Offload the request to a background context
DispatchSemaphore.wait() without timeout on the main thread Use async-await or a timeout
Deadlock between @MainActor and synchronous Swift Concurrency code Avoid blocking the actor
Heavy JSON decode in an URLSession closure Switch thread using dataTask with qos: .userInitiated

Process of work

  1. Analysis — we study the current architecture, iOS versions, typical scenarios. We collect metrics via MetricKit (if already used).
  2. Design — we choose the optimal stack: MetricKit + Sentry / Sentry only / custom + Sentry. We determine trigger thresholds.
  3. Implementation — we write and integrate code, test on a simulator and real devices with different iOS versions.
  4. Testing — we simulate hangs (e.g., via sleep(10) on the main thread) and verify that the detector triggers and sends diagnostics.
  5. Deployment — we roll out via TestFlight, monitor initial data, and adjust thresholds as needed.

Timeline and cost

Basic setup via Sentry: 4–8 hours ($500–$1,000). MetricKit integration with sending diagnostics to your server: 1–2 days ($1,500–$3,000). Full cycle with a custom detector and analysis: from 3 days ($4,000–$7,000). The cost is calculated individually — contact us for a project assessment. Get a consultation — we'll help reduce Watchdog Termination frequency and improve user experience. With 6+ years of iOS development experience and over 60 monitoring projects, we guarantee a quality setup.

Mobile App Analytics: Firebase, Amplitude, AppsFlyer and Attribution

Our team regularly encounters projects where analytics is already "set up" but yields no real insights. A typical example is a startup with 50k DAU: tracking dozens of events without a single answer to the question "why don't users reach payment?". In two weeks we built a basic funnel and found that 70% of users drop off at the phone number verification screen. After fixing the bug, retention increased by 12%. The takeaway: analytics should start with specific questions, not tracking everything indiscriminately.

Why Event Taxonomy is the Foundation of Mobile App Analytics?

Firebase Analytics, Amplitude, Mixpanel — technically similar. The difference lies in what you put into them. A common mistake: events like screen_view, button_tap_1, button_tap_2 without context. A month later, no one remembers what button_tap_2 means.

Proper taxonomy: object + action + context. product_viewed, checkout_started, payment_completed with parameters product_id, category, price, source. This allows building funnels, cohort analysis, and retention without additional tracking.

We document the naming convention in a tracking plan — a document (Google Sheet or Amplitude Data Catalog) describing every event, its parameters, and triggering conditions. The tracking plan is synced with the analytics team before development begins, not after. This approach ensures that data remains interpretable months later and doesn't become a dump. Experience from 50+ projects confirms: without a tracking plan, analytics maintenance costs increase 2-3 times due to rework.

What Should You Choose for Mobile App Analytics: Firebase, Amplitude, or Mixpanel?

The table below highlights key differences between the three popular platforms. Choice depends on budget, traffic, and tasks.

Criteria Firebase Analytics Amplitude Mixpanel
Free limit Unlimited (Spark plan) Up to 10M events/month Up to 1K MTU/month (Special)
Data latency Up to 24 hours (standard) Minutes (real-time) Minutes (real-time)
Funnels and cohorts Basic funnels, limited count Deep funnels, Journeys, cohorts Funnels, Retention, Insights
BigQuery export Yes (free, raw data) Yes (subscription) Yes (Enterprise)
Session Replay No Yes (iOS/Android SDK) No
Ad integration Google Ads (native) Via Universal Links Via partners

Firebase Analytics — free, deep integration with Google Ads, BigQuery export for raw data. Limitations: data latency up to 24 hours, limited funnels. For startups with Google Ads traffic, it's the first choice.

Amplitude — product analytics focused on cohorts and user journeys. Journeys (formerly Pathfinder) shows actual paths between events — not assumed funnels but real routes. Session Replay records sessions for UX analysis. The free tier up to 10M events/month is enough for most products at launch.

Mixpanel — close to Amplitude, stronger in real-time segmentation. Insights, Funnels, Retention cover 90% of product analysts' tasks.

How to Solve Multi-Channel Attribution with AppsFlyer?

Knowing where a user came from is a separate task. Firebase Attribution works only within the Google ecosystem. For multi-channel attribution (Facebook Ads, TikTok, Apple Search Ads, programmatic), an MMP (Mobile Measurement Partner) is needed.

AppsFlyer is the market leader. OneLink — universal deep link working on iOS and Android, correctly attributing installs from any channel. Protect360 — built-in fraud protection (fake installs, click injection on Android). Adjust and Branch are competitors with similar features. Branch excels in deep linking; Adjust is popular in gaming.

According to Apple, with iOS 14.5, apps must obtain user permission via ATT before collecting IDFA for tracking. AppsFlyer uses probabilistic matching (IP + user agent + timing) for these users — accuracy is lower but better than nothing. SKAdNetwork and Privacy Preserving Attribution provide aggregated data from Apple with a 24-72 hour delay.

How to Set Up Crash Analytics to Not Miss Bugs?

Firebase Crashlytics is the standard for crash reporting. It automatically groups crashes by stack trace, shows affected users %, and sends velocity alerts when crash rate increases by more than 10% per hour.

Important: symbolication. On iOS, .dSYM files must be automatically uploaded with each build — via Fastlane upload_symbols_to_crashlytics or Xcode Cloud built-in. Without symbols, crashes in Crashlytics appear as memory addresses. This happens more often than expected when switching to a new CI — in one project with 500k users, we found that 40% of crashes remained unsymbolicated due to a missing CI/CD step. After automation, bug response time dropped from 3 hours to 15 minutes.

For React Native and Flutter, @sentry/react-native and sentry_flutter provide additional context: breadcrumbs, network requests before the crash, Redux/Provider state.

Below is a comparison of popular crash analytics tools to choose according to your needs.

Criteria Firebase Crashlytics Sentry Instabug
Free limit Unlimited (Spark) 5k events/month 250 MAU
Grouping By stack trace + parameters By fingerprint By stack trace + metadata
Symbolication Automatic (via file) Automatic (via CLI) Automatic
Velocity alerts Yes (by % change) Yes (by count) Yes (by threshold)
Extra context Logs, Keys, Custom Keys Breadcrumbs, User, Tags User steps, network requests
Price Free (in Firebase) Paid plans available Paid plans available

Environment Setup

Three environments with separate Firebase projects: dev, staging, production. Mixing analytics from test sessions and production is a common mistake that skews all metrics. On iOS via GoogleService-Info.plist per scheme, on Android via google-services.json in each flavor folder.

Timelines: basic analytics with Firebase + Crashlytics — 3-5 days. Full tracking plan + Amplitude/Mixpanel with funnels and cohorts — 2-3 weeks. Attribution via AppsFlyer with deep linking and fraud protection — 1-2 weeks. Cost is calculated individually based on integration complexity.

What Is Included in Our Work

As part of analytics implementation, we provide:

  • Development and approval of a tracking plan with product and marketing teams.
  • SDK integration (Firebase, Amplitude, Mixpanel, AppsFlyer) considering your stack (Swift/Kotlin/Flutter/React Native).
  • Setup of funnels, cohorts, dashboards, and alerts.
  • Automation of symbolication and .dSYM upload via Fastlane.
  • Documentation of events and parameters.
  • Team training on the analytics platform.
  • Two weeks of post-release support and tracking adjustments.

Our experience: 7 years of analytics implementation and over 80 successful projects in mobile development. We guarantee data correctness and transparency at every stage.

Contact us for a consultation on setting up analytics for your app. Request an audit of your current analytics — and we will show you which metrics you are losing.