Get in touch:

Thinking through a new idea or stuck with a challenge? Drop us a message—we'll listen, brainstorm, and help move things forward.

What Counts as "AR in a Mobile App"

In a mobile app, augmented reality uses a phone's motion sensors and camera to insert computer-generated material into a live image of the user's physical environment. The material is anchored, remaining in position while the phone moves. Maintaining that anchor — not drawing the content — is the challenging work supplied by platform SDKs.

Nearly every commercial AR feature fits one of four patterns: see a product in your surroundings, take a measurement, try an item on, or work through instructions displayed as an overlay. Anything beyond those patterns is a demonstration.

Your first meaningful choice is among four ways to deliver it:

Most teams ought to begin with the first route. Almost every article about "AR in mobile apps" overlooks it: because no AR code is written, it produces an unappealing case study.

Our take: clients most often make a scoping mistake by requesting "an AR feature" when their actual requirement is a 3D product viewer with an AR button. For only the price of model production, AR Quick Look and Scene Viewer deliver exactly that — without an SDK, session management or a custom camera-permission flow. When the use case is covered, replacing it with a bespoke ARKit session adds several months of work for very little benefit.

The Popular Statistics — and Those That Withstand Scrutiny

AR's own evidence base is exceptionally poor, which is why this section is necessary. The same four figures appear repeatedly in the AR sales decks we encounter. We followed each one back to its source.

The final row merits a closer look, as the corrected version is more revealing than the misconception. According to Statista's series, the mobile AR user base moves from 1.03 billion in 2024 to 1.07 billion in 2025, before reaching a projected 1.19 billion by 2028. That is less than 4% annual growth and an almost level forecast period. Rather than merely being below the widely repeated number, the genuine figure portrays a mature user population expanding slowly — not a land grab.

Two additional entries need fuller treatment than a single row permits.

The Shopify figure rests on a failed chain of citations. Among AR statistics it is repeated especially often, yet its origin is promotional. When accessed on 14 September 2026, Shopify's current page had substituted merchant-specific figures: Rebecca Minkoff says users who see a 3D model are 44% more likely to add to cart and 27% more likely to place an order, while those viewing in AR are 65% more likely to purchase. At least a merchant is identified, although sample sizes and control groups remain absent. At the same time, a heavily cited Snap post assigns the 94% result to a Harvard Business Review piece on pandemic retail — but that piece does not include it. No business case should rely heavily on a statistic when its most common secondary citation directs readers to a primary source where it cannot be found.

The returns figure lacks any identifiable starting point. That is important because return reduction is AR's strongest commercial proposition. We could not trace any version of the 25–40% number to a source dataset. There is, however, peer-reviewed research: Deepa and Venkatesan, article 1769831, published by Frontiers in Communication on 25 February 2026. Applying PLS-SEM to 209 online shoppers, it found that AR adoption significantly mediated return-prevention behaviour in statistical terms, with the model accounting for roughly 21% of the variance. This is genuine support for an association that deserves measurement in your own funnel. Yet it does not express a reduction percentage at all — variance explained is not the same as returns prevented — and the self-reported sample is small and comes from one country. A defensible conclusion is that AR may reduce returns, but no credible published figure establishes the amount.

Forecasts conflict over how large the existing market is

AR decks also routinely feature market-size statistics. Although these are legitimate research outputs, presenting just one creates a highly misleading impression that the field has reached a settled view.

The discovery is in the ranking, so examine the order. In report SE 2288, published March 2026, MarketsandMarkets values the combined augmented reality and virtual reality market at $89.36bn in 2025 and forecasts $268.58bn by 2032, implying an 18.4% CAGR. For AR alone, Precedence Research — updated 26 August 2026 — places 2025 at $149.57bn and 2034 at $2,804.82bn, with 38.5% growth. Between the two sits Grand View Research: AR alone is $120.2bn in 2025, then $1,050.56bn by 2033 at 29.7%.

