Skip to main content
How-To11 min read·2,039 words

Placeholder Image Generator for App Mockups

Use a placeholder image generator and realistic app copy to expose text, image, locale, loading and empty-state failures before engineering starts.

#how-to#mobile app design#assets#placeholder content design#lorem ipsum alternative#ios#android
floow.design Team

floow.design Team

Mobile Design·

Use a placeholder image generator to fill every mobile mockup with production-shaped images, the longest realistic strings, and locale-correct names, prices, and dates. Replace lorem ipsum because its word lengths and punctuation do not reveal truncation, wrapping, or hierarchy failures. Match each image slot’s exact aspect ratio, then design full, loading, and empty states for the same screen. Test Android’s en-XA and ar-XB pseudo-locales before handoff, and verify every label survives the target locale’s real formatting rules.

Key takeaways

  • Android en-XA and ar-XB pseudo-locales expose expansion and right-to-left layout failures.
  • A 4:5 image slot needs a 4:5 placeholder, such as 1080 × 1350 px.
  • Test the longest approved realistic string in every fixed-width text slot.
  • iOS ContentUnavailableView provides a named pattern for no-content screens.
  • Locale-aware formatters should render prices and dates instead of hard-coded strings.

This guide is for mobile UI/UX designers, founders, and engineers who can already create iOS and Android screen mockups.

Time: 35 minutes · You'll need: A mockup of one iOS or Android screen with its text styles, A content sheet with representative names, titles, prices, dates, and counts, Target locale list, including one right-to-left locale when supported, Image editor or floow.design Placeholder Image Generator, Android Emulator for en-XA and ar-XB pseudo-locale checks

What's on this page

  1. Replace lorem ipsum with a realistic copy set
  2. Measure the longest realistic string
  3. Generate mockup placeholders at production ratios
  4. Design full, loading, and empty states
  5. Format locale-specific placeholder content
  6. Reference table

Using placeholder content in app mockups

1. Replace lorem ipsum with a realistic copy set

Create a small content sheet before placing any text. Include 8 to 12 realistic examples for each variable: person names, product titles, locations, prices, dates, notification counts, and error messages. Use actual sentence punctuation, capitalisation, numerals, apostrophes, and currency symbols. Lorem ipsum is a poor lorem ipsum alternative because its repeated Latin word shapes hide the uneven word lengths, short function words, long nouns, and mixed character widths that determine real line breaks.

Put a complete content set into one representative screen, not only its cards. A two-word Latin label can make a 44 pt-tall iOS list row look finished while a real two-line title pushes the metadata below its baseline. Include an action label such as “Continue to payment” rather than “Submit”; button width, truncation, and visual priority change with actual language. Keep the source copy visible beside the mockup so engineering can distinguish fixed labels from server-provided fields.

Tip: Use a real support or catalog export with personal data removed; invented names tend to be too uniformly short.

2. Measure the longest realistic string

For each fixed-width field, sort the approved content sheet by rendered character count and place the longest realistic value in the mockup. Test the maximum product title in a 2-line card, the longest account name in a 1-line navigation header, and the longest price presentation used by the target locale. Do not design from the shortest label: it proves only that empty space exists.

Define the intended overflow behaviour on the screen itself. For example, specify “title: maximum 2 lines, tail truncation after line 2” or “account name: 1 line, tail truncation.” Android text layouts can use maxLines with ellipsizing, while iOS text may truncate according to the configured line-break mode. If a string needs a third line, decide whether the card grows, the field truncates, or the content model changes. Do not leave that decision to a default implementation.

Run the same screen in Android’s en-XA pseudo-locale. Android uses this pseudo-locale to reveal strings that expand during localization, making it a useful check after the longest source-language string fits.

Tip: A label that only fits after reducing its text style is usually a content-priority problem, not a typography problem.

3. Generate mockup placeholders at production ratios

List every image container by its rendered aspect ratio, then create a mockup placeholder at that same ratio. A square avatar needs a 1:1 source; a feed image shown at 4:5 needs a 4:5 source; a video thumbnail shown at 16:9 needs a 16:9 source. Do not drop a 1:1 grey box into a 4:5 slot and call the layout tested. The production crop may cut off a face, a product label, or the only high-contrast area needed for readable overlaid text.

For the manual method, make a raster frame at the intended ratio, add a visible subject boundary or focal marker, and export it at a size such as 1080 × 1350 px for a 4:5 fixture. Use at least three image types: high-detail photography, low-contrast photography, and a deliberately awkward crop. This reveals whether gradients, badges, and text overlays still work.

When you need a fast fixture, hand off to floow.design’s free Placeholder Image Generator at /free-tools/placeholder-image-generator. It can produce PNG, WebP, or a sub-kilobyte SVG data URI at the dimensions you specify; the manual ratio check remains the same.

Tip: Put a face or product edge near the crop boundary in one fixture, because centred subjects flatter image containers.

