32 posts tagged with "Bugs"

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 major objective for any app developer is to make sure that their iOS app is smooth and responsive. So, how does one make sure the app is responsive? The rule of thumb is that an application should be able to react to user inputs and touches within 250ms.

If the response time is above 250 ms then the delay becomes apparent and will be noticeable to the app user. iOS documentation categorizes any app response delay that persists for more than 250 ms as App hang.

What developers need is a proper way to identify and fix App hangs. XCode organizer and bug reporting tools like MetricKit and Appxiom report App hangs. Reports generated by xcode organizer and MetricKit are not real-time and they also miss App Hangs at times.

Appxiom reports App hangs that occur in the application in real-time and supports development, Test Flight and App Store builds. Because the reports are real-time, most App Hang situations will be captured.

Analyzing an App Hang Report​

Here are some of the metrics needed for deeper analysis from an App hang report generated by Appxiom,

• Top iOS versions affected.

• Top device models affected.

• First app version where the issue is detected.

• Number of occurrences of the issue.

• Total time for which the app was unresponsive.

• Stack trace to identify the point of hang.

Appxiom provides App hang issue reports with these metrics.

Top OS versions, Device models and countries where App hang was reportedNumber of Devices and total occurrence count of App hang issuePrevious app versions, if any, where the same App hang issue was reportedIn most cases the stack trace provided with the issue should give indication of where the root cause lies.

Stack-trace indicating the point of origin of App hang issueThere could be situations where stack trace alone might not be sufficient. This is when the rest of the metrics help.

Look for patterns like the top OS versions, device models and the app version where this issue first occurred in the issue report. Occurrences count of the issue will provide a sense of how severe the issue is. Using the combination of these, developers will be able to prioritize and create the test device configuration to reproduce the issue.

Next step is to retrace how the user interacted with the app when the issue occurred. Activity trail, which is a chronologically ordered list of events that happened prior to the App hang which is provided with each App hang issue report in Appxiom dashboard. It will have events like the lifecycle of the different viewcontrollers, network changes and state changes of the app along with custom events that are set by the developer.

Activity trail listing events that occurred prior to App hang issue.This will help developers to retrace the app events to identify and reproduce the issue.

How to avoid App Hang situations.​

Now that we know how to detect and fix App hangs, let us explore ways to prevent App hangs.

In order to achieve this the main thread of the app should be free from running intensive operations as the application gets frozen when the main thread is stuck.

Now what this means is, execute only tasks that interact with the user interface in the main thread i.e UIKit, AppKit, or SwiftUI based tasks. So how does one execute other long running tasks? Use background threads directly or either through the operation queue or through the Grand Central Dispatch queue to execute such operations.

Let us take the example of a simple HTTP(s) request and using its response data to update a tableview in the app. It is not just the HTTP(s) request that we execute in the separate thread, but de-serializing the JSON object from the response data should be executed outside of the main thread as well. Only the actual tableview update code needs to be executed in the main thread.

Following this coding practice will lower the possibility of App hang issues in your application.

Appxiom is available for Objective-C and Swift in iOS and watchOS, and for Java and Kotlin in Android. Click here to get started.

ChatGPT is brilliant, and awesome. I asked what I should do to reduce bug fixing time. This is the reply 👇.

•  There are several ways that you can reduce the time required to fix bugs, including the following:

Use automated testing tools: Automated testing tools can help to quickly identify and diagnose bugs, allowing developers to focus their efforts on fixing the issues rather than manually testing for them.

• Prioritize bug fixes: Prioritizing the most important or severe bugs can help to ensure that the most critical issues are addressed first, saving time and effort in the long run.

• Use debugging tools: Debugging tools can help to quickly identify the source of a bug, allowing developers to fix the issue more efficiently.

• Collaborate and communicate: Effective collaboration and communication among team members can help to identify and resolve bugs more quickly, saving time and effort.

• Adopt agile development methodologies: Agile development methodologies, such as Scrum and Kanban, can help teams to quickly identify and fix bugs, as well as adapt to changing requirements and priorities.

Overall, using a combination of these strategies can help to reduce the time and effort required to fix bugs.

 I'm like .. Impressed !!!

Clear, and to the point.

Do as ChatGPT suggests, and you will indeed reduce bug fixing time.

