9 posts tagged with "crash"

In local development, diagnosing a memory leak is a solved problem.

You fire up Android Studio Memory Profiler or Xcode Instruments Allocations, attach a debugger, record a trace, inspect the object graph, or let LeakCanary dump a heap snapshot. Within minutes, you can pinpoint the exact retain cycle or static reference pinning an Activity or UIViewController in RAM.

In production, that luxury vanishes.

Running a heap dump in a live production app is an engineering non-starter. A standard Android heap dump (Debug.dumpHprofData()) freezes the main thread for 10 to 30 seconds, creates an uncompressed 500MB+ .hprof file on user storage, risks exfiltrating unredacted Personally Identifiable Information (PII), and frequently triggers operating system watchdogs. On iOS, you cannot capture memory graphs or attach Instruments to App Store binaries at all.

Even worse, Out-Of-Memory (OOM) events are the most silent killers in mobile engineering.

When an iOS device runs out of physical RAM, Apple's Jetsam kernel daemon terminates your process with a SIGKILL. On Android, the LowMemoryKiller daemon (lmkd) sends a silent kill to reclaim pages.

Neither operating system gives your application time to execute an uncaught exception handler. Traditional crash reporting SDKs register zero crash logs. To your backend and analytics dashboards, the user simply disappeared - or worse, the app restarts cleanly on next launch, disguising catastrophic memory exhaustion as ordinary user session churn.

Here is how modern engineering teams move beyond development-only profilers to implement Production Memory Diagnostics - tracking runaway allocations, memory leaks, and OS termination events without degrading app performance.

Production Memory Diagnostics is the practice of continuously monitoring runtime memory health (Resident Set Size, dirty physical footprint, system memory pressure warnings, and screen-by-screen memory deltas) on live user devices without capturing heavy heap dumps. By correlating memory growth with user journeys and lifecycle events, production diagnostics identify retain cycles, native cache bloat, and LowMemoryKiller (LMK)/Jetsam terminations before they cause silent churn.

The Anatomy of Silent Memory Kills​

To diagnose production memory issues, you must first understand how modern mobile operating systems enforce memory limits and terminate processes.

1. iOS: The Jetsam Mechanism (FOOM)​

iOS devices operate without a traditional disk swap file. To manage memory pressure, iOS relies on memory compression and aggressive process termination enforced by the kernel daemon memorystatus (commonly known as Jetsam).

When an app's dirty physical memory footprint crosses the system limit (which varies by device model and memory tier - often between 1.2GB and 2.2GB on modern iPhones, but as low as 350MB on older iPads or memory-constrained extensions), Jetsam sends an uncatchable SIGKILL.

The Virtual Memory Trap​

Many developers attempt to track memory in Swift by reading task_basic_info.virtual_size. This metric is virtually useless: virtual size includes clean mapped read-only files (such as .dylib frameworks and asset catalogs) that the OS can evict at zero cost.

Jetsam only cares about Physical Footprint - dirty pages that cannot be compressed or paged out.

Low-Overhead Physical Footprint Telemetry in Swift​

To capture actual memory pressure in production, you must query the Mach kernel's task_vm_info:

import Foundation
import MachO

public struct MemoryDiagnostics {
    
    /// Returns the exact physical memory footprint (in Megabytes) tracked by Jetsam.
    public static func getPhysicalMemoryFootprintMB() -> Double? {
        var vmInfo = task_vm_info_data_t()
        var count = mach_msg_type_number_t(MemoryLayout<task_vm_info_data_t>.size / MemoryLayout<integer_t>.size)
        
        let result = withUnsafeMutablePointer(to: &vmInfo) { ptr in
            ptr.withMemoryRebound(to: integer_t.self, capacity: Int(count)) { intPtr in
                task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), intPtr, &count)
            }
        }
        
        guard result == KERN_SUCCESS else { return nil }
        
        // phys_footprint is the exact metric used by iOS Jetsam to trigger kills
        let footprintBytes = Double(vmInfo.phys_footprint)
        return footprintBytes / (1024.0 * 1024.0)
    }
    
    /// Queries remaining memory available to the process before system intervention
    public static func getAvailableMemoryMB() -> Double {
        return Double(os_proc_available_memory()) / (1024.0 * 1024.0)
    }
}

By querying os_proc_available_memory() upon entering critical funnels, your app can dynamically evict caches before Jetsam strikes.

2. Android: The LowMemoryKiller (LMK) & The OOM Paradox​

On Android, memory management is split across two layers:

1. The ART (Android Runtime) Java/Kotlin Virtual Heap: Subject to garbage collection with an upper limit defined by Runtime.getRuntime().maxMemory().
2. The Linux Kernel & Native Allocations: Governed by the lmkd daemon, which monitors system-wide RAM and kills processes based on their oom_score_adj priority.

The "Straw That Broke the Camel's Back" Fallacy​

When an Android app crashes with a fatal java.lang.OutOfMemoryError, developers almost always misdiagnose the root cause by staring at the stack trace:

java.lang.OutOfMemoryError: Failed to allocate a 32784 byte allocation with 12582912 free bytes and 12MB until OOM
    at java.lang.StringFactory.newStringFromChars(StringFactory.java:328)
    at java.lang.StringBuilder.toString(StringBuilder.java:407)
    at com.example.app.ui.cart.CartAdapter.onBindViewHolder(CartAdapter.kt:42)

The stack trace points to a 32KB string allocation inside CartAdapter. Developers spend days optimizing StringBuilder usages in the cart screen.

In reality, the cart adapter was blameless. Five minutes earlier, a background image pipeline leaked five 50MB uncompressed Bitmap instances because an Activity failed to unsubscribe from an EventBus. The heap was already at 99.8% capacity; the 32KB string just happened to be the unlucky allocation that tripped the wire.

Production Memory Telemetry in Kotlin​

To monitor real memory consumption and intercept OS warnings before LMK strikes:

package com.appxiom.diagnostics

import android.app.ActivityManager
import android.content.ComponentCallbacks2
import android.content.Context
import android.content.res.Configuration
import android.os.Debug
import android.os.Process

class ProductionMemoryObserver(private val context: Context) : ComponentCallbacks2 {

    fun captureMemorySnapshot(): MemorySnapshot {
        val runtime = Runtime.getRuntime()
        val javaHeapUsedMB = (runtime.totalMemory() - runtime.freeMemory()) / (1024 * 1024)
        val javaHeapMaxMB = runtime.maxMemory() / (1024 * 1024)
        
        // Native allocation tracking (Bitmaps, C++ libs, OpenGL/Vulkan buffers)
        val nativeHeapAllocatedMB = Debug.getNativeHeapAllocatedSize() / (1024 * 1024)
        
        // PSS (Proportional Set Size): The most accurate representation of app footprint
        val activityManager = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
        val memoryInfo = ActivityManager.MemoryInfo()
        activityManager.getMemoryInfo(memoryInfo)

        return MemorySnapshot(
            javaHeapUsedMB = javaHeapUsedMB,
            javaHeapMaxMB = javaHeapMaxMB,
            nativeHeapAllocatedMB = nativeHeapAllocatedMB,
            systemAvailableMemMB = memoryInfo.availMem / (1024 * 1024),
            isSystemLowMemory = memoryInfo.lowMemory
        )
    }

    override fun onTrimMemory(level: Int) {
        when (level) {
            ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL -> {
                // The app is running, but device is critically low on memory.
                // Evict non-essential bitmap caches immediately.
            }
            ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN -> {
                // UI moved to background. Free heavy UI resources to lower LMK kill priority.
            }
        }
    }

    override fun onConfigurationChanged(newConfig: Configuration) {}
    override fun onLowMemory() {
        // Legacy callback: system is running out of memory
    }
}

data class MemorySnapshot(
    val javaHeapUsedMB: Long,
    val javaHeapMaxMB: Long,
    val nativeHeapAllocatedMB: Long,
    val systemAvailableMemMB: Long,
    val isSystemLowMemory: Boolean
)

3. Flutter & React Native: The Split-Heap Blindspot​

Cross-platform frameworks introduce a dangerous architectural duality: The VM Heap vs. The Native Graphics Engine.

In Flutter, Dart manages object lifecycle on the Dart VM Heap. However, images, shaders, Skia/Impeller render pipelines, and texture backings live in native C++ memory.

// DANGEROUS: Decodes a 4032x3024 12MB camera photo into raw RGBA memory
// Dart heap allocates only a tiny metadata pointer (~120 bytes)
// Skia / Native heap allocates 4032 * 3024 * 4 bytes = ~48.7 MB of uncompressed bitmap!
Image.network(
  "https://cdn.example.com/products/4k_photo.jpg",
  width: 150,
  height: 150,
)

// SAFE: Resizes bitmap during decode step, saving 95% native RAM
Image.network(
  "https://cdn.example.com/products/4k_photo.jpg",
  width: 150,
  height: 150,
  cacheWidth: 300, // 2x density for 150dp
  cacheHeight: 300,
)

