Image size and memory limits for HTML IVAs

HTML interactive visual aids (IVAs) and other HTML presentations open in Mobile Locker’s embedded web view. How you export images has a large effect on download size, memory use, and reliability when field users switch between Mobile Locker and other apps.

Mobile Locker is multi-platform (native apps for iPad, iPhone, and Windows, plus browser tools for content management). Most teams present IVAs on iPad—including both 11" and 12.9" / 13" iPad Pro models, and other iPads. The same package can open on iPhone, but teams rarely use iPhone as the primary device for full IVAs. Some organizations use Windows with or instead of iPads.

This guide is for agencies and developers who build or export HTML packages. The numeric limits below are sized for iPad—the usual presentation device. They use the larger tablet class (about 2732×2048, typical of 12.9" iPad Pro) as a practical upper design target, so one package works well across mixed fleets. Meeting them is still the right default for Windows and other clients: smaller assets mean faster downloads and lower memory pressure everywhere.

How HTML presentations use images

1. The presentation is a static web package (for example index.html plus assets) opened inside Mobile Locker.
2. Images load as normal web assets (img tags, CSS background-image, and similar). The web view decodes them at their source pixel dimensions.
3. Decoded memory for a typical bitmap is about width × height × 4 bytes (RGBA). Example: a 5000×4000 image is about 80 MB in memory after decode, even if the file is only a few megabytes on disk.
4. CSS scaling does not reduce decoded memory. Fitting a 5000 px-wide image into a smaller on-screen box still decodes the full source first.
5. Many tablet-first IVAs use a fixed virtual canvas near 2734×2048 (aligned with 12.9" iPad Pro ~2732×2048). That is a common large-iPad canvas—not a requirement that every rep uses a 12.9" device. Assets much larger than that do not improve sharpness on 12.9"/13" models and waste memory on every size of iPad (and on Windows).

Recommended limits (iPad-first)

Treat these as the iPad baseline most teams should meet, whether the field uses 11" iPads, 12.9" or 13" iPad Pros, or a mix. If the package is also used on Windows, use the same limits so you do not ship oversized bitmaps that hurt every platform.

Why 2800 px on the longest edge

Larger iPad Pros are about 2732×2048 (12.9" class; newer 13" models are in a similar range). Capping the longest edge at 2800 px leaves a little headroom for CSS fit while cutting decoded memory dramatically versus 4500–5500 px exports.

11" and other smaller iPads have lower native resolution. They still benefit from the same cap: you do not need bigger bitmaps for larger devices, and smaller devices pay the full decode cost for any oversized asset.

Example: a 5468×4100 background is about 86 MB decoded. Resized so the long edge is 2800, it is on the order of ~30 MB decoded—similar look on device, much less RAM—on every iPad size in the fleet.

Common problems to avoid

• Design exports at 2× “just in case.” Retina density is already reflected in a ~2732×2048 large-iPad target. Doubling again wastes memory on all devices.
• Huge files that look small on disk. A ~1 MB PNG that is 3000×7500 can still decode to ~90 MB of RAM.
• One screen, multiple huge assets. A large background plus a large profile or chart can push 100+ MB decoded for a single view before any modals open.
• Unoptimized photo PNGs. Prefer JPEG/WebP when you do not need transparency.
• Hard-coded paths after rename. If you resize in place, keep the same relative paths so minified bundles still resolve assets.

Verify before you hand off

From the presentation root (the folder that contains index.html and your image assets). If images live somewhere other than images/, change the path in the commands.

# Package and images totals
du -sh . images/

# Largest raster files
find images -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' \) \
  -exec ls -lh {} \; | awk '{print $5, $9}' | sort -hr | head -30

# Any PNG/JPEG with longest edge over 2800 (macOS sips)
find images -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' \) -print0 \
  | while IFS= read -r -d '' f; do
  w=$(sips -g pixelWidth "$f" 2>/dev/null | awk '/pixelWidth/{print $2}')
  h=$(sips -g pixelHeight "$f" 2>/dev/null | awk '/pixelHeight/{print $2}')
  # Skip if sips did not return dimensions
  [ -n "$w" ] && [ -n "$h" ] || continue
  max=$(( w > h ? w : h ))
  if [ "$max" -gt 2800 ]; then
    echo "$max  ${w}x${h}  $f"
  fi
done | sort -rn

Pass criteria

1. No full-art raster image longer than 2800 px on any edge.
2. No single typical (non-document) image over 2 MB on disk; most under 1 MB.
3. Total image assets under about 80 MB (stretch goal under 60 MB for mid-size packages).
4. Spot-check key screens and expanded charts on a real iPad for sharpness—ideally the models your team actually uses (11", 12.9", 13", or a mix).
5. Open the presentation in the Mobile Locker app on the devices your team uses (iPad for most teams; Windows if applicable), navigate main flows, then leave the app and return and confirm the presentation still renders correctly.

Example resize (macOS)

# Cap longest edge at 2800, keep aspect ratio
sips -Z 2800 path/to/image.png

# Optional lossless PNG recompress
optipng -o2 path/to/image.png

Use the same idea in your automated export pipeline (ImageMagick, build plugins, or design tool export presets).

Summary

Right-sizing assets for iPad improves memory headroom, download time, and runtime stability without changing how the presentation looks at display resolution—and keeps packages efficient for teams that also use the Windows app.

For product or upload questions, contact support@mobilelocker.com.