On a side note, Appxiom helps you with first 3 points, and 4th point to an extend.

Now that you are here, I recommend to you this blog post. How to reduce bug fixing time in mobile apps.

Bugs in physical world are beautiful. But in digital world, bugs are unwanted, but they do come uninvited.

We hate bugs in our apps because we need to put extra efforts to fix them.

Let's look at some basic numbers.

A ballpark optimistic estimate of the effort involved in fixing a medium severity bug is as follows.

Activity

Hours

​Collecting data

1.5

Reproducing the bug

0.5

Coding the fix

0.5

Testing

0.5

Total

3

If the effort required can be cut by 1/3rd, for each bug we will save one hour.

With a tool which can auto-detect and report bugs, the data collection can be cut short to 30 minutes from 90 minutes. That's a 1/3rd cut in total effort.

Effort saved => One hour.

If the time required to reproduce the bug and test the fix are reduced by 15 minutes each, that will be half an hour saved. For now let's not add that into this calculation.

Even with a very low estimate of 10 medium severity bugs per month, and with the saving of one hour in data collection alone, we will be saving 10 man-hours. This is equivalent to 1.25 man-days, assuming one man-day is equal to 8 man-hours. So we will save more than one man-day every month.

The actual can only go north by many multiples as the numbers considered here are much below realistic, and that's what we gather from our customers.

Try Appxiom to reduce bug fixing time in Android and iOS apps. Visit https://appxiom.com for more details.

Happy Bug Fixing.

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.

While architecting any software solution, it’s important to focus on below three principles.

• Incoming data is impure unless proven otherwise.

• All data is important unless proven otherwise.

• All code is insecure unless proven otherwise.

To incorporate these principles while building software applications, programmers tend to rely almost entirely on defensive programming, as if it is a divine universal solution. So wrapping entire code in multiple layers of try / catch blocks, verifying the same data at multiple points in the call flow, keeping unused data in memory because ‘all data is important’, and ignoring the 'proven otherwise' part of the principles, are common features in codebase these days. Throwing and catching Exceptions, as the name indicates, are to handle 'exceptions', and using them all over the place is an expensive bad idea.

I (almost) hate defensive programming the way it is done today.

No, I am not at all advocating not to take precautions against failure scenarios and potential security loopholes. We should. But over doing the precautionary measures do have a negative impact on the performance. Many programmers end-up doing exactly that in the name of defensive programming, and screwing up the performance as a result.

Another problem is that the defensive coding techniques end up preventing some bugs to manifest, and such bugs go unnoticed. The bugs will continue to exist, but they are not conspicuous enough. They may end up manipulating the end result, or affect the performance, but still go unnoticed. Even security bugs, though might get prevented from executing, would continue to exist as potential threats in the code. As the developer remains unware of the existence of these bugs, they go unfixed.

Of course, defensive programming has its advantages too. It helps the application much in gracefully handling unpleasant situations arising due to bugs. Also it helps in writing cleaner logging code.

So I very well understand why programmers tend to go for it.

How to make use of defensive programming while still enabling active reporting of bugs and errors? This has been one of the thought processes when we started building Appxiom for detecting and reporting bugs in mobile apps. The bugs have to be reported with as much data points as possible. And there should be a call back mechanism when bugs occur so that the developer can gracefully handle the situation. The entire process should happen in a resource efficient manner utilising less of CPU and Memory. Appxiom is architected based on these concepts.

The way Appxiom is architected helps mobile app developers to handle the buggy situation and also get notified as and when they occur. So they get the advantage of defensive programming and also get enough information to reproduce and fix the bugs.

If you are an android app developer, and use Java or Kotlin, or if you are an iOS developer, and if you use Objective-C or Swift, do check appxiom.com.Happy bug fixing.

Performance Analytics has been a demand from our customers since Appxiom 1.0. Now with the release of Appxiom 6.0 the mobile app developers will get a clear understanding about how the bugs are impacting the installation base. The data is presented graphically and provides insights into the percentage and absolute number of android, watchOS and iOS devices that got affected.

Fig 1: Analysis of bugs and the impact on mobilesThe impact of memory leaks, abnormal memory usages, slow frames and frozen frames, ANR and App Hang, UI thread blocks, network issues, and all other bugs are now presented in a tangible way. Also bugs can be ordered based on the number of devices that are affected. This helps mobile app developers to prioritise bugs and to understand where they need to focus on to improve the performance of the app.

