How to Add AR Filters to Your App

Adding AR filters to your mobile app seems simple enough… until you start looking at the code.

Suddenly, you’re drowning in face-tracking APIs, rendering pipelines, and real-time graphics optimization.

It’s enough to make you want to quit before you even start.

But there IS good news:

Adding AR filters doesn't have to take months of painful development.

In fact, if you choose the right approach, you can have a fully functioning AR filter running in your app as soon as this afternoon.

In this guide, I’m going to show you the exact 4-step structure to integrate AR filters into your app without rebuilding camera technology from scratch.

Specifically, you'll learn:

• The 4 AR implementation approaches 
• Native vs. SDKs: When to use ARKit/ARCore and when a commercial SDK is worth the money
• The #1 mistake developers make that destroys app frame rates

Let's get into it.

Choose Your Implementation Approach First

Before writing any code, decide how you're going to add AR filters to your app.

This single decision determines your development time, maintenance cost, and how much control you'll have over the final experience.

As we said above, there are four approaches to it.

If your goal is simply to launch AR effects inside your app, a commercial SDK is usually the shortest path. 

If your product requires complete control over rendering or computer vision, building on native frameworks may be the better long-term investment.

The rest of this guide explains the trade-offs so you can choose the right option before you start integrating anything.

Should You Use ARKit, ARCore, or a Face Filter SDK?

Once you've decided that your app needs AR filters, the next question is whether to build the technology yourself or use an existing face filter SDK.

The answer depends on what you're trying to ship.

If your goal is to launch a polished camera experience as quickly as possible, a commercial SDK is usually the most practical option. 

But if your product requires complete control over computer vision, rendering, or spatial tracking, building on a native framework’s worth the effort.

Here's how both options compare.

ARKit and ARCore

ARKit (iOS) and ARCore (Android) provide the foundation for AR experiences. 

They handle problems such as face tracking, world tracking, depth estimation, and motion tracking.

And while they're powerful frameworks, it’s only one layer of the overall solution.

Why?

Because while they provide:

• Face tracking and facial landmarks
• Face meshes
• World and surface tracking
• Motion tracking
• Camera calibration

They don’t offer:

• Beauty filters or skin smoothing
• Makeup effects
• Face masks and stickers
• Background replacement
• An effect library
• Designer tools for creating filters
• A cross-platform API

That's because ARKit and ARCore focus on tracking; so everything that turns tracking data into a visual experience is still your job.

That means building the rendering pipeline, writing GPU shaders, handling compositing, creating an effect format, and maintaining separate implementations for iOS and Android.

For teams with graphics expertise, that can be a major advantage.

But for most product teams, though, it's quite a lot of engineering work before users ever see their first filter.

Computer Vision Frameworks

Frameworks such as MediaPipe, ML Kit, and Apple Vision solve an even smaller part of the problem.

For instance, they can detect a face, segment the background, or identify landmarks (if any), but after that? Full stop.

You'll still need to build everything that happens after detection, including rendering, effect management, animation, and GPU optimization.

Commercial Face AR SDKs

A commercial face SDK combines the pieces above into a single pipeline.

Instead of integrating separate tracking, rendering, and effect systems, you get a package already including:

• Face tracking
• Rendering
• Effect loading
• Beauty filters
• Face masks
• Background segmentation
• Authoring tools for designers
• Cross-platform APIs

From your application's perspective, integrating the SDK usually means connecting the camera preview, and loading an effect package.

This reduces both development time and long-term maintenance.

When Does a Commercial SDK Come in Handy?

A commercial SDK is usually the right choice if you:

• want to launch quickly
• don't have graphics engineers on the team
• need the same experience across iOS and Android
• expect to maintain a growing library of filters
• want designers to create new effects without engineering involvement

On the other hand, native frameworks are the better choice if:

• you're building highly specialized computer vision features
• your product depends on custom rendering technology
• you need capabilities that existing SDKs don't provide
• long-term flexibility is more important to you than development speed

Neither approach is better than the next one; the right one depends on your product rather than the technology itself.

Where Does Snap Camera Kit Fit?

Snap Camera Kit lets developers integrate Snapchat's camera technology directly into their own apps. 

It also gives access to Lens Studio, where designers can create and publish Snap-compatible lenses.

For many consumer apps, that's a compelling combination.

As for HAVEs and NOT-HAVEs, Snap Camera Kit is a good fit when you:

• want access to Snapchat's lens ecosystem
• already have designers using Lens Studio
• are building a consumer or social application
• don't mind depending on Snap's platform and licensing model

On the other hand, a standalone face filter SDK may be a better fit if you want:

• complete white-label branding
• your own effect ecosystem
• custom licensing
• full control over how filters are distributed and managed

Again, neither option is better than the other; they simply solve different business problems.

Now that you've chosen an implementation approach, the actual integration process becomes much simpler. 

And regardless of which SDK you use, the workflow is quite similar.

Steps to Add AR Filters to Your App

Whether you're using Nosmai, Banuba, DeepAR, or another face AR SDK, these are the steps that follow:

1. Initialize the SDK.
2. Connect it to your camera.
3. Load an effect package.
4. Render the live preview.

Let's walk through what that looks like.

Step 1: Initialize the SDK

Every commercial SDK requires a valid license before being operational.

After installing the SDK, you'll initialize it with the license key provided by the vendor. 

Without a valid license, the SDK won't initialize correctly, so the camera preview or effects typically won't appear.

If you ever run into the classic "black preview" problem, checking the license configuration should be one of your first troubleshooting steps.

Step 2: Connect the Camera

Next, configure the camera and attach the SDK's preview to your application's UI.

