How Long Does It Take to Develop an AR Mobile App?

Ask ten studios how long an AR build takes and you'll get ten different numbers, most of them cheerful. AR app development time is hard to quote honestly because the camera layer is the small part. The weeks go somewhere else, into 3D content, device testing, permissions, hardware behaviour and decisions nobody made early enough.

AR builds rarely slip because the camera work is hard. They slip because decisions arrive late.

We've watched a project that should have been on the store in three to four months run for twelve to fourteen and never launch at all. That was a well-funded sports club app for managing finances, games, schedules and players across several sports. The budget almost doubled. None of it surprised us, because we'd forecast exactly that outcome near the start and written it down.

So this isn't a single number. It's a map of where the time actually goes, based on the projects we've run and the ones we've watched drift. Some of those stories are uncomfortable to tell, and they're the useful ones. A timeline you can hold to comes from understanding what's inside the build, what you're going to argue about, and what you're willing to leave out of version one.

The Honest Answer: Typical AR App Timelines by Project Type

AR isn't one thing, so the honest answer starts by splitting it up. A packaging trigger that plays a video is a different animal from a room-scale furniture placement tool with a content system behind it. The table below is how we'd plan each of them, assuming a client who makes decisions when asked.

Where AR app development time goes

Those windows line up with what's published elsewhere. A SLAM and location-based AR app built around one realistic 3D model, a luxury superyacht, took two to three months and cost between $43,000 and $98,000, according to ITRex Group. That's a single object, carefully made, with no catalogue behind it. Multiply the objects and you multiply the calendar.

What Actually Sits Inside an AR Build

People picture the AR bit and forget the app around it. Underneath the camera view you've still got onboarding, accounts, a content system, analytics, offline states, error handling and a way to update the 3D content without shipping a new build. That ordinary app work takes the same time it always takes, and the AR sits on top of it.

There's also the question of whether AR is being bolted onto something that already exists. We worked on a wellness genetics product where a luxury-looking design was handed to developers who were working with a functional, older codebase. The handoff went through an intermediary designer, which put more distance between what was intended and what got built. The gap between the design and what the code could support created real rework, and rework is just time with a different name.

As Simon puts it, "it can sometimes be tricky to apply existing code and put a new kind of interaction layer on top. It can be done, but you just need to be very careful." AR is that interaction layer at its most demanding. It wants camera access, sensor data, decent rendering performance and a memory budget the old app was never written for. Plan for that honestly and the estimate holds. Assume it's a feature you can drop in and it doesn't.

Discovery: The Weeks That Shorten Everything After Them

Discovery feels like the part you can trim when the launch date is tight. It's the part that shortens everything after it. We worked with a property developer building a concierge app for high-rise properties, and they came in with a budget already set and a clear picture of what they wanted. What they really wanted from us was a nod of agreement.

We convinced them to run a proper discovery phase instead, with focus groups and user workshops. What we found was that the product needed to be much simpler than they'd imagined. A lot of the features they'd planned never got built, and the focus moved to creating a human connection with the product rather than replacing systems the building already had. Better product, lower cost, shorter build.

Discovery doesn't add weeks to a project. It decides which weeks you're going to spend twice.

Skipping it has a price tag we can put a number on. On a dating app built around verified profiles and bot prevention, the client wanted to skip discovery for messaging and concentrate on onboarding. We built a generic messaging feature that allowed automated and fake messages, which contradicted the whole premise of the product. The section had to be rewritten, at roughly £15,000 of extra budget and two months of extra work. Nielsen Norman Group puts the reduction in project failure risk at around 75% when teams invest properly in discovery, which matches what we see.

Designing for Three Dimensions Takes Longer Than Screens

Flat screens are forgiving. You draw a layout, you agree it, you build it. AR design has to work when someone is standing in a kitchen holding a phone at a strange angle in bad light, so a static mockup only tells you part of the story. We build small prototypes early for that reason, because an AR interaction can't really be signed off from a flat image.

Sign-off is also where projects quietly lose months. On a fitness and wellness product with two co-founders who were new to app development, we had a repeated cycle of getting design sign-off, starting to build, and then having the clients walk the approval back. They'd say they hadn't understood that this was what would actually get built. There was no real agreement between the two of them, and approval was given to be polite rather than as a decision.

We warned them repeatedly that budget was going into design iterations that wouldn't materially improve the product. That advice didn't land. The project never got past the design and research stage because the money ran out first, and nothing was ever built. For AR work specifically, that pattern is more expensive again, because every design loop drags 3D assets along behind it.

3D Assets, Models and Content Production

This is the line item that surprises people. A single good 3D model takes a 3D artist one to three weeks and costs between $2,000 and $6,000, according to ITRex Group. That's one model. If you sell skincare in forty SKUs and you want them all placeable on a bathroom shelf, you've just described the longest thread in your schedule, and it runs in parallel with everything else or it doesn't finish.