Appxiom 6.0 comes as Android SDK, iOS framework and watchOS framework. It's currently in closed beta, and is expected to go live by 21st of February, 2022. If you would like to request access for Appxiom 6.0, click here.

Any developer who has ever written an Android app must have faced the age old issue of 'App Not Responding' popularly known by the acronym ANR. ANRs are UI/Main thread blocks that prevail for more than 5000 milliseconds. Fixing ANRs require three steps much like any other issue.

1. Get to know the existence of the issue.

2. Get accurate data points to identify the root cause of the issue.

3. Get the issue fixed and release a patch version fast.

Unlike crashes, the problem that we developers face here is in step 2. We at Appxiom figured out a method that will help us get accurate data points to fix ANRs in Android apps.

Let us get started.

Integrate Appxiom.​

The first step is to add Appxiom SDK to the android application. SDK is capable of automatically detecting and reporting UI thread blocks in Android apps out of the box. SDK comes as a Gradle library, and the integration will take only couple of minutes.

Steps to integrate​

1. Add maven tag to your project level build.gradle file.

buildscript {
    repositories {
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:x.x.x'
    }
}
allprojects {
    repositories {
        jcenter()
        maven {
            url "https://appxiomcoreandroid.s3.amazonaws.com/release"
        }
    }
}

2. Add dependencies to the app level build.gradle file and sync the project with gradle files.

releaseImplementation('com.appxiom:appxiomcore:x.x.x@aar') {
    transitive = true;
}

debugImplementation('com.appxiom:appxiomdebug:x.x.x@aar') {
    transitive = true;
}

3. Finally, initialize the SDK in the onCreate function of Application class.

Ax.init(this, appKey, platformKey);

Ax.init(this, appKey, platformKey)

Run the app using Exerciser Monkey.​

Exerciser Monkey is an adb command. It executes random touches and gestures in the app, just as if a monkey is using the app. This will help in detecting abnormalities in the app that regular tests may miss.

It is easy to execute Monkey tool. Run this command from the terminal and wait for the execution to complete. Please feel free to customize these command options.

$ ./adb shell monkey -v-v --ignore-crashes --ignore-timeouts --ignore-security-exceptions --throttle 100 --pct-touch 35 --pct-motion 40 --pct-nav 0 --pct-majornav 0 --pct-appswitch 5 --pct-anyevent 5 --pct-trackball 5 --pct-syskeys 0 --pct-pinchzoom 5 --bugreport 11000

Before executing the command, it is a good practise to keep the app pinned to the screen. This is to make sure that the monkey command does not accidentally close your app.

Once the execution is complete you will get detailed report with the number of ANRs encountered. But as I said at the beginning, it is real hard to identify the exact reason for the ANRs purely from these bug reports.

Appxiom reports ANR as and when they occur, unlike Firebase Crashlytics which report only those ANRs which resulted in the user Force Quitting the app and restarting it.

Identifying root cause of ANR​

So, how do we identify the root cause of these issues. Head over to Appxiom dashboard and look for all issues reported.

ANR reported in Appxiom dashboardStacktrace available with each ANR issue report will help us to identify the exact line that triggered the ANR and to fix them.

Custom ANR threshold to detect shorter UI thread blocks.​

Now, let us take this to the next level. We can use the @AX annotation provided by the SDK to set a custom threshold in detecting UI thread blocks. The value can be anywhere between 500 and 5000 milliseconds. Once set, SDK will report UI thread blocks detected above the set threshold. The default value is 3000 milliseconds.

