...

How to debug mobile apps across devices | MDN Blog

How to debug mobile apps across devices | MDN Blog

As stated above, the steps of the debugging process may not be the end of the mobile app debugging cycle.
An additional parameter to consider in the debugging cycle is the existence of thousands of types of mobile devices.

For instance, in the snapshot below, consider just the screen size as a differentiator in these three devices and observe how the UI design should change accordingly:

A diagram showing UI design on three different devices with blocks as content placeholders. A small, cellphone-sized device has a single column layout, the same content is shown with cards in a tablet-sized device, and a third desktop version shows fullscreen cards and content spanning larger widths.

Screen size is only one area where a mobile device can differ.
If you consider other device characteristics, debugging on multiple devices early in the development lifecycle becomes increasingly important.
Let’s look at some ways that devices may be unique:

  • Extremely high device fragmentation:
    Devices today come with unique specifications, and each of them affects the presentation of an application.

    Some may have different screen sizes, while others work on different processing powers.
    This makes the compilation, execution, and operation of the application vary on various devices.

  • Variation in operating systems: The StatCounter report puts Android and iOS at 99.34% of the world’s mobile market share.
    However, it’s more complicated than testing on two OSes, as each operating system ships a new version to end users yearly.

    Each new OS version includes deprecations, newer APIs, and optimizations in existing methods.
    These changes affect how applications work and are developed and are a potential cause of bugs.

  • Vendor UI modifications: The Android operating system is open-source and welcomes downstream modifications according to mobile manufacturers’ requirements.

    An excellent example of this is Samsung’s One UI.
    The company uses the source code of the newly released Android and makes changes to the UI in-house.
    This makes their devices different from those of other manufacturers.
    Still, a tester should understand that such changes happen because UI elements are designed and analyzed differently in One UI as compared to in ‘vanilla’ Android.

    Therefore, vendor-specific changes can cause bugs in an application’s UI, making it an essential action item in the testing and debugging cycle.

  • Considerable system changes: Many manufacturers have changed the general design of Android (including core kernel functionality) and incorporated that into their devices.
    An example of this modification is the OxygenOS from OnePlus.

    This OS modification can affect the functional aspects of a mobile application, making it work differently on certain operating systems compared to Android.

  • Hardware optimization: Many device manufacturers hire specialists who optimize hardware based on their software for increased performance.
    Optimizations include complete SOC design and development, custom battery discharge rates, and managing heat dissipation.

    All these factors are critical to mobile app behavior.
    Therefore, a bug on one device may appear (or not appear) on another due to these optimizations.

When the above points are combined, it should become more apparent why each device, no matter how different it is from another, must be placed in a device farm and incorporated into all debugging cycles.