Mobile Game VFX and Particle System Development

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Mobile Game VFX and Particle System Development
Medium
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1159
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

We develop particle systems and VFX for mobile games that look convincing even on budget devices. In our practice, a desktop effect with 50,000 particles on an iPhone 11 led to overheating and 20 FPS. We found the limit: the effect looks quality at 10,000 particles or fewer while maintaining thermal stability. With over 5 years of accumulated experience, we select the optimal stack and technique for each platform. A proper particle system increases player retention by 15% according to our data, without requiring expensive devices.

Tool selection: Unity vs SpriteKit vs Metal

Most mobile games use one of three: Unity's built-in Particle System (Shuriken), Apple SpriteKit SKEmitterNode, or a custom system on Metal/OpenGL ES/Vulkan for special requirements. Compare them in the table.

Tool Platform Performance Flexibility When to use
Unity Shuriken Cross-platform High (GPU Instancing) Medium 2D/3D games on Unity
SpriteKit SKEmitterNode iOS Very high (native) Low 2D games only iOS
Metal Compute Shaders iOS Maximum High Complex custom effects

Unity's Shuriken is the de facto standard. Visual editor, Sub Emitters support, GPU Instancing, Burst compiler for CPU simulation. VFX Graph (GPU simulation via Compute Shaders) works on mobile starting from Metal (iOS 12+) and Vulkan (Android API 24+). On older devices VFX Graph is not available — a fallback to Shuriken is needed.

SpriteKit SKEmitterNode is for 2D games natively on iOS. Simple, fast, no Unity overhead. But limited: no Sub Emitters, no custom shaders without Metal. For simple effects (fire, rain, confetti) it's sufficient.

Which tool to choose for VFX in a mobile game?

If the project is cross-platform, take Unity's particle system. For iOS-only 2D games, SpriteKit is enough. If you need unique effects with full control, write custom shaders on Metal. Our team ensures that the chosen stack does not hit GPU limitations on target devices.

Particle budget and GPU limitations

On mobile GPUs (Apple A-series, Adreno, Mali) the bottleneck is often not the number of particles, but overdraw — the number of times a single pixel on screen is redrawn per frame. Source: Apple Developer Documentation

Transparent particles with additive blending give overdraw multiplied by the number of layers. An explosion of 5000 particles in the center of the screen can have real overdraw of 50–100x. This kills fill rate even on A15.

Strategies to reduce:

  • Texture Atlasing: all particle sprites into one 512×512 or 1024×1024 atlas. Reduces draw calls on texture change.
  • Billboard imposters: for volumetric effects (explosion cloud) — a quad with baked texture instead of hundreds of spheres.
  • Particle LOD: at distance/low fps — reduce maxParticles by half via QualitySettings.particleRaycastBudget or custom LOD manager.

How to optimize particle overdraw step by step:

  1. Identify the worst overdraw using GPU profiler (e.g., Xcode Metal Debugger).
  2. Reduce the number of transparent layers by using additive blending only for glowing parts.
  3. Apply texture atlasing to all particle sprites.
  4. Set up LOD system to halve particle count below 45 FPS.
  5. Test on weakest target device (e.g., iPhone SE 2016) to confirm 60 FPS.
// Unity: dynamic LOD for particle system based on FPS
public class ParticleLODManager : MonoBehaviour {
    [SerializeField] private ParticleSystem targetSystem;
    private ParticleSystem.MainModule _main;
    private float _fpsTimer;
    private int _originalMax;

    void Start() {
        _main = targetSystem.main;
        _originalMax = _main.maxParticles;
    }

    void Update() {
        _fpsTimer += Time.deltaTime;
        if (_fpsTimer < 1f) return;
        _fpsTimer = 0;

        float fps = 1f / Time.smoothDeltaTime;
        if (fps < 45f) {
            _main.maxParticles = Mathf.Max(100, _main.maxParticles / 2);
        } else if (fps > 58f && _main.maxParticles < _originalMax) {
            _main.maxParticles = Mathf.Min(_originalMax, _main.maxParticles * 2);
        }
    }
}

Why is overdraw the main performance enemy?

GPU simulation via VFX Graph runs 4x faster than CPU simulation on A14 Bionic, but overdraw eats that gain. With additive blending, each pixel can be redrawn dozens of times. To avoid this, we apply texture atlasing and reduce the number of particles with high alpha overlap.

Custom shaders for mobile VFX

Built-in Unity shaders for particles (Particles/Standard Unlit) are safe but limited. For dissolve effect, heat distortion, energy shield — a custom shader is needed.

