Lottie iOS and Android Compatibility Checklist Before Handoff

1. Name the SDK and minimum app targets

Ask the mobile developers which packages the application uses before production begins. Record the exact versions, integration approach and supported operating-system targets. If the product has a shared application layer, identify which native or wrapped player ultimately renders the animation. “We support mobile” is not enough information to prepare a reliable export or to reproduce a later problem.

The official Lottie iOS and Lottie Android repositories provide the starting documentation for those libraries. They are separate implementations with their own integration guidance. Check the documentation and release information for the versions actually used by the client; do not copy a setup instruction from an unrelated web example and assume it applies to a native app.

Define where the animation appears. An onboarding sequence, a compact payment result and a persistent loading treatment need different acceptance scenarios. Note whether the screen can rotate, whether it appears in several layouts and whether the application can revisit it without restarting. The designer needs this context to choose useful resting states and the developer needs it to plan lifecycle behavior.

Include the actual device mix in the test plan. A preview on one recent development device does not describe every supported device. The team should agree representative targets appropriate to its product rather than claiming universal compatibility. This guide supplies a test structure; it does not invent a device certification list or benchmark scores for the studio’s portfolio assets.

2. Audit the exported feature set

Review the composition before promising one identical file for every platform. Identify text, images, masks, gradients, expressions or other features that deserve closer inspection in the chosen runtimes. The relevant question is whether the actual export is accepted and displayed correctly in the target environment. A feature’s appearance in the production software is not proof of identical support after export.

Ask for a representative early export when the artwork is complex or the delivery environment is unfamiliar. Testing one meaningful section can expose an incompatibility before the entire sequence is polished. Choose a section that contains the important visual features rather than the easiest frame. Record what was tested and which parts of the final composition still need review.

Keep external assets with the runtime package and explain how they are resolved. If the app loads files remotely, agree who hosts them, how versions are selected and what happens when the network is unavailable. If assets are bundled with the app, identify which release owns the update. Those delivery decisions belong to the implementation scope and cannot be inferred from a standalone preview.

Do not confuse packaging with compatibility. A .lottie container can change how resources are delivered, but the selected player still needs to support the relevant package and animation features. Read the dotLottie versus JSON guide before deciding the handoff format. Confirm the final file type with both platform owners rather than choosing it solely because the extension looks more modern.

3. Compare the same frames on each platform

Use a shared review sheet containing the approved visual and the same representative frames from each target implementation. Include the entrance, a visually complex moment, a state transition and the resting frame where relevant. Align playback conditions before judging differences. Comparing different moments in the timeline can create a false impression that one platform is missing artwork.

The wallet, declined-payment and deposit-success references below are original studio examples that can help discuss composition and state meaning. They are not published as certified test results for every iOS or Android SDK. Their portfolio platform labels express potential delivery directions; a commissioned implementation still needs its own acceptance evidence.

Document discrepancies in concrete terms. “The label is clipped in this view” is easier to investigate than “Android looks wrong.” Include the app build, screen size and relevant asset version. Decide whether the fix belongs in the export, the container layout or the runtime configuration. Avoid changing the source until the team understands which layer is responsible.

4. Test lifecycle, loading and reduced motion

Test entering and leaving the screen while playback is active. Return to it, background and resume the app, and trigger the same product event again. The desired behavior may be resume, restart, remain complete or show a still. Choose it according to the product state and document it. The animation should not accidentally replay a success confirmation for an operation that has not just occurred.

Separate visual playback from business logic. A payment result should follow the actual result supplied by the application. Completion of an animation timeline must not become the source of truth for a financial or account state. The designer can define the visual response, while the developer connects it to real events and handles interruption or failure.

Agree how the app handles motion preferences and what static alternative it uses. The platform implementation differs from a web CSS media query, so the native team should own the appropriate detection and response. The common design requirement is that the user keeps the same information and available actions when unnecessary motion is reduced. Review the actual app rather than assuming a web fallback transfers automatically.

Include missing or delayed assets in the test when remote delivery is used. Confirm that an ordinary screen remains usable and that a meaningful fallback appears. Decide whether an update can arrive while a component is already visible and how that version change is handled. These cases are easy to overlook when everyone reviews a local file that always loads immediately.

5. Agree a platform-specific acceptance matrix

Turn the comparison sheet into a delivery agreement. Name who checks each platform and what evidence is sufficient for acceptance. The designer may supply the runtime files and preview, while the product team provides builds and device testing. If native integration work is included, state that explicitly. File delivery alone does not imply development access or testing on every app target.

List any approved differences. A product may accept a simplified effect on one platform, or it may require matching artwork and therefore a revised composition. Either can be a deliberate decision, but the limitation should not be hidden. Preserve the original requirement, observed issue and agreed resolution in the handoff so later maintainers understand the chosen tradeoff.

Version the files and the acceptance record together. When artwork changes, the team should know which platform evidence applies to which asset. An old screenshot is not a test result for a newly exported file. Likewise, a runtime upgrade may justify repeating the relevant checks even if the animation source is unchanged. Keep the retest scope tied to what actually changed.

For a quote, send the intended screens, exact players, supported app targets, source artwork and platform owners. Start with Lottie animation services and attach the handoff checklist to the scope discussion. Clear acceptance responsibilities are more useful than a broad compatibility badge with no definition of what was tested.

Frequently asked questions

Sources and related reading

• Official Lottie iOS and Lottie Android projects.
• dotLottie versus JSON and developer handoff checklist.
• Accessible motion requirements, troubleshooting and Lottie services.