If a list view displays 30 unconstrained images, the Dart VM reports a healthy 45MB heap, while the native iOS/Android process footprint spikes past 1.4GB. Within seconds, Jetsam or LMK kills the app. A standard Dart crash handler will never capture a stack trace.

Why Traditional Monitoring Tools Fail in Production​

The Appxiom Solution: Memory Activity Trail​

Diagnosing production memory leaks does not require capturing every allocated byte in RAM. It requires understanding Memory Delta Attribution.

A leak is not defined by high memory usage; it is defined by memory that is allocated during a user journey and fails to reclaim after that journey terminates.

Correlating Memory Deltas with User Journeys​

The Appxiom SDK records lightweight memory snapshots attached to each discrete step in the Activity Trail. By comparing memory footprint across screen transitions, network invocations, and user interactions, Appxiom calculates the exact memory delta ($\Delta$) per step.

Activity Trail Trace: Diagnosing a Retain Cycle in Production​

Consider this telemetry log captured by Appxiom immediately before an iOS Jetsam event:

The Root Cause Revealed​

Without Appxiom, your team would be looking at an unhandled session termination during checkout. You might assume the payment gateway SDK crashed.

With the Appxiom Activity Trail, the bug is obvious in five seconds:

1. When the user entered ARProductViewer, RAM jumped from 168 MB to 495 MB (+327 MB).
2. When the user navigated back to HomeScreen, memory should have dropped back toward 168 MB. Instead, memory remained pinned at 490 MB (only -5 MB reclaimed).
3. The ARProductViewer controller or its Metal texture buffers had a strong retain cycle (e.g., an uncancelled closure capture or unreleased camera delegate), keeping 320MB of native resources permanently alive in background memory.
4. When the user reached Checkout, the normal memory requirement of the payment sheet pushed the app over the device's Jetsam threshold.

Connecting Memory Diagnostics to Business Health​

Memory diagnostics is not merely an infrastructure concern; it directly impacts revenue and customer retention.

1. Goal Friction Impact (GFI)​

When an app terminates due to an OOM during an onboarding or checkout flow, users rarely re-enter payment credentials - they abandon the transaction. Appxiom's Goal Friction Impact (GFI) quantifies the precise financial loss attributable to memory degradation, allowing engineering leads to prioritize memory fixes with hard ROI data.

2. Quality Score (QS)​

Rather than relying solely on the deceptive crash-free rate, Appxiom calculates a holistic Quality Score (QS). Devices experiencing excessive memory pressure warnings (TRIM_MEMORY_RUNNING_CRITICAL or didReceiveMemoryWarningNotification) trigger a score penalty, giving you an early warning system days before crashes escalate.

3. Version Analytics​

During staged rollouts, Appxiom's Version Analytics compares memory distributions across app versions:

• v2.4.0: 90th percentile physical footprint = 185 MB.
• v2.5.0: 90th percentile physical footprint = 340 MB (+83% regression detected in first 2% rollout).

You can halt the release before the regression compromises millions of devices.

Actionable Production Memory Hardening Checklist​

Follow these engineering best practices to eliminate memory leaks and build resilience against LMK and Jetsam:

iOS (Swift / SwiftUI)​

• Enforce Weak Capture in Async Closures: Audit all Task { [weak self] in ... } blocks and delegates to prevent retain cycles holding view controllers in memory.
• Drain Autorelease Pools in Heavy Loops: Wrap batch data transforms or file processing in autoreleasepool { ... } so intermediate objects are reclaimed immediately.
• Listen to Memory Pressure: Implement UIApplication.didReceiveMemoryWarningNotification to flush image memory caches and clear transient view states.
• Audit Background Tasks: Ensure background tasks end promptly with UIApplication.shared.endBackgroundTask(). Pinned background allocations are the #1 trigger for Jetsam priority kills.

Android (Kotlin / Jetpack Compose)​

• Observe ComponentCallbacks2: Evict Glide/Coil bitmap caches upon receiving TRIM_MEMORY_RUNNING_CRITICAL or TRIM_MEMORY_RUNNING_LOW.
• Beware of Static View/Context References: Never store a Context or View in a companion object, singleton, or long-lived coroutine scope.
• Bind Coroutines to Lifecycle: Use viewLifecycleOwner.lifecycleScope in Fragments and rememberCoroutineScope() in Compose to ensure allocations cancel with UI teardown.
• Optimize Large Bitmaps: Always decode images using BitmapFactory.Options.inSampleSize or rely on modern vector drawables and hardware-accelerated rendering.

