3 ways to save time while fixing bugs in your mobile app

Unfortunately, efficiency isn’t always an innate practice on many tech teams, and it’s difficult to figure out where to implement timesaving improvements while balancing other engineering priorities.

To help make it easier, in this post we’ll cover three key ways to save time while fixing bugs in your app.

It’s vital that you run thorough tests on your app both before and after deployment. Unit tests confirm that your methods produce the behavior you expected from the code you wrote. To ensure that you’re delivering the best possible app to your users, you need to ensure that the tests you’re running are comprehensive.

In practice, this looks like tests that are:

• Simple: It’s best to write simple tests that focus on individual behaviors. This helps you easily maintain and potentially refactor these tests down the line, and leaves you room to add new tests for edge cases as they arise.
• Deterministic: Writing a deterministic test means that the test presents the same behavior as long as the code remains unchanged. Writing tests this way allows you to easily understand the issue at hand, serves as an informal history of past issues, and provides information on how to fix them. Then, when you make changes and run another test, you’ll clearly see results.
• Isolated: You should run your test in isolation without any interdependencies or external dependencies for clarity.
• Readable: It’s important to adopt consistent naming conventions for your tests. Remember that your tests also serve as documentation, so your tests should have names that reflect the scenario that they’re testing.
• Fast: Unit tests should be fast to run since a project can have hundreds or thousands of unit tests. If the unit tests are too slow, engineers may be tempted to skip the process and are more likely to deliver code full of bugs.

Now, all of this is a lot to consider, not to mention time consuming. This is where automated testing tools become helpful.

Automated testing tools are helpful because they reduce human error and help speed up a meticulous process. When you’re ready to automate, it’s vital that you look into Continuous Integration and Continuous Deployment (CI/CD) tools. CI/CD is a software development practice that embraces making incremental changes to your code on a frequent basis. CI/CD tools automate the manual work humans would traditionally need to do including the building, testing, and deployment.

Logging and breadcrumbing are two of the most vital practices you can implement when seeking to learn about your users.

Logging plays an important role in identifying, reproducing, and fixing bugs in the most efficient way possible. Logs serve as a primary tool for engineers to discover issues and track events like errors. If you want to make the most of your logging, then it’s important to center your logs around key performance indicators (KPIs) concerning engagement, retention, or revenue.

In practice, this may look like logging:

• Events that directly affect user experience, like signing into your app, requesting a ride, posting a photo, or creating a post.
• Events that directly affect your revenue like checking out, adding items to cart, or upgrading a subscription plan.
• Events that are highly technical or resource-intensive like loading a map, launching a video player, or displaying a product list.

Breadcrumbing is a great way to add even more context to your logs. Mobile breadcrumbs are a lightweight way to add logging to your sessions. It’s lightweight because these breadcrumbs aren’t captured and sent in real-time. Instead, they are part of the metadata that’s collected for an overall session.

A few great examples of when to use breadcrumbs include:

• Tracking the overall app state.
• Tracking local user states like whether they have tapped on a sidebar, navbar, or carousel.
• Tracking the progress of complex actions like taking a call, loading a map, scrolling through images, or filling out a form.

With breadcrumbs and logs at your disposal, it’s important to know when it’s most appropriate to use each. For example, if you want aggregated, searchable metrics for a specific event, then you should choose a log. However, if you only need data when investigating a particular user experience, then you need a breadcrumb instead.

You can be as prepared as possible, but you can’t predict everything that’s going to go wrong with your app. This is when it’s important to have helpful alerts available to monitor the most important aspects of your app and focus your attention on what matters most.

Dynamic alerting capabilities are most helpful here. There are a variety of alert types depending on your specific needs. Some of the most frequently used include:

• Alerts for count-based or time-based events.
• Alerts for stalls, crashes, and abandons.
• Alerts for important groups of users (e.g. paid users versus free users).
• Alerts specifically to those who need to know (e.g. the relevant engineering team) via email, Slack, PagerDuty, etc.

When determining what is most important to alert, poll your team and consider factors that align with your KPIs before instrumenting your alerts.

Saving time is a top priority of mobile engineers, but finding places to optimize your limited resources can be difficult.

Optimizing your testing process, following logging and breadcrumbing best practices, and instrumenting helpful alerts can help free up engineering time so it can be refocused to more important tasks like innovating new features.

Better processes are a large part of the equation, but alignment within your engineering organization is equally important.

If you’re looking for even more engineering insights to better align your team, check out the 2024 Mobile App Builders Report. It analyzes the data from a survey of over 1,000 mobile engineers covering their priorities, frustrations, and tooling concerns and provides insights that can help you improve your mobile app building process.

Download the report here.