In other words, one established firm's combined AR and VR estimate is lower than the AR-only totals from the other two. This is not dishonesty. Each draws the perimeter differently, particularly around enterprise software, services and related hardware counted as "AR"; the headline figures reveal none of those boundaries.

We found another issue only after checking the calculations. The endpoints published by the firms fail to reconcile with two of the three CAGRs. Precedence is internally consistent: applying 38.5% growth to $149.57bn for nine years produces almost precisely $2,804.82bn. However, moving from Grand View's $120.2bn to $1,050.56bn during 2025–2033 works out at about 31.1% annually, rather than its stated 29.7%. Likewise, the MarketsandMarkets move from $89.36bn to $268.58bn during 2025–2032 implies close to 17.0%, not 18.4%. The likeliest explanation is that full reports use hidden conventions for the base year and period, rather than that the figures are mistaken. Still, that information is unavailable in the headlines. And that is precisely the concern: when a figure cannot be derived from the accompanying published figures, it does not belong in a board pack.

All three sources justify saying that AR is expanding. Use them for that conclusion, but not to quantify a business case; treat any deck citing only one with caution.

Figures that survive the check

The clearest proof of large-scale mobile AR use comes not from projected research, but from an operator disclosing its own usage. In Snap's Q1 2026 investor letter, the company writes:

"More than 75% of Snapchatters are engaging with augmented reality every day on average, and our community uses Lenses in our Snapchat camera 9 billion times per day on average."

It also records 483 million daily active users, 956 million monthly active users, and "more than 400,000 Lenses submitted in Q1, increasing more than 150% year-over-year." These are operating measures disclosed to investors by a public company, which is a substantially stronger evidential bar than promotional webpage copy. That is why we give them priority over an assertion about conversion uplift.

The figures are not completely current: they cover January through March in Q1 2026. Released on 3 August 2026, Snap's Q2 2026 results release lists 493 million daily active users and a 19% rise in revenue, yet does not repeat the AR engagement statistics. Consequently, the strongest publicly available large-scale mobile AR dataset trails by one reporting period.

A second well-sourced indicator of demand is the Deloitte Digital and Snap consumer study. Unlike most work in this area, it disclosed its method: a 20-minute online questionnaire completed by 15,000 consumers in 15 countries, supplemented by more than 50 interviews with experts. Among respondents, 56% said AR increased their confidence in product quality, and 41% were more inclined to consider a brand that supplied AR. Its age needs emphasis, however: it dates to May 2021. The fact that the soundest consumer survey available is five years old says much about the quality of this evidence base.

For product teams, the conclusion is more limited than "AR is huge." The form of AR achieving enormous scale is camera-effect AR — lenses and facial filters — not product placement anchored in physical space. Engineering requirements and costs differ between them, so evidence about one cannot simply be applied to the other.

The Platform Landscape in 2026

The news in this section is genuinely positive, and it contradicts much of what is currently being published.

ARCore is actively maintained

Several 2025–2026 articles suggest that ARCore is being wound down. The evidence says otherwise. Ten days before this article, Google released ARCore v1.56.0 on 4 September 2026. That release added AcquireDepthImageMeters and AcquireRawDepthImageMeters, exposing depth data in metres as floats, while also moving targetSdkVersion to Android API level 37. This year's dated releases were v1.53.0 (10 March 2026), v1.54.0 (22 April 2026) and v1.56.0 (4 September 2026); on that page, v1.55.0 does not appear as a separately dated release.

What seems to have caused the confusion is the recirculation of real deprecations that were completed long ago. NDK camera image access was removed in November 2022, while the old Cloud Anchor endpoint stopped working on 31 August 2023. Both events are now three-plus years old.

Last updated 4 September 2026, the Geospatial API page contains no deprecation notice. A published deprecation policy governs Cloud Anchors and promises "commercially reasonable efforts to continue to operate these services for one year after" any discontinuation announcement. We found no such announcement.

ARKit's most interesting change is arriving from the headset