Asset work also has a quality cliff. A model that looks fine in a product render can look plasticky and weightless when it's sitting on a real worktop next to real objects. Getting the materials, scale and lighting right is iterative, and each round of feedback costs days rather than hours. Fashion and homeware brands feel this hardest, because fabric and texture are exactly where cheap models fall apart.

Start 3D asset production in week one, before the interface is finished. Modelling is the longest lead time in most AR builds, and it's the one thing you can't compress at the end.

Decide early how assets get updated after launch. If every new product needs a developer and a new app build, you've created a permanent tax on your own team. A content system that lets the brand upload and swap models is more work upfront and far less work forever after.

Device Compatibility and the Hidden Testing Burden

ARKit and ARCore don't behave identically, and ARCore devices vary wildly among themselves. A placement that's rock solid on a recent iPhone can drift badly on a three-year-old Android handset with a weaker camera and no depth sensor. Deciding which devices you support is a scheduling decision as much as a technical one, and it needs making before the build starts.

Coordination makes that harder when the work is spread out. On a baby monitor product, the build sat across a consortium of teams in the UK, elsewhere in Europe and further afield. Keeping everyone aligned on what the product could actually do, and what each team needed from the others, was a constant job. Distance between teams shows up in a timeline as waiting, and waiting is invisible until you add it up.

Our usual approach to cutting the testing burden comes down to a few decisions made early.

• Name a supported device list in writing, with a minimum OS version.
• Pick two or three low-end Android handsets as the real benchmark.
• Define what happens on unsupported devices rather than hiding the feature.
• Test performance and heat on long sessions, not thirty-second demos.

Testing AR in the Real World, Not the Office

An office is the worst place to test AR. The lighting is even, the surfaces are flat and matte, and everyone's holding a flagship phone. Take the same build into a shop floor, a conservatory in full sun or a dim hotel room and it behaves like a different product. Real-world testing has to be in the schedule as its own phase, with time to fix what it finds.

Sometimes you have to build the conditions yourself. On the baby monitor project we had no access to the physical hardware or test devices, so we created our own version of the monitor to work against. We'd test all of our work against that internal rig and then hand everything over to the hardware team. It cost us time upfront and saved far more, because we weren't blocked every time the real device was unavailable.

AR that works in a meeting room has only proved it works in a meeting room, which is nobody's kitchen.

Budget two to four weeks for this on a medium build, and more if the use case is outdoors or across varied spaces. The bugs that come out of it are rarely cosmetic. They're tracking drift, overheating, battery drain and surface detection failing on carpet or glass, and each one needs proper engineering time rather than a quick patch.

Hardware, Sensors and Third-Party Integrations

The moment your AR app talks to something outside the phone, the estimate changes shape. On the baby monitor work, the client was building the physical cameras and sensors alongside the companion app. Everyone assumed off-the-shelf Bluetooth protocols would carry it. The integration turned out to be far more complex than anyone had planned for.

We ended up formally defining the contract between the software and the hardware. That document set out exactly how the app would turn things on and off, pull sensor data and get camera feeds, all in a format the app could actually use. Writing it took real time. Not writing it would have cost multiples of that in guesswork, failed handovers and rebuilt code on both sides.

Third-party services behave the same way. Product data, stock levels, payment, analytics and any AR platform you're licensing all come with their own documentation quality, rate limits and surprises. Space-O Technologies estimates that API documentation alone adds 10% to 15% to total project cost, which sounds like overhead until the week you spend reverse-engineering an undocumented endpoint. Build integration spikes into the early weeks so the unknowns surface while there's still room to react.

Scope Creep: The Single Biggest Cause of Overrun

Scope creep rarely arrives as a big request. It arrives as a series of small, reasonable-sounding ones, usually in meetings called to make the product smaller. On the sports club app, every refinement session we ran to narrow a feature down ended with the feature bigger than before. Stakeholders used those sessions to introduce requirements they'd never mentioned, and each one came wrapped in "of course it needs to do this".

Simon's account of it is blunt. "Every time we go in and we start to refine a feature down, it's like well of course it needs to do this, of course it needs to do that, which is something we'd never talked about before. And they were adamant that they wanted it to fit into the product specs." The refinement process had become a machine for expansion.

We warned them early that the budget would get wildly out of control and that they risked running out of money before anything shipped. The warnings were noted and then ignored. They burned through the entire budget adding feature after feature, never got anything onto the store, and we parted ways at the end of it.

Give every new request a price in weeks, in writing, at the moment it's raised. Features that sound free in a meeting stop sounding free when they carry a date attached.

Budget and Timeline Are the Same Conversation

You can have a small budget or a premium experience. Holding both at once is where projects break. We worked on a football-focused social media app where the client asked for a streamlined MVP-style first release but expected the polish of something several times the price. A lower budget means less flexibility and a hard focus on getting something launchable out quickly. This client wanted the low budget without the limitations that come with it.

We had multiple conversations trying to line up the expectation with the financial reality. The product did get finished, with compromises on features, because the client chose to spend budget on areas our team considered lower priority. Those were their calls to make. The cost showed up as things they'd wanted that never made the build.

