4 posts tagged with "anr"

For years, Apdex (Application Performance Index) has been a standard metric for measuring application responsiveness. Popularized by Application Performance Monitoring (APM) platforms, Apdex helps engineering teams understand whether application response times meet predefined performance thresholds. It is an effective indicator of infrastructure and backend performance.

However, mobile app quality extends far beyond response time.

An app can maintain an excellent Apdex score while users still experience crashes, ANRs, frozen screens, memory issues, or UI failures that prevent them from completing important tasks. These problems may not affect server latency, but they significantly impact user experience, release stability, and customer retention.

To bridge this gap, Appxiom introduces Quality Score (QS) - a version-level metric that provides a holistic view of application health by combining signals from crashes, performance issues, stability problems, and other quality indicators into a single score.

Alongside Quality Score, Appxiom also provides Goal Friction Impact (GFI), a complementary metric that measures how technical issues disrupt specific user journeys such as signup, login, checkout, or onboarding.

Together, these metrics help teams answer two equally important questions:

• How healthy is the overall application release? → Quality Score (QS)
• Which user journeys are being affected the most? → Goal Friction Impact (GFI)

In this article, we'll explore why traditional performance metrics like Apdex are no longer sufficient for evaluating mobile application quality and how Appxiom's Quality Score provides a more complete picture of release health.

Why Apdex Is Necessary - But Not Sufficient for Product Teams​

Apdex measures application responsiveness against a predefined performance threshold (T), helping teams understand whether users experience acceptable response times.

It classifies requests into three categories:

• "Satisfied:" Response time ≤ T
• "Tolerating:" T < Response time ≤ 4T
• "Frustrated:" Response time > 4T or request failures

For infrastructure and backend monitoring, this works extremely well.

What Apdex Measures Effectively​

Apdex provides valuable insights into system performance, including:

• Backend and API response times
• Infrastructure latency
• Service availability
• Performance regressions
• SLA and SLO compliance

These metrics help engineering teams identify slow services and maintain application responsiveness.

What Apdex Doesn't Measure​

While response time is important, it represents only one aspect of application quality.

Modern mobile applications frequently experience issues that have little or no impact on server latency but significantly affect user experience.

Examples include:

• Application crashes
• ANRs (Application Not Responding)
• App hangs
• Frozen frames
• Memory-related issues
• UI rendering problems
• Broken user interactions
• Startup failures

A payment screen may load instantly but crash when the user taps Pay.

A signup form may respond within milliseconds but fail because of an unexpected client-side validation error.

An application may achieve an excellent Apdex score while users continue abandoning critical workflows due to stability and usability issues.

These problems directly affect application quality, even though traditional performance metrics report everything as healthy.

This is where version-level quality metrics become essential.

The Business Blind Spot: When Apdex Is Green but Application Quality Is Declining​

Consider a typical mobile application after a new release:

• Weekly Active Users: 500,000
• Apdex Score: 0.96 (Excellent)
• 95th Percentile API Response Time: 180 ms
• Server Availability: 99.98%
• Infrastructure Alerts: 0

From an infrastructure perspective, the release looks nearly perfect.

But here's what users are actually experiencing:

• 3,200 users encountered app crashes.
• 1,850 users experienced ANRs while opening key screens.
• 4,700 users faced frozen frames and UI responsiveness issues.
• 2,100 users couldn't complete onboarding because of a client-side validation bug.
• 1,400 users abandoned checkout after a payment screen failure.

In total, more than 13,000 users experienced quality issues - even though Apdex reported an excellent score.

Traditional performance metrics don't capture these client-side failures because response times remain within acceptable limits. As a result, engineering teams may assume a release is healthy while application quality steadily declines across real user devices.

This disconnect becomes even more significant as applications expand across multiple operating systems, device models, and release versions. Infrastructure metrics reveal how quickly systems respond, but they don't indicate whether a release is becoming more stable - or introducing new quality issues.

This is where Appxiom Quality Score (QS) fills the gap. By continuously evaluating the health of every app version, Quality Score enables teams to compare releases, detect quality regressions early, and understand whether application stability is improving over time.

While Quality Score provides the overall health of a release, Goal Friction Impact (GFI) complements it by identifying how those technical issues affect critical user journeys such as signup, login, onboarding, and checkout.

