mobile app dev

Mobile App Requirements

By: Bruce G. Kreeger

Choosing a Platform

The ideal approach to development is to launch on both platforms; however, that is not always feasible. Sometimes, you will have to develop for one platform first and introduce a second platform later for reasons like time constraints, budget, and resource limitations.

Both iOS and Android offer distinct advantages, but also attract contrasting users. When deciding what platform is best for your mobile app, a key question to ask is: what is the goal and purpose of your application? Is the sheer volume of users the main identifier of success for your app, or is your focus on driving engagement? Choosing the appropriate platform will depend on the goal you’re trying to achieve and how you plan to monetize your mobile app.

If you are unsure which platform works best for you, your goals and your audience, we suggest reading the following resources:

  1. iOS vs Android: Which Platform Should You Build For?
  2. Android vs. iOS User Behavior: How Does it Impact Mobile App Development?

Include Your Maintenance and Upgrade Requirement:


Do not make the mistake of thinking your project finishes after launch. At the very least, you need to plan for the cost of maintaining your app to fix bugs and meet system upgrade requirements. In your PRD, includes a long-term product vision that accounts for user demands, product improvements, and new features for future iterations of the product.


Dependencies are any aspect that the product or product team relies on to meet objectives. These may include:

  1. Hardware that the app will run on/communicate with (for example, beacons)
  2. Service/API documentation
  3. Profile/account/platform credentials
  4. Any third-party software your app relies on
  5. Any flowcharts, documents, or information related to the product


Assumptions typically relate to how product teams suspect users will behave or interact with their product. However, it is important to include assumptions surrounding the business and technical aspects of the product in this section. In the early stages of a project, knowledge, experience, or current information form assumptions. Examples of these assumptions can include:

  1. X% of users will see enough value in the product to become regular users.
  2. Technical requirement A will work on the latest operating system.
  3. We can develop the product within a proposed time frame.



Constraints are the limitations that teams must work within, typically related to scope, budget, and time. However, they may also include aspects like risk tolerance, resources/staff, and quality requirements.



Your mobile app requirements document should include all technical assets and information required for Apple’s App Store submission and Google Play submission. Defining these requirements in the early stages of a project will significantly expedite the submission process when the product is ready for release. While these will vary depending on the app stores being submitted to, below are the assets and information to include for the Apple App Store and Google Play.

General Assets:

  1. Icons of supported sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
  2. Splash screens of recommended sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
  3. Screenshots in the correct dimensions and required languages
  4. App descriptions in required languages
  5. Search keywords in required languages
  6. List of supported devices and OS versions


Apple App Store:

  1. iTunes Connect Account access
  2. Company/Entity Name
  3. App Store app listing name
  4. Search keywords
  5. Bundle id / SKU
  6. Demo account for reviewers
  7. Description
  8. Support URL
  9. Marketing URL
  10. Privacy policy
  11. App category
  12. Copyright information
  13. Contact information
  14. App icon (1024Ă—1024)
  15. App Store distribution provision profile
  16. App Store distribution code signing identity
  17. Screenshots (correct sizes based on devices)


Google Play:

  1. Google Play Developer access
  2. Store listing name
  3. Paid/free
  4. Short description
  5. Full description
  6. App icon (512Ă—512)
  7. Feature Graphic (1024Ă—500)
  8. App type
  9. App category
  10. Content Rating
  11. Contact Email
  12. Privacy Policy
  13. Screenshots (correct sizes based on devices)

Things to Keep in Mind For Your Product Requirements Document:

While going through the process of writing your PRD, some considerations should be kept in mind. Firstly, it is crucial to leverage a variety of experience and insight that comes from multiple team members. Gathering this input will help you develop comprehensive definitions for different sections of your PRD.

Secondly, as you fill in the template, be sure to keep your responses and definitions for each outlined section high-level. While detail is helpful, keep in mind that while specific requirements might seem obvious to you, others viewing the document may have an entirely different perspective. Eliminating industry-specific terms will ensure that everyone can easily understand the document. As the product evolves and requirements change, ensuring everyone understands what you are trying to communicate is key to developing a successful mobile product.

Final Thoughts:


Keep in mind that the best PRDs are adaptive. While this may seem counterintuitive, perfecting a PRD is not easy. This is why following a structure is so important.  Begin the process with the general criteria, your end-user, the problem you’re solving. Then get increasingly more specific, detailing functionalities and desired features for an MVP. The general criteria are what is set in stone, but as you go through the process, be prepared to adapt your more specific requirements.

The goal of creating a mobile app requirements document is to provide a foundation for a successful product. To give your team the ammunition it needs to get your project off the ground, make sure you map out every business and technical requirement and clarify all dependencies, constraints, and assumptions. During development, questions are bound to come up, even with the most thorough PRDs.

During the process of defining the product, it is essential to always focus on delivering superior value to the marketplace. It is easy to get distracted by competitors, vocal customers, and architectural issues, and while you do need to understand those needs, when it comes to defining a great product, always remember to focus on the value.

Clarity is proud to have been providing Mobile Application Development to North America for many years. With the addition of our Dotman Tech division and an extensive team of developers we will continue to surpass expectations.


Call Clarity at 800-354-4160 today or email us at [email protected]. We are partnered internationally around the globe and we are open seven days a week 8:30 AM to 5:00 PM EST/EDT. and

[mc4wp_form id=”314″]


Pin It on Pinterest