@AX(ANRThresholdInMilliseconds = 1000)
public class BlogApp extends Application {
    ...

@AX(ANRThresholdInMilliseconds = 1000)
class BlogApp: Application() {
    ...

It is important to note that, monkey tool is not mandatory for Appxiom to detect ANRs. We run the app in any device or simulator and it will detect issues.

One of our customers tells us on how the new improved ANR detection feature helped them identify the root cause. Read it here https://www.blog.appxiom.com/post/identifying-root-cause-of-anr-in-android-apps.

Visit https://docs.appxiom.com for detailed documentation. To know more about Appxiom, visit https://appxiom.com.

Watch this space for more updates.

That computer programs could have errors is a thought as old as computers. In a note dated 1843, Countess Ada Lovelace, world's first computer programmer, explained how Charles Babbage's Analytical engine could generate wrong output not because of any mistake with the device itself, but because it could be given wrong instructions. No wonder one of the most common and important features in programming languages is 'error handling'.

The first ever written reference, as available today, of 'bugs' is in a letter written by Thomas Alva Edison to his colleague in 1878. No, not the living 'bugs'. This is about 'bugs' as in 'failures', 'errors', unexpected results' in the non-living world of atoms and bits.

Edison writes ...

It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise-this thing gives out and [it is] then that "Bugs"-as such little faults and difficulties are called-show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.Those days it meant mechanical errors and problems. First time the term was used in computer domain was in 1947. This was when Grace Hopper reported the root cause of a problem in the electromechanical computer Harvard Mark II to the presence of a moth trapped in a relay. Soon the word entered the common lexicon of computer engineers. Initially the term was used for hardware problems.

But it was the software engineers who took 'bugs' to its current popularity. Now we even have a whole industry built around software bugs. This includes bug detection, tracking, resolution, testing and so on. The objective is to provide the end users with a clean experience by early detection and fixing of bugs. The interesting fact is, as more bugs get fixed, even more bugs manifest.

Team Appxiom is happy and proud to be part of this 'bug' industry.

Happiness is ... your customers coming back with stories of how your product helped them in solving their problems.Team Appxiom consider ourselves to be lucky as we do get such feedback. Of course we get reasonable share of critical feedback too. Most of our features evolved from problem statements conveyed by customers during our interactions.

ANR issues in Android apps.​

One of such problem statement was regarding ANR in Android apps. While there are tools that will tell you if an ANR exists or not, none of them help you in identifying the root cause. Our co-founder Don Peter spend much time in trying to identify a solution. And he did come up with a good solution.

"Root cause of ANR issues identified", says team members of a leading mobile app.​

​

One of our new customers, a very popular mobile app, had ANR issues being reported from their testing tools. They use Monkeyrunner extensively and the logs showed a bunch of ANR issues. Initially they thought third party SDKs like Appxiom could be the problem. But ANR issues were still reported indicating issues are within the app. So they reintegrated Appxiom and checked the dashboard.

I can only guess how happy they were when they saw ANR issues reported by Appxiom had pointers to the exact root cause. And mails from the developer and QA lead reflected their satisfaction and happiness 🙂.Appxiom provides cleaner stack trace that identifies root causes of ANR issues in Android app, says the developerAppxiom helped in identifying the exact root causes of ANR issues in Android app, says the QA leadTo know more about how Appxiom detects and reports ANR issues in android apps, here is an article by Don Peter. https://www.blog.appxiom.com/post/how-to-detect-and-fix-anr-in-android-apps

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

Have you ever thought about the importance of a medium in the communication process? A medium, as we know, is a channel through which information is circulated between the sender and the receiver. What if the medium encounters a problem? It then becomes a barrier to an effective communication process.

Similarly, an HTTP API call acts as a medium of communication between the mobile app and the server. Failures in HTTP calls are critical as it affects the functioning of the app, which may lead to users uninstalling the app.

What could be the reasons for HTTP request failure?​

Consider a scenario where your app user types all the required credentials in the login screen of your Android app and taps on the login button but nothing happens. As the page becomes unresponsive, chances are your users may uninstall your app never to return. We consider HTTP call issues as fatal issues right up there along with app crashes.

How to overcome this situation?​

​

HTTP request failures can occur when the app sends incorrect data to the server, delayed calls, exceptions thrown during an HTTP call or even executing duplicate HTTP calls. The thing to note here is that developers need to be notified of such issues in real time.

Now the question in your mind will be, should I use a bug reporting tool to manually call functions to report HTTP request issues on every callback block? Well that is messy and time consuming.

Instead, an automated HTTP request tracking mechanism will serve the purpose.

By enabling the HTTP tracking mechanism in Appxiom SDK with a single line of code, developers will be able to monitor for failures in all okhttp based API calls originating from the application.

//Current OkHttpClient code.
client = new OkHttpClient.Builder().build();

import com.appxiom.android.appxiomcore.OkHttp3Client;

...

//Appxiom based OkHttpClient code.
client = new OkHttp3Client(new OkHttpClient.Builder()).build();

//Current OkHttpClient code.
var client = OkHttpClient.Builder().build()

import com.appxiom.android.appxiomcore.OkHttp3Client

...

//Change to Appxiom based OkHttpClient code.
var client = OkHttp3Client(OkHttpClient.Builder()).build()

Please find our detailed Java and Kotlin documentation on enabling HTTP tracking with libraries like OkHttp, Retrofit and Volley.

​

Are the developers getting notified of HTTP issues enough?​

​

The answer is a big No.

The next logical step is to be able to reproduce and fix them fast. In order to accomplish this, we need to have access to precise data points involved in the execution of an API call.

Appxiom SDK is capable of generating detailed bug reports with data points like complete URL, URL parameters, status code, request body and request-response headers.

But what about user sensitive data?​

​

Making sure that privacy and security is maintained is of utmost importance especially when dealing with HTTP request monitoring. Most of the HTTP calls will have authorization tokens and other sensitive data in the header fields. The tool that is used to track HTTP requests should have a way to mask the sensitive data from the application side itself, which will prevent this data from reaching third party servers.

Appxiom provides a simple and easy to use @AX annotation to enable filtering such sensitive data and prevent it from being sent to the Appxiom dashboard. Please find our detailed Java and Kotlin documentation.

@AX(maskHeaders = {"X-Key", "Accept"})
public class BlogApp extends Application {
        @Override
        public void onCreate() {
                super.onCreate();
                Ax.init(this, appKey, platformKey);
        }
}

@AX(maskHeaders = {"X-Key", "Accept"})
class BlogApp: Application() {
        override fun onCreate() {
                super.onCreate()
                Ax.init(this, appKey, platformKey)
        }
}

Apart from these, data points like device and device state data along with activity trail will also be included with every issue report.

Appxiom is capable of detecting HTTP request issues in iOS and watchOS apps. Apart from this, SDK is capable of detecting and reporting crashes, frame rate issues, ANR, function failures, feature failures, memory leaks, abnormal memory usage, exceptions and custom issues. Appxiom is available for Android as Java & Kotlin SDK, iOS as Objective-C & Swift Framework and watchOS as Objective-C & Swift Framework.

Visit appxiom.com to learn more about Appxiom. Detailed documentation is available at docs.appxiom.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.

We all know how difficult it is to build an app from scratch. In fact, you might be in the middle of building an app as you read this blog post. From working on the basic idea, conducting market research, deciding on the platform, fixing bugs at the development time, testing the beta version and finally releasing it, each process is tedious and time-consuming.

Then you spend a lot of time formulating various digital marketing and outreach initiatives to market your app and finally succeed in attracting users to sign up and use the app. But then, a section of users start complaining that the crucial feature in your mobile app fails.

Understandably, you would now be in a hunt to find out what could’ve gone wrong. But in most cases, you may not even be able to reproduce the issue or to identify where exactly the issue occurred in the code because of lack of data points.

Identifying the issue before app users report them​

Now the question is, is there a way to identify such failures even before the users start leaving poor reviews on play store?

This is where the feature tracking mechanism in Appxiom comes in handy. With feature tracking enabled, Appxiom SDK will notify developers when a tracked app feature fails.

How does Appxiom report such feature failures?​

Making use of feature tracking API, developers will be able to chain multiple functions and track feature failures in Android apps for failures.

Overview of how Appxiom SDK help report feature failuresLet us consider the example of an application like WhatsApp or Facebook messenger that allows users to chat with each other. In order to track its messaging feature, we chain the send and receiveAcknowledgement functions in our codebase using the API provided by the SDK.

Once chained, Appxiom will monitor if the end function is triggered after the execution of the start function within the expected time which can be set by the developer with milliseconds precision. In case the end function is not executed within the expected time, Appxiom will report it as an issue to the dashboard immediately.

// Function to be executed when user types a text message and clicks on send button.
    // Replace traditional function call with Ax.call() API.
    Ax.call("messageTextFromUser", ChatActivity.this,         
                                    chatEditText.getText());
}
 
// By using @AX annotation, chain the start function 'messageTextFromUser' and the end function 'messageSentSuccessfully'. Appxiom will raise an issue report if the end function is not executed within the expected execution time.
 
@AX(nextFunctionId = "messageSentSuccessfully",
            nextFunctionClass = ChatActivity.class,
        expectedChainedExecutionTime = 5000)                            
public void messageTextFromUser(String message){
    ...
}