Together, they provide a complete view of both release quality and business impact.

Understanding Appxiom Quality Score (QS)​

As mobile applications become increasingly complex, evaluating release quality requires more than monitoring crashes or response times in isolation. Engineering teams need a single metric that reflects the overall health of every application version.

Appxiom Quality Score (QS) is designed to provide exactly that.

Quality Score is a version-level health metric that continuously evaluates the stability, reliability, and overall quality of an application release. Instead of analyzing individual issues separately, QS combines multiple quality signals into a single score, allowing teams to quickly understand whether an app version is improving or degrading over time.

Rather than asking:

"How many crashes occurred?"

Quality Score answers:

"How healthy is this release compared to previous versions?"

This enables engineering, QA, and product teams to compare releases at a glance and identify quality regressions before they affect a larger percentage of users.

What Contributes to Quality Score?​

Quality Score considers multiple indicators of application health, including:

• Application crashes
• ANRs (Application Not Responding)
• App hangs
• Frozen frames
• Memory-related issues
• UI responsiveness problems
• Startup failures
• Network and API issues
• Other stability and performance indicators

Instead of reviewing each metric independently, Appxiom aggregates these signals into a single Quality Score for every application version.

Why a Single Quality Score Matters​

Without a consolidated quality metric, engineering teams must manually compare crashes, ANRs, frozen frames, memory issues, and startup failures across every release. Quality Score simplifies this process by summarizing overall release health into a single metric, making it easier to identify regressions and prioritize investigation.

Quality Score Dashboard: Understanding Release Health at a Glance​

One of the biggest challenges in release management is understanding the health of multiple app versions without manually analyzing dozens of performance metrics.

The Appxiom Quality Score Dashboard simplifies this by presenting a consolidated view of every release, allowing engineering and product teams to identify quality trends within seconds.

Instead of reviewing crashes, ANRs, memory issues, and performance metrics separately, teams can immediately compare the quality of every application version using a single score.

The dashboard provides visibility into:

• Quality Score for every application version
• Affected Installations experiencing quality issues
• Total Issue Occurrences detected in each release
• Historical Quality Score Trends
• Quick access to issues impacting each version

This enables teams to answer important release questions immediately:

• Which release is currently the healthiest?
• Did application quality improve after the latest deployment?
• Which version introduced the highest number of quality issues?
• Which release should be prioritized for investigation?

Instead of spending hours correlating multiple dashboards, teams can quickly identify release regressions and focus on the versions that require immediate attention.

Example

In the dashboard below, each application version is assigned its own Quality Score, along with the number of affected installations and total issue occurrences.

This makes it easy to compare release health over time. A declining Quality Score immediately signals that the latest release may have introduced stability or performance regressions, allowing teams to investigate before issues affect a larger portion of users.

Quality Score vs. Apdex vs. Goal Friction Impact​

While Quality Score provides a comprehensive view of release health, it isn't designed to replace traditional performance metrics like Apdex or user journey metrics like Goal Friction Impact (GFI). Each metric answers a different question about your application.

Rather than competing with one another, these metrics work together to provide a complete understanding of application health - from infrastructure performance to release stability and user experience.

How Goal Friction Impact Complements Quality Score​

Quality Score provides a version-level view of application health, making it easy to compare releases and identify stability regressions.

However, even when two releases have similar Quality Scores, the user experience may differ significantly depending on where the issues occur.

For example, a release with minor UI glitches across multiple screens may receive a similar Quality Score to one where a payment failure affects only the checkout journey. While both releases require attention, their business impact is very different.

This is where Goal Friction Impact (GFI) complements Quality Score.

Instead of evaluating the overall health of an application version, GFI focuses on individual user journeys such as signup, login, onboarding, and checkout. It helps teams identify which business-critical goals are experiencing the highest friction, enabling faster prioritization of issues that directly affect user success.

Together, these two metrics provide a more complete view of application quality:

• Quality Score answers "How healthy is this application release?"
• Goal Friction Impact answers "Which user journeys are being disrupted?"

By combining both perspectives, engineering and product teams can prioritize fixes based not only on technical severity but also on their impact on the overall release and the user experience.

In our next article, we'll take a deeper dive into Goal Friction Impact (GFI), exploring how it measures friction across user journeys and helps teams prioritize issues based on real business impact.

