Instabug Integration for Mobile App Bug Tracking

A tester finds a bug. They take a screenshot in Telegram and write a text description of what they did. The developer cannot reproduce—no logs, device info, or network requests. According to our data, up to 70% of bug‑fixing time is spent gathering context. Instead of back‑and‑forth, we integrate Instabug: shake‑to‑report, annotated screenshots, logs, device and session data. After integration, bug report processing time drops by 3–5 times. Instabug is 3–5 times faster than traditional debugging methods, reducing debugging costs by 60–70%. Our team, with 8+ years of mobile development experience and over 50 successful Instabug integrations, has served clients in FinTech, E‑commerce, and HealthTech since 2018. We offer a free project evaluation that guarantees a seamless setup—contact us.

Data automatically attached to a report

Instabug automatically captures up to 100 recent user steps (session replay), up to 50 network requests with headers and bodies, device info (model, OS, app version), and memory/CPU usage over the last 30 seconds. The tester only needs to describe what went wrong—within 5 minutes the developer sees the full picture. In 90% of cases, the report contains enough information to reproduce without further clarification. This comprehensive Instabug log collection is the cornerstone of effective mobile bug tracking.

Platform support comparison for Instabug

Problems Instabug solves

Instabug is indispensable when a bug only appears on a rare configuration: iOS 16.3 with locale en‑US or Android 12 with Cyrillic input. The developer immediately sees device info and logs. It is especially useful for network race conditions: Instabug saves all requests even if the connection drops. Our experience shows a 60–70% reduction in bug report time. For example, a FinTech client had a bug that only appeared on Android 12 with Cyrillic input in the amount field. Instabug captured device info and the network request—turns out the server returned 400 due to incorrect encoding. Without Instabug, debugging would have taken 2 days; with it, 2 hours. This proven debugging time reduction is why we recommend Instabug setup for all mobile apps.

How to integrate Instabug

Step 1: Add SDK to project

For iOS, use CocoaPods or SPM; for Android, Gradle. Instabug supports Swift 5.9+, Kotlin 1.9+, and Flutter/React Native via official plugins. For Android, add the following ProGuard rules to keep Instabug classes:

-keep class com.instabug.** { *; }

Step 2: Initialize with token

iOS (Swift):

// AppDelegate.swift
import Instabug

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    Instabug.start(withToken: "YOUR_APP_TOKEN", invocationEvents: [.shake, .screenshot])
    Instabug.welcomeMessageMode = .disabled  // remove onboarding for testers
    NetworkLogger.enabled = true
    return true
}

Android (Kotlin):

// Application class
override fun onCreate() {
    super.onCreate()
    Instabug.Builder(this, "YOUR_APP_TOKEN")
        .setInvocationEvents(InstabugInvocationEvent.SHAKE, InstabugInvocationEvent.SCREENSHOT_GESTURE)
        .build()
    NetworkLogger.setEnabled(true)
}

For intercepting network requests on Android—OkHttp interceptor:

val client = OkHttpClient.Builder()
    .addInterceptor(InstabugOkhttpInterceptor())
    .build()

Step 3: Configure obfuscation of sensitive data

Instabug logs network requests fully. If your API passes passwords or tokens in the body, configure a blacklist using NetworkLogger.addIgnoredURL with the endpoints that require masking. For finer control, implement a custom response sanitizer to mask specific fields. This sensitive data obfuscation prevents leakage of passwords, tokens, and personal data.

Step 4: Configure environments

Use separate tokens for Debug, Staging, and Release. Enable full logging and session replay in Debug, and only crash reports in Release. This reduces noise and speeds up critical bug detection.

Importance of configuring Instabug for your workflow

Without proper configuration, Instabug can clutter the dashboard with test reports. Setting up a report template with required fields (priority, component, steps to reproduce) is key to order. Integration with Jira, GitHub Issues, or Linear automatically creates tickets with attached logs. We configure the report template for your workflow and train the team. For example, Instabug Jira integration saves hours of manual ticket creation.

Instabug integration with your stack

Instabug adapts to your development cycle. We configure it for CI/CD: separate configs for Staging and Release, automatic enabling of NetworkLogger only for internal builds. This reduces noise and speeds up critical bug detection.

What's included in Instabug integration

• SDK installation and configuration for iOS / Android / Flutter / React Native
• Initialization setup for all environments (Debug, Staging, Release)
• Network request interception (OkHttp / URLSession)
• Obfuscation of sensitive fields (passwords, tokens)
• Integration with your bug tracker (Jira, Linear, GitHub Issues)
• Report template and custom invocation events configuration
• Documentation for the team on using Instabug
• Post-implementation support

Timelines and cost

Basic integration starts at $500 and takes from 1 day. Extended integration (with tracker integration, obfuscation, environment setup) costs up to $2500 and takes up to 5 days. Cost is calculated individually based on configuration complexity. Request a consultation—we will evaluate your project and propose the optimal solution. Our guaranteed process ensures you reduce debugging time by at least 3x.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.