Hybrid to native app migration: lessons from Swiggy's rebuild

Swiggy's engineers expected native code to improve latency, performance and crash rates. What surprised them was the business effect: "a meaningful uptick in conversion and a reduction in bounce rates", in the words of engineer Shashwat KN in Apple's developer story on the Instamart and Dineout rebuild. Apple does not publish a single figure behind that claim. If you are weighing a hybrid to native app migration, this post separates what Swiggy actually said from what it did not, sets it against Shopify's migration, which did publish numbers, and gives you the tests we use to decide whether a rewrite is worth it.

What Swiggy changed, and what Apple did not say

Swiggy Food has always been native; Instamart and Dineout began as hybrid experiences. According to senior engineering manager Agam Mahajan, the team saw "clear limitations in performance and stability" as those businesses scaled, and in early 2024 decided to move them to native apps built with a combination of Swift and SwiftUI.

Assistant vice president Tushar Tayal named the problems precisely: on Instamart, "high page load times, app hangs on large SKU lists, memory pressure, and inconsistent animations"; on Dineout, rich restaurant images and video that were "constrained in a hybrid setup". The team also wanted all three businesses on one design system, and access to platform features such as Core Animation and Apple Intelligence.

Three things the story does not tell you are worth stating before anyone quotes it in a planning meeting:

• No numbers. Swiggy reports "improvements in engagement, completion rates, and app ratings" and faster loads, smoother scrolling and more fluid animations, "especially on older devices". Apple publishes no percentages, load times or crash rates for any of them.
• No hybrid stack. The story says "hybrid" without naming the technology, so it does not tell you whether Swiggy moved from web views, React Native or something else. Do not read it as a verdict on any particular framework.
• No total timeline. Swiggy "shipped our first native experiences within weeks and completed the broader transition", but the story gives no end date or team size. It is also an Apple developer story about Swiggy's iOS team, so it says nothing about Android.

None of that makes the story wrong. It makes it a qualitative account from the team that did the work, published by the platform owner, and it should be weighed as that.

How the hybrid to native app migration was sequenced

The most useful detail in the story is the order of work, not the outcome. Mahajan says the first step was "identifying high-impact journeys rather than attempting a full rewrite." Swiggy rebuilt the Instamart and Dineout home and search experiences first, "where most customer interactions happen", then followed a phased approach.

Incremental native migration, screen by screen

Screen-by-screen migration works because it gives you a comparison while both versions exist. You can ship the native home screen, keep the hybrid checkout, and watch whether the metrics you care about move before committing the next journey. It also limits the blast radius when the native build has a bug the hybrid one did not.

The cost is running two systems at once. Engineer Aviral Garg describes it directly: the team "had to continue shipping new features in parallel while migrating, which required clear ownership and careful coordination between hybrid and native systems." Plan for that coordination explicitly; it is where incremental migrations stall.

Two mistakes Swiggy corrected along the way

Garg names two course corrections that we would put in any migration plan from day one. First, the team "leaned toward ideal implementations, which slowed execution", and corrected by prioritising iterative delivery. Second, they "initially replicated the existing UI in native, but later pivoted to adopting native design patterns with minor adjustments", which improved reuse and sped up development. Pixel-copying a hybrid UI into SwiftUI gives you native code with hybrid-era design constraints.

Is native faster than hybrid? What Shopify measured

Shopify's Shop app migration is the counterweight to Swiggy's story, because it publishes figures. Shopify moved from React Native, not a web-view hybrid, to Swift and Kotlin with SwiftUI and Jetpack Compose. We covered why Shopify reversed its React Native bet in React Native vs native in 2026; here are the results it reported.

Measure	React Native	Native	Change
Cold start to home feed, iOS	3,200 ms	2,466 ms	23% faster
Cold start to home feed, Android	4,433 ms	2,233 ms	50% faster
Session stability	99.5%+	99.95%+	10x fewer crashing sessions
Release build size, Android	293 MB	184 MB	−109 MB (−37.2%)
Release build size, iOS	67 MB	68 MB	+1 MB (+1.5%)

Shopify also reports Android release build time falling approximately 75% while iOS builds take about the same time, and the native Android app reaching 120 FPS while scrolling the feed on a Pixel device. Notice the unevenness: iOS gained less than Android on startup and nothing on size or build time. "Native is faster" was true for Shopify, but by how much depended on the platform.

Shopify is also explicit about why it moved when it did. Adopting React Native's New Architecture would have meant revisiting native modules, rendering and the shared-code boundary anyway, and "advances in coding agents changed the tradeoffs behind maintaining a shared mobile codebase." One engineer spent a week with coding agents on a SwiftUI proof of concept; a core group of six engineers then built the foundations and main journeys, and the rebuilt app reached the stores 12 weeks after the proof of concept. Shopify preserved sign-in, push notifications and the analytics events downstream systems relied on, and retired some screens along the way.

When to move from hybrid to native, and when not to

Read together, the two stories give a usable test. Both teams moved because of specific, observed problems on specific journeys, not because native is better in general. Swiggy named load times, hangs on long lists, memory pressure and media-heavy screens. Shopify named startup time, stability and a framework upgrade it would have had to pay for anyway.

A migration is worth scoping when most of these are true for your app:

1. You can point to a journey, such as home, search or a long catalogue list, where performance problems show up in your own telemetry.
2. Those journeys carry the conversion you care about, so a faster screen plausibly moves revenue.
3. A meaningful share of your users are on older or low-memory devices; Swiggy says the difference was "most pronounced" there.
4. You need platform features the hybrid layer makes awkward, such as Swiggy's OCR menu search and on-device Apple Intelligence summaries. We looked at that on-device option in our Foundation Models framework guide.
5. You already face a large upgrade or rewrite of the hybrid layer, as Shopify did with the New Architecture.

It is the wrong move if your slow screens are slow because of the API behind them, if your team has no native iOS or Android experience to review what gets built, or if you cannot fund two platform codebases after the migration. Shopify says plainly that "building separately for iOS and Android still has costs", and it now has to enforce iOS and Android feature parity through process rather than a shared codebase. It also found that native expertise "remained essential": agent-generated code could meet requirements while "introducing duplication, architectural drift, or performance problems."

How long does a native migration take?

A native migration takes as long as the journeys you choose to move, and neither public account gives a figure that transfers to your app. Shopify's 12 weeks came from a six-engineer core team with coding agents and a working React Native app to copy from, and it did not include the proof of concept week. Swiggy's first native screens shipped "within weeks", with the rest phased after. What both share is a small first step you can measure: one journey rebuilt, instrumented, and compared against the old version before the next one starts.

The cost of rewriting an app in native is mostly the cost of parity: behaviour, analytics events, sign-in and push must all survive the switch, and that has to be verified journey by journey. Shopify built dedicated tooling to compare screenshots and event payloads between the old and new apps for exactly this reason.

What to measure before you migrate a hybrid app to native

Shopify compared the native apps with their React Native predecessors on five measures: startup time, session stability, app size, build time and rendering performance. It defined startup precisely, from tapping the app icon until the initial home feed content is visible. That is a good baseline set for any migration, because it covers what users feel, what the stores and devices penalise, and what your own team pays in build minutes.

Swiggy's account adds the business layer: conversion, bounce rate, completion rates and app ratings. Capture all of these for the journey you plan to move before you touch it. Without a before, the after is an anecdote, which is exactly the limit of the Swiggy story as published. Swiggy also credits the move with easier component reuse and one design system across three business lines; if that matters to you, count reused components too, not only milliseconds.

The decision in front of you is not "hybrid or native". It is which one journey to rebuild first and which number will tell you it worked. Pick the journey where your telemetry shows the problem, write down the metric before you start, and only commit the second journey when the first one moves it. If you want help scoping that first journey, that is mobile app development work we do, including iOS app development, and we will tell you if the numbers say not to migrate.