On mobile the rules are strict: no discard in shader (breaks early Z-test, fill rate drops), minimal texture samples, avoid dependent texture reads. Shader Model 2.0 as baseline for wide coverage.

Example of a simple distortion effect for an explosion (Unity HLSL):

CGPROGRAM
#pragma vertex vert
#pragma fragment frag
#include "UnityCG.cginc"

sampler2D _NoiseTex;
float _DistortionStrength;
float _FadeEdges;

fixed4 frag (v2f i) : SV_Target {
    float2 noise = tex2D(_NoiseTex, i.uv + _Time.y * 0.3).rg * 2 - 1;
    float2 distortedUV = i.uv + noise * _DistortionStrength * i.color.a;

    float edge = 1 - saturate(distance(distortedUV, float2(0.5, 0.5)) * _FadeEdges);
    fixed4 col = tex2D(_MainTex, distortedUV) * i.color;
    col.a *= edge;
    return col;
}
ENDCG

i.color.a is the particle alpha from Unity Particle System, synchronized with lifetime. Distortion fades with the particle automatically.

Effects on SpriteKit: fire and confetti

SKEmitterNode can be configured either in Xcode editor (.sks file) or programmatically. Programmatically is preferable for dynamic parameters:

func makeFireEmitter() -> SKEmitterNode {
    let emitter = SKEmitterNode()
    emitter.particleTexture = SKTexture(imageNamed: "spark")
    emitter.particleBirthRate = 120
    emitter.particleLifetime = 1.2
    emitter.particleLifetimeRange = 0.4
    emitter.particleSpeed = 80
    emitter.particleSpeedRange = 40
    emitter.emissionAngle = .pi / 2  // upward
    emitter.emissionAngleRange = .pi / 8
    emitter.particleScale = 0.15
    emitter.particleScaleSpeed = -0.1
    emitter.particleAlphaSpeed = -0.8
    emitter.particleColorSequence = SKKeyframeSequence(
        keyframeValues: [SKColor.yellow, SKColor.orange, SKColor.red, SKColor.clear],
        times: [0, 0.3, 0.7, 1.0]
    )
    emitter.particleBlendMode = .add
    return emitter
}

.add blending — additive blending. Fire and sparks look luminous. Not used for smoke and dust — there .alpha is needed.

GPU profiling tools

Xcode Metal Debugger — frame capture for Metal games. See every draw call, textures, overdraw visualization. For Unity on iOS: through Xcode GPU Frame Debugger when connected via USB.

Android GPU Inspector (AGI) — from Google for Adreno and Mali. Frame Profiler shows pipeline stages where GPU waits.

Unity Profiler — built-in, shows CPU/GPU time for each effect render. Rendering → ParticleSystem.Update takes more than 2ms — look at CPU simulation and reduce maxParticles or switch to GPU Mode.

What is included in the work

  • Custom shader development for target platform
  • Optimization of existing particle systems (LOD, atlasing, overdraw)
  • Integration into game engine (Unity, SpriteKit, custom)
  • Profiling and tuning for weak devices (e.g., iPhone SE 2016)
  • Documentation of parameters and support
  • Training for your team on how to use and extend the VFX
  • Ongoing support for the first month after delivery

Process of work

Technical art direction: what effects are needed, their frequency on screen simultaneously, target devices. Development of shaders and particle systems in the editor with profiling on a weak Android device. LOD system setup. Integration into the game engine, thermal throttling test (10-minute gaming session with temperature analysis).

Time estimates

3–5 working days for a basic VFX set (3–5 effect types) starting at $500. Complex custom system on Metal Compute Shaders — from 2 weeks, starting at $2000. The exact cost is calculated individually after analyzing your requirements. We will evaluate your project: contact us for a preliminary analysis. Get a consultation on tool selection for your effects.

Overdraw reduction techniques comparison table

Technique Overdraw reduction Complexity Implementation time
Texture atlasing 2-3x reduction Low 1 day
Billboard imposters 10x for volumetric effects Medium 2-3 days
Particle LOD 2x when needed Low 1 day
Reducing max particles 5x if halved Low 1 hour

Animations in Mobile Apps: Lottie, Rive, Spring, and Reanimated

We've built animations for dozens of projects — from game interfaces to bank-grade applications. We know how to achieve 120 fps even on Android with ProGuard. If an animation stutters, the problem isn't the tool but the approach. Below we show how we choose between Lottie and Rive, why Spring physics beats UIView.animate, and how Reanimated 3 pushes 60 fps on older devices. Get a consultation for your project — we'll assess the animation layer for free.

Why does UIView.animate break on complex scenarios?

UIView.animate(withDuration:) and ObjectAnimator on Android are fine for simple transitions. But as soon as the animation becomes interactive (user drags an element, speed depends on gesture), a different approach is needed.

On iOS, the right tool for gesture-driven animation is UIViewPropertyAnimator. It allows pausing, reversing, and modifying the animation in progress. A typical use case: a bottom sheet that follows the finger, continues with inertia after release, and snaps to the nearest position. With UIView.animate, this is either not possible or requires manual physics.

In SwiftUI, withAnimation works out of the box, but interactivity is limited — there's no direct analog to UIViewPropertyAnimator. A workaround is using .gesture(DragGesture()) + @GestureState + explicit position calculation. Or move to SwiftUI Animations API with Animation.spring(duration:bounce:) from iOS 17.

How does React Native Reanimated bypass the JS bridge?

React Native Animated API executes animations on the JS thread — this causes jank when the bridge is busy. Reanimated 3 solves this with worklets: functions that compile and run directly on the UI thread without crossing the JS bridge.

Example: parallax scroll header. With basic Animated.Value, fast scrolling drops FPS to 40-45 on mid-range Android. With Reanimated using useAnimatedScrollHandler, it stays at a stable 60 fps because all position calculations happen on the UI thread.

Reanimated 3 with useSharedValue, useAnimatedStyle, and withSpring/withTiming is the current standard for animations in React Native. Gesture Handler v2 is tightly integrated: useAnimatedGestureHandler replaces PanResponder and also runs on the UI thread.

Why can Lottie reduce FPS on Android?

Lottie exports After Effects animation as JSON. On iOS with lottie-ios it's stable, but on Android, complex effects (blur, particles, gradients) via Canvas rendering can cause drops to 30-40 fps. The solution: either simplify the animation or use Rive with hardware rendering. We tested: a 5 MB Lottie file with blur on Xiaomi Redmi Note 10 gave 48 fps, while the same animation in Rive (.riv 400 KB) gave 60 fps.

Lottie vs Rive: What to choose for interactive interfaces?

Both tools solve the task of "designer creates animation, developer adds the file." But they differ fundamentally.

Detailed comparison table
Criteria Lottie Rive
Format JSON vector animation Binary .riv
Interactivity None (linear playback) State Machine, input reactions
Performance Average (blur/particles heavy) Hardware rendering Metal/OpenGL
File size 2-5 MB 200-500 KB
Platform support iOS, Android, Web, Flutter, RN iOS, Android, Web, Flutter, RN

The choice is simple: static decorative animation (splash screen, onboarding illustrations) — Lottie. Interactive UI elements with states — Rive. For example, a button with hover, pressed, loading, success states — one Rive animation with four states versus four separate Lottie files.

Spring physics and Hero transitions: how to achieve naturalness?

Spring animation feels natural because it simulates physics — mass, stiffness, and damping. In SwiftUI: Animation.spring(response:dampingFraction:). In Android Compose: spring(dampingRatio = Spring.DampingRatioMediumBouncy).

For Hero transitions (an element "flies" between screens), on iOS use UIViewControllerTransitioningDelegate + UIViewControllerAnimatedTransitioning. In SwiftUI with iOS 17 — matchedTransitionSource + navigationTransition(.zoom). On Flutter — Hero widget, which works out of the box.

How to avoid common mistakes in Hero transitions?

The animation starts fine, but on the target screen the element "jumps" to the final position. The reason: AutoLayout constraints are applied before the animation completes. Solution: call layoutIfNeeded() inside the animation block or use transform instead of frame changes.

What's included: animation layer turnkey

  • Integration of Lottie/Rive files into the design system
  • Code for gesture-driven transitions (bottom sheets, drawers, carousels)
  • Testing on real devices (iOS 15–17, Android 10–14)
  • Animation documentation (architecture, state keys)
  • Support for design updates (30-day warranty)

We have 5+ years of experience in mobile development, over 30 projects with animations, certified iOS/Android developers.

Timelines

  • Basic screen transitions and micro-interactions — 1 week.
  • Lottie/Rive integration with design system — 3-5 days after receiving final files.
  • Custom gesture-driven interactivity (sheet, drawer, physics carousel) — 1-2 weeks.

Contact us — we'll add animations turnkey in 2 weeks. First consultation is free.