Underestimating is close to universal. Agile Soft Labs, drawing on more than 200 MVPs they've built themselves, reckons founders underestimate MVP development time by two to three times. That's their own project experience rather than independent research, but it matches the shape of what we see. For AR the multiplier is harsher, because 3D content and device testing both scale with ambition.

Release Strategy: Why All-or-Nothing Launches Slip

The sports club app had funding, a real market and a capable team. What it didn't have was a release strategy. From the start the client rejected any incremental approach. We advised launching with one sport, on one platform, as an MVP, and getting it in front of real users. They pushed back through the entire process.

Simon's summary is worth quoting in full. "The client pushed back entirely through the whole process saying that they wanted to launch everything. They didn't want to launch until everything was ready. They didn't want to launch with a single sport. They didn't want to launch on a single platform first. They didn't want to do an MVP. They wanted everything." Three to four months of work became twelve to fourteen, and nothing ever shipped.

A product that refuses to launch small often ends up never launching at all.

AR gives you an obvious first slice. Pick one product, one room type or one in-store trigger, ship it, and watch how people hold the phone. The learning from two weeks of real usage beats another two months of internal debate, and it gives you a reason to cut the features nobody touched.

Store Submission, Soft Launch and Announcing a Date

Review time is short and predictable now. Lowcode Agency puts Apple's average at 24 to 48 hours, with first submissions and major updates stretching to around 72. The risk isn't the queue. It's rejection for camera permission wording, privacy labels or a feature a reviewer can't reach, and each round trip costs a day or two you hadn't planned.

Build structure around who can ship what. On a social football product, the client held the App Store Connect Account Holder role because the account was registered in their name. They gave us admin access to most of it, and we set up three testing groups, one for our team, one for the client, and an external QA beta group for their testers. As launch approached, the client started manually sending already-uploaded builds to whichever group they fancied, which caused problems we had limited power to prevent.

Then there's the date itself. On a gaming app for art enthusiasts and on a grassroots football product, both clients ignored our advice to avoid announcing fixed dates before a soft launch. Both picked arbitrary dates and drip-fed social posts carrying them. Both hit development changes, missed those dates, and had to publicly backpedal while their marketing spend went nowhere.

Post-Launch: Keeping Pace With ARKit and ARCore

An AR app isn't finished at launch in the way a content app nearly is. Apple and Google update their AR frameworks on their own schedule, and each major OS release brings new device capabilities, deprecated APIs and occasional behaviour changes in tracking or occlusion. A build left alone for eighteen months starts looking dated next to competitors who kept up.

We'd plan for a maintenance commitment from the first conversation, not as an afterthought once the budget's spent. Realistically that means a few days a month for framework updates and device testing, plus a larger block around each autumn OS release. Treat it as part of the cost of running an AR product rather than an unexpected bill.

There's an upside to staying current. New capabilities arriving in ARKit and ARCore often let you delete code you wrote to work around their absence, which makes the app lighter and faster. Teams that keep pace tend to find their AR app development time for new features drops over the years, because the platform is doing more of the heavy work.

Hold back a slice of the budget, around 15% to 20%, for the three months after launch. The real feedback arrives then, and you'll want the means to act on it.

How to Build a Timeline You Can Actually Hold To

The projects that hit their dates aren't the ones with the most optimistic plans. They're the ones where the hard decisions happened early and stayed decided. Here's the order we'd work in.

1. Run discovery properly, including real users, before anything is estimated.
2. Write down the supported device list and the minimum OS version.
3. Start 3D asset production immediately, in parallel with design.
4. Prototype the core AR interaction on a real phone in week two or three.
5. Agree one feature set for version one, with a written change process.
6. Soft launch to a small group, then set the public date.

Two of those carry most of the weight. The property developer's concierge app got better and cheaper because discovery was allowed to change the brief rather than confirm it. The dating app cost an extra £15,000 and two months because discovery was skipped on one component and the result contradicted the rest of the product.

The last point matters more than it looks. Once a date is public, every decision after it gets made under pressure, and pressure is where scope arguments are lost. Keep the date private until you've seen the product work in real hands.

Conclusion

A realistic answer to how long an AR mobile app takes runs from around six weeks for a simple marker-based experience to eight months or more for a full AR platform with a content system behind it. Most lifestyle brand projects land somewhere in the middle, at three to seven months. The range exists because the variables are yours, not ours.

What we've learned from the projects above is that AR app development time is mostly a function of decisions. The property developer let discovery reshape their product and got a better one for less money. The dating app client skipped it on one feature and paid for a rewrite. The sports club app had funding and a market and spent twelve to fourteen months adding features instead of launching, while we warned them in writing that exactly this would happen.

So the useful question isn't how fast we can build it. It's which version of it you can get into real hands first, and what you're prepared to leave out to make that happen. That conversation takes an hour and saves months.

If you're weighing up an AR build and want a straight read on the timeline, let's talk about your AR project.

Frequently Asked Questions