Mobile App Design Company: What Gets Designed, Specified and Handed Over

Updated November 2026 · Written and maintained by the Progression Agency strategy team

An app can look finished in a design file and still stall at the store. App Store Connect refuses screenshots that carry transparency, and Google Play will not publish a listing without a 1024 by 500 feature graphic. A mobile app design company plans for both audiences from the first screen: the developers who build the app need flows, components and measured specs, and the stores need icons and screenshots at their own sizes. Android’s guidance alone sets touch targets at 48dp and text contrast at 4.5 to 1. Progression’s team is based in New York and designs apps for businesses across the US.

Store screenshots refused for a transparent corner

A hypothetical meal planning app had six screenshots ready for its first release. Each had been exported with rounded transparent corners to match a phone frame, and App Store Connect would not take them, because images can’t include alpha channels or transparencies.

The design was right. The export setting was not. Flattened onto a solid background at 1206 by 2622 pixels, the same six frames pass. A team that knows the store rules exports them that way from the first draft.

Why does a good screenshot get refused?

Because stores judge the file, not the picture. A frame that looks perfect in a design tool can still carry transparency, sit outside an accepted pixel size or promise a ranking, and any of those stops a submission.

What a mobile app design company hands over

A handover is a set of files, each with a person who uses it and a rule it has to meet. The table lists them in the order they are usually produced.

Touch targets and contrast, measured before handoff

Android’s accessibility guidance sets touch targets at a minimum of 48dp by 48dp, and larger is better. It sets text contrast at 4.5 to 1 for text under 18sp or bold text under 14sp, and 3 to 1 for all other text. Designers check every button, field and label against those numbers before a file leaves the design tool, because a developer cannot fix a 40dp button the design never marked.

One icon master, two store exports

Google Play takes a 512 by 512 pixel 32-bit PNG up to 1024KB and keeps badges or text that suggest ranking, price or Google Play categories off the icon. Draw one master at the larger size, then export a copy for each store and check each store’s current icon rules before upload.

• Name every handover file by screen and platform.
• Keep the icon master separate from the exports.
• Mark every touch target that sits below its 48dp box.
• List the screens that exist only for errors and empty states.

App Store screenshot sizes without the guesswork

App Store Connect asks for at least one screenshot and takes up to 10 for each device size, in JPEG or PNG. The checklist below covers what a submission needs.

1. Provide at least one screenshot for iPhone with Dynamic Island (medium display).
2. If the app supports iPadOS, provide at least one for the iPad 13-inch display.
3. Use .jpeg, .jpg or .png files, with no alpha channel and no transparency.
4. When the interface is consistent across sizes and localizations, supply the highest required resolution and let App Store Connect scale it down.
5. Keep every screenshot within the App Store Review Guidelines.

Landscape sizes use the same numbers reversed. Design screenshots as their own frames, with headline text, device mockup and background laid out on a solid canvas, rather than exporting raw captures. That gives marketing control of the message and keeps transparency out of the file.

Do both iPhone sizes need separate designs?

Not when the interface is the same across sizes. Supply the highest required resolution and the store scales the rest.

Google Play listing graphics without the guesswork

Google Play Console treats some graphics as required and others as optional. A listing cannot be published without a feature graphic, so it belongs in the schedule from the start.

• Keep ranking, price and award wording off the icon, feature graphic and screenshots.
• Avoid repeating the same message across the short description, screenshots and feature graphic.
• Use a color theme and style that matches the icon and the app itself.
• Check the graphic at phone width, where the message must still be readable.

The feature graphic appears in several places on the store, often smaller than designers expect. A short message at a large size survives that; a sentence does not.

How many Google Play screenshots are enough?

The store allows up to 8 for each supported device type. Use the first few for the main task, because they are the ones people see without scrolling.

App design firm work on an app that is already live

A redesign starts with an audit of the screens as they are. Each screen is measured against the touch and contrast numbers, and the results become a change list ranked by how many people reach each screen.