At this point, the SDK starts receiving live camera frames. Nothing visual has changed yet; you just have a camera feed flowing through the pipeline.

Once the camera is connected, the SDK can begin tracking faces and preparing each frame for rendering.

Step 3: Load an Effect Package

This is where the actual AR filter is added.

Instead of writing rendering code for every new filter, you simply load an effect package; once loaded, the SDK handles the rendering automatically.

That's one of the biggest advantages of using a commercial SDK: adding a new filter usually means shipping a new asset rather than writing new rendering code.

Step 4: Rendering the Preview

After the effect is loaded, the SDK combines the camera feed, face tracking, and visual assets into a single real-time preview.

As the user moves, facial landmarks keep updating and the effect stays attached to the face.

And from this point forward, the pipeline repeats for every frame captured by the camera.

Ready-Made Filters vs. Custom Filters

One question that often comes up at this stage is whether you need to build every filter yourself.

In most cases, the answer is no.

Most SDKs let you start with ready-made effects (making it possible to launch quickly without involving a designer).

As your product evolves, you can replace those with custom-branded ones created specifically for your app.

But, whether the effect comes from the SDK's library or your own design team, your application still loads it the same way.

That means you can launch with existing effects, gather user feedback, and introduce custom filters later without rewriting your implementation.

iOS vs. Android vs. Flutter: What's Different?

The core integration process looks almost identical across every single platform.

You'll still initialize the SDK, connect the camera, load an effect package, and render the preview. 

What changes is the platform-specific setup needed to get there. 

For iOS 

iOS is generally the most straightforward platform for integrating AR filters because Apple’s hardware ecosystem is very consistent. 

A typical setup includes:

• Installing the SDK with CocoaPods
• Adding the required camera permission (NSCameraUsageDescription) to Info.plist
• Initializing the SDK with your license key
• Connecting the camera preview to your app's UI
• Loading an effect package

Most integration issues on iOS come down to configuration rather than rendering.

Android

Android follows the same overall workflow but typically requires more testing.

The biggest challenge isn't writing the integration but supporting the wide variety of Android devices, cameras, GPUs, and OS.

A typical Android setup includes:

• adding the SDK through Gradle or an AAR package
• configuring CameraX or Camera2
• requesting camera permissions at runtime
• initializing the SDK
• attaching the preview surface
• loading an effect package

Even when implementation is correct, two Android devices can behave differently because of camera hardware, GPU drivers, or manufacturer-specific software.

That's why testing on multiple device types is important while shipping production-ready AR effects.

Flutter

Flutter gives you a single Dart API while relying on native implementations underneath.

Most SDKs expose their native functionality through platform channels, while the live camera preview is displayed using a platform view.

Although your application code stays largely in Dart, you'll still need to complete the native setup for both iOS and Android.

That includes:

• adding native SDK dependencies
• configuring platform permissions
• completing the required iOS and Android project setup

Which Platform’s the Easiest One?

If you are supporting multiple platforms, remember this simple rule of thumb:

• iOS is the fastest to get up and running (thanks to consistent hardware).
• Android takes the most time (due to brutal device fragmentation).
• Flutter cleans up your app code but still requires native setup on both platforms. 

Common Mistakes When Adding AR Filters 

Even if your code compiles perfectly, a few critical mistakes can completely ruin your user experience.

1. Doing Heavy Work on the Main Thread

This is the #1 mistake developers make.

Every single camera frame needs to be analyzed and rendered in real time. If you run expensive image processing on the main UI thread, your frame rate will plummet.

The Fix: Always run heavy rendering and computer vision processing on background threads. Keep rendering GPU-accelerated.

2. Testing Only on High-End Devices

Your new filter might run flawlessly at 60 FPS on a brand-new iPhone or Pixel.

But how does it perform on a $150 budget Android phone?

If you don't test on lower-end devices, your users will be the ones finding your performance hurdles.

3. Using Insanely High Camera Resolutions

More pixels equal more processing power. So unless your app strictly requires cinematic-quality video, drop the input camera resolution down.

It drastically improves your frame rate, and your users won’t even notice the visual difference on a mobile screen.

4. Letting Frames Queue Up

If the processing pipeline can't keep up with the incoming camera feed, frames begin to accumulate.

Instead of trying to process every frame, it's often better to process only the latest available frame and discard older ones.

Conclusion

At the end of the day, your users don't care how many lines of custom GPU shaders you wrote.

They care about how smooth, fun, and fast the AR filters feel inside your app.

So don't waste six months rebuilding camera technology that already exists; pick the shortcut that matches your business goals, get a prototype live, and iterate based on real user feedback.

FAQs

What are AR filters?

AR filters use your phone’s camera to detect a face or background, and the device’s graphic processor to smoothly draw graphics locked to it. This allows you to apply virtual makeup, digital masks, or replace backgrounds, refreshing 30 to 60 times a second.

Is Spark AR still available?

No. Meta retired Spark AR and removed third-party filters from Facebook and Instagram. 

Current creation options include:

Snap Ecosystem: Snap Lens Studio and Camera Kit.

Commercial SDKs: Third-party kits like Nosmai, Banuba, and DeepAR.

Native Platforms: Directly using Apple's ARKit or Google's ARCore.

Do I need to build on ARKit or ARCore directly?

No. You can use a ready-made commercial camera SDK. This provides the full filter pipeline (including tracking, rendering, and existing effects) without building the core technology from scratch.

How long does the integration take?

Timelines depend heavily on your app's setup and the range of devices you support:

Basic Filters: As soon as an afternoon to a couple of days.

Polished Production Integration: A few days to roughly two weeks.

Do I have to build the effects myself?

No. You can launch your app using ready-made effect files. You can then add custom, branded effects later. The integration code remains the same either way.