To deliver a really good application a mobile software development team needs an efficient way of capturing and resolving bugs. To do this they need clear bugs raised and the complete picture of what happened when a bug occurs. The bugs are raised by testers or testing teams who can be more efficient if they have a quick and simple way to raise bugs and defects.

I have worked on numerous mobile software development projects and often the teams have pain points around their but process because:

  • testers have to raise bugs using multiple devices
  • bugs do not always have all of the information required to understand what has happened
  • bugs do not have the technical logs or information to help the developer resolve the issue.

All of the above leads to more cost in both time and money for the development team.

What it does

Mobile bug tracking provides an easy and efficient way to deliver mobile bug raising and resolving quickly and easily. It comes in two parts:

Mobile SDK

The SDK allows users of your mobile app to raise bugs and tickets directly from the app. It is really easy to integrate and requires just adding the dependency and then a single line of code to activate. The SDK can be using where it requires users to authenticate (for instance if you had an in house testing team) or with an Admin API key (if you were planning on end users raising bugs and issues).

Starting the Raise Issue The SDK provides a mechanism so that a user (testers) can raise a bug with default out of the box mechanisms like touching the top bar, shaking the device or tapping a "Raise bug" button. This means that when a user comes across an issue they can easily trigger the raise.

Filling out the form the SDK will read the fields from board and reflect those in the app dynamically so you can add the fields you want to capture the correct data from your testers or users. The fields also correctly populate themselves with correct data like options in status fields, user lists etc. This means that bug raising form automatically reflects what is set in Using the SDK you can set default values and restrict or hide certain fields as required.

Submitting the form when a user presses save the SDK will submit the entered fields to the correct columns in Monday, but if you have a file field it will also a Zip file containing the App information, UI Log and Network log.

  • App Information This contains the app icon, build, version number, device name, and bundle id so that you have a complete picture of what the app is running on when the bug occurred.
  • UI Log This contains a history of everything the User did within the app to get to the point that they raised the bug. Including every button that they tapped and where they tapped. You will see in the video and screenshots that the app has intelligently built a log eg. "User tapped on 'Network Request' button" and shows a small red cross on the app where the user actually tapped.
  • Network Log. This contains all of the network requests the app made with their urls, status codes, mime types, duration etc. this is the complete picture of how the app connected with the outside world whilst it was being used.

Item View

The item view is a component that surfaces the Submitted data uploaded from the SDK. It provides a view that surfaces the App Information, Event Log and Networking data in an easy to use way so that you can look through the data easily and quickly. Software teams can also start a conversation about how they resolve issues from the item within the log that caused the issue.


This application means software teams can make the following gains with their bug resolution process:

  • Bugs always have complete network logs so it is easy to check if a bug occurred from a backend or network connectivity issue. This is revealed with the status codes.
  • Identify if slow network activity caused an issue. The SDK monitors the performance of network requests and adds them to the logs for issue diagnosis.
  • Easily check if users raised a bug with the correct version. There can often be confusion if a user is using an old version of the app. The version number is clearly displayed.
  • Even with short manually entered information software developers have more information to resolve the issue
  • all bugs have full UI logs so it is easy to recreate any issues locally for testing as you know how a user used the app

This benefits the software developer team by reducing time taken to resolve issues and saving cost.

How I built it

I built it by first writing a mobile SDK for iOS, this was written in swift and integrated the native code to the APIs. Then I setup a ReactJS Item View component to visualise the data on the monday board. Finally I added a Lambda service to process and handle the files from API to the Item View Component.

Challenges I ran into

  • Capturing the events for the network logs and UI logs was challenging as it required me to use a swizzling technique. This is a very low level part of the iOS Swift Language from Apple but it means that the integration into a mobile app is easy. You just add one line and the SDK handles the rest, no need tagging, no adding custom events, no changing your components just add the line and you are good to go.
  • Processing the ZIP files I had to setup a lambda service so that I could pass the ZIP files to the item view in an easy to use way.

Accomplishments that I'm proud of

The aspects I am proud of are:

  • The easy of integration of the SDK into mobile app. The SDK could also be used as it is a true native SDK client of the Monday APIs.
  • The depth of information captured by the SDK. It captures the full snapshot log and network logs in great detail.
  • Showing touch points on screenshots. I was able to write a function that could add a red cross where the user touched so that developers can see where the user touched the app in their flow.
  • Having a more natural log of what the user is doing "User touched 'Network Button'" rather object ids or tags. This required the SDK to understand which component was being interacted with aka if it is a button, tab bar, table view etc so that it can correctly describe the action.

What I learned

I learnt a lot about the Monday APIs and how they can be leveraged. Writing a full API client in iOS for them has given me a good understand and laid the ground work for more great apps I can build on for mobile. I have also learnt a lot about iOS low level code operation as that was essential to deliver the functionality.

What's next for Mobile Bug Logging

Next is to deliver the Android SDK. The iOS SDK is ready for release.

Built With

Share this project: