Forem: GeekyAnts

How Workflow Automation Powers Scalable Digital Platforms

GeekyAnts Inc — Thu, 26 Mar 2026 13:06:40 +0000

Building digital platforms today isn't just about features or UI polish. Anyone can add sign-up forms, payment gateways, or a profile page. The real challenge comes when you scale: How do you make sure all your systems — onboarding, subscriptions, payments, CRM, analytics, and support — stay in sync without chaos?

The invisible backbone is workflow automation, the machinery that ensures every system stays in sync, every transaction is reliable, and every user journey feels seamless. And now, with the rise of AI, automation is no longer just about consistency. It's about intelligence.

The Growing Complexity of Digital Platforms

Every modern platform ends up connecting with a wide range of systems:

Authentication and access management
Payment gateways and subscription billing
CRMs for customer data
Databases and spreadsheets for operations
Email and notification services
Analytics and reporting

Each is useful in isolation, but together they create a messy web. Without automation, teams resort to manual syncs, spreadsheets, and custom scripts that eventually break. At 100 users, you might manage. At 10,000 users, this becomes a bottleneck.

Why Automation Matters

When we think about product development, most of the energy goes into building features: the UI, the payment flow, the content library, the recommendation engine. But features are only half the story.

The other half — often invisible to users — is the machinery that keeps everything connected and consistent. This machinery is automated. It is the backbone of any modern product.

1. The Backbone of Scale

A product without automation may work fine in the early days. But as soon as user numbers, transactions, and integrations grow, the cracks show:

Users get duplicate accounts because onboarding isn't consistent.
Subscriptions don't expire on time, leading to revenue leakage.
Data doesn't sync across tools, so analytics can't be trusted.

Automation ensures that your product can scale beyond "startup hacks." It applies rules consistently, keeps systems in sync, and prevents chaos as you grow.

2. The Safety Net in Urgent Situations

Automation isn't just about efficiency when things are smooth. It's about resilience when things go wrong.

Imagine these scenarios:

A payment gateway goes down during peak hours. An automated retry workflow ensures transactions are re-attempted, preventing revenue loss.
A contract expires, but instead of cutting access immediately, an automated grace-period flow sends emails and coupons, saving a customer relationship.
An urgent security patch requires revoking access for specific users. An automated workflow ensures it happens instantly, across all integrated systems.

In urgent situations, automation acts as your safety net — responding in seconds, not hours, when human intervention would be too slow.

3. The Glue for User Experience

Users don't see your internal systems. They only see the experience. When automation is absent, the gaps show up in frustrating ways:

"Why did I get charged but not upgraded?"
"Why am I still locked out even after renewing?"
"Why is my profile incomplete when I signed up through Google?"

With automation, these cracks disappear. Every event — a signup, a payment, an expiry — triggers the right downstream workflows instantly. To the user, the platform feels seamless.

4. The Enabler of Focus

Without automation, teams spend hours reconciling spreadsheets, chasing expired contracts, or fixing data mismatches. With it, they can focus on building features, talking to customers, and improving the product.

Automation is not just a cost saver. It's a growth enabler.

Why n8n?

There are many automation tools: Zapier, Make, Temporal, and custom scripts. But n8n stands out for building production-grade workflows:

Open-source & self-hostable → You own your automation infra, control security, avoid lock-in.
Rich integrations → Hundreds of pre-built connectors with SaaS apps, APIs, and databases.
Flexibility → From simple if-this-then-that flows to multi-branch orchestrations with error handling and retries.
Developer + business friendly → Visual UI for non-engineers, code nodes for engineers.
Scalable architecture → Docker/Kubernetes-ready for enterprise adoption.

In short: n8n is more than a tool. It's the automation backbone for platforms at scale.

Case Study: User Sync Across Systems with Automated Emails

One of the most common challenges in scaling platforms is when users exist in multiple systems but aren't synchronized. For example:

A user signs up for the community platform.
Their subscription data is in Stripe.
Their profile lives in Airtable.
Their access rights are in a third-party system like VendHub.

Without automation, you'd need manual reconciliation — exports, imports, and constant checking. That's slow, error-prone, and breaks at scale.

The Automated Solution

Using n8n, we built a workflow that did the following:

Step 1 — Trigger on User Event
Any signup, update, or contract change (from Stripe, the app, or CRM) triggers the workflow.

Step 2 — Fetch User Records Across Systems
The workflow queries Airtable, VendHub, and the internal database. Data is normalized (email is the unique identifier).

Step 3 — Check Contract Information

If the contract is active → keep the user synced across all systems.
If the contract has expired → mark as expired, revoke access, and prepare communication.

Step 4 — Send Automated Email
If expired, send a personalized email notifying the user. Include a 14-day trial offer and a unique coupon code to reactivate.

Step 5 — Update Master Dataset
All states (active, expired, reactivated) are written back to Airtable. This ensures a single source of truth for analytics and operations.

Even a simple automation like this can eliminate hours of manual work and ensure a consistent user experience across every system your platform touches.

The Impact of an Automation Backbone

AI elevates automation from being rule-based to becoming adaptive and intelligent. Instead of rigid "if-this-then-that" workflows, platforms gain the ability to make context-aware decisions:

Deciding which users should get a discount versus a survey
Detecting anomalies in transactions before they escalate
Cleaning and enriching messy data across systems
Generating personalized communications that feel human rather than robotic

The result is not just operational efficiency, but a platform that is resilient under stress, proactive in preventing failures, and capable of delivering experiences that scale with intelligence rather than brute force.

Automation gives consistency; AI makes it smart.

When workflow automation becomes part of your architecture, the results are transformative:

Teams gain efficiency → No more manual sync firefighting.
Rules are enforced reliably → No more ad hoc decisions.
Scale doesn't hurt → More users don't mean more chaos.
Users stay happy → Seamless, consistent experiences win loyalty.

Looking Ahead

We are entering a future where automation + AI layers become invisible infrastructure. Instead of cobbling systems together with patches and scripts, platforms will run on orchestrators that quietly handle:

Compliance rules
Retention campaigns
Data normalization
Personalization flows

Tools like n8n, with AI-powered extensions, are leading the way by being both accessible and powerful enough for production.

Final Thoughts

Automation isn't about replacing humans — it's about removing the chaos that slows them down.

Features get you started. Automation makes you scale.

Today, in an era where products are built and shipped faster than ever, the real challenge isn't speed — it's stability. Moving fast without a strong backbone leads to chaos: fragmented data, broken user journeys, and endless manual fixes. This is where automation, powered by AI, becomes essential. Automation brings the structure and reliability needed to scale with confidence, while AI adds the intelligence to adapt in real time. Together, they create platforms that don't just move fast, but move fast without breaking — resilient, seamless, and ready for growth.

Originally published on the GeekyAnts Blog. GeekyAnts is a global software consultancy helping enterprises build scalable digital platforms.

Building Responsive and Performant Graphs in React Native

GeekyAnts Inc — Fri, 20 Mar 2026 08:40:24 +0000

Data visualization plays a key role in modern mobile apps — from analytics dashboards to performance summaries. Well-designed graphs make complex data easy to understand at a glance. However, building responsive and high-performance graphs in React Native can be challenging.

In this blog, we will walk through how we approached building responsive and performant graphs in React Native — the challenges we faced and the strategies we adopted.

The Challenges We Faced with Graph Implementations

When working with popular graph libraries in React Native, several practical issues often arise, particularly around responsiveness, alignment, and performance. Here are a few of the most common challenges we encountered:

1. Y-Axis Scrolling Issue

When making the graph horizontally scrollable (for large datasets), the Y-axis scrolled along with the graph content, making it difficult to keep the labels visible while navigating through the data.

2. Axis Alignment Issues

To fix the above issue, we attempted to create two separate graphs — one for the Y-axis and another for the main scrollable X-axis. While this approach initially worked, it introduced alignment inconsistencies between the two graphs, especially when the chart data or layout was updated dynamically.

3. Performance and Crashes on iOS

For large datasets, especially in bar charts or grouped bar charts, the app would occasionally crash on iOS. The crash logs pointed to Metal texture creation failures, meaning the graphics rendering system could not allocate textures large enough for the entire dataset.

What We Require from Our Charting Solution

After evaluating multiple libraries and approaches, it became clear that our ideal solution had to:

Handle large datasets gracefully without crashes.
Support independent Y-axis rendering for better user readability.
Offer responsiveness across screen sizes.
Be lightweight and performant, minimizing bundle size and build times.
Stay easy to integrate.

The Solution

After exploring several options, we found that combining a lightweight, flexible charting library like react-native-gifted-charts with custom dynamic logic gave us the right balance between performance, maintainability, and control.

Some of the features that stood out about the library were:

Built-in support for scrollable charts with fixed axes
Smooth animations and transitions
Highly customizable props for colors, labels, gradients, and legends
Optimized rendering that prevents crashes even with large datasets
Lightweight and efficient, which reduced the app's bundle size, improved runtime performance, and significantly shortened the time required to create production builds

1. Installation

To get started, install the necessary dependencies that will enable chart rendering and responsive scaling in your React Native project:

react-native-gifted-charts (the charting library)
react-native-svg (for rendering graphics)
react-native-linear-gradient (or expo-linear-gradient if in an Expo project)
react-native-responsive-screen for dynamic sizing across devices (recommended)

Using React Native CLI:

npm install react-native-gifted-charts react-native-svg react-native-linear-gradient react-native-responsive-screen

Using Expo (recommended):

npx expo install react-native-gifted-charts react-native-svg expo-linear-gradient react-native-responsive-screen

Note: Make sure these dependencies are linked (in non-Expo projects) so the native modules work correctly. Autolinking should handle it in recent React Native versions.

2. The Final Optimized Implementation

Let's walk through the final optimized setup step-by-step, starting from the base configuration and moving into the dynamic enhancements we added to make the graphs stable, scalable, and production-ready.

Setting Up the Base Chart

The react-native-gifted-charts library provides a solid and efficient starting point for creating bar graphs. It handles much of the heavy lifting for graph rendering, animations, and performance optimizations internally.

Here's a basic setup to render a simple bar chart:

import { BarChart } from 'react-native-gifted-charts';
import { widthPercentageToDP as wp } from 'react-native-responsive-screen';

const barData = [
  { value: 250, label: 'Jan' },
  { value: 500, label: 'Feb' },
  { value: 745, label: 'Mar' },
  { value: 320, label: 'Apr' },
  { value: 600, label: 'May' },
];

const SimpleBarChart = () => {
  return (
    <BarChart
      data={barData}
      barWidth={wp('5.5%')}
      height={wp('38%')}
      width={wp('90%')}
      spacing={65}
      noOfSections={5}
      maxValue={1000}
      stepValue={200}
      frontColor="#4ABFF4"
    />
  );
};

This base setup alone helps resolve two major pain points:

App crashes on iOS for large datasets: react-native-gifted-charts handles large datasets smoothly without triggering the Metal texture allocation errors previously encountered on iOS.
Y-axis scrolling along with chart content: The library keeps the Y-axis fixed while allowing horizontal scrolling of large datasets, significantly improving readability and usability.

Key Props and Their Purpose

Before diving into custom enhancements, it's essential to understand a few key props that form the backbone of every chart:

barWidth

Controls the width of each bar. Using wp("5.5%") keeps it proportional to screen width, ensuring the chart looks balanced on both phones and tablets.

height and width

Defines the overall chart dimensions. Using percentage-based values (like height={wp("38%")}) makes the graph scale fluidly across devices.

spacing

Determines the horizontal space between bars. Dynamically adjusted using:

spacing={isTablet ? 70 : 65}

so that the chart maintains even spacing on different screen types.

noOfSections, stepValue, and maxValue

These three props control the scaling of the Y-axis:

noOfSections — Number of horizontal grid lines
stepValue — Value difference between each section
maxValue — The highest Y-axis value (multiply the maximum value by 1.2 to add a buffer, ensuring the tallest bar is never cropped at the top)

These three values must always satisfy:

maxValue = noOfSections * stepValue

formatYLabel

A function used to format the Y-axis values. Used to round decimal values and ensure clean, readable labels:

formatYLabel={(value) => Math.round(Number(value)).toString()}

xAxisLabelTextStyle and yAxisTextStyle

Controls the font size, alignment, and color of the X and Y-axis labels. Adjust font sizes for tablets and phones for better legibility.

frontColor, xAxisColor, and yAxisColor

frontColor — Sets the color of the bars
xAxisColor & yAxisColor — Defines the axis line colors for a subtle and professional look

dashGap

Defines gaps between dashes in grid lines. Set to 0 to show solid lines behind the graphs.

Making the Charts Truly Dynamic

Now that the base graph is working, let's move on to the custom enhancements that improve accuracy, responsiveness, and flexibility.

Dynamic Y-Axis Width for Large Values

One of the first issues encountered was truncated Y-axis labels when large numerical values were displayed. The Y-axis width is calculated dynamically based on the number of digits in the largest value:

const getYAxisWidth = (maxValue) => {
  const digits = maxValue.toString().length;
  if (digits <= 3) return wp('8%');
  if (digits <= 5) return wp('10%');
  return wp('12%');
};

This approach:

Prevents label truncation — The Y-axis automatically adjusts to fit larger values.
Maintains proper alignment — Bars and axes remain visually consistent regardless of dataset size.
Improves responsiveness — Works seamlessly across devices with different screen sizes.

Properly Calculating Chart Sections and Scaling

For the graph to render correctly, the three properties (noOfSections, stepValue, and maxValue) must always follow this mathematical relationship:

maxValue = noOfSections * stepValue

If this relationship is not maintained — for instance, when only one of the three values is adjusted manually — the chart may render incorrectly or not at all.

Note: The documentation advises reloading the app whenever these values or related props (height, stepHeight, etc.) are modified, as the new configurations are sometimes applied only after a full reload.

Here's how to handle these configurations dynamically:

const calculateChartScaling = (data) => {
  const maxDataValue = Math.max(...data.map((item) => item.value));
  const bufferedMax = maxDataValue * 1.2;

  const noOfSections = 5;
  const stepValue = Math.ceil(bufferedMax / noOfSections / 10) * 10;
  const maxValue = noOfSections * stepValue;

  return { noOfSections, stepValue, maxValue };
};

Structuring the Data for Flexibility

In react-native-gifted-charts, the data prop accepts an array of objects, each representing a single bar or data point:

const chartData = [
  {
    value: 150,
    label: 'KA-51-AF-4155',
    topLabelComponent: () => (
      <Text style={{ fontSize: isTablet ? 10 : 8, color: '#333' }}>150</Text>
    ),
  },
  {
    value: 320,
    label: 'MH-12-BT-9921',
    topLabelComponent: () => (
      <Text style={{ fontSize: isTablet ? 10 : 8, color: '#333' }}>320</Text>
    ),
  },
];

Property breakdown:

value — Defines the height of the bar
label — Sets the X-axis label
topLabelComponent — A custom React component for displaying value labels above each bar

Our Graph in Action

Here's how the charts render across different devices:

The End Result

By combining the base setup from react-native-gifted-charts with these enhancements, we achieved:

Smooth, crash-free performance on both iOS and Android, even with large datasets
A fixed, properly aligned Y-axis for improved readability
Dynamic scaling and sizing that adapts to any screen size or dataset
Clean, customizable visuals ready for production use

3. Advanced: Creating Grouped Bar Graphs

In many scenarios, we need to display multiple metrics side-by-side for the same category — such as current vs expected values. The react-native-gifted-charts library makes it straightforward to implement grouped bar charts by structuring the data prop appropriately and customizing the top labels.

Data Structure for Grouped Bars

To implement a grouped bar chart, most of the setup remains the same as a standard bar chart. However, there are a few additional considerations for handling multiple bars per category:

spacing — Adds space between bars within a group to clearly separate metrics
topLabelComponent — For grouped bars, dynamically render the label above the taller bar in each group
frontColor — Used to differentiate bars within the same group

Example snippet for grouped data:

const groupedData = [
  {
    value: 400,
    label: 'Vehicle A',
    frontColor: '#4ABFF4',
    topLabelComponent: () => <TopLabel value={400} compareValue={300} />,
  },
  {
    value: 300,
    frontColor: '#FFA07A',
    topLabelComponent: () => null,
  },
  {
    value: 520,
    label: 'Vehicle B',
    frontColor: '#4ABFF4',
    topLabelComponent: () => <TopLabel value={520} compareValue={480} />,
  },
  {
    value: 480,
    frontColor: '#FFA07A',
    topLabelComponent: () => null,
  },
];

Dynamic Top Labels

For grouped bars, top labels must be carefully positioned to avoid overlapping. Here's a reusable component that automatically adjusts the label width and position based on the taller bar in the group:

const TopLabel = ({ value, compareValue }) => {
  const isLow = value < compareValue;
  const labelText = value.toString();
  const labelWidth = isTablet
    ? Math.max(labelText.length * 8, 40)
    : Math.max(labelText.length * 6, 30);

  return (
    <View style={{ width: labelWidth, alignItems: 'center' }}>
      <Text
        style={{
          fontSize: isTablet ? 10 : 8,
          color: isLow ? '#FF6347' : '#333',
          fontWeight: '600',
        }}
      >
        {labelText}
      </Text>
    </View>
  );
};

Key points:

Dynamic Positioning — The top label is placed above the bar with the larger value in the group, ensuring it doesn't overlap or look misaligned.
Dynamic Width Calculation — Width is calculated based on text length and screen type (tablet vs mobile) to prevent clipping.
Conditional Styling — Using an isLow flag, different colors indicate low vs high values, improving readability and visual cues.

Our Grouped Bar Graph in Action

Final Thoughts

Building responsive and performant graphs in React Native is about more than just aesthetics — it's about ensuring usability, speed, and adaptability across devices. The react-native-gifted-charts library offers a strong foundation, and with a few tailored enhancements like adaptive layouts and precise alignment, we can create production-ready graphs that deliver a seamless experience across Android, iOS, and tablets.

Originally published on GeekyAnts Blog

React Query as a State Manager in Next.js: Do You Still Need Redux or Zustand?

GeekyAnts Inc — Fri, 20 Mar 2026 08:32:44 +0000

If you have built apps with React for a while, you have probably gone through a few phases of state management: useState → Context → Redux → Zustand → React Query. And now with the Next.js App Router and server components, the old patterns feel less obvious than ever.

A common question keeps coming up today:

"Do we still need Redux or Zustand when React Query already handles most of our data?"

It is a fair question. React Query now handles fetching, caching, background updates, optimistic UI, and persistence almost effortlessly. For many apps, it feels like enough. But at the same time, global UI state, client-only logic, and hydration quirks in Next.js still need careful thought.

In this article, we will look beyond tutorials and focus on the real-world balance between these tools. We will break down what kind of state React Query truly manages, how that fits into the App Router world, and where it falls short compared to client-state tools like Redux or Zustand.

Server State and Client State in Modern Next.js

Before we can talk about React Query replacing Redux or Zustand, we need to understand what kind of state we are dealing with in the first place.

In a Next.js App Router setup, state can be broadly divided into two buckets:

1. Server State

This is data that lives outside your React app — things like product lists, user profiles, or analytics coming from an API or database. It's fetched, cached, and often changes independently of the UI. This is where React Query shines.

2. Client (UI) State

This covers everything that exists inside the browser: UI toggles, form steps, modal visibility, theme selection, etc. It doesn't need to be fetched from anywhere; it is managed entirely by your app. Zustand and Redux were built for this kind of state.

With the App Router, this line has become more visible. Server Components now handle data fetching directly on the server, while Client Components are mostly for interactivity. That means the amount of client-side state you actually need to manage is smaller than before — but still important.

The key shift is this: you no longer have to push everything through a global client store. Server data can stay on the server, and tools like React Query can handle syncing and caching it efficiently on the client side.

Understanding this separation — and resisting the urge to treat all state the same — is what makes modern Next.js apps faster, simpler, and easier to maintain.

What React Query Actually Solves

React Query is not a traditional state management library. It is built for server state — data that lives on your backend but needs to be kept in sync with your UI.

Instead of thinking of it as "just a data fetching tool," think of React Query as a client-side cache layer for your backend. It knows when to fetch, when to refetch, when to use cached data, and when to update silently in the background — all without you having to wire up actions or reducers.

Some of its key capabilities that make it feel like a full-fledged state layer include:

Automatic caching: React Query stores API responses and serves them instantly when needed again.
Background refetching: It silently updates stale data, so your UI stays fresh.
Mutations and optimistic updates: You can make changes (like submitting a form or liking a post) and see results instantly before the server even responds.
Invalidation: You can mark certain queries as "stale" and refetch only what's needed.
Persistence: The cache can survive page reloads, navigation, and even be synced across tabs.

When I first added React Query to a Next.js project, the "background refetch" feature was really useful. We had a dashboard with project data, and with React Query, the data just stayed in sync without us even thinking about it — and our API calls dropped because of caching.

In Next.js, React Query works especially well alongside the App Router. You can prefetch data during navigation, hydrate server-fetched data into the client cache, or revalidate on demand — making transitions seamless without relying on heavy global state.

So while Redux or Zustand manage what the user is doing, React Query manages what the app knows about the outside world. That's the sweet spot where it fits naturally into a Next.js architecture.

Where React Query Falls Short

For all its strengths, React Query is not perfect — and it is definitely not meant to replace every kind of state in your app.

I have made the mistake of using React Query for things it was not meant for — like managing modals and UI flags. It worked for a while, but quickly turned messy. Keeping modal visibility in React Query felt overkill, so we moved that logic to Zustand, which fit naturally.

In another one of our projects, we had to juggle multiple roles, permissions, and cross-cutting state. React Query was great for syncing data from the backend, but it was not enough to coordinate all the user flows. Redux's strict structure helped us trace issues and keep things aligned.

React Query shines for server state, not UI logic.

Its entire design revolves around server state — data that exists on your backend or comes from an external API. Once you try to stretch it to manage pure client-side logic, things get messy fast.

Here are some cases where React Query is not the right fit:

Global UI state: Things like toggling a sidebar, opening modals, or tracking whether a toast is visible. You don't want to "fetch" or "mutate" this kind of state. Zustand or Context work much better here.
Local component state: Simple form steps, filters, or dropdowns don't need to touch React Query at all. A normal useState or useReducer is cleaner.
Non-fetch data flows: Tracking drag-and-drop state, theme mode, or ephemeral in-app flags. Forcing these into React Query just adds unnecessary complexity.
Complex cross-component UI logic: If you are syncing things like "is user editing?" or "is modal X open?" across multiple components, React Query will quickly feel unnatural.

Another thing to remember: React Query's caching and invalidation logic assume data eventually comes from the server. When you try to fake that with local-only data, you end up fighting the library instead of benefiting from it.

So while it can technically hold client-side data, it should not. Let it do what it is built for — syncing server data efficiently — and pair it with a lightweight state manager for everything else.

Comparison of Redux, Zustand and React Query

It is easy to treat Redux, Zustand, and React Query as interchangeable tools, but they solve very different problems. To make sense of where each one fits, let's look at them side by side.

Aspect	Redux	Zustand	React Query
Primary Purpose	Global client state	Lightweight client state	Server state and caching
Best fit	Large apps, strict patterns	UI toggles, feature flags	API data, prefetching, mutations
Boilerplate	High	Low	Low–Medium
SSR / Hydration	Manual hydration required	Client-only (hydrate manually if needed)	Built for SSR + hydration flows
Performance	Good, but can be verbose	Excellent (minimal re-renders)	Excellent (cache-first reads, background refresh)
Use with App Router	Works, but more wiring	Natural fit for client components	Native fit for server-client data flows
Developer experience	Predictable, verbose	Fast iteration, simple API	Declarative, fewer edge cases for server data

In the Next.js App Router world, Redux's use cases are shrinking — most apps do not need a massive global store anymore. Zustand fills the gaps nicely for lightweight UI or interaction-based state. And React Query has become the de facto choice for managing anything that touches the network.

Instead of choosing one and forcing it to do everything, modern teams often combine them strategically:

React Query for API data and caching
Zustand for UI-level and ephemeral state
Redux only for edge cases where strict architecture or predictable action logs are needed

I like to use Zustand in projects where I have to manage a lot of small UI flags. Things like dark mode, sidebars opening, and which tab is active. React Query or Redux would be way too heavy for that.

I've used Redux in projects where we had a big team and a ton of shared global state — like user roles, permissions, and project-wide settings. Debugging was slower, but the Redux DevTools really helped us trace things.

Each tool still has a place, but fewer apps need all three at once.

Real-World Scenarios

In real-world Next.js App Router projects, React Query can simplify how you handle data fetching and caching, but it is not a one-size-fits-all solution. Let's look at a few common cases:

1. Authentication State

React Query can fetch and cache user data (like getCurrentUser) efficiently. However, it's not ideal for storing session tokens or controlling global auth state like "isLoggedIn." For that, a lightweight store such as Zustand or even React Context still works better.

Verdict: Use React Query for user data, but manage auth status separately.

2. Modals and UI Toggles

These are purely client-side states that do not involve the server — opening a modal, toggling a sidebar, or handling dark mode. React Query is not meant for this kind of transient state.

Verdict: Keep UI states in local or global client state (Zustand/Context), not React Query.

3. Forms and Mutations

React Query handles form submissions well. You can use mutations to send form data and optimistically update the UI before the server confirms it. It also helps with background syncing and retries.

Verdict: React Query works great for forms that interact with the backend, but not for controlling form UI states like "step," "validation," or "focus."

4. Background Sync and Refetching

One of React Query's biggest advantages is automatic data refetching and background sync. If your app displays live data (like dashboards or notifications), React Query keeps it fresh without manual effort.

Verdict: This is a core strength — no need for Redux or Zustand here.

Decision Checklist: When to Use React Query, Zustand, or Redux

Here's a practical checklist you can use when setting up state management in your Next.js App Router project:

Use React Query when

You are fetching or mutating server-side data (APIs, databases, third-party services).
You want auto-caching, background refetching, and syncing across tabs or sessions.
Your data depends on URL params, filters, or pagination that change often.
You need optimistic updates or retries without writing boilerplate.
You're building dashboards, analytics, or feed-style apps with live data.

Use Zustand (or Context) when

You need client-only state — modals, toasts, theme toggles, or active tabs.
You are managing UI state that does not come from the server.
You want a simple, minimal store with no boilerplate.
Your app has a few global flags or preferences that do not justify Redux.

Use Redux when

Your app has complex, cross-slice state logic (e.g. large enterprise dashboards).
You need strict state control, middleware, or predictable reducers.
You are working in a large team where traceability and dev tools matter.
You rely on custom event pipelines, analytics tracking, or deep action-level debugging.

In most modern Next.js projects, React Query + Zustand is enough 90% of the time. Redux still fits when you need heavy coordination across different domains or long-lived background processes.

Wrapping Up

State management in Next.js doesn't have to be complicated — it is just about using the right tool for the right layer. React Query handles the server-side beautifully, while Zustand or simple context handles UI logic cleanly. Redux still has its place, but it is no longer the default choice it once was.

If you think in terms of server vs client state, your architecture decisions become simpler, your codebase lighter, and your team faster. That is really the takeaway — not picking one library over another, but knowing where each fits best.

Originally published on GeekyAnts Blog

iOS Live Activities in React Native: A Complete Guide

GeekyAnts Inc — Wed, 11 Mar 2026 10:32:48 +0000

A comprehensive step-by-step guide to building real-time Lock Screen & Dynamic Island experiences in React Native

*Originally published on GeekyAnts Blog by Yuvraj Kumar, Software Engineer III

Understanding Live Activities & Dynamic Island

Live Activities change how users engage with time-sensitive information. They bring real-time updates straight to the iPhone's Lock Screen and Dynamic Island. For flight-tracking apps, this means you do not have to keep opening them to check departure gates, delays, or boarding status.

Dynamic Island Integration (iPhone 14 Pro and later) provides three distinct presentation modes:

Minimal: Single icon or short text (gate number)
Compact: Leading and trailing elements (flight status + countdown)
Expanded: Full, detailed view with interactive elements

In flight-tracking scenarios, users can monitor boarding countdowns, receive gate-change notifications, and access quick actions like viewing boarding passes — all without unlocking their device.

Key Benefits

40% higher engagement than traditional push notifications
Persistent visibility during critical travel moments
Seamless integration with iOS design language
Real-time updates even when the app is terminated

Project Configuration Requirements

Push Notification Setup

Live Activities depend on Apple Push Notification Service (APNs) for real-time updates. Configure push notifications first:

In Xcode: Select your app target → Signing & Capabilities
Add Capability: Click "+" and select "Push Notifications"
Verify Entitlements: Ensure aps-environment is properly configured

Info.plist Configuration

Enable Live Activities in your main app's Info.plist:

<key>NSSupportsLiveActivities</key>
<true/>
<key>NSSupportsLiveActivitiesFrequentUpdates</key>
<true/>

The NSSupportsLiveActivitiesFrequentUpdates key is essential for flight tracking as it allows updates more frequently than the standard limit — critical for gate changes and boarding updates.

Widget Extension Target

Create a separate Widget Extension for Live Activities:

Add Target: File → New → Target → Widget Extension
Configuration: Name it FlightTrackerWidget, include Live Activity intent
Build Settings: Set deployment target to iOS 16.1+, configure App Groups for data sharing

Build Phases — Critical Step

For React Native compatibility, verify the Build Phases configuration:

Navigate to Build Phases → Embed App Extensions
Ensure "Copy only when installing" is unchecked

This step is crucial for Live Activities to function properly in React Native environments.

Live Activity Widget Structure

Core SwiftUI Implementation

The Widget Extension contains several key files, but focus on these essential components:

FlightActivityAttributes.swift (Data Structure)

import ActivityKit
import Foundation

struct FlightActivityAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        var flightStatus: String
        var gateNumber: String
        var boardingTime: Date
        var delayMinutes: Int
        var isBoarding: Bool
    }

    // Static data (doesn't change during the activity)
    var flightNumber: String
    var origin: String
    var destination: String
    var scheduledDeparture: Date
    var airline: String
}

FlightActivityWidget.swift (UI Implementation)

import ActivityKit
import SwiftUI
import WidgetKit

struct FlightActivityWidget: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: FlightActivityAttributes.self) { context in
            // Lock Screen / Banner UI
            FlightLockScreenView(context: context)
                .activityBackgroundTint(Color.black.opacity(0.8))
                .activitySystemActionForegroundColor(Color.white)
        } dynamicIsland: { context in
            DynamicIsland {
                // Expanded view
                DynamicIslandExpandedRegion(.leading) {
                    FlightStatusLeadingView(context: context)
                }
                DynamicIslandExpandedRegion(.trailing) {
                    GateInfoTrailingView(context: context)
                }
                DynamicIslandExpandedRegion(.bottom) {
                    BoardingProgressView(context: context)
                }
            } compactLeading: {
                Image(systemName: "airplane")
                    .foregroundColor(.blue)
            } compactTrailing: {
                Text(context.state.gateNumber)
                    .font(.caption2)
                    .bold()
            } minimal: {
                Image(systemName: context.state.isBoarding ? "airplane.departure" : "airplane")
                    .foregroundColor(context.state.isBoarding ? .green : .blue)
            }
        }
    }
}

struct FlightLockScreenView: View {
    let context: ActivityViewContext<FlightActivityAttributes>

    var body: some View {
        VStack(spacing: 8) {
            HStack {
                VStack(alignment: .leading) {
                    Text(context.attributes.flightNumber)
                        .font(.headline)
                        .bold()
                    Text("\(context.attributes.origin) → \(context.attributes.destination)")
                        .font(.subheadline)
                }
                Spacer()
                StatusBadgeView(status: context.state.flightStatus)
            }

            Divider().background(Color.white.opacity(0.3))

            HStack {
                InfoItemView(
                    icon: "door.right.hand.open",
                    label: "Gate",
                    value: context.state.gateNumber
                )
                Spacer()
                InfoItemView(
                    icon: "clock",
                    label: "Boarding",
                    value: context.state.boardingTime.formatted(date: .omitted, time: .shortened)
                )
                Spacer()
                if context.state.delayMinutes > 0 {
                    InfoItemView(
                        icon: "exclamationmark.triangle",
                        label: "Delay",
                        value: "+\(context.state.delayMinutes)m",
                        valueColor: .orange
                    )
                }
            }

            if context.state.isBoarding {
                BoardingNowBannerView()
            }
        }
        .padding()
        .foregroundColor(.white)
    }
}

Understanding the Architecture

ActivityAttributes: Defines both static data (flight details) and dynamic state (status, gate)
Lock Screen Layout: Primary real estate for detailed information
Dynamic Island Regions: Different areas serve specific purposes (leading for status, trailing for gate info)

Native Module Bridge Implementation

To control Live Activities from React Native, create a bridge using three essential files:

1. LiveActivityModule.swift (Core Logic)

import ActivityKit
import Foundation
import React

@objc(LiveActivityModule)
class LiveActivityModule: NSObject {

    private var activeActivities: [String: Activity<FlightActivityAttributes>] = [:]

    @objc func startFlightActivity(
        _ flightData: NSDictionary,
        resolver resolve: @escaping RCTPromiseResolveBlock,
        rejecter reject: @escaping RCTPromiseRejectBlock
    ) {
        guard ActivityAuthorizationInfo().areActivitiesEnabled else {
            reject("ACTIVITIES_DISABLED", "Live Activities are not enabled", nil)
            return
        }

        do {
            let attributes = FlightActivityAttributes(
                flightNumber: flightData["flightNumber"] as? String ?? "",
                origin: flightData["origin"] as? String ?? "",
                destination: flightData["destination"] as? String ?? "",
                scheduledDeparture: Date(timeIntervalSince1970: flightData["scheduledDeparture"] as? Double ?? 0),
                airline: flightData["airline"] as? String ?? ""
            )

            let initialState = FlightActivityAttributes.ContentState(
                flightStatus: flightData["status"] as? String ?? "On Time",
                gateNumber: flightData["gate"] as? String ?? "TBD",
                boardingTime: Date(timeIntervalSince1970: flightData["boardingTime"] as? Double ?? 0),
                delayMinutes: flightData["delayMinutes"] as? Int ?? 0,
                isBoarding: false
            )

            let activity = try Activity<FlightActivityAttributes>.request(
                attributes: attributes,
                contentState: initialState,
                pushType: .token
            )

            activeActivities[activity.id] = activity

            // Listen for push token updates
            Task {
                for await pushToken in activity.pushTokenUpdates {
                    let tokenString = pushToken.map { String(format: "%02x", $0) }.joined()
                    // Send token to React Native
                    self.sendEvent("onPushTokenUpdate", body: [
                        "activityId": activity.id,
                        "pushToken": tokenString
                    ])
                }
            }

            resolve([
                "activityId": activity.id,
                "success": true
            ])

        } catch {
            reject("START_FAILED", "Failed to start Live Activity: \(error.localizedDescription)", error)
        }
    }

    @objc func updateFlightActivity(
        _ activityId: String,
        updateData: NSDictionary,
        resolver resolve: @escaping RCTPromiseResolveBlock,
        rejecter reject: @escaping RCTPromiseRejectBlock
    ) {
        guard let activity = activeActivities[activityId] else {
            reject("NOT_FOUND", "Activity not found: \(activityId)", nil)
            return
        }

        let updatedState = FlightActivityAttributes.ContentState(
            flightStatus: updateData["status"] as? String ?? activity.contentState.flightStatus,
            gateNumber: updateData["gate"] as? String ?? activity.contentState.gateNumber,
            boardingTime: Date(timeIntervalSince1970: updateData["boardingTime"] as? Double ?? activity.contentState.boardingTime.timeIntervalSince1970),
            delayMinutes: updateData["delayMinutes"] as? Int ?? activity.contentState.delayMinutes,
            isBoarding: updateData["isBoarding"] as? Bool ?? activity.contentState.isBoarding
        )

        Task {
            await activity.update(using: updatedState)
            resolve(["success": true])
        }
    }

    @objc func endFlightActivity(
        _ activityId: String,
        resolver resolve: @escaping RCTPromiseResolveBlock,
        rejecter reject: @escaping RCTPromiseRejectBlock
    ) {
        guard let activity = activeActivities[activityId] else {
            reject("NOT_FOUND", "Activity not found", nil)
            return
        }

        Task {
            await activity.end(dismissalPolicy: .immediate)
            self.activeActivities.removeValue(forKey: activityId)
            resolve(["success": true])
        }
    }

    @objc static func requiresMainQueueSetup() -> Bool {
        return false
    }
}

2. RCTFlightActivityModule.m (Objective-C Bridge)

#import <React/RCTBridgeModule.h>

@interface RCT_EXTERN_MODULE(LiveActivityModule, NSObject)

RCT_EXTERN_METHOD(
  startFlightActivity:(NSDictionary *)flightData
  resolver:(RCTPromiseResolveBlock)resolve
  rejecter:(RCTPromiseRejectBlock)reject
)

RCT_EXTERN_METHOD(
  updateFlightActivity:(NSString *)activityId
  updateData:(NSDictionary *)updateData
  resolver:(RCTPromiseResolveBlock)resolve
  rejecter:(RCTPromiseRejectBlock)reject
)

RCT_EXTERN_METHOD(
  endFlightActivity:(NSString *)activityId
  resolver:(RCTPromiseResolveBlock)resolve
  rejecter:(RCTPromiseRejectBlock)reject
)

@end

3. FlightActivity-Bridging-Header.h

#import <React/RCTBridgeModule.h>
#import <React/RCTEventEmitter.h>

Critical Setup: Add the bridging header file path in Build Settings → Swift Compiler - General → Objective-C Bridging Header.

React Native Service Integration

FlightActivityService.ts

Creating a service to manage Live Activities from JavaScript:

import { NativeModules, NativeEventEmitter, Platform } from 'react-native';

const { LiveActivityModule } = NativeModules;

interface FlightData {
  flightNumber: string;
  origin: string;
  destination: string;
  airline: string;
  scheduledDeparture: number; // Unix timestamp
  status: string;
  gate: string;
  boardingTime: number; // Unix timestamp
  delayMinutes: number;
}

interface UpdateData {
  status?: string;
  gate?: string;
  boardingTime?: number;
  delayMinutes?: number;
  isBoarding?: boolean;
}

interface ActivityResult {
  activityId: string;
  success: boolean;
}

class FlightActivityService {
  private eventEmitter: NativeEventEmitter | null = null;
  private pushTokenCallback: ((token: string, activityId: string) => void) | null = null;

  constructor() {
    if (Platform.OS === 'ios' && LiveActivityModule) {
      this.eventEmitter = new NativeEventEmitter(LiveActivityModule);
      this.setupEventListeners();
    }
  }

  private setupEventListeners() {
    this.eventEmitter?.addListener('onPushTokenUpdate', (data) => {
      if (this.pushTokenCallback) {
        this.pushTokenCallback(data.pushToken, data.activityId);
      }
    });
  }

  async startActivity(flightData: FlightData): Promise<ActivityResult> {
    if (Platform.OS !== 'ios') {
      throw new Error('Live Activities are only available on iOS');
    }

    if (!LiveActivityModule) {
      throw new Error('LiveActivityModule is not available');
    }

    return LiveActivityModule.startFlightActivity(flightData);
  }

  async updateActivity(activityId: string, updateData: UpdateData): Promise<{ success: boolean }> {
    if (Platform.OS !== 'ios' || !LiveActivityModule) return { success: false };
    return LiveActivityModule.updateFlightActivity(activityId, updateData);
  }

  async endActivity(activityId: string): Promise<{ success: boolean }> {
    if (Platform.OS !== 'ios' || !LiveActivityModule) return { success: false };
    return LiveActivityModule.endFlightActivity(activityId);
  }

  onPushTokenUpdate(callback: (token: string, activityId: string) => void) {
    this.pushTokenCallback = callback;
  }
}

export const flightActivityService = new FlightActivityService();
export type { FlightData, UpdateData, ActivityResult };

App Integration (React Example)

import React, { useState, useCallback } from 'react';
import { View, Button, Text, Alert } from 'react-native';
import { flightActivityService, FlightData } from './FlightActivityService';

const FlightTrackerApp = () => {
  const [activityId, setActivityId] = useState<string | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  const flightData: FlightData = {
    flightNumber: 'GA 2025',
    origin: 'BLR',
    destination: 'BOM',
    airline: 'GeekyAir',
    scheduledDeparture: Date.now() / 1000 + 3600,
    status: 'On Time',
    gate: 'A12',
    boardingTime: Date.now() / 1000 + 2700,
    delayMinutes: 0,
  };

  const startTracking = useCallback(async () => {
    setIsLoading(true);
    try {
      const result = await flightActivityService.startActivity(flightData);
      setActivityId(result.activityId);

      // Register for push token updates
      flightActivityService.onPushTokenUpdate(async (token, id) => {
        // Send push token to your backend
        await fetch('https://your-api.com/register-push-token', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ activityId: id, pushToken: token }),
        });
      });

      Alert.alert('Success', 'Flight tracking started!');
    } catch (error) {
      Alert.alert('Error', `Failed to start tracking: ${error}`);
    } finally {
      setIsLoading(false);
    }
  }, []);

  const simulateGateChange = useCallback(async () => {
    if (!activityId) return;
    await flightActivityService.updateActivity(activityId, {
      gate: 'B7',
      status: 'Gate Changed',
      delayMinutes: 15,
    });
  }, [activityId]);

  const simulateBoarding = useCallback(async () => {
    if (!activityId) return;
    await flightActivityService.updateActivity(activityId, {
      isBoarding: true,
      status: 'Boarding Now',
    });
  }, [activityId]);

  const endTracking = useCallback(async () => {
    if (!activityId) return;
    await flightActivityService.endActivity(activityId);
    setActivityId(null);
  }, [activityId]);

  return (
    <View style={{ flex: 1, justifyContent: 'center', padding: 20 }}>
      <Text style={{ fontSize: 24, fontWeight: 'bold', marginBottom: 20 }}>
        Flight Tracker
      </Text>

      {!activityId ? (
        <Button title="Start Tracking" onPress={startTracking} disabled={isLoading} />
      ) : (
        <>
          <Text style={{ marginBottom: 10 }}>Activity ID: {activityId.slice(0, 8)}...</Text>
          <Button title="Simulate Gate Change" onPress={simulateGateChange} />
          <Button title="Start Boarding" onPress={simulateBoarding} />
          <Button title="End Tracking" onPress={endTracking} color="red" />
        </>
      )}
    </View>
  );
};

export default FlightTrackerApp;

Push Notifications Architecture

Backend Implementation (Node.js)

Live Activities can receive updates even when your app is completely terminated through APNs:

const http2 = require('http2');
const fs = require('fs');
const jwt = require('jsonwebtoken');

class APNsLiveActivityService {
  constructor(config) {
    this.teamId = config.teamId;
    this.keyId = config.keyId;
    this.privateKey = fs.readFileSync(config.privateKeyPath);
    this.bundleId = config.bundleId;
    this.isProduction = config.isProduction || false;
    this.client = null;
    this.tokenCache = null;
    this.tokenExpiry = 0;
  }

  getAPNsHost() {
    return this.isProduction
      ? 'api.push.apple.com'
      : 'api.sandbox.push.apple.com';
  }

  generateJWT() {
    const now = Math.floor(Date.now() / 1000);

    if (this.tokenCache && now < this.tokenExpiry) {
      return this.tokenCache;
    }

    const token = jwt.sign(
      { iss: this.teamId, iat: now },
      this.privateKey,
      { algorithm: 'ES256', keyid: this.keyId }
    );

    this.tokenCache = token;
    this.tokenExpiry = now + 3000; // Refresh before 1-hour expiry
    return token;
  }

  async getConnection() {
    if (!this.client || this.client.destroyed) {
      this.client = http2.connect(`https://${this.getAPNsHost()}`);
    }
    return this.client;
  }

  async sendLiveActivityUpdate(pushToken, flightUpdate) {
    const client = await this.getConnection();
    const token = this.generateJWT();

    const payload = {
      aps: {
        timestamp: Math.floor(Date.now() / 1000),
        event: 'update',
        'content-state': {
          flightStatus: flightUpdate.status,
          gateNumber: flightUpdate.gate,
          boardingTime: flightUpdate.boardingTime,
          delayMinutes: flightUpdate.delayMinutes || 0,
          isBoarding: flightUpdate.isBoarding || false,
        },
        alert: {
          title: flightUpdate.alertTitle || 'Flight Update',
          body: flightUpdate.alertBody || `Gate: ${flightUpdate.gate} | ${flightUpdate.status}`,
        },
      },
    };

    return new Promise((resolve, reject) => {
      const path = `/3/device/${pushToken}`;
      const payloadBuffer = Buffer.from(JSON.stringify(payload));

      const req = client.request({
        ':method': 'POST',
        ':path': path,
        'authorization': `bearer ${token}`,
        'apns-topic': `${this.bundleId}.push-type.liveactivity`,
        'apns-push-type': 'liveactivity',
        'apns-priority': '10',
        'content-type': 'application/json',
        'content-length': payloadBuffer.length,
      });

      req.write(payloadBuffer);
      req.end();

      let statusCode;

      req.on('response', (headers) => {
        statusCode = headers[':status'];
      });

      req.on('end', () => {
        if (statusCode === 200) {
          resolve({ success: true });
        } else {
          reject(new Error(`APNs returned status ${statusCode}`));
        }
      });

      req.on('error', reject);
    });
  }
}

// Usage example
const apnsService = new APNsLiveActivityService({
  teamId: process.env.APPLE_TEAM_ID,
  keyId: process.env.APPLE_KEY_ID,
  privateKeyPath: './AuthKey.p8',
  bundleId: 'com.geekyants.flighttracker',
  isProduction: process.env.NODE_ENV === 'production',
});

// Express endpoint to handle flight status updates
app.post('/flight-update', async (req, res) => {
  const { activityId, pushToken, flightUpdate } = req.body;

  try {
    await apnsService.sendLiveActivityUpdate(pushToken, flightUpdate);
    res.json({ success: true });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Push Notification Flow:

App starts Live Activity and receives a unique push token
Token sent to the backend and stored with the activity ID
Backend monitors flight data changes
Real-time updates are sent via APNs to a specific activity
iOS automatically updates Live Activity UI

Key Flow Benefits

Updates work even when the app is completely closed
Each Live Activity has a unique push token
No polling required — real push notifications
Automatic UI refresh by the iOS system
Battery efficient — no background processing
Multiple activities can run simultaneously

Example APNs Payload Structure

{
  "aps": {
    "timestamp": 1700000000,
    "event": "update",
    "content-state": {
      "flightStatus": "Boarding Now",
      "gateNumber": "B7",
      "boardingTime": 1700003600,
      "delayMinutes": 15,
      "isBoarding": true
    },
    "alert": {
      "title": "Boarding Started",
      "body": "Gate B7 is now boarding — hurry!"
    }
  }
}

Interactive Elements & Deep Links

AppIntents Implementation

Adding interactive buttons to your Live Activity:

import AppIntents

struct ViewBoardingPassIntent: LiveActivityIntent {
    static var title: LocalizedStringResource = "View Boarding Pass"
    static var isDiscoverable: Bool = false

    @Parameter(title: "Activity ID")
    var activityId: String

    init() {}

    init(activityId: String) {
        self.activityId = activityId
    }

    func perform() async throws -> some IntentResult {
        // This triggers deep link handling in the main app
        return .result()
    }
}

struct CheckInIntent: LiveActivityIntent {
    static var title: LocalizedStringResource = "Check In"
    static var isDiscoverable: Bool = false

    @Parameter(title: "Flight Number")
    var flightNumber: String

    init() {}

    init(flightNumber: String) {
        self.flightNumber = flightNumber
    }

    func perform() async throws -> some IntentResult {
        return .result()
    }
}

Integration in Live Activity UI

struct InteractiveLiveActivityView: View {
    let context: ActivityViewContext<FlightActivityAttributes>

    var body: some View {
        HStack(spacing: 12) {
            Button(intent: ViewBoardingPassIntent(activityId: context.attributes.flightNumber)) {
                Label("Boarding Pass", systemImage: "qrcode")
                    .font(.caption)
            }
            .buttonStyle(.borderedProminent)
            .tint(.blue)

            Button(intent: CheckInIntent(flightNumber: context.attributes.flightNumber)) {
                Label("Check In", systemImage: "checkmark.circle")
                    .font(.caption)
            }
            .buttonStyle(.borderedProminent)
            .tint(.green)
        }
    }
}

React Native Deep Link Handling

import { Linking } from 'react-native';
import { useEffect } from 'react';

const useDeepLinkHandler = () => {
  useEffect(() => {
    const handleDeepLink = (event: { url: string }) => {
      const url = new URL(event.url);

      switch (url.pathname) {
        case '/boarding-pass':
          const flightNumber = url.searchParams.get('flight');
          navigateToBoardingPass(flightNumber);
          break;

        case '/check-in':
          const flight = url.searchParams.get('flight');
          navigateToCheckIn(flight);
          break;
      }
    };

    Linking.addEventListener('url', handleDeepLink);
    return () => Linking.removeAllListeners('url');
  }, []);
};

Push-to-Start Implementation (iOS 17.2+)

Push-to-Start allows your backend to initiate Live Activities without user interaction:

Backend Implementation

async function sendPushToStartActivity(pushToStartToken, flightData) {
  const payload = {
    aps: {
      timestamp: Math.floor(Date.now() / 1000),
      event: 'start',
      'content-state': {
        flightStatus: 'Scheduled',
        gateNumber: flightData.gate || 'TBD',
        boardingTime: flightData.boardingTime,
        delayMinutes: 0,
        isBoarding: false,
      },
      'attributes-type': 'FlightActivityAttributes',
      attributes: {
        flightNumber: flightData.flightNumber,
        origin: flightData.origin,
        destination: flightData.destination,
        airline: flightData.airline,
        scheduledDeparture: flightData.scheduledDeparture,
      },
      alert: {
        title: `${flightData.flightNumber} Tracking Started`,
        body: `${flightData.origin} → ${flightData.destination} — Live tracking is now active`,
      },
    },
  };

  return apnsService.sendToDevice(pushToStartToken, payload, 'liveactivity');
}

Strategic Use Cases

Auto-activate tracking 24 hours before departure
Begin monitoring immediately after successful booking
Start the activity when the gate is assigned
Initiate during the mobile check-in process

Business Impact & Implementation Strategy

Engagement Metrics

Live Activities create measurable business value through enhanced user engagement and new revenue streams:

User Engagement

Metric	Impact
Interaction rate vs. push notifications	+40%
Reduction in app abandonment during delays	-60%
Increase in session duration when active	+50%

Conversion Impact

Metric	Impact
Ancillary service bookings (upgrades, meals)	+30%
Click-through rate on cross-sell offers	+45%
Reduction in customer support queries	-20%

Conclusion

iOS Live Activities represent a significant evolution in mobile user experience, particularly for time-sensitive applications like flight tracking. The technical implementation requires coordination between native iOS development and React Native, but the user engagement and business benefits justify the complexity.

Key Success Factors

User-Centric Design: Focus on displaying only essential information that users need at critical moments
Technical Reliability: Robust error handling and graceful degradation for network issues
Performance Optimization: Minimize battery impact through intelligent update strategies
Business Integration: Leverage Live Activities for revenue generation, not just user experience

The investment in Live Activities technology positions your application at the forefront of mobile user experience while creating new opportunities for user engagement and revenue generation.

Note: This guide reflects best practices as of September 2025 for iOS 17.5+ and React Native 0.74+. Always refer to Apple's latest documentation for current APIs and requirements.

Written by **Yuvraj Kumar, Software Engineer III at GeekyAnts — a global software development and technology consulting firm specializing in cross-platform mobile and web engineering.

GeekyAnts is a React Native development company with deep expertise in iOS and Android native integrations.

Performant Vertical Feed in Expo: HLS Caching on iOS

GeekyAnts Inc — Wed, 11 Mar 2026 10:14:58 +0000

*By Monisankar Nath, Senior Software Engineer II at GeekyAnts

In the world of modernmobile apps, users have been trained to expect instant. Whether scrolling through TikTok, swiping on Instagram Reels, or watching course content, they expect videos to play immediately — even in tunnels, elevators, or spotty network conditions.

To achieve this instant feel, offline caching is non-negotiable. You need to pre-download the next few videos in the feed so they are ready before the user even scrolls to them.

React Native developers often rely on the Expo ecosystem to abstract away the complexity of native media players. With the release of Expo SDK 52, the team introduced the powerful new expo-video library (replacing the older expo-av). It brought a modernized player implementation, better performance, and — crucially — a native useCaching prop that stabilized in Expo SDK 53.

For many use cases, this seemed like the final piece of the puzzle. But as we dug deeper into building a high-performance, offline-first video feed, we hit a significant roadblock: iOS HLS support.

The Gotcha with HLS

While Android (via the powerful ExoPlayer/Media3) and standard .mp4 files worked seamlessly with the new native caching, trying to cache HLS (.m3u8) streams on iOS resulted in... nothing.

The native iOS AVPlayer is fantastic at streaming, but it simply doesn't support a straightforward, "one-line code" way to cache complex HLS playlists to the disk for offline retrieval. This left us with a critical feature gap: our Android users enjoyed a smooth, offline-ready experience, while our iOS users faced buffering or playback failures the moment they lost connection.

We decided to solve this. This post details how we built expo-video-cache, a drop-in solution to enable offline HLS playback on iOS, and the lessons we learned along the way.

Why HLS is Hard to Cache

To understand the solution, we first have to understand why HLS is fundamentally different from the video files you might be used to.

MP4: The "Single File" Approach

When you play a standard MP4 file, you are dealing with a monolithic file. Caching it is trivial:

Download movie.mp4 (500MB).
Save it to file:///documents/movie.mp4.
Tell the player to play that local path.

HLS: The Tree Protocol

HLS (HTTP Live Streaming) is a file and streaming protocol. It behaves less like a single book and more like a library card catalog.

If you simply download the .m3u8 link, you have not downloaded the video. You have only downloaded a tiny text file (a few kilobytes) that contains links to other files.

To cache HLS, you must traverse a complex tree structure:

The Master Manifest — The entry point. It lists available resolutions (1080p, 720p, etc.).
The Media Playlist — Once a resolution is chosen, this file lists thousands of tiny video chunks.
The Segments — The actual video data (usually .ts or .fmp4 files), lasting 2–6 seconds each.

The iOS Roadblock. On Android, the native ExoPlayer is smart enough to handle this "tree walking" and caching internally.

On iOS, the AVPlayer is designed primarily for streaming. While Apple provides APIs for downloading HLS (like AVAssetDownloadTask), they are complex, restrictive, and often designed for long-form content (like downloading a movie on Netflix to watch on a plane) rather than the instant, short-form caching required for a TikTok-like feed.

We needed a way to make AVPlayer treat a cached HLS stream just like a live one — without it knowing the difference.

The Solution: A Local Proxy Server

Since we could not force AVPlayer to cache the stream natively, we decided to trick it. We built expo-video-cache using a Local Proxy Architecture.

The concept is simple but powerful: we spin up a tiny web server on the device itself (localhost) that sits between the video player and the internet.

Instead of feeding the player the remote URL:

https://example.com/video.m3u8

We feed it a local URL pointing to our proxy:

http://127.0.0.1:9000/proxy?url=https://example.com/video.m3u8

Visualizing the Flow

Here is exactly what happens when you press "Play." The proxy acts as a traffic controller, deciding whether to fetch data from the internet or serve it from the device's storage.

How It Works Under the Hood

The magic happens in three distinct phases:

1. Interception

When the AVPlayer tries to load our localhost URL, it connects to our internal server instead of the internet. The player has no idea it is talking to a local script; it thinks it's streaming from a standard web server.

2. Manifest Rewriting

This is the most critical technical step. To prevent the player from bypassing us, our proxy downloads the manifest and parses it line-by-line.

We added an optimization here. We check our local cache for each segment listed in the manifest:

If the file exists on disk, we rewrite the URL to point to our localhost proxy (serving it instantly from storage).
If the file is missing, we keep the original remote URL in the manifest.

This ensures the player only uses our proxy when we actually have the data, reducing overhead for new content.

3. Smart Caching

Finally, when the player reads our rewritten manifest:

Cache Hit: If we point the player to localhost, we serve the video segment instantly from the disk. This enables offline playback and eliminates buffering.
Cache Miss: If the segment wasn't in our cache, the player reads the original URL and streams it directly from the internet. Crucially, we trigger a background download simultaneously. This ensures that while the user watches the "live" stream, we are silently saving a copy to the disk so that the next time they view it, it will be instant.

This architecture allows the AVPlayer to function exactly as Apple intended — streaming small chunks — while we silently manage the file persistence in the background.

Implementation: The "Hybrid" Strategy

When building cross-platform modules, it is tempting to force both platforms to behave exactly the same way. However, we realized that Android's native caching (via ExoPlayer) is already excellent. It supports HLS caching out of the box.

We didn't want to add the overhead of a local proxy server on Android where it wasn't needed. We only wanted to intervene on iOS.

This led to a "Hybrid" Implementation Strategy:

Android: Passthrough (Let the native player handle it).
iOS: Intercept (Route through our local proxy).

Visualizing the Logic

Here is how our application decides how to load a video URL at runtime:

1. Installation

npx expo install expo-video-cache

2. The Global Server Setup

We spin up the local server once when the app launches. A great place for this is your root _layout.tsx file.

We use a "Fire and Forget" approach here. We do not wait for the server startup before rendering the UI because the server starts almost instantly (in milliseconds), and we don't want to block the user from seeing the splash screen or home feed.

// app/_layout.tsx
import { useEffect } from 'react';
import { VideoCache } from 'expo-video-cache';

export default function RootLayout() {
  useEffect(() => {
    // Fire and forget — don't await this
    VideoCache.startServer().catch(console.error);
  }, []);

  return (
    // ... your app layout
  );
}

3. The Smart Source Helper

This is the most critical piece of code in your app. We created a utility function, getVideoSource, to abstract away the platform differences.

Critical Note on useCaching: On iOS, we explicitly set useCaching: false.
Why? Our proxy is already caching the file to disk. If we told the native AVPlayer to cache it too, it would try to cache the response from our localhost server, leading to redundant data duplication and potential conflicts. We want the player to treat our proxy as a "live" stream.

// utils/video.ts
import { Platform } from 'react-native';
import { VideoCache } from 'expo-video-cache';

export async function getVideoSource(remoteUrl: string) {
  if (Platform.OS === 'ios' && remoteUrl.includes('.m3u8')) {
    // Check if the proxy server is ready
    const isReady = await VideoCache.isServerReady();

    if (isReady) {
      const proxiedUrl = VideoCache.convertUrl(remoteUrl);
      return {
        uri: proxiedUrl,
        useCaching: false, // CRITICAL: proxy handles caching, not the native player
      };
    }
  }

  // Android or MP4: use native caching directly
  return {
    uri: remoteUrl,
    useCaching: true,
  };
}

Using it in your component becomes trivial. You no longer need to think about platforms inside your UI code:

// components/VideoFeedItem.tsx
import { VideoView, useVideoPlayer } from 'expo-video';
import { getVideoSource } from '../utils/video';
import { useEffect, useState } from 'react';

export function VideoFeedItem({ url }: { url: string }) {
  const [source, setSource] = useState<{ uri: string; useCaching: boolean } | null>(null);

  useEffect(() => {
    getVideoSource(url).then(setSource);
  }, [url]);

  const player = useVideoPlayer(source, (player) => {
    player.loop = true;
    player.play();
  });

  return <VideoView player={player} style={{ flex: 1 }} />;
}

Challenges & Caveats

Building a native proxy server from scratch wasn't without its hurdles. Here are the key "Gotchas" we discovered during development that might save you some headaches.

1. The MP4 Trap

In our first prototype, we got excited and tried to run everything through the proxy. This was a mistake.

The Issue: If you try to proxy a large static file (like a 500MB .mp4 movie), the proxy attempts to download the entire file to disk before it serves the first byte to the player.
The Result: The user sees a black screen and a loading spinner for 2 minutes.
The Rule: Use the right tool for the job.
- HLS (.m3u8): Use expo-video-cache. The segments are small (~2MB), so they download and play instantly.
- MP4: Use standard expo-video caching. The native player is much better at handling large static file buffering.

2. The "App Launch" Race Condition

We ran into an edge case where a video on the very first screen of the app would fail to load.

The Cause: The app launched so fast that the React Native UI tried to request the video URL before our localhost server had finished binding to port 9000 (which takes ~10–50ms).
The Fix: We built a safety check into the convertUrl function. If the server isn't ready, it simply returns the original remote URL. The video still plays (uncached), preventing a crash or error screen.

3. DRM Limitations

This approach relies on Manifest Rewriting — literally opening the text file and changing the URLs.

The Issue: DRM systems (like Apple's FairPlay) rely on digital signatures to verify that the manifest hasn't been tampered with. Rewriting the URLs breaks this signature.
The Limit: This solution is strictly for non-DRM (Clear) content. If you need offline playback for Netflix-style DRM content, you must use the platform's native offline download managers, which are significantly more complex to implement.

Performance & Size Impact

We know that bundle size matters. We measured the impact of adding expo-video-cache to a production build to ensure it respects your app's footprint.

iOS Impact: ~2.5 MB

The iOS module includes a lightweight embedded Swift HTTP server (Swifter). In a production release build (stripped and optimized), this adds approximately 2.5 MB to your final .ipa size.

Android Impact: ~0 KB (Negligible)

Since Android relies entirely on the native ExoPlayer for caching, our module acts as a simple pass-through shim.

Platform	Size Increase	Implementation
iOS	~2.5 MB	Embedded Swift HTTP server (Swifter)
Android	~0 KB	Native ExoPlayer pass-through

This creates a "best of both worlds" scenario: robust utility where it's needed (iOS) and zero overhead where it's not (Android).

In Conclusion

expo-video-cache was born out of necessity, but it has become a robust solution for our offline-first requirements. It bridges the critical gap between iOS's strict streaming protocols and the need for a modern, instant, cached user experience.

We've open-sourced this package for the community because we believe no one should have to write a Swift web server just to play a video loop.

If you are struggling with offline HLS on iOS, give it a try.

Originally published on GeekyAnts Blog.

GeekyAnts is a global software development and technology consulting firm. We build cross-platform apps, design systems, and AI-powered products for enterprise clients worldwide.

AI App Development Cost in 2025: A Complete Guide

GeekyAnts Inc — Wed, 04 Mar 2026 09:40:12 +0000

Artificial Intelligence (AI) is no longer a futuristic concept—it’s a driving force behind modern digital products. From AI chatbots and recommendation engines to predictive analytics and generative AI applications, companies across industries are investing in AI-powered solutions.

But before building an AI-powered product, one critical question arises:

How much does it cost to develop an AI app?

The answer depends on several variables including AI model complexity, development team, infrastructure, and ongoing maintenance. In this guide, we’ll break down everything you need to know about AI app development costs in 2025.

Key Takeaways

AI Market Growth: The global AI market is projected to grow from $40.3B in 2024 to $221.9B by 2034.
Wide Cost Range: AI app development costs typically range from $30K for MVPs to $500K+ for enterprise applications.
Major Cost Drivers: AI model complexity, data requirements, integrations, and compliance requirements.
Hidden Costs: Cloud infrastructure, model retraining, security audits, and maintenance.
Cost Optimization: MVP-first strategy, open-source frameworks, and cloud-based AI services.

Why AI Apps Are Transforming Businesses

AI-powered applications deliver automation, personalization, and predictive capabilities that traditional software cannot match.

Companies use AI apps for:

Intelligent chatbots and virtual assistants
Personalized product recommendations
Fraud detection systems
Predictive analytics platforms
Generative AI tools for content and automation

Unlike traditional apps, AI systems continuously learn and improve with data, making them more valuable over time.

How Much Does AI App Development Cost?

The cost of building an AI application varies depending on the complexity of the solution.

App Type	Estimated Cost
Basic AI App	$30,000 – $75,000
Mid-Level AI App	$75,000 – $150,000
Enterprise AI Solution	$150,000 – $500,000+
Custom Generative AI Platforms	$500,000 – $1M+

The final cost depends on several factors including data pipelines, AI models, infrastructure, and integrations.

AI App Development Cost Breakdown by Stage

Developing an AI-powered application involves several phases.

1. Planning & Discovery

Before development begins, teams define the AI use case, required datasets, and architecture.

Phase	Estimated Cost	Timeline
Planning & Discovery	$5,000 – $10,000	1–2 weeks

Deliverables include:

AI project roadmap
feasibility analysis
technology stack selection
dataset identification

2. UX/UI Design

AI interactions must be intuitive and easy to use.

Phase	Estimated Cost	Timeline
UX/UI Design	$5,000 – $15,000	2–4 weeks

This stage includes:

AI interaction flows
prototypes and wireframes
predictive interface design
accessibility considerations

3. AI Model Development

This phase builds the core intelligence of the application.

Component	Estimated Cost
AI Model Development & Training	$20,000 – $50,000+
Backend Development	$10,000 – $50,000+
MVP/Core Development	$15,000 – $35,000+

Tasks include:

dataset preparation
model training and tuning
API development
database architecture

4. Testing & Quality Assurance

AI apps require extensive validation to ensure reliability.

Phase	Estimated Cost	Timeline
QA & Testing	$5,000 – $15,000	2–4 weeks

Testing includes:

model accuracy validation
load testing
security checks
edge case testing

5. Deployment & Launch

Once tested, the AI application is deployed to cloud infrastructure.

Phase	Estimated Cost	Timeline
Deployment	$5,000 – $20,000	1–2 weeks

Deployment includes:

cloud hosting setup
model serving infrastructure
monitoring and analytics

6. Maintenance & Optimization

AI apps require ongoing improvements to maintain accuracy.

Phase	Cost
Ongoing Maintenance	15–25% of development cost annually

Maintenance activities include:

model retraining
performance tuning
infrastructure scaling
security updates

11 Factors That Influence AI App Development Cost

Several variables determine the final development cost.

1. AI Feature Complexity

Basic chatbots cost less than advanced systems like predictive analytics or generative AI.

2. Data Requirements

AI systems rely heavily on clean, labeled datasets, which may require extensive preparation.

3. AI Model Selection

Using pre-trained models is cheaper than building custom models from scratch.

4. Technology Stack

Frameworks like TensorFlow, PyTorch, and LangChain influence development cost.

5. Integrations

Integrating with CRMs, ERPs, payment gateways, or IoT devices increases complexity.

6. Development Team Expertise

Hiring specialized AI engineers, data scientists, and ML engineers raises costs.

7. Infrastructure

AI workloads require high-performance GPUs or cloud environments.

8. Compliance & Security

Industries like healthcare and fintech require strict regulatory compliance.

9. Deployment Strategy

Multi-platform apps (web, iOS, Android) require additional development effort.

10. Maintenance Requirements

AI models degrade over time and require retraining.

11. Geographic Development Costs

Hourly rates vary significantly across regions:

Region	Average Hourly Rate
Asia	$30 – $60
Eastern Europe	$50 – $90
USA	$120 – $145

Hidden Costs in AI App Development

Many teams underestimate ongoing costs.

Hidden expenses include:

Cloud hosting and GPU usage
API subscription costs
model retraining
monitoring tools
marketing and user acquisition

These costs can account for 15–50% of the total investment.

How to Reduce AI App Development Costs

Smart planning can reduce development expenses without sacrificing quality.

Start with an MVP

Build a minimal version first to validate the product idea.

Use Pre-trained Models

APIs from providers like OpenAI can reduce development time.

Use Open-Source Frameworks

Libraries like PyTorch, TensorFlow, and Hugging Face accelerate development.

Use Cloud Infrastructure

Cloud platforms eliminate the need for expensive hardware.

Adopt Agile Development

Iterative development reduces risk and improves efficiency.

AI vs Traditional App Development

AI applications differ significantly from traditional software.

Feature	Traditional Apps	AI Apps
Logic	Static rules	Data-driven models
Personalization	Limited	Real-time personalization
Improvement	Manual updates	Continuous learning
Automation	Low	High

This ability to learn and evolve is what makes AI-powered applications so powerful.

Final Thoughts

AI is reshaping the future of digital products. Businesses that invest in AI-driven applications today gain a significant competitive advantage.

While AI app development costs can range from $30K to $500K+, the long-term value often outweighs the initial investment.

With the right strategy—starting with an MVP, leveraging pre-trained models, and partnering with experienced developers—you can build a scalable AI product without overspending.

💡 Planning to build an AI-powered app?

Working with experienced AI developers can help you optimize costs, reduce risks, and launch faster.

Learn more:

https://geekyants.com/blog/ai-app-development-cost-a-complete-guide