Because ARKit is bundled with iOS rather than versioned independently by Apple, "ARKit 7" is not a real product version. On 9 September 2026, Apple's release feed showed iOS 27.0 as Release Candidate (build 24A435), and general availability is expected around this article's publication date. Before depending on any iOS 27 detail here, verify the current build.

The major development was announced at WWDC26. During session 287, Apple said:

"To bring object tracking to iOS, we're releasing an ARKit API that supports the same functionality as visionOS."

On training, it added:

"We designed the ML model training in Create ML to be platform agnostic. This means once you create a reference object, you can use it in both your iOS and visionOS app and get the same level of tracking quality."

The feature that enables viable industrial and field-service AR is object tracking: recognising a particular physical object, then following its pose. It is also another example of machine learning moving into the mobile toolchain. Having debuted on the headset, the capability is now moving to the phone, and the same trained reference object works on both. Since Apple did not specify an iOS version for the API in that session, describe it as a WWDC26-cycle capability rather than as an iOS 27 feature.

In its WWDC26 update, RealityKit (session 279) gained lightmaps and soft shadows, a navigation-mesh system, cloth simulation, level-of-detail based on camera distance and screen area, thermal state monitoring, and first-class support for Gaussian splats (GaussianSplatResource, GaussianSplatComponent). For phones, the additions to watch are LOD and thermal monitoring. Both address the practical field constraint on session duration: handsets overheating during sustained AR use.

The tooling market consolidated hard

For any stack choice being made this quarter, this section has direct consequences.

The statement on 8th Wall's own site is unambiguous: "All paid subscriptions ended on February 28, 2026 when the hosted platform was retired." Visitors to 8thwall.com are now redirected to 8thwall.org; there, the XR Engine is available as a free binary and the utilities carry an MIT licence. Because a paid tier no longer exists, an article that still quotes monthly pricing for 8th Wall is documenting a product that is no longer sold.

The transition is most starkly illustrated by Niantic. Having bought 8th Wall in 2022, the company was then the largest independent wager on consumer mobile AR. By 2026, Scopely owns the games, 8th Wall has become an unhosted open-source project, and Niantic Spatial offers capture, reconstruction and "vision-based positioning for machines" — in other words, enterprise geospatial AI and robotics. Lightship and ARDK appear nowhere in its current product lineup as of 14 September 2026.

The dependable cross-platform default left standing is Unity AR Foundation, which was at version 6.6.2 as of 28 August 2026 after four releases between May and August 2026. Its often-misrepresented architecture deserves attention: AR Foundation defines interfaces for AR capabilities, but implements none itself. A provider plug-in must be installed for each platform (ARKit XR Plugin, ARCore XR Plugin).

Unreal offers the contrasting case. Although handheld AR retains formal support and has no deprecation notice, the UE 5.8 AR documentation continues to cite ARCore 1.7 and ARKit 3.0, alongside feature notes that go back to UE 4.23.1. Meanwhile, ARCore is at 1.56.0. Documentation effectively frozen around 2019 makes Unity the less risky handheld-AR option — not because Epic has removed a capability, but because the map has not been updated.

WebAR: still two codepaths, not one

WebAR's most enduring misconception is that WebXR produces a single cross-platform build. It cannot, since iOS Safari does not support WebXR: according to caniuse, every release through Safari 26.6 continues an uninterrupted run of "not supported". Chrome for Android has partial rather than full support. With Apple's own webkit.org/status feature-status page retired, there is no Apple-hosted indicator left to monitor.

The practical pattern therefore remains the same, and it needs to be explicit because it determines the asset budget: AR Quick Look with USDZ on iOS, Scene Viewer with glTF/GLB on Android. Start from one 3D source model, export it twice, and support two formats through two entry paths.

Device Reach: The Ceiling Nobody Prices In

More than any market forecast, the following constraint ought to guide an Indian company's AR strategy.

From it, three practical conclusions about reach emerge.

