Automate and scale manual testing with AI ->

Top 1 Alternative to Paparazzi (Cash App) for Screenshot Testing

Introduction and Context

Screenshot testing has become a staple in Android UI quality assurance because it lets teams lock visual expectations into version control and catch regressions early. Long before Android had mature snapshot tooling, teams on other platforms were already using visual regression techniques to keep UI changes honest. Over time, this approach found a strong foothold in Android projects—especially as design systems, theming, and dynamic content grew more complex.

Paparazzi (Cash App) emerged from this context as a purpose-built, open source tool focused squarely on Android. Created by engineers at Cash App, Paparazzi takes a JVM-first approach: it renders Android views and Jetpack Compose UI directly on the JVM using the same underlying rendering engine that powers Android Studio’s layout previews. The big idea is simple and compelling: run fast, deterministic UI screenshot tests without the emulator.

Why did Paparazzi become popular?

• Emulator-free execution: No booting emulators or managing device farms for visual tests.
• Fast feedback loops: JVM tests run quickly and integrate smoothly with Gradle.
• Deterministic rendering: By staying in a controlled JVM environment, tests tend to be more reproducible.
• First-class Kotlin support: Paparazzi meshes well with modern Android stacks and Jetpack Compose.
• Open source under Apache-2.0: Easy adoption within organizations from a licensing standpoint.

Key components and capabilities typically include:

• A Gradle plugin to wire in recording and verifying snapshots.
• JVM-based rendering leveraging Android’s layout library.
• Golden image baselines stored in the repository with diffing on changes.
• Support for both classic Views and Compose-based UI.

Paparazzi’s adoption has grown largely because it removes a major source of flakiness and complexity: the emulator. For many teams, the ability to run screenshot tests like regular unit tests is a game changer for speed and developer experience.

Still, teams sometimes look beyond Paparazzi. Why? Because screenshot testing spans a spectrum—at one end, pure speed and determinism, and at the other, fidelity to how UI looks and behaves on a real device. Depending on your UI, infrastructure, and visual accuracy requirements, you may want an alternative that runs on emulators or real devices to capture the full rendering pipeline. That trade-off is where alternatives enter the conversation.

Overview: The Top 1 Alternative to Paparazzi (Cash App)

Here are the top 1 alternative for Paparazzi (Cash App):

• Shot (Kakao)

Why Look for Paparazzi (Cash App) Alternatives?

Paparazzi (Cash App) is excellent at what it does, but it isn’t for every situation. Common reasons teams explore alternatives include:

• Need for device-level fidelity: Because Paparazzi renders on the JVM, it doesn’t exercise the full Android hardware and GPU rendering pipeline. If your UI relies on effects, shaders, or OEM-specific rendering quirks, a device/emulator-based tool may produce more accurate results.
• Gaps for complex components: Views that depend on WebView, Google Maps, camera previews, video surfaces, or other system-level components may not render as intended in a layoutlib/JVM environment.
• Niche applicability: Paparazzi targets Android only. If your organization wants a uniform approach across Android and other platforms, a device-based tool (or one that mirrors your pattern on iOS) can simplify standardization.
• Baseline churn during upgrades: Updating Android Gradle Plugin versions, Compose versions, or fonts can cause baseline changes. While not unique to Paparazzi, JVM-rendered snapshots can shift with layoutlib changes, prompting re-record cycles.
• Integration with other test layers: Paparazzi focuses on visual assertions. If you need deep integration with Espresso-based flows, instrumentation hooks, or system-level behaviors, an emulator-based approach may align better with those needs.

None of these are absolute blockers—many teams successfully use Paparazzi for years. But when the above pain points matter, it’s worth examining an alternative.

Detailed Breakdown of the Alternative

Shot (Kakao)

Shot (Kakao) is a screenshot testing tool for Android that runs screenshot tests on devices or emulators. Built in Kotlin and released under the Apache-2.0 license, it’s well-established in the Android testing niche. The tool is commonly adopted by teams who want instrumentation-level fidelity and tight integration with UI testing frameworks like Espresso.

What makes it different?

• Device/emulator execution: Shot captures screenshots on actual Android runtime environments, exercising the GPU pipeline and system components more closely aligned with what users see.
• Works with standard Android test stacks: Because it runs as instrumentation tests, Shot plays well with existing test flows, test orchestrators, and CI setups that already run Android UI tests.

Core strengths and capabilities:

• High-fidelity rendering: Running on emulator/real device yields screenshots closer to production behavior, helpful for animations, blurs, shadows, custom drawing, and OEM-specific nuances.
• Espresso-friendly workflows: Combine navigational flows (Espresso/UiAutomator) with screenshot checkpoints to validate multi-screen journeys, error states, or content-driven UIs.
• Compose and View support: Cover both modern Compose screens and legacy View hierarchies, making it useful during multi-year migrations.
• Gradle integration for record/verify: Record baselines and verify changes via Gradle tasks, similar to Paparazzi’s workflow, easing adoption.
• Configurable tolerance and reporting: Use diff thresholds or artifacts to help reviewers quickly understand whether visual changes are acceptable.
• CI-ready using emulators: Leverage standard emulator images for consistent builds; parallelize devices to keep runtimes predictable.

How Shot (Kakao) compares to Paparazzi (Cash App):

• Execution environment: Paparazzi runs tests on the JVM without an emulator, prioritizing speed and determinism. Shot runs instrumentation tests on a device/emulator, prioritizing fidelity.
• Speed vs fidelity trade-off: Paparazzi usually runs faster and is easier to parallelize on typical CI runners. Shot may be slower (emulator boot, device orchestration) but yields screenshots that better reflect real-world rendering.
• Complexity of setup: Paparazzi’s setup is often simpler for developers because it avoids the emulator step. Shot’s setup requires emulator/device management, but teams already running Espresso tests may find it fits naturally into their existing pipeline.
• Scope of what’s testable: Paparazzi may struggle with components that rely on system-level features (e.g., WebView), while Shot can often capture these as they appear on the device.
• Stability and flakiness: Paparazzi offers deterministic JVM rendering (fewer moving parts). Shot can be stable when emulators are consistently configured, animations are disabled, and fonts/locales are pinned—but emulator/device variability introduces more factors to control.

Best for:

• Teams requiring automation in this category who value device-level fidelity.
• Organizations with mature instrumentation testing pipelines (Espresso/UiAutomator) and CI environments already provisioning emulators.
• Projects with advanced visual effects, custom rendering, or heavy reliance on components like WebView and Maps.

Platform and tech details:

• Platforms: Android
• Primary tech: Kotlin
• License: Open Source (Apache-2.0)

In short, Shot (Kakao) is a strong alternative if your primary goal is high-fidelity screenshots that reflect what users see on physical devices. If you’re comfortable with emulator orchestration on CI and you want deep integration with UI flows, it’s a natural fit.

Things to Consider Before Choosing a Paparazzi (Cash App) Alternative

Selecting a screenshot testing strategy is about aligning your tooling with your project’s realities. Before you switch—or adopt screenshot testing for the first time—evaluate these areas:

• Project scope and UI complexity
• Technology, language, and build compatibility
• Ease of setup and day-to-day ergonomics
• Execution speed and developer feedback
• CI/CD integration and maintenance
• Debugging and flakiness control
• Community support and long-term viability
• Scalability
• Cost and infrastructure
• Team workflow and processes

Putting It All Together: When to Choose Which

• Choose Paparazzi (Cash App) when:
• Choose Shot (Kakao) when:

Practical Adoption Tips

• Start small: Snapshot a few critical components or screens to validate the workflow and diff review process.
• Pin environments: For emulator-based testing, standardize device profiles (API level, DPI, locale, fonts, night mode) and disable animations.
• Document a baseline policy: Define how to handle expected visual changes (e.g., update baselines with clear commit messages) and unexpected diffs (e.g., investigate before re-recording).
• Integrate with code review: Make diffs easy to access in CI artifacts. Encourage reviewers to inspect deltas as part of regular PR reviews.
• Keep tests maintainable: Build small, deterministic UI fixtures. Avoid network and data variability by using fakes and seeded data.
• Plan for storage: Store images efficiently and consider strategies for pruning large artifacts over time.

Conclusion

Paparazzi (Cash App) helped mainstream JVM-based screenshot testing on Android by removing emulator complexity, speeding up feedback loops, and providing deterministic renders—all under a permissive open source license. It remains a strong default for many Android teams, especially those focused on component-level checks and rapid iteration.

That said, not every UI can be faithfully represented in a JVM-rendered environment. If your app leans on hardware-accelerated graphics, WebView, or other system-driven components, or if you need to validate full end-to-end flows under instrumentation, Shot (Kakao) is a compelling alternative. Its device/emulator execution offers higher fidelity to what users actually see, and it integrates well with existing Espresso-based test suites.

In practice, many teams blend approaches: use Paparazzi (Cash App) for fast, broad coverage on component and screen-level snapshots, and employ Shot (Kakao) selectively where hardware fidelity matters most. Whichever path you take, treat screenshot tests like any other part of your engineering system: automate the boring parts, define clear policies for baselines, and build reliable pipelines that keep visual quality high without slowing teams down.