    // Function to be executed once the text message is successfully sent.
    // Replace traditional function call with Ax.call() API.              
    Ax.call("messageSentSuccessfully", ChatActivity.this,         
                                    conversationIdentifier);
}
                                    
public void messageSentSuccessfully(Object conversationId){
    ...
}

// Function to be executed when user types a text message and clicks on send button.
    // Replace traditional function call with Ax.call() API.
    Ax.call("messageTextFromUser", this@ChatActivity,         
                                    chatEditText.getText())
}
   
// By using @AX annotation, we chain the start function 'messageTextFromUser' with the end function 'messageSentSuccessfully'. Appxiom will raise an issue report if the end function is not executed within the expected execution time.
                                                                
@AX(nextFunctionId = "messageSentSuccessfully",
            nextFunctionClass = ChatActivity::class,
        expectedChainedExecutionTime = 5000)                               
fun messageTextFromUser(message :String){
    ...
}
    

    
    // Function to be executed once the text message is successfully sent.
    // Replace traditional function call with Ax.call() API.        
    Ax.call("messageSentSuccessfully", this@ChatActivity,         
                                    conversationIdentifier)
}
                                    
fun messageSentSuccessfully(conversationId :Object){
    ...
}

Please find our detailed Android documentation to find out how to chain functions to track feature failures.