1. Audit the current screens against the 48dp and contrast numbers.
2. Rank the findings by how many people reach each screen.
3. Redraw the most visited screens first.
4. Release in stages, so each change can be seen on its own.
5. Refresh the store screenshots once the screens they show have changed.

Changing the screens with the most traffic first moves the numbers sooner and leaves the rarely used settings for a later stage.

Will existing users notice a redesign?

They notice what moves. Staged releases keep the main task where people expect it while the surrounding screens improve.

Where iOS and Android screens should differ

Shared flows and brand keep the app recognizable on both platforms. Navigation patterns, back behavior, system controls and typography follow each platform’s own conventions, so people use the controls they already know.

• Keep the same tasks, content and brand voice on both.
• Let each platform handle back navigation its own way.
• Use each platform’s system controls for pickers, dialogs and sharing.
• Apply the Android numbers on this page, 48dp and the contrast ratios, to the Android screens.
• Check Apple’s own guidelines for the iOS numbers before drawing.

For build work on each platform, see iOS app development company and Android app development company.

Can one design serve both platforms?

For flows and brand, yes. For controls and navigation, a design that ignores platform conventions feels slightly wrong on both.

A mobile application design agency inside a build team

Design and development overlap, and the overlap goes better when it is planned. Questions get answered in the handoff file, components carry the same name in design and code, and designers and developers look at the same screens on a regular schedule.

• Name components the same way in design and in code.
• Hold design reviews with developers while screens are still cheap to change.
• Write answers to developer questions into the handoff file.
• Keep the file current after launch.

Design can run beside Progression’s developers or beside yours. For the wider discipline of research, prototyping and design systems, see UI/UX design services, and for a studio spanning products and brands, product design agency.

Do designers need to attend developer meetings?

Often, yes, for the first builds. A designer in the room settles spacing and state questions in minutes instead of days.

How mobile app design is quoted

Mobile app design is quoted per project, after scope. The price is set in the written proposal and is subject to change. An app designing service prices five things, and the proposal states how each was counted.

• Ask how many screens the quote assumes.
• Ask whether store art is included.
• Ask how added states, such as errors, are counted.
• Ask what happens when scope grows mid project.

Why is there no price list?

Because two apps with the same number of screens can need very different work. A figure published without a scope would be a guess.

What to bring to the first design session

Seven things shape the first pass, and bringing them early shortens the planning. Sessions can be remote, or on site on request.

• The main task the app must do.
• Who uses it and when.
• Reference apps you like.
• Logo files, colors and type.
• The platforms you need.
• Store listing copy, if written.
• The launch date.

What if the listing copy is not written?

Then the screenshots carry placeholder text and are redrawn when the copy arrives, which is a normal step.

From brief to handoff file

The sequence matters more than any single deliverable. Each step produces something the next one needs.

Skipping a step usually shows up later as a question from a developer or a message from a store reviewer.

How does design stay on schedule?

By fixing the platform list and the main task first. Both change the scope more than any other decision.

Empty, error and loading screens

Most of an app’s screens are not the happy path. Empty lists, failed requests, offline states and permission prompts are designed with the same care, because they are where users decide whether to trust the app.

• Design what a new user sees before any data exists.
• Write error messages that say what to do next.
• Show progress, not a blank screen, while content loads.
• Explain a permission before the system asks for it.

These screens also feed the store art. A screenshot of a clean, filled state sells the app; the empty state is for the build team.

Who writes the error messages?

The designer drafts them with the product lead, and the handoff file keeps them in one place for developers.

Dark mode, text size and other settings

People change system settings, and the app has to survive them. Dark mode, larger text and reduced motion each change how a screen looks, so the design file shows them.

• Check contrast in both light and dark themes.
• Let text grow without clipping buttons.
• Keep touch targets at 48dp when labels get longer.
• Offer a way to pause or skip motion.

Contrast is the one most often missed. A color pair that passes in the light theme can fail in the dark one.

Does every setting need its own screen set?

No. The component library carries the variants, and the file shows the screens where they matter most.

Frequently asked questions