5 Steps to Troubleshooting iOS Applications

When your users are facing issues, how do you go about troubleshooting? The first step is to recreate the issue so that when you think you’ve fixed it you can actually test to confirm. Sometimes even recreating the issue is a challenge because some issues are very specific combinations of devices, OS, app version, account information, or workflows.

Depending on the complexity of the issue you may need to gather quite a bit of information in order to identify the cause and come up with a solution.

Below are some of the key steps we take when working on a complicated issue. Steps 1 and 2 are really just to be able to create the problem – preferably with minimal impact on the user.

Step 1: Gather information from the user

The first step is pretty obvious, try to figure out what the user was doing that lead to the issue. It could be a complicated workflow, an unexpected chain of events, or a normal user story that is simply failing on a certain device.

Start by gathering the following information from the user either by asking them directly or capturing this information via remote logs:

  1. Device
  2. OS version
  3. App version
  4. Internet connection (if applicable): 2G, 3G, LTE, Wifi
  5. Date & time of issue: this information is used to lookup server logs
  6. Screenshots of the issue
  7. Username and password (if applicable and only if necessary)
  8. Specific records being accessed at the time (if applicable): some issues will be related to specific records that may be corrupted or otherwise not handled correctly
  9. Crash logs from iTunes or remote crash logging services: we highly recommend setting up remote crash logging as it’ll keep track of crashes and provide powerful analytics
  10. Available memory on device and how much memory your application is using (screenshot of the settings screen helps here)

Pro tip: using services like TestFlight or Hockey App you can get remote logs and during beta testing you can even see which user faced the issue. This is a major time saver for both developers and users.

Step 2: Watch the user recreate the issue

If the above information you’ve gathered about the affected user(s) doesn’t help recreate the issue, then watching the user recreate the issue in real-time will help. If you’re able to physically sit with the user while they recreate the issue that’s preferred; however, if they’re remote then you can ask them to recreate the issue while in a conference call.

Using software like AirServer, the user can turn their computer (Mac or PC) into a Air Play server and mirror their iPhone/iPad/iPod Touch. This will enable you to watch them tap through the screens, switch orientation, and so on as they recreate the issue.

Step 3: Recreate the problem

Steps 1 and 2 are really aimed at recreating the problem. It’s very important that the development and QA teams be able to recreate the problem consistently on their test devices. This will make it easier to troubleshoot and confirm once the issue is resolved. This is also the stage where you test on several devices and operating systems to see how widespread the issue is.

Step 4: Resolve the issue and test

Once you have confirmed recreate steps, now you can work to resolve the issue and conduct QA to ensure no other issues have been created. This is a good time to create some additional unit tests or test cases to ensure this issue does re-appear down the road.

Step 5: Deploy the fix

After the issue has been resolved on a test system, it’s time to deploy. Depending on your relationship with the user, this is a good time to test the fix on the production environment and confirm that the issue has been adequately resolved. It’s very important to test once again after deployment as the test environment may behave differently from production.


1 reply
  1. Vipul Kulshrestha says:

    It may be useful to also ask for information on which other applications, if any, were running on the phone at the time.

    Many times, some issues occur after a system or app update, so this too may be relevant to know.

Comments are closed.