ARCore's floor is low, and its depth support is high. At the device level, Android 7.0 is required by ARCore unless a given model specifies a newer version. In the manifest, an "AR Required" app must use minSdkVersion 24, whereas an "AR Optional" app needs 19. Read on 14 September 2026, Google's supported devices page gives its own dated figure: "As of May 2026, over 88% of active devices support the Depth API." The denominator matters. This means 88% of devices that support ARCore, not 88% of every Android handset; depth is therefore close to universal inside the AR-capable population, not throughout the market. Even so, it is a dated, first-party statistic — more than the circulating device counts can claim.

We could find no Google-published device count. Models are listed by manufacturer on the supported-devices page, which also provides a CSV download, but no total appears there; we could not find a current Google-published tally elsewhere. When articles state "1.4 billion AR-ready devices" or give an exact count of certified models, their source is something we could not trace to Google.

LiDAR remains Pro-only. Introduced with the iPhone 12 Pro in October 2020, LiDAR remains missing from the standard and budget ranges almost six years later. As read on 14 September 2026, Apple's own comparison page lists no LiDAR for the iPhone 17, 17e, Air, 16, 16 Plus or 16e. Since Apple refreshes its lineup each September, check again on the day you read this. Because LiDAR is necessary for scene reconstruction, features centred on accurate occlusion or mesh capture can reach only a Pro-tier portion of India's 7.15% iOS share.

And the Android base has its own ceiling, which we could find no published data on. For the budget and mid-tier handsets comprising most of that 92.79%, neither Google nor device manufacturers publish data on sustained-AR thermals or GPU throttling. We have not found a public dataset on it. That missing evidence should itself inform planning: at the low end, expect usable AR sessions to be shorter than tests on your own devices imply. Before committing to a design, measure session duration on a representative handset instead of a flagship.

Our take: on two occasions, we were asked to create an AR measurement feature offering LiDAR-grade precision for an Indian consumer app. In both cases, the candid advice was to accept lower accuracy and build the plane-detection implementation that works everywhere. With an Indian user base that is 93% Android, treat ARCore's Depth API as the baseline and ARKit as an enhancement — not vice versa. Teams that reverse those priorities tend to learn the lesson only after development, when the sole phone producing a good result is the demo device.

What It Actually Costs to Build

The SDKs cost nothing. That fact is exactly why budgets are misleading: it obscures where expenditure actually occurs.

The 3D asset pipeline is the real line item

Each AR product feature requires one 3D model for every SKU. This is ongoing content production, rather than a one-off engineering expense. Few published rates exist because most agencies price by quotation, making Modelry (by CGTrader) the most useful public benchmark. Its price list, read 14 September 2026, specifies $42 per model for 3D product visualisation suitable explicitly for augmented reality, plus $250 per model for customised lifestyle scenes. Beyond a free allowance of 20 GB and 10,000 monthly views, hosting begins at $13/month.

Because $42 sits below most estimates found in blogs, it serves as a more candid baseline. The arithmetic below is our calculation from a published rate card, rather than a figure taken from elsewhere:

Here, once is the crucial word. A catalogue does not stand still: each additional product, colourway or revision demands another model. Consequently, the expense belongs as a continuing content-budget item, not as capital expenditure within the build budget.

The natural response is Apple's Object Capture, free within RealityKit and Xcode: photogrammetry that converts photographs into a textured USDZ. Apple's own capture advice reveals the limitation, however. It calls for roughly 100 photographs of each object with at least 70% overlap, requires the subject to remain static, and expressly excludes reflective, transparent or translucent surfaces. Glassware, jewellery, chrome and anything wrapped in packaging film are therefore unsuitable. The software is free; the catalogue is not. That helps explain why providers charging $42 a model continue to attract buyers.

The size budget is tighter than you think

App-size constraints quickly collide with AR assets, and Apple and Google Play calculate those limits differently:

