97 posts tagged with "iOS"

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.

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.

Friends, I would like to share an incident where I failed as a programmer.

I got my first freelance project​

After my college days, I began working as a freelance developer. I got my first project from my LinkedIn network. I was in charge of developing both the mobile app, and the backend. The core feature of the app was implemented with a periodic data fetch from the server and displaying it to the user.

​

And the dreaded moment came knocking​

A month of development work, and the application went live. We got some traction. And negative comments started appearing in the Play Store. A good number of users said they were not able to view the data !!!

Tested the app multiple times only to find out that it was working as per the expected workflow. This made us scratch our heads as feedback suggested our core feature was failing. Client started yelling at me during the project calls.

Many days of testing and in-depth analysis, we concluded that the data loss would have occurred due to some raise-condition in fetching and deleting data. The client had suggested removing the data from the server after it was consumed by the mobile app. I communicated the same to the server team and they made sure data is removed as soon as the data is retrieved by the app.

So this is what was happening. App sends a GET request to fetch data. After sending the response, the server then goes ahead and deletes the data. As per plan, yes !!! Now, if there is a network issue or any delay in receiving the response, the app sends the GET request again only to find the data is already deleted.

The app lost customers, and our client dropped the project before we could fix it.

​

Years passed, And I became a better developer​

As time progressed, I started working on multiple programming languages, read RFC specifications and got experienced on software architectural patterns. Working on different products at scale enabled me to understand the need to properly architect a product. As I began to learn more about API design, It made me rethink what actually went wrong in my project.

The first mistake that I made was not recognizing the lifecycle of data that is to be deleted. Once the app receives data from the server, the data should be deleted only after the app sends a confirmation back to the server. The second mistake was that I executed multiple tasks in a single API call. Here, a single HTTP GET call was used to fetch and delete the data at the same time. Using GET requests to delete data goes against the intention of GET in HTTP spec. The app would have functioned smoothly and data loss would not have occurred if one HTTP call was assigned to fetch the data and another call was made to delete the data.

This is just one among the many instances where poor product architecture messed up the product.

Why am I writing this post? Because I see some of the product companies rushing through product development without focusing on the architecture. Spending quality time to understand the lifecycle of data and architecting the solution accordingly helps much. As a developer it will save you from embarrassment.

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 hard to find issues developers come across in iOS apps is frame rate related issues. These issues are often overlooked, which tend to affect the user experience and smooth functioning of iOS apps.

Before we dive head first, let us take a look at some of the basic terminologies.

Screen refresh rate and Frame rate​

Every device with a screen has something called screen refresh rate. It is the number of times the screen gets refreshed in a second which is measured in Hertz (denoted Hz) and is hardware-specific.

Whereas frame rate refers to the number of times UI frames are updated within a second. This is measured in frames per second or fps.

Higher the screen refresh rate, smoother will be the user experience for events like scrolling, gaming animation, switching over between apps and other UI events.

Screen refresh rate in a device remains constant which is generally around 60 Hz to 120 Hz depending on the type of device, while the frame rate can vary. Ideally, both screen refresh rate and frame rate should be the same in order for the user to experience smooth animations and to have fluid interactions with the app.

But there may arise situations where the screen content may not get updated as often as it is capable of. This is called frame rate dips. Frame rate dip occurs in an iOS app when resource-intensive tasks are executed in the UI thread. In such situations, frame rate in an iOS device with a screen refresh rate of 60 Hz can become less than 60 fps.

Reasons for frame rate bugs in iOS apps​

Normally, frame rate bugs occur in iOS apps when the UI thread/ main thread, that is responsible for updating the user interface (UI) and processing user input events, gets stuck for a few milliseconds or even seconds.

Some of the scenarios that can cause UI thread block are when blending pixels with multiple values, off-screen rendering or even adding misaligned images to a view.

I am planning to write a separate blog post on each of these individual scenarios that cause frame rate bugs next.

​

So how do we detect frame rate issues?​

Appxiom is an automated bug reporting tool that is capable of detecting frame rate issues without the need for profiling the entire application.

With basic integration, Appxiom development mode SDK is capable of monitoring UI/main thread. Whenever the UI thread gets stuck in iOS apps, Appxiom detects and reports it. For more details, please visit our documentation pages on Objective-C and Swift.

Initializing Appxiom in Objective-C​

#import <AppxiomCore/Ax.h>

- (BOOL)application:(UIApplication *)application         
                    didFinishLaunchingWithOptions:
                       (NSDictionary *)launchOptions {

    [Ax initialize:application];
    return true;
}

Initializing Appxiom in Swift​

import AppxiomCoreSwift

func application(_ application: UIApplication, 
            didFinishLaunchingWithOptions launchOptions: 
               [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    Ax.initialize(application)
    return true
}

Developers can also use inbuilt tools like Time profiler and Core Animation in Xcode Instruments to identify the root cause of frame rate issues and avoid them in iOS apps.

The only way to avoid frame rate issues in iOS apps is by ensuring that the UI thread has very less burden and all time-consuming processes are executed in separate threads. Most of the modern apps target 60 frames per second which is equivalent to 16.67 milliseconds per frame. Hence developers need to make sure to set app drawables at this stable frame rate.

Apart from frame rate issues, Appxiom also detects API call issues, memory leaks, abnormal memory usage, function failures, and delays along with custom issues and crashes. To know more about how Appxiom detects and reports ANR issues (an extension of frame rate issues) in Android apps, please read our blog post on How to detect and fix ANR issues in Android apps.

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