Cross-Platform (Flutter / React Native)​

• Constrain Image Cache Dimensions: Never use unconstrained Image.network() without specifying cacheWidth and cacheHeight.
• Dispose Controllers Explicitly: Always invoke .dispose() on AnimationController, TextEditingController, FocusNode, and ScrollController in the widget dispose() lifecycle.
• Verify Native Bridge Cleanup: Ensure custom native platform channels (MethodChannels) release native listeners and texture handles when widgets unmount.

Eliminate Memory Blindspots with Appxiom​

You cannot fix what you cannot measure, and you cannot debug production memory with development-only profilers.

By combining low-overhead physical footprint telemetry with the Appxiom Activity Trail, your engineering team gains complete visibility into every memory spike, retain cycle, and silent OOM kill across iOS, Android, and Flutter.

Stop losing users to invisible memory kills. Explore Appxiom's Activity Trail or start monitoring your mobile applications today.

You know that moment when you're rushing to book a cab, the payment is about to go through, and suddenly the app freezes? For a few seconds, you're stuck - did the payment go through or not? Do you retry? Do you close the app? That tiny moment of uncertainty is enough to frustrate most users. And more often than not, they don't come back.

That's exactly how silent damage begins in mobile apps. Not with big disasters-but with small, unexpected failures in moments that matter most. On Android, even one crash in a critical flow like login, checkout, or onboarding can quietly push users away, hurt your ratings, and impact revenue. While no app can ever be completely crash-proof, Kotlin gives you a strong safety net to reduce these risks long before users feel them.

In the world of Android app development, crashes are an unfortunate reality. No matter how well you write your code, there's always a chance that something unexpected will happen on a user's device, leading to a crash. These crashes can result in a poor user experience, negative reviews, and lost revenue. To build robust Android apps, it's crucial to not only prevent crashes but also monitor and report them when they occur.

In this blog post, we'll explore how to avoid crashes in Android apps using Kotlin and how to report crashes using Appxiom, a powerful APM tool.

Avoiding Crashes​

1. Null Safety with Kotlin​

Kotlin, as a modern programming language, brings a significant advantage to Android development - null safety. Null pointer exceptions (NPEs) are one of the most common causes of app crashes. Kotlin's null safety features, such as nullable types and safe calls, help you prevent NPEs at compile time.

Here's an example of how to use nullable types:

var name: String? = null // Declare a nullable String
name?.length // Safe call: returns null if 'name' is null

By using nullable types and safe calls, you can catch potential null references early in the development process.

2. Exception Handling​

While you can't always prevent exceptions, you can handle them gracefully to avoid app crashes. Use try-catch blocks to catch exceptions and provide a fallback or error message to the user.

For example:

try {
    // Code that might throw an exception
} catch (e: Exception) {
    // Handle the exception, e.g., log it or display an error message
}

By handling exceptions properly, you can prevent crashes and provide a better user experience.

3. Defensive Programming​

Adopt defensive programming practices by validating inputs, using assertions, and adding proper checks throughout your code. For instance, when accessing an array or list, ensure that you're within the bounds to avoid index out of bounds exceptions.

val list = listOf(1, 2, 3)
if (index >= 0 && index < list.size) {
    val item = list[index]
    // Use 'item' safely
} else {
    // Handle the out-of-bounds condition
}

4. Robust API Calls​

When making network requests or interacting with external services, always assume that the network may fail or the data may be invalid. Implement retry mechanisms, timeouts, and data validation to handle unexpected scenarios gracefully.

Reporting Crashes with Appxiom​

Even with the best preventative measures, crashes may still occur. When they do, it's essential to gather detailed information about the crash to diagnose and fix the issue. Appxiom is a powerful tool for crash reporting and analysis.

1. Integrating Appxiom into Your App​

To get started, sign up for a Appxiom account. Then, add the Appxiom SDK to your Android project. You can do this by adding the following dependency to your app's build.gradle file:

dependencies {
    implementation 'com.appxiom:appxiomcore:x.x.x'
}

Initialize Appxiom in your app's Application class:

import android.app.Application

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        Ax.init(this, appKey, platformKey)
    }
}

​

2. Capturing and Reporting Crashes​

Appxiom automatically captures crashes and unhandled exceptions in your app. When a crash occurs, it collects valuable information, including the stack trace, device details, and user actions leading up to the crash.

You can also manually report non-fatal errors and exceptions using the following code:

try {
    // Code that might throw a non-fatal exception
} catch (e: Exception) {
    Ax.reportException(this, e, Severity.MAJOR)
}