The numbers above were read on 14 September 2026 from Apple's maximum build file sizes reference and Google Play's app size documentation. On Apple, the 200 MB threshold triggers consent rather than imposing a barrier: users select either "Always Allow" or "Ask If Over 200 MB". Even so, an extra consent tap is a measurable install-funnel drop-off point. Also remember that Apple's 4 GB maximum refers to the uncompressed size, whereas Google uses compressed download size, so a direct comparison is invalid.

Across our own projects, production exports before Scene Viewer optimisation have ranged from approximately 5 MB to 50 MB apiece. Google's documented 15 MB Scene Viewer maximum does not apply to these: assets shipped inside an app are not bound by that viewer's limits. A few dozen heavy SKUs bundled together can cross the 200 MB threshold unaided; lightweight assets require several times as many. The remedy does not change: instead of including models in the base binary, distribute them as downloadable packs using Play Asset Delivery on Android and On-Demand Resources on iOS.

Google documents its limits. Apple does not.

An exceptionally detailed specification appears in Google's Scene Viewer documentation: glTF 2.0/glb supporting the KHR_materials_unlit and KHR_texture_transform extensions; a recommended size of 10 MB and a maximum of 15 MB; 100,000 recommended triangles, with 30,000–50,000 identified as ideal; no more than 10 materials, of which two can use alpha; texture dimensions capped at 2048×2048; 254 bones; four bone weights for each vertex; one UV for every mesh; sRGB; PBR; HTTPS-only loading; and one unit representing one metre.

We could not locate a numeric Apple equivalent. The newest guidance that remains retrievable comes from WWDC21 session 10078 and stays qualitative: "There's always a tradeoff between visual fidelity and file size," followed by advice to export both Reduced and Medium detail, then compare them.

That gap matters because confident claims about "Apple limits" proliferate online: USDZ below 50 MB, 100,000 vertices and 2048×2048 textures, none of which we could trace to an Apple source. One of them is demonstrably Google's, whose published Scene Viewer texture maximum is 2048×2048. Another — the assertion of "100,000 vertices" — resembles Google's 100,000 triangles, but those are not the same measurement. We could not trace the 50 MB number to anything either platform publishes. Fortunately, the operational conclusion is straightforward: budget against Google's published ceiling, since it is both the stricter limit and the only one documented. Just do not present it to a client as an Apple requirement.

The Review-Failing App Store Rule

Guideline 4.2.1 in Apple's App Store Review Guidelines states:

"Apps using ARKit should provide rich and integrated augmented reality experiences; merely dropping a model into an AR view or replaying animation is not enough."

In other words, Apple explicitly rejects the minimum-viable AR functionality found in most briefs. A plan to build a custom ARKit feature that "lets users see the product in their room" is therefore at risk. Yet the same idea, when delivered via AR Quick Look, is precisely what the viewer was designed to do and creates no equivalent concern — one more reason the unexciting approach is frequently the correct choice.

The other rule worth knowing is guideline 5.1.2(vi): information gathered by facial-mapping and depth tools, including ARKit, "may not be used for marketing, advertising or use-based data mining, including by third parties." You cannot pass face-tracking try-on data into your advertising stack.

Where AR Pays Back, and Where It Does Not

Once the claims we could not verify are removed, this is the pattern that can be defended.

AR pays back when it prevents a return, an error, or a site visit. Think of high-consideration products for which physical fit determines the purchase — appliances, furniture, fixtures. Another case is industrial maintenance and field service, where placing an overlay on a particular machine avoids flying a technician out; Apple's announced cross-platform object tracking is aimed at this use case. It also applies to training involving equipment that is costly to remove from service. Across these examples, the benefit is an avoided cost you can measure, rather than higher conversion.

As a marketing novelty, AR is a weak wager, with the platform graveyard providing at least some suggestive evidence. Campaign AR depended heavily on Meta Spark, Adobe Aero and 8th Wall's hosted service; within 14 months, all three were gone. To be fair, every departure has a separate rationale unrelated to demand — Meta removed only third-party tooling while retaining its own effects, Niantic's restructuring reflected corporate considerations, and 8th Wall was open-sourced instead of being shut down. The category's failure is not proven by three exits. Still, anyone commissioning a one-off branded AR project should notice that the specialists serving that precise need are the vendors that departed.