Release Health: Connecting Code Changes to Usability​

Quality Score becomes even more valuable when tracked across consecutive releases. By comparing scores over time, engineering teams can quickly identify regressions, validate the impact of bug fixes, and measure whether application quality is improving with each deployment. Instead of reviewing dozens of individual metrics after every release, teams can use Quality Score as a consistent benchmark for release health.

Business Benefits of Quality Score​

By monitoring Quality Score, engineering and product teams can:

• Detect release regressions earlier
• Compare application quality across versions
• Validate the impact of bug fixes
• Improve collaboration between engineering, QA, and product teams
• Release updates with greater confidence

Quality Score provides a consistent benchmark for measuring application health instead of relying on isolated crash reports or individual performance metrics.

Best Practices for Using Quality Score​

To get the most value from Quality Score:

• Monitor every release: Track Quality Score after every deployment to identify unexpected regressions early.
• Compare versions regularly: Review Quality Scores across consecutive releases to measure improvements and validate engineering efforts.
• Investigate declining scores: A lower Quality Score should prompt deeper analysis into crashes, ANRs, memory issues, and other quality indicators contributing to the decline.
• Use Quality Score alongside other metrics: Quality Score provides an overall view of release health. Pair it with infrastructure metrics such as Apdex for system performance and Goal Friction Impact (GFI) for understanding how technical issues affect critical user journeys.

Conclusion​

Traditional performance metrics like Apdex remain essential for monitoring infrastructure responsiveness, but they provide only part of the picture. Modern mobile applications require a broader understanding of release quality - one that considers stability, reliability, and the overall user experience.

Appxiom's Quality Score (QS) provides that broader perspective by combining multiple quality indicators into a single version-level metric. Instead of reviewing crashes, ANRs, performance issues, and stability metrics separately, engineering teams can quickly evaluate the health of every application release, compare versions, and identify regressions before they affect more users.

When used alongside infrastructure metrics such as Apdex and complementary insights from Goal Friction Impact (GFI), Quality Score helps engineering and product teams make faster, data-driven release decisions while continuously improving application quality.

If you'd like to explore these metrics in more detail, check out:

• Appxiom Quality Score (QS): https://www.appxiom.com/how-to-evaluate-app-performance-quality
• Goal Friction Impact (GFI): https://www.appxiom.com/which-bugs-cause-user-drop-off-in-apps

Ready to evaluate the quality of your own app?

Sign up for Appxiom and start monitoring your application's release health with Quality Score and Goal Friction Impact. Every new account includes a 30-day free trial, no credit card required, and cancel anytime - so you can explore the platform and see how Appxiom helps you detect, prioritize, and resolve quality issues before they impact your users.

Flutter, Google's open-source UI development framework, has gained immense popularity among developers for its cross-platform capabilities and smooth performance. However, like any software development framework, Flutter apps may encounter frame rate issues that can impact user experience.

In this blog, we will explore the common causes of frame rate issues in Flutter apps and provide effective solutions to mitigate them.

Understanding Frame Rate Issues in Flutter Apps​

The frame rate of a Flutter app refers to the number of frames or screen updates displayed per second. The standard frame rate for smooth user experience is 60 frames per second (fps). If an app fails to achieve this frame rate consistently, it can result in stuttering animations, sluggish responsiveness, and an overall degraded user experience.

In Android, frame rate issues may manifest as App Not Responding (ANR) if the UI Thread gets blocked for 5000 milliseconds or more. If the UI Frames take 700 milliseconds or more to render it is a Frozen Frame situation and if it takes 16 milliseconds or more it is a Slow Frame situation.

In iOS, if the UI Thread is stuck for 250 milliseconds or more it is an App Hang, also called App Freeze, situation.

Common Causes of Frame Rate Issues​

1. Expensive Widget Rebuilds​

class MyExpensiveWidget extends StatelessWidget {
  final ExpensiveData data;

  const MyExpensiveWidget({required this.data});

  @override
  Widget build(BuildContext context) {
    // Widget build logic that might be expensive
    return ...;
  }
}

To optimize widget rebuilds, use const constructors whenever possible. By using const, Flutter can efficiently skip the widget rebuild if the constructor parameters haven't changed.

2. Inefficient Animations​

​