In-depth data points to reproduce and fix the issue​

The activity trail which is a chronologically ordered list of app events along with function parameters that were passed to the tracked function at runtime will help identify the root cause of the issue.

Apart from these, data points like device and device state data will also be included with every issue report. These in-depth data points will enable developers to reproduce the issue and fix them fast.

Appxiom is capable of detecting feature failures in iOS and watchOS apps. Apart from feature failures, SDK is capable of detecting and reporting crashes, API call issues, frame rate issues, ANR, function failures, memory leaks, abnormal memory usage, exceptions and custom issues. Appxiom is available for Android as Java & Kotlin SDK, iOS as Objective-C & Swift Framework and watchOS as Objective-C & Swift Framework.

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

While using an app, users expect it to be highly responsive and fast loading. At times apps may take an abnormal amount of time to open a new screen. In Android, this issue is known as screen load delay.

Normally screen load delay occurs in Android apps when the main thread consumes a lot of time to execute complex processes while loading a new activity or a fragment.

Screen load delays affect the user experience, but they go unnoticed by developers and cause users to even rate the app poorly on the android play store. Therefore, it is important for developers to be notified about screen load delay at the earliest.

This is where Appxiom comes in.

With a simple 3 step integration process, Appxiom SDK for Android apps is capable of automatically detecting screen load delay. For more detailed integration guide, visit our documentation pages for Android (Java & Kotlin)

Detecting screen load delay with the help of activity trail​

When an activity or a fragment in an Android app takes more than 6 seconds to load, Appxiom immediately reports it as an issue. Bug reports from Appxiom include relevant data points like activity trail, device and device state data, that will help developers to reproduce the bugs faster.

Activity Trail​

Activity trail is a chronologically ordered list of app events, that will aid the developers to understand the user flow for a minute prior to the occurrence of the issue.

Activity trail has three components

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

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

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

Screen loading delay reported by Appxiom SDK for AndroidThe above screenshot shows that Appxiom SDK has detected a delay in the loading of ‘ChatActivity’.

To identify the root cause of the issue, let us take a close look at the activity trail. Here 'ChatActivity:onStart' started after the event 'ChatActivity: loading user from db' with a gap of more than six seconds. The delay is caused during the event 'loading user data from the database' and this information gives a clear direction on what the fix should be.

Fixing screen loading delay​

It is better to execute all time-consuming processes like database operations, I/O operations and calculations through separate threads. This approach will help in avoiding such delays.

Appxiom also detects screen load delay in iOS and watchOS apps. Apart from screen load delays, Appxiom is capable of detecting API call issues, ANR issues, memory leaks, abnormal memory usage, function failures, crashes and custom issues.

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