Our take: before pricing AR work, we ask whether the proposed feature remains sensible after removing the term "AR" from the brief. "Let customers check the sofa fits their room" passes. "An AR experience for the product launch" fails. A measurable counterfactual exists for the former; the latter offers only a launch date, followed by nothing.

Scoping AR Without Wasting the Budget

The following order accounts for both reach limits and the underlying cost structure:

1. Begin with the platform viewers. Use AR Quick Look and Scene Viewer, supplying one USDZ and one glTF for every product. You get maximum possible reach, with no review-guideline exposure and no AR code. For plenty of catalogues, that constitutes the entire job.
2. Create several models before approving the full catalogue. At published prices, twenty hero SKUs comes to roughly $840. That small batch reveals whether customers engage with the capability and how much your actual products cost to model — expect surprises from glass and chrome.
3. Run your own measurement. Since public evidence is reported by vendors, add instrumentation for AR-view rate, AR-view-to-cart, and the return rate of AR-viewers versus a holdout. Your own six weeks of evidence is more useful than every statistic quoted here.
4. Consider a custom AR session only afterwards — if your audience is Indian, develop the ARCore route first. Make the Depth API your baseline, while treating LiDAR functionality as a progressive enhancement.
5. From day one, distribute models in downloadable packs instead of bundling them into the base binary. Waiting until the app exceeds 200 MB to retrofit Play Asset Delivery or On-Demand Resources creates needless rework.

For most teams, this does not justify keeping an AR specialist in-house indefinitely. Pipeline setup concentrates the effort into a few months, so an embedded dedicated developer is a reasonable alternative to hiring.

Want another view on which rung of that ladder fits your AR product feature? You can get in touch — if a free viewer with no app development is the right answer, we will say so. Our article about the ROI of mobile app development explains the measurement framework for the wider problem of defending spend on any mobile feature; native vs cross-platform examines the surrounding stack choice in which AR belongs.

The Bottom Line

Augmented reality's actual effect on mobile app development was not simply to make apps immersive. Rather, it turned content creation into a continuing engineering-budget item and penalised teams that backed the incorrect platform.

Each of the three changes introduced earlier remains valid, with an accompanying warning. AR shifted from a category into a feature; accordingly, built-in platform viewers should be the starting point and a custom ARKit session the final option — Apple's own review rules deem the minimum-viable form of that session insufficient. The difficulty moved from code to content: although SDKs are free, 3D catalogue assets cost $42 each at published prices and continue generating expense; Apple's free Object Capture also has a straightforward limitation, since shiny objects cannot be photographed with it. Tooling became concentrated: from January 2025 through February 2026, Meta Spark, Adobe Aero and 8th Wall's hosted service ended, whereas ARCore released on 4 September and Unity AR Foundation on 28 August — leaving the first-party SDKs and the sole cross-platform layer that maintains a meaningful release tempo.

When assessing somebody else's argument for AR, keep two additional findings in mind. The underlying evidence is less robust than sales decks imply: the most frequently repeated conversion number for AR has disappeared from the page belonging to the company that originally shared it, a widely cited article both propagated and misattributed the number, returns-reduction figures have no origin we could trace, and three credible forecasters disagree about the scale of an already-existing market. Hardware sets the upper limit, which is low in India: because Android holds 92.79%, any approach centred on ARKit and LiDAR is aimed at the Pro-tier subset of an iOS share measuring 7.15%.

Our clearest advice concerns ordering, not the choice of technology. First deploy the free platform viewers; build twenty models before ordering five hundred; instrument usage and compare outcomes with a holdout; and do not create a custom AR session until your data demonstrates demand. AR provides real utility, yet its surrounding literature is exceptionally promotional. Teams derive value when they approach it as a device-reach limitation combined with a content-supply challenge — instead of treating it as a purchasable growth metric.