4. Design full, loading, and empty states

Create three frames for the same route: full content, loading, and empty content. Keep the app bar, navigation, title, and primary action consistent unless the state genuinely changes their purpose. In the loading frame, show the geometry users will receive: the same card count, image ratio, title line count, and spacing as the full state. A generic spinner centred on an otherwise blank screen does not test layout shift when the first response arrives.

For iOS, use the Content Unavailable pattern when a screen has no content and explain what is unavailable plus the next useful action. For Android, write a distinct empty-state message for “no saved items,” “no search results,” and “offline”; these states require different recovery actions. Make each state visible in the handoff file with a named variant such as Search / Full, Search / Loading, and Search / Empty.

Also include an error state when the screen depends on a network request. A loading placeholder should not imply that content will appear if the request can fail or return zero results.

Tip: An empty state with a primary action needs a realistic action label; “Try again” and “Browse products” imply different product paths.

5. Format locale-specific placeholder content

Choose one target locale per mockup variant and format every variable through that locale’s conventions. Do not type $1,299.00, 03/04/26, or John Smith as universal defaults. A US locale can render a date as 3/4/26, while a date written as 03/04/26 is ambiguous without locale context. Use locale-aware sample data for currencies, dates, times, decimal separators, names, addresses, and phone numbers.

On Android, use locale-sensitive formatting APIs rather than assembling currency and date strings from fragments. Android’s localization guidance also calls for testing ar-XB, its right-to-left pseudo-locale, so check icon placement, text alignment, back affordances, and mixed Latin-number strings. On iOS, use Foundation formatters or FormatStyle in the product and use the resulting output in the mockup fixtures.

Make a second variant for a locale that changes reading direction if the app supports it. Mirroring a screen image without checking component semantics can put a trailing action, progress indicator, or directional icon on the wrong side.

Tip: Keep currency values as numbers in the content sheet and generate display strings per locale; one hard-coded price cannot test localization.

Reference table

Placeholder image test fixtures

Image slotExact ratioFixture dimensions
Avatar or square tile1:11200 × 1200 px
Feed or product image4:51080 × 1350 px
Video or media thumbnail16:91600 × 900 px

Do it with the free Placeholder Image Generator

Build placeholder images at any size as PNG, WebP or a sub-kilobyte SVG data URI — no third-party service.

Open the Placeholder Image Generator → — free, no sign-up.

Common mistakes

Using one short Latin phrase for every title and button.

Use approved, realistic strings and test the longest one in each constrained field. Define line count and truncation behaviour where content cannot grow.

Using placeholders with convenient crops instead of production ratios.

Create each fixture at the slot’s exact ratio. Include an off-centre subject and low-contrast image to test crop and overlay failures.

Showing only the populated screen in the design file.

Add loading, empty, and error variants for the same route. Preserve the real card geometry in loading so layout shifts are visible.

Hard-coding US price and date examples for every market.

Generate display values with the target locale’s formatting conventions. Test Android en-XA and ar-XB when the app will be localized.

Frequently asked questions

What should I use instead of lorem ipsum in an app mockup?

Use realistic content samples that match the app’s actual names, titles, prices, dates, counts, and messages. Include the longest approved value for each constrained field and preserve real punctuation and numerals. Lorem ipsum is useful only as an early shape marker; it cannot validate wrapping, truncation, localization, or content hierarchy.

How do I choose dimensions for a placeholder image generator?

Choose the exact aspect ratio of the image container, then enter any dimensions that preserve that ratio. A 4:5 card can use a 1080 × 1350 px fixture, while a 16:9 media card can use 1600 × 900 px. The ratio matters because it determines crop behaviour; export format does not change the layout test.

Do I need loading and empty states in a mockup?

Yes, a production-ready mobile mockup needs full, loading, and empty states for every data-dependent screen. Loading verifies reserved geometry before data arrives, while empty content explains why no results exist and what action is available. Add an error state when a request can fail rather than return an empty result.

How do I test placeholder content design for localization?

Test locale-formatted names, prices, dates, and numbers, then run Android en-XA and ar-XB pseudo-locales. The pseudo-locales help expose text expansion and right-to-left layout problems before translation begins. Do not judge a localized layout from a manually typed US-style date or dollar amount.

Where this leaves you

A useful stand-in is deliberately inconvenient. It contains the title that reaches the second line, the photo whose focal point is near the crop edge, the empty result that needs a recovery action, and the date format that changes across markets. Those fixtures turn a polished static screen into an implementation test for iOS and Android. Save the full, loading, empty, and error variants beside the same content sheet, then replace every flattering placeholder on one priority user flow. The next action is to choose that flow and populate its narrowest text field with its longest realistic value.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

Related

Sources

Design your mobile app with AI

Generate pixel-perfect iOS & Android screens in seconds. Export to Figma and ship faster.