class MyAnimationWidget extends StatefulWidget {
  @override
  _MyAnimationWidgetState createState() => _MyAnimationWidgetState();
}

class _MyAnimationWidgetState extends State<MyAnimationWidget>
    with SingleTickerProviderStateMixin {
  late AnimationController _controller;
  late Animation<double> _animation;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      duration: const Duration(milliseconds: 500),
      vsync: this,
    );
    _animation = Tween(begin: 0.0, end: 1.0).animate(_controller);
    _controller.forward();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _animation,
      builder: (context, child) {
        // Widget build logic using the animation value
        return ...;
      },
    );
  }
}

To optimize animations, use lightweight animations like Tween animations instead of heavy ones like Hero animations. Properly dispose of animation controllers to release resources and avoid unnecessary computations. Implement animation caching techniques, such as pre-loading and reusing animations, to reduce performance impact.

3. Inadequate Caching and Data Fetching​

​

class MyDataFetcher {
  static final Map<String, dynamic> _cache = {};

  static Future<dynamic> fetchData(String url) async {
    if (_cache.containsKey(url)) {
      return _cache[url];
    } else {
      final response = await http.get(Uri.parse(url));
      final data = json.decode(response.body);
      _cache[url] = data;
      return data;
    }
  }
}

To optimize caching and data fetching, implement proper caching strategies. Utilize Flutter's built-in caching mechanisms, such as cached_network_image, to minimize repeated image downloads. Implement pagination techniques to fetch data incrementally instead of in one large chunk.

4. Simplify Layouts​

​

class MyComplexLayout extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      child: Column(
        children: [
          Expanded(
            child: Row(
              children: [
                Flexible(child: Container()),
                Flexible(child: Container()),
              ],
            ),
          ),
          Expanded(
            child: Container(),
          ),
        ],
      ),
    );
  }
}

To simplify layouts, minimize nested layouts and unnecessary constraints. Use appropriate layout widgets based on specific requirements. Avoid excessive use of Expanded and Flexible widgets when other layout techniques like SizedBox or AspectRatio can achieve the desired results.

Use App Performance Monitoring (APM) Tools​

Monitoring the frame rate of a Flutter app is crucial for maintaining optimal performance and delivering a smooth user experience. APM tools provide valuable insights into the app's rendering performance, allowing developers to identify and address frame rate issues effectively.

Two widely used tools for frame rate monitoring in Flutter are Firebase Performance Monitoring and Appxiom.

Conclusion​

Frame rate issues in Flutter apps can negatively impact the user experience, leading to reduced engagement and user satisfaction. By optimizing widget rebuilds, animations, caching and data fetching, as well as simplifying layouts, developers can ensure a smooth and responsive UI.

Remember to profile your app, optimize animations, simplify layouts, and follow best practices to address frame rate issues effectively. Use APM tools to continuously monitor app performance including frame rate issues. With careful attention to performance optimization, Flutter can deliver exceptional user experiences across various platforms.

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.

Firebase Crashlytics is used in most of the mobile apps to detect crashes. It also reports ANRs in Android with a detailed stacktrace.

Appxiom is a bug detection tool for Android and iOS apps. It captures a range of bugs including Crashes, ANRs, Memory Leaks, Memory Spikes, Abnormal Memory Usage, Frozen Frames, Slow Frames, HTTP API call issues, Screen Load Delays, and much more.

By definition ANR is triggered when the UI Thread gets blocked for 5 seconds or more. Appxiom detects and reports ANRs as and when the issue happens. It provides a chronologically ordered Activity Trail and a detailed Stacktrace that helps in locating where the ANR was triggered.

In Firebase ANRs get captured only when the user opts to Force Quit the app and then reopen it. This selection is done when the dialog message pops up asking if the app should Force Quit or it should wait to see if the UI Thread comes back. That means if the user waits and the UI Thread comes back to normalcy the ANR will not be reported. Also if the user decides to not come back the Firebase will not report the ANR.

ANR detection in Appxiom & FirebaseA detailed write up on how to use Appxiom to detect the root cause of ANR is available here https://www.blog.appxiom.com/post/detecting-and-fixing-anr-in-android-apps.

To know more about how Appxiom can help you in detecting bugs, visit https://appxiom.com. BTW, the tool works seamlessly in development, testing and live phases.