For more on how to use Appxiom to detect crashes and other issues like memory leak and frame rate issues, check the Appxiom documentation at https://docs.appxiom.com.

​

3. Analyzing Crash Reports​

Once crashes are reported to Appxiom, you can log in to your Appxiom dashboard to view and analyze crash reports. Appxiom provides detailed insights into the root cause of crashes, enabling you to prioritize and fix issues quickly. You can see stack traces, device information, and the activity trail of the user that led to the crash.

Conclusion​

Building crash-resilient Android apps is a critical aspect of delivering a positive user experience. By following best practices in Kotlin for avoiding crashes and integrating crash reporting and analysis tools like Appxiom, you can significantly reduce the impact of crashes on your app and ensure that your users have a smooth and trouble-free experience.

Remember that continuous monitoring and improvement are essential for maintaining the reliability of your Android app.

Performance testing is a critical aspect of iOS app development. It ensures that the app performs optimally, providing a seamless user experience. With millions of apps available in the App Store, it is imperative that an iOS app must perform well to succeed.

In this blog, we will explore what iOS app performance testing is, the best practices to follow, and the tools available.

What is iOS App Performance Testing?​

iOS app performance testing is the process of testing an application's performance and behavior on iOS devices. The testing process includes evaluating the app's response time, speed, stability, scalability, and resource utilization. The goal of iOS app performance testing is to identify any performance issues before the app is released to the public.

What to test?​

• Memory usage including memory leaks, abnormal memory usage, memory spikes.

• Battery drain

• CPU usage

• Network call performance issues, Error status codes in responses, delayed calls, duplicate calls.

• App Hang

• Screen responsiveness

• User flow and logic

Steps in iOS App Performance Testing​

• Define Test Objectives - The first step in iOS app performance testing is to define the test objectives. This includes identifying the target audience, user scenarios, and performance goals.

• Identify Performance Metrics - The next step is to identify the performance metrics that need to be tested. This includes response time, speed, stability, scalability, and resource utilization.

• Create Test Environment - The test environment should be created to simulate real-life scenarios. This includes configuring the hardware and software components, network conditions, and device settings.

• Develop Test Plan - A detailed test plan should be developed, outlining the test scenarios, test cases, and expected results.

• Execute Test Plan - The test plan should be executed as per the defined scenarios, and the app's performance should be evaluated under different conditions.

• Analyze Test Results - The test results should be analyzed to identify performance issues and bottlenecks.

• Optimize App Performance - Based on the test results, the app's performance should be optimized to ensure that it meets the performance goals and objectives.

Tools for iOS App Performance Testing​

• Xcode Instruments - Xcode Instruments is a powerful tool that can be used for iOS app performance testing. It provides a wide range of profiling and debugging tools that can help identify and resolve performance issues.

• Charles Proxy - Charles Proxy is a tool that can be used to monitor network traffic, including HTTP and SSL traffic. It can be used to test the app's performance under different network conditions.

• XCTest - XCTest is an automated testing framework provided by Apple for testing iOS apps. It can be used to create automated performance tests.

• Firebase Test Lab - Firebase Test Lab is a cloud-based testing platform that provides a wide range of testing capabilities, including performance testing.

• BrowserStack - Cloud based testing platform with a range of features to identify and debug issues while testing.

• Appxiom - SaaS platform that reports performance issues and bugs in iOS apps in real time. It detects Memory issues, screen responsiveness, crashes, rendering issues, network call issues over HTTP and HTTPS and much more in development, testing and live phases of the app.

Best Practices for iOS App Performance Testing​

• Test Early and Often - iOS app performance testing should be an integral part of the development process, and testing should be done early and often.

• Use Real Devices - Testing should be done on real devices to simulate real-life scenarios accurately.

• Define Realistic Test Scenarios - Test scenarios should be defined based on real-life scenarios to ensure that the app's performance is tested under realistic conditions.

• Use Automated Testing - Automated testing should be used to reduce the testing time and improve accuracy.

• Monitor App Performance - App performance should be monitored continuously to identify any performance issues and bottlenecks.

• Collaborate with Developers - Collaboration between testers and developers can help identify and resolve performance issues early in the development process.

Conclusion​

iOS app performance testing ensures that the app performs optimally, providing a seamless user experience. By following best practices and using the right tools, iOS app developers can identify and resolve performance issues early in the development process, resulting in a high-quality app that meets the user's expectations. It is essential to test the app's performance under different conditions to ensure that it performs well under all circumstances. Therefore, app performance testing should be an integral part of the iOS app development process.

