You're developing a mobile app. How can you explain compatibility constraints to non-tech stakeholders?

It's always challenging for a team to convey the compatibility issue to non-tech stakeholders. But you must convey your message with proper data and resources. For example if you want to say something about an Android screen size issue,you can use a reference from Android Developer Portal directly and show it to your partner or client. That will validate your points and hope they will understand it properly. Secondly always prepare with some alternate solution which can be used to reduce the compatibility issue. That's more important.

There are hundreds of Android manufacturers with thousands of models, each with different hardware, screen sizes, and Android versions. Initially, it’s hard to make an app suitable for all devices since testing can only cover a few models. Start by developing apps on Google-recommended phones like Pixels, and ensure they work on lower configuration phones and older OS versions as well. Be aware of restrictions in new Android OS versions as they become more secure. Use tools like Firebase Crashlytics to track crashes and bugs, and fix them over time. This approach will help make your app stable and compatible with most models eventually.

Android devices come in thousands of models with various screen sizes, including phones, foldable devices, tablets, watches, and TVs. Your app design should adapt to all these screens. Maintain brand consistency but avoid identical designs for different screens. Colors may appear differently on lower-end vs. high-end devices due to varying resolutions. Instead of fixed size values, use weights and percentage fractions for design elements. This approach ensures a seamless user experience and better engagement across all devices.

In mobile development, we usually use third party services for various features and functionalities. If we need to utilize a third-party services for the feature we want to build, we need to make sure whether the service is well maintained or not. Or even is it depreciated or not. In my opinion, a better way to communicate this to non-tech stakeholders is to associate it to users experience. If the service or software is outdated, discontinued, or not maintained well, then it will have a huge impact where users may find bugs and gets frustrated using it. This way they can understand the magnitude of the problem in dealing with such kind of constraint. We should either use another, build from ground-up or modify the requirement.

Testing is crucial for finding bugs and ensuring compatibility. Writing tests might take longer than coding, but it’s worth it. Focus on edge cases and verify tests before each release. Developers may unintentionally make changes that affect other parts of the app; tests help catch these issues. Use layout inspectors to check UI recomposition and design on various devices. Employ different types of tests, such as unit, instrument, and end-to-end testing, to achieve thorough coverage. This approach ensures your app works well for all users.