Performance monitoring and continues bug monitoring are critical parts of the Mobile App development lifecycle. As mobile devices become more powerful and users expect more from their apps, it is essential to ensure that apps are performing well and are free of bugs. One way to achieve this is by using Application Performance Management (APM) tools.

APM tools are designed to help mobile app testers and developers detect and diagnose performance issues and bugs in their apps. These tools provide a wide range of information about an app's performance, including memory usage, CPU usage, network activity, and more. This information can be used to identify bottlenecks, memory leaks, and other issues that can negatively impact an app's performance.

One of the main benefits of using APM tools is that they can help app developers and testers find and fix performance issues before they become a problem for users. By identifying issues early in the development process, teams can make changes to improve performance and ensure that the app is stable and reliable. This can help reduce the number of crashes and improve the overall user experience.

Another benefit of using APM tools is that they can help developers and testers understand how users are interacting with their apps. This can be especially useful for understanding how different user segments are interacting with the app, which can help teams optimize the user experience and make improvements that will have the biggest impact.

In short, APM tools are an essential tool for mobile app testers and developers. They help teams identify and fix performance issues and bugs, improve the user experience, and ensure that apps are stable and reliable. By using APM tools, teams can deliver better quality apps and create a more positive user experience.

Visit appxiom.com to know more about how Appxiom can help you with monitoring performance and bugs in mobile apps.

One of the important advice from my mentor is to keep collecting as much publicly available information about apps that use our platform, connect with key people, and collect feedback about Appxiom. Appxiom helps mobile app developers to detect bugs and performance issues in Android and iOS apps, and to collect all relevant data for reproducing them.

And thus early last year we came across an app named Showreel.

Video for professional networking​

Showreel is Tiktok for professional networking. You build your profile in Showreel as a well stitched series of short videos where you talk about yourself and what you do. It’s ideal for pitching for new jobs, or just to present what you do in your professional life. They also have a section for startup’s where founders can create short video pitches.

Showreel appVideo content has become the maximum consumed content format in our personal digital life, Bringing that to professional life is a great idea, isn’t it?

The Super Star founder​

We explored further. And me and Don Peter were elevated to Cloud 9 when we realised who the founder is. Remember Hotmail? And its founder Sabeer Bhatia? Yes, Showreel is the new venture founded by Mr. Bhatia.

Sabeer Bhatia, founder of Hotmail and ShowreelHotmail was my first email id. I’m sure so is the case with almost everyone who got exposed to digital world in late 90’s. It was probably the first SaaS product that was adopted by masses across the globe. Mr. Bhatia became our hero and manifestation of what we all could dream to become. Selling Hotmail to Microsoft for a whopping $400M in 1998 made us all realize the scale of opportunity that the new world offered. He became a Super Star in the Web 1.0 era.

More than a customer​

Coming back to the present, we connected with the engineering team of Showreel, and requested their feedback. They obliged and gave very valuable inputs and insights regarding how they use the product. The engagement is still continuing strong and they keep sharing their suggestions. Long story short, their inputs have contributed much to our product roadmap and many of their suggestions are included in Appxiom 6.0.

Thank you Team Showreel for choosing Appxiom, and supporting us with your thoughts and suggestions on improving the product. We value that much.

Check out Showreel here. https://www.showreelapp.com.

Year 2020 started with the fear of pandemic induced economic recession. But it seems technology domain was less unaffected than expected. Reason for this is the increased dependency on technology. This increase in demand reflected in the number of bug reports Appxiom handled in 2020. Appxiom captured 464 Million bug reports which is 45 times the count for 2019.

We analysed the bug types to get an understanding about the common issues reported in mobile apps. We decided to share this data to help developers to focus more on such issues and to improve the quality of mobile apps.

Bug stats for iOS apps​

​

In 2020 Appxiom captured 138 Million bug reports from 624 iOS apps built on Objective C or Swift. This is from an install base of 1.3M devices.

API related bugs are the most common bugs in iOS and contribute 42.9% of all issues reported, followed by memory leaks at 25%. Crashes contribute 14.3% of bugs. Frame skips came next at 9.5%.

Bugs in iOS apps

Bug stats for Android apps​

​

Appxiom captured 324 Million bug reports in 2020 from 1853 android apps built on Java or Kotlin. Total install base is 2.1M devices.

Memory leaks are the most common bugs in android and contribute 29.7% of all issues reported, followed by screen load delays at 25.4%. Crashes contribute 23.7%% of bugs. API bugs are at 9.5%.

Bugs in Android apps

Conclusion​

​

While we do not claim this to be an exact representation of state of mobile app bugs across millions of apps out there, this data has some clear indicators. Higher density of memory related bugs is a major concern, and one of the reasons is that a good number of the memory leaks go unnoticed during development phase. API bugs and crashes are issues that could be identified before going in production, but looks like a not so small number of them make it to live apps.

Though it is often advised to keep the app’s memory footprint as low as possible, developers tend to overlook this aspect during app development. As a result, the elements that consume the app’s memory go unchecked, which leads to the app consuming an abnormal amount of the device’s memory.

When the iOS app consumes a considerable amount of allocated memory, it leads to an out of memory exception, resulting in an app crash and affecting user experience. This makes it important for developers to be notified about abnormal memory usages in both development and production environments at the earliest.  

Abnormal memory usage occurs when unused memory is not reclaimed properly or because of inefficient object reuse.​

With Appxiom, abnormal memory usage can be detected at the earliest and developers get to fix the issue fast.Appxiom is an automated bug reporting tool that is capable of detecting abnormal memory usages and memory spikes in iOS apps.

Using Appxiom to track memory issues in iOS​

With a simple 3-step integration process, Appxiom framework for iOS detects and reports abnormal memory usage in both development and production environments. Please visit our documentation page for more details. 

Tracking memory usage with Activity trail​

Appxiom reports high memory usage when the iOS app consumes more than 30% of the physical memory. The bug report will have data points like activity trail with memory usage patterns along with device and device state information, which will aid developers to reproduce the bug. 

Activity Trail from an issue reportActivity trail consists of a list of events that occurred one minute prior to the issue occurrence. The app events along with the percentage of free memory available at each point are displayed in a chronological order. 

Components of Activity trail​

Section of Activity Trail

Activity​

The activity segment has details of the app events. The user event will have two components separated by a colon

•  The name of the class in which the event gets reported

•  The textual description of the event.

Timestamp​

The timestamp segment has details related to the time at which the event gets recorded. 

Free Memory​

The memory segment also contains the percentage of free memory available for the app at the time of the event. 

How Appxiom helps in finding the root cause​

Abnormal memory usage reported by AppxiomLet’s consider a use case as indicated in the above screenshot. Here, Appxiom has detected high memory usage in an iOS app. The issue is that the app’s memory usage crossed 2587213824 bytes, which is more than 30% of the physical memory size i.e 8589934592 bytes. 

With an in-depth evaluation of the activity trail section in the issue report, we understand that while loading the first banner image, the free memory was around 79%. But when the final banner image was loaded, the memory dipped down to almost 71%. So with each banner image, the amount of free memory available goes down. By analysing the issue further in code, we can come to the conclusion that the root cause for the free memory dip was that the allocated objects for banner images are not released. 

This scenario may lead to an app crash. In order to avoid the app from crashing, Appxiom detects and reports whenever the app consumes more than an ideal amount of free memory.

Activity trail helps developers to pinpoint where exactly the issue is so that necessary changes can be made in the code and a patch version be released fast. 

Custom Activity Trail events​

Apart from default events, Appxiom allows developers to set custom app events in activity trail (refer our Objective-C and Swift documentation) with an API, which can be called anywhere in the code. These custom events will be recorded and shown along with default app events in the activity trail section in Appxiom dashboard. 

Along with high memory usage and spikes, Appxiom also detects memory leak in iOS apps. To know more read our blog Detect memory leaks in iOS

Apart from memory-related issues, Appxiom capable of detecting and reporting crashes, API call issues, frame rate issues, ANR, function failures, exceptions, delays and custom issues.  Appxiom is available for iOS as Objective-C and Swift Frameworks, watchOS as Objective-C and Swift Frameworks, and Android as Java and Kotlin SDKs platforms. 

Visit appxiom.com to know more about Appxiom. Detailed documentation is available at docs.appxiom.com

One of the challenges mobile app developers face is collecting as much relevant data to reproduce bugs reported during testing and more so production. In production even detecting bug occurrences becomes a challenge. Manual bug detection and data collection in Android mobile apps during testing and development environment is time consuming and in production it is near impossible. Here is where tools like Appxiom aid the developers.

Appxiom is an automated, light-weight bug reporting SDK for Android apps that helps developers to reduce the bug fixing time by providing clear and crisp issue reports with detailed data points for effective root cause analysis.

First things first, Appxiom has an easy three step integration process.

• Register with Appxiom using the ‘Get Started’ button in https://appxiom.com and login to the dashboard. 

• Use ‘Add App’ to link your Android app to Appxiom.

• Integrate Appxiom SDK to your app as a gradle library.

For a more detailed integration guide, visit our documentation pages for Android (Java & Kotlin).

Appxiom is capable of reporting multiple bug types in Android apps. Some of the main types of bugs in Android apps are,

Types of Issues captured and reported by Appxiom​

​

Memory Leaks​

​

Memory Leaks occur in Android apps when unused objects are not cleared from the device’s memory. Appxiom SDK has out of the box capability to detect memory leaks in Android apps. and reports it to the dashboard with data points like class stack, activity trail, device and device state info. 

Memory Leak in Android

Crashes​

​

App Crashes are fatal and will affect the user experience, which may lead to user’s uninstalling the app. 

App Crash in AndroidWith basic integration, Appxiom SDK is capable of reporting crashes along with data points like device and device state data, activity trail and full stack trace.

​

API Failures​

With a single line of code, Appxiom SDK is capable of reporting API issues like status code errors, delayed API call executions or even duplicate API calls. Appxiom reports API failures with detailed data points including network parameters like full URL, request-response headers and request body. 

API Issue in Android

Abnormal memory usage​

​

When an app consumes a high amount of device’s memory, Appxiom SDK immediately reports it. Activity trail in issue report will enable developers to identify the reason for the spike in memory usage.

Abnormal Memory Usage in Android

Function failures​

​

Issues in code level functions like unexpected return value, delay in function execution are called function failures. Appxiom SDK provides a single line API to track code level function failures. Data points like function parameters are sent along with each issue report with will aid developers in fixing the issue fast.

Function Failure in Android

Feature failures​

​

Using the function tracking API, SDK allows developers to chain multiple functions. Once chained Appxiom will monitor if the second function is executed within the stipulated time (can be set by the developer) after the execution of the first function. If not, then Appxiom SDK reports it as an issue. This will enable developers to report any app feature failures.

Feature Failure in AndroidBug reports will include data points like activity trail, function parameters and return values.

​

Custom issues​

​

Appxiom SDK provides a single line API for developers to report any custom issues. 

Custom Issue report in Android

ANR​

​

ANR or App Not Responding occurs due to frame rate issues in Android, that block the UI thread for more than 5 seconds. By tracing the Activity trail events, developers can reproduce and can fix ANR issues fast. 

ANR report in Android

Screen loading delay​

​

Delay in loading of any activity or fragment will be automatically reported by Appxiom SDK. 

Screen Loading delay in AndroidNow, let us take a look at the data points in bug reports of Appxiom that help developers to reproduce the bugs effectively. 

Data Points Explained​

​

Error insights​

​

Error insights help the developers to find commonalities across occurrences for faster root cause analysis. Error insights consist of information like bandwidth strength, battery level, low memory warning, OS versions, device names, country name and timezone offsets. 

Error Insights from an issue report in Android

Activity Trail​

​

Activity trail is a list of chronologically ordered app events, that helps developers to identify where the issue occurred. It consists of three components, 

• The Activity segment, that has the details of the app event.

• The timestamp segment, that has time at which the event got recorded.

• The memory segment, that shows the percentage of free memory.

Activity-trail from an issue report in Android

Stack trace​

​

Stack trace helps the developers to track the exact line of code where the crash occurred.

Stack trace from an issue report in Android

Network Parameters​

Network parameters provide in-depth information on network request and response data. Network parameters will have request headers, request body, request body size, response headers, status code and response body size. 

Network parameters from an issue report in Android

Device & Device State info​

​

Device & Device state info gives the developer information about the device and the state of the device at the time of bug occurrence.

Device and Device State data from an issue report in Android

Function Parameters​

​

Function parameters section of data points will contain parameter value and data type of all the parameters passed to the function being tracked during runtime.

Function parameters from an issue report in Android

Data Security & Data Privacy​

​

Appxiom SDK is architectured in such a way that all our app users remain anonymous to the system as we do not collect any PII which ensures data privacy. All data collected, sent and stored by Appxiom are secured with end to end encryption. Appxiom is also GDPR compliant.

Call back mechanism​

​

For every issue that is raised by the Appxiom SDK, a callback function will be triggered, which allows developers to handle the issue gracefully. You can read more about the same in our Java and Kotlin documentation pages.

Appxiom is also available as Objective-C and Swift frameworks for iOS and watchOS. Visit appxiom.com to know more about Appxiom Detailed documentation is available at docs.appxiom.com.