DEV Community: Tyche Labs

App maintenance cost in the UK: what to budget per month

Tyche Labs — Tue, 27 Oct 2026 16:16:35 +0000

First published on tychelabs.net.

Trying to budget for an app after launch? Here is what maintenance covers, what six UK agencies publish, our own £550 a month plan and a step-by-step way to build your monthly figure.

Most app budgets stop at launch. The build is quoted, approved and paid for, and the line for what happens afterwards is either missing or a guess. Then the first iOS update breaks a screen, Apple changes a submission rule, a certificate expires, and someone asks how much it costs to keep an app alive.

This guide gives a straight answer for the UK in 2026: what maintenance actually involves, what we charge, what other UK agencies publish, and how to build a monthly figure for your own app. We publish our own iOS apps as well as building them for clients, so the examples are from apps we look after ourselves.

What "maintenance" actually means for an iOS app

An app that nobody touches does not stay the same. The platform moves under it. These are the things that need doing even when you ask for no new features:

Each year's iOS and Xcode. Apple ships a major iOS release every autumn and, some months later, requires every upload to be built with the matching tools. The current rule is that since 28 April 2026 "apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26" [1]. An app last built with older tools cannot be updated at all until it is rebuilt, and a rebuild with a new SDK usually surfaces deprecated APIs, layout changes and at least one thing that used to work.
Apple's changing submission rules. The same page lists age rating questions that had to be answered by 31 January 2026 to keep submitting updates, the requirement since May 2024 to declare approved reasons for certain APIs including those in third-party SDKs, and trader status for apps sold in the EU [1]. Each is small; each blocks the next update if it is missed.
Certificates, profiles and keys. If your distribution certificate expires or is revoked, Apple says "you'll no longer be able to upload new apps or updates signed with the expired or revoked certificate" [2]. Push notification keys, provisioning profiles and the Developer Program membership itself all have renewal dates.
The Developer Program membership. It costs 99 USD per membership year, or the local-currency equivalent [3]. If it lapses, "your apps will no longer be available for download and you won't be able to submit new apps or updates" [4]. The app disappears from the store until you pay.
Crashes and bugs. New devices, new OS behaviour and new data expose bugs that were not there at launch. Someone has to read the crash reports.
The store listing. Screenshots go out of date when devices change shape. The privacy label has to stay accurate; Apple says you are "responsible for keeping your responses accurate and up to date" and that you can change them any time without a new build [5]. Review notes, support URL and privacy policy URL all need to keep working.
Third-party SDKs. Payment, analytics, crash reporting and advertising SDKs ship updates, deprecate versions and occasionally change what data they collect, which changes your privacy label.

None of this is optional, and all of it is cheaper done on schedule than done in a hurry when an update is blocked.

If this is you right now: App care, £550 a month for one live iPhone or iPad app. We reply within one working day.

How often a new app actually changes

The textbook figure is one or two maintenance releases a year. Early in an app's life, it is much more. In the first few weeks after launch it is common to ship several updates, typically covering:

more languages, and links that open the app from the web;
a new in-app purchase or a corrected listing description;
a rating prompt and offer code redemption inside the app;
new search keywords for each storefront, updated What's New copy and localised screenshots.

Several of those changes are not features at all. A listing fix corrects a description that no longer matches what the app sells. A privacy label has to change whenever the app starts collecting a new data type, for example when analytics are added. And new strings had to be translated into every language the app ships in at once.

The point is not that every app needs a release a week. It is that the first three months after launch are the busiest period an app will ever have, and a maintenance budget that assumes a quiet quarterly update will be wrong exactly when it matters.

What we charge

Our monthly plan for a live iPhone or iPad app is App care at £550 a month, or £5,500 a year if paid yearly, which is two months free. Prices exclude VAT. It covers:

Each year's iOS and SDK update: the app rebuilt and tested with the new iOS and Xcode, and any required SDK updates made.
Keeping the app passing App Review as Apple's rules change, including privacy details and new submission requirements.
Crash and bug fixes from the crash reports we watch. A fix that needs real rework is quoted first.
Store listing and screenshot upkeep, so the listing matches the app and current devices.
Renewals of certificates, provisioning profiles and push keys before they expire, and a reminder before your Apple Developer membership renews.
Up to 4 hours of changes a month, for small features, copy changes or tweaks.
A short note each month on what we did and anything coming up from Apple.

It does not cover Apple's Developer Program fee, which you pay so the account stays yours, or new features beyond the monthly hours, or the Android version of the app, which is £895 a month for both platforms together. There is a three-month minimum term and a £500 onboarding fee, waived when we built the app; after that it is monthly with 30 days' notice.

If the app was built by someone else, we start with a takeover audit, from £650, so we know the code, the accounts and the risks before we take responsibility for it. For products that need steady new development rather than upkeep, our ongoing development plan starts at £1,500 a month for reserved build days.

What other UK agencies publish

Few UK agencies put a maintenance price on their website. These did, when we checked on 27 October 2026. We quote them so you can see the range, not to say any of them is wrong; their plans include different things from ours.

Agency	Location	Published figure
Foresight Mobile [6]	Manchester	App Care from £675 a month (Essentials), £995 (Standard), £1,495 (Premium); onboarding fee £500 to £1,000; three-month minimum
Stakk [7]	London	"between £1,500 and £8,000 per month in the UK depending on the scope"; basic retainers £1,500 to £2,500
chilliapple [8]	Tunbridge Wells and London	15 to 25% of the original build cost per year, "or roughly £1,500–£8,000+ per month for custom software"; ad hoc £60 to £150 an hour
Nordstone [9]	UK	15 to 20% of the original development cost per year; a simple MVP £5,000 to £15,000 a year
KerenLabs [10]	Manchester	15 to 25% of the build cost each year
Pixelfield [11]	London	Worked example for a small app: £9,792 a year, from 8 engineering hours a month at £80, hosting, monitoring and a 15% reserve

Two patterns stand out. Agencies that quote a percentage cluster around 15 to 25% of the build cost a year, so a £40,000 app implies £6,000 to £10,000 a year, or £500 to £830 a month. Agencies that quote a monthly price start between £675 and £1,500 for the entry tier, and those figures usually cover both iOS and Android, backend monitoring or a service-level agreement, which is why they sit above our £550 for one iOS app.

Pixelfield's worked example is the most useful comparison because it shows its working: 8 hours of engineering a month plus hosting and a reserve comes to £816 a month [11]. Our plan includes 4 hours of changes on top of the update, review and renewal work, which is where the difference lies.

How to build your own monthly figure

Start with the platform work. For an iOS app, budget for one significant rebuild a year when the new iOS and Xcode arrive, plus two or three smaller updates for Apple's rule changes and bug fixes. On a plan like ours this is what the fixed fee covers. On an hourly basis, Pixelfield's 8 hours a month at £80 is a fair planning figure for a small app [11], and chilliapple's £60 to £150 an hour shows the range of UK rates [8].
Add Apple's fee. 99 USD a year, or the local equivalent [3]. Keep it in your name.
Add hosting and services, if the app has a backend. An app that runs entirely on the device has a hosting line close to zero. An app with accounts, sync or payments is different. Nordstone suggests £100 to £300 a month for a lightweight MVP [9] and Pixelfield uses £60 for its small example and £250 for its complex one [11]. Add a line for each paid SDK or service: crash reporting, push, analytics, email, maps.
Add the Android version, if you have one. Most published monthly prices above include both platforms; ours covers iOS and quotes Android separately. Either way, two platforms are not twice the work but they are not one platform's work either.
Add a reserve for the unplanned. Pixelfield uses 15% of engineering [11]. We think that is sensible for the first year, when the surprises are largest.
Decide who does the small changes. Copy tweaks, a new screenshot, a price change, a new onboarding line. If they are in the plan, as they are in ours, the budget is predictable. If they are billed hourly, they are where the budget drifts.
Check the plan covers the moments that block you. The expensive failures are not the hours; they are the week the app cannot be updated because the certificate expired, the membership lapsed, or the build no longer meets Apple's SDK floor. Any plan worth paying for owns those dates.

A worked example for a small single-platform app on our plan: £550 for App care, roughly £6 to £7 a month for Apple's fee at current exchange rates, nothing or a few pounds for hosting, and a reserve of around £70 for the first year. Roughly £630 a month, or about £7,600 a year, with the first-year reserve dropping out after that. For an app with a backend and an Android version, the published UK figures above suggest £1,000 to £2,500 a month is realistic.

What happens if you spend nothing

We take over apps that have had no maintenance for a year or more, so we see the result. Usually the app still runs, which is why nobody noticed. Then one of three things happens: a new iOS release breaks something visible; the owner needs a change and finds the project will not build with current Xcode or will not upload under Apple's SDK rules [1]; or the membership lapses and the app leaves the store [4]. At that point the bill is the year of skipped maintenance plus the urgent fix, with the app offline while it is done.

The cheapest maintenance plan is the one that starts the month the app launches, when the code is fresh and the people who built it are still around. If that moment has passed, a takeover audit is the way back to a predictable monthly figure.

Questions we get asked

How much does app maintenance cost per month in the UK?

For one live iPhone or iPad app, our App care plan is £550 a month excluding VAT, with Apple's Developer Program fee of 99 USD a year paid by you. UK agencies that publish prices start between £675 and £1,500 a month for entry plans that usually cover both platforms, and agencies that quote a percentage say 15 to 25% of the build cost a year, so a £40,000 app implies about £500 to £830 a month.

Why does an app need maintenance if nothing changes?

Because Apple changes. A new iOS and Xcode arrive every year, and some months later every upload must be built with the new tools; since 28 April 2026 that means Xcode 26. Certificates, push keys and the Developer Program membership all expire, and if the membership lapses the app is removed from download. Crash reports and the privacy label also need attention.

Is 15 to 20% of the build cost a year a good rule of thumb?

It is the figure most UK agencies publish, and it is reasonable for an app with a backend and two platforms. For a small single-platform app it often overstates the work, and for the first three months after launch it understates it. We prefer a fixed monthly plan with a clear list of what it covers.

How often will a new app need updates?

Far more often in the first few months than later. Several updates in the first few weeks is normal: languages, listing corrections, privacy label changes and store keywords. After the first quarter, a significant rebuild each autumn plus a few smaller updates is typical.

What does your £550 a month include and exclude?

It includes each year's iOS and Xcode rebuild, keeping the app passing App Review as rules change, crash and bug fixes, store listing and screenshot upkeep, certificate and key renewals, up to 4 hours of changes a month and a monthly note. It excludes Apple's Developer Program fee, new features beyond the hours, and the Android version, which is covered by the £895 a month plan for both platforms. There is a three-month minimum term and a £500 onboarding fee, waived when we built the app.

Can you maintain an app another developer built?

Yes. We start with a takeover audit, from £650 for an app, so we know the code, the accounts and the risks. You get a written report either way, and the app then moves onto App care.

Want a fixed monthly figure instead of a guess? App care is £550 a month for one live iPhone or iPad app, with a three-month minimum term, and covers the iOS updates, App Review changes, crash fixes, renewals and 4 hours of changes described above. If someone else built the app, we start with a takeover audit from £650. Tell us about the app and we will say which fits.

What to do next

Free: send us the App Store link and who built the app through the takeover page and we will say which route fits, with no charge for the answer.
Talk it through: book a 20-minute call and we will tell you honestly whether we are the right people to help.
Fixed price: App care, £550 a month for one live iPhone or iPad app, three-month minimum term.

Sources

Apple Developer, "Upcoming requirements" (Xcode 26 SDK minimum since 28 April 2026, age ratings, approved reasons for APIs, EU trader status): https://developer.apple.com/news/upcoming-requirements/
Apple Developer, "Certificates" support page (effect of expired or revoked distribution certificates): https://developer.apple.com/support/certificates/
Apple Developer, "What's included" in the Apple Developer Program (99 USD per membership year): https://developer.apple.com/programs/whats-included/
Apple Developer, "Renewal" support page (what happens when a membership expires): https://developer.apple.com/support/renewal/
Apple Developer, "App privacy details on the App Store": https://developer.apple.com/app-store/app-privacy-details/
Foresight Mobile, "Mobile App Maintenance Services UK" (App Care plans): https://foresightmobile.com/services/app-support-and-maintenance
Stakk, "App Maintenance & Support UK": https://stakk.co.uk/app-maintenance-support/
chilliapple, "Application Maintenance Services and Support Packages": https://www.chilliapple.co.uk/application-maintenance-and-support
Nordstone, "Year-2 Mobile App Costs Explained for UK Businesses" (22 May 2026): https://nordstone.co.uk/blog/app-maintenance-cost-uk-what-year-2-actually-costs
KerenLabs, "How much does an app cost in the UK in 2026?" (2 October 2026): https://kerenlabs.com/blog/how-much-does-an-app-cost-uk
Pixelfield, "What Does It Cost to Maintain an App After Launch?" (23 September 2026): https://pixelfield.co.uk/blog/app-maintenance-cost/

Native vs Flutter vs React Native for a UK startup

Tyche Labs — Tue, 27 Oct 2026 16:11:12 +0000

First published on tychelabs.net.

Choosing between native, Flutter and React Native for a UK startup? Here is when each wins, what it costs, the myths worth ignoring and a five-question way to decide.

If you are commissioning an app, one of the first technical decisions is how it will be built. There are three realistic options for most startups in 2026: native apps (Swift for iPhone, Kotlin for Android), Flutter, or React Native.

You will find strong opinions online about each one. Most of them come from developers who use only one. We build in all three at Tyche Labs, so this is our attempt at a fair comparison and a simple way to decide.

The three options in plain English

Native

A native app is written in the language and toolkit each platform's maker recommends. On Apple devices that means Swift and, for the interface, SwiftUI, which Apple describes as a way to build apps "across all Apple platforms with the power of Swift" [1][2]. On Android it means Kotlin; Google announced in 2019 that Android development would be increasingly Kotlin-first [3], and it calls Jetpack Compose its "recommended modern toolkit for building native UI" [4].

If you want both platforms natively, you build two separate apps with two codebases.

Flutter

Flutter is Google's open-source framework for building apps for mobile, web and desktop "from a single codebase" [5]. You write in a language called Dart, which compiles ahead of time to machine code for mobile apps [7]. Flutter draws its own interface rather than using the platform's standard controls. Its rendering engine, Impeller, has been the default on iOS and on Android API 29 and above since the 3.27 release, and it precompiles its shaders so they don't compile while the app is running [6]. In practice that means smooth, consistent animation and an app that looks the same on both platforms.

React Native

React Native lets you write the app in JavaScript or TypeScript using React. Its tagline is "Written in JavaScript, rendered with native code": your components map to the platform's real interface elements [9]. Version 0.76 made the "New Architecture" the default in October 2024 [10], and version 0.82 in October 2025 was the first to run entirely on it [11]. The React Native docs recommend using a framework for new apps, such as Expo, which provides "file-based routing, high-quality universal libraries, and the ability to write plugins that modify native code without having to manage native files" [12].

If this is you right now: iPhone app MVP in 6 to 10 weeks, from £15,000 with App Store submission included. We reply within one working day.

When native wins

Choose native when one or more of these is true:

You are launching on iPhone first. Many UK consumer and B2B products can validate on one platform. One native app is often the fastest, simplest route to a first release.
The app lives close to the hardware. Camera pipelines, audio processing, on-device machine learning, Bluetooth accessories, background location, widgets and other system integrations are easiest with direct access to the platform's own APIs.
You need new platform features on day one. When Apple or Google release a new capability, it appears in Swift and Kotlin first. Cross-platform frameworks get there, but sometimes later and sometimes through a plugin someone else maintains.
Performance is the product. Video, real-time audio and heavy graphics leave the least margin for overhead.

A typical example: a camera app that records video while running on-device speech recognition and sells subscriptions through StoreKit 2. Almost every important part of it talks directly to Apple frameworks, so it belongs in native Swift and SwiftUI. A cross-platform layer would add little and get in the way.

The trade-off is cost when you need both platforms. Two native apps means two codebases to build, test and maintain.

When Flutter wins

Choose Flutter when:

You need iOS and Android from launch and most of the app is standard product screens: lists, forms, dashboards, booking flows, content.
You want a strongly branded interface that looks identical on both platforms. Because Flutter draws every pixel itself, custom designs are easy to reproduce exactly.
You don't already have a JavaScript team. Dart is quick to learn, and a single small team can own the whole app.
You might add web or desktop later. Flutter targets these from the same codebase [5], although a mobile-first Flutter app usually needs design work to feel right on a large screen.

Where Flutter needs care: if the app must look and behave exactly like a standard iPhone app, matching every platform detail takes effort. And anything Flutter doesn't cover out of the box needs native code connected through platform channels [8], which means someone on the team still needs Swift and Kotlin skills.

When React Native wins

Choose React Native when:

You already have a React web app or team. Developers who know React can be productive quickly, and some business logic, types and validation can be shared with a web product.
You want the platform's own interface elements rather than a custom-drawn look [9].
You value the JavaScript ecosystem and Expo's developer tooling [12].

Where React Native needs care: like Flutter, it depends on third-party libraries for many device features, and the quality of those libraries varies. Upgrades across major versions have historically taken real work, though the move to the New Architecture [10][11] was meant to put that on a firmer footing.

Cost: what we charge

These are Tyche Labs' typical ranges, not market statistics:

Approach	Standard	Complex
Flutter (iOS and Android)	£15,000–£40,000, 8–14 weeks	£40,000–£80,000, 14–24 weeks
React Native (iOS and Android)	£15,000–£45,000, 8–14 weeks	£45,000–£90,000, 14–22 weeks
Native iPhone MVP (fixed scope)	from £15,000, 6 to 10 weeks	quoted per project

A cross-platform app is often less than building two native apps, depending on how much platform-specific work there is. If half of your app is camera, audio or hardware integration, the savings shrink, because that half gets written per platform anyway. If it is mostly standard screens talking to a server, the savings can be substantial.

The other comparison that matters is one native app versus one cross-platform app. If you only need iPhone at launch, a native app is often the cheaper choice, because there is no framework layer to work around.

Myths worth ignoring

"Cross-platform apps are slow." For typical business apps, a well-built Flutter or React Native app is fast enough that users won't notice. Performance problems usually come from how an app is built, not which framework it uses.

"Native is always better." Native is better at some things. It is not automatically better value for a product that needs two platforms and has no special hardware needs.

"The framework decides whether Apple approves you." App Review judges the app, not the language. Rejections come from crashes, missing information, privacy problems and metadata issues, whatever the app is written in. See our guide to App Store rejections.

"We can switch later easily." You can, but it is a rewrite. Choose with your next two years in mind, not just the first release.

A simple decision framework

Answer these in order:

Do you need Android at launch? If not, and your users are on iPhone, start native on iOS. Add Android when you have evidence it is worth it.
Is the core of the app hardware, media or deep OS integration? If yes, lean native, even for two platforms.
Do you already have React developers or a React web app? If yes, React Native is usually the natural fit.
Do you want a custom, brand-led interface identical on both platforms? If yes, Flutter is usually the natural fit.
Still undecided? Either cross-platform option will serve a standard business app well. Pick the one your long-term team, in-house or agency, is strongest in. Who maintains the app in year two matters more than small technical differences.

Whichever route you take, make sure you own the source code and the store accounts, and that the code is in a repository you control. That keeps your options open whatever you choose.

We build native iPhone apps, native Android apps, Flutter apps and React Native apps, so we have no reason to push you towards one. If you want a second opinion on your plans, get in touch and we will tell you which route we would take and why. You can also read more about our Flutter and React Native work, or our fixed-scope iPhone app MVP in 6 to 10 weeks, from £15,000 with App Store submission included.

What to do next

Free: use our estimator for a price range on your app.
Talk it through: book a 20-minute call and we will tell you honestly whether we are the right people to help.
Fixed price: iPhone app MVP in 6 to 10 weeks, from £15,000, App Store submission included.

Sources

Apple Developer, "Swift": https://developer.apple.com/swift/
Apple Developer, "SwiftUI": https://developer.apple.com/swiftui/
Android Developers, "Android's Kotlin-first approach": https://developer.android.com/kotlin/first
Android Developers, "Jetpack Compose": https://developer.android.com/compose
Flutter: https://flutter.dev/
Flutter docs, "Impeller rendering engine": https://docs.flutter.dev/perf/impeller
Dart, "Dart overview": https://dart.dev/overview
Flutter docs, "Writing custom platform-specific code": https://docs.flutter.dev/platform-integration/platform-channels
React Native: https://reactnative.dev/
React Native blog, "New Architecture is here" (23 October 2024): https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here
React Native blog, "React Native 0.82" (8 October 2025): https://reactnative.dev/blog/2025/10/08/react-native-0.82
React Native docs, "Get started with React Native": https://reactnative.dev/docs/environment-setup

Guideline 4.3(a) design spam: whether to respond, appeal or rebuild

Tyche Labs — Tue, 27 Oct 2026 16:04:42 +0000

First published on tychelabs.net.

Rejected under guideline 4.3 as spam or a copycat? Here is what 4.3(a) and 4.3(b) actually say, and the seven questions that decide whether to reply, appeal or rebuild.

Guideline 4.3 is the rejection that feels most personal. Other rejections say your app has a bug or a missing link. This one says your app should not exist in its current form, because the App Store already has enough like it. It is also one of the hardest to respond to well, because the right move depends on which half of the guideline you were rejected under and on how different your app really is.

We have not been rejected under 4.3 ourselves, so this guide does not have a war story. What it has is the exact text of the guideline, the questions we ask before deciding whether a client should reply, appeal or rebuild, and a description of how we positioned our own app so that the question would not come up.

What guideline 4.3 says

The guideline has two parts, and Apple cites them separately.

4.3(a) says: "Don't create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city). This practice results in unnecessary apps, which makes it hard for users to find the apps they want. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and providing the variations using in-app purchase" [1].

4.3(b) says: "Don't submit apps that are indistinguishable from what's already widely available. Opportunistically creating variants of existing app categories or popular apps degrades App Store discovery, reduces overall app quality, and harms both users and developers." It names categories Apple considers "well established", including dating, flashlight, sound effects, wallpaper, simple timers and fortune telling, and says Apple "will not accept new submissions unless they offer a meaningfully different or improved experience". It also lists kinds of apps Apple considers low effort, and warns that "repeated submissions of this kind may lead to removal from the Apple Developer Program" [1].

Two neighbouring guidelines are often cited alongside 4.3. 4.2.6 says that "apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content" [1]. 4.1 Copycats says: "Don't simply copy the latest popular app on the App Store, or make some minor changes to another app's name or UI and pass it off as your own" [1].

If this is you right now: App Store rescue, from £650. Write before 2pm UK time, Monday to Friday, and we reply the same working day.

Why you were rejected: three different situations

Before deciding what to do, work out which of these describes your app. The right response is different for each.

Situation 1: you publish several apps that share a codebase

This is the classic 4.3(a) case. A gym chain with one app per branch. A publisher with one app per magazine. A white-label agency shipping the same app for each client under the client's name. Apple's view is that these should be one app with the variation inside it, chosen by the person or sold through in-app purchase [1].

There is a legitimate version of this, and Apple describes it in 4.2.6: the template provider ships "a single binary to host all client content in an aggregated or 'picker' model", such as a restaurant finder with a page for each restaurant [1]. There is also a route where the client submits the app from their own developer account, as the provider of the content, rather than the agency submitting on their behalf [1].

Situation 2: your app is in a crowded category and the reviewer could not tell it apart

This is 4.3(b). The app is yours, built from scratch, but to a reviewer spending a few minutes with it, it looks like the twenty apps above it in search results. Apple names some categories, but the list is illustrative. Timers, note-takers, habit trackers, QR scanners, white-noise apps, calculators and simple photo filters all get this treatment.

Situation 3: your app looks like a specific popular app

If the icon, name, screens or flow closely resemble one well-known app, you may be cited under 4.1 Copycats as well as, or instead of, 4.3. Apple treats impersonation as a conduct issue "and may result in removal from the Apple Developer Program" [1], so this situation is the most serious.

Respond, appeal or rebuild: how we decide

There are three possible moves after a 4.3 rejection, and they are not interchangeable.

Respond means replying to the reviewer in App Store Connect with information they may not have had. It costs a day or two and works when the reviewer could not see what makes the app different.

Appeal means asking the App Review Board to overrule the rejection. Apple asks you to "provide specific reasons why you believe your app complies with the App Review Guidelines", to submit only one appeal per rejected submission, and to respond to any requests for information before appealing [2]. An appeal is for when you believe Apple is wrong, not for when you hope a second reviewer will be kinder.

Rebuild means changing the app, or your portfolio of apps, so that the objection no longer applies. It costs the most and is the only move that works when the reviewer is right.

Here are the questions we ask.

Which clause is cited, 4.3(a) or 4.3(b)? If it is (a), you have a portfolio problem and no amount of explaining one app will fix it. If it is (b), the question is whether the difference is real and whether a reviewer can see it.
Can you state the difference in one sentence that a non-user would understand? "Our timer uses a nicer colour scheme" is not a difference. "Our timer reads the recipe aloud and pauses when you leave the kitchen" might be. If you cannot write the sentence, you have your answer: rebuild.
Is the difference visible in the first two minutes? Reviewers are quick. If the distinctive feature is behind sign-up, a paywall, a settings toggle or a third screen, the reviewer may never have reached it. That is a case for responding, with a demo video and review notes that point straight at it, before you consider an appeal.
Does your listing make the same case? Compare your name, subtitle, screenshots and first paragraph with the three apps you most resemble. If they are interchangeable, fix the listing as part of your response. Apple's reviewers see the listing as well as the build, and metadata must "accurately reflect the app's core experience" [1].
Are there other apps on your account that look like this one? If so, assume the reviewer has seen them. Consolidating them, or removing the ones that no longer matter, is often what gets the main app through.
Did you build it from a template, app builder or purchased source code? If yes, 4.2.6 is in play even if only 4.3 was cited. Reskinning does not solve it. Either the content owner submits from their own account, or the app has to become something the template did not provide.
Would you be comfortable showing the reviewer your app and the app it resembles side by side? If the honest answer is no, do not appeal.

In short: respond when the reviewer missed something that is already there; appeal when the app clearly complies and the rejection is a mistake; rebuild when the reviewer is right.

How to respond well

If you decide to respond, do it properly.

Reply in the rejection thread, not in a new submission. The reviewer who rejected you, or their team, reads the reply. Keep it short and specific.
Lead with the one-sentence difference. Then list two or three concrete features that no comparable app has, and say exactly where to find each one in the app.
Attach a short screen recording. Apple suggests being ready with a demo video when features are hard to reach or reproduce [2]. Thirty to sixty seconds that go straight to the distinctive feature is enough.
Fix the listing at the same time. Put the difference in the subtitle and the first screenshot. If the reviewer's objection was that the app looks generic, make it stop looking generic before they look again.
If you also have duplicate apps, say what you are doing about them. "We have removed the three regional versions from sale and this app now covers all regions" is a sentence reviewers respond to.
Then resubmit. A reply alone does not restart review. Resubmit the build, with changes if you made any.

How to appeal, if the app really complies

Appeals are read by the App Review Board, not by the original reviewer. Apple's conditions are specific reasons, one appeal per rejected submission, and no outstanding information requests [2]. Write the appeal as an argument, not a complaint:

Quote the guideline as cited.
State what the app does that places it outside the guideline, with reference to specific screens.
Name the apps you believe the reviewer compared you with, and say in one line each how yours differs.
Attach the same recording you would attach to a response.

Expect an appeal to take longer than a resubmission. Keep working on the listing while you wait.

How to rebuild so the objection goes away

If the reviewer was right, a rebuild does not have to mean starting over. It means finding the one thing your app does, or could do, that the category does not.

We went through this exercise with Cuefold, our own teleprompter camera app, before writing any code. Teleprompter apps are a crowded category. When we researched it in October 2026, we found that the features we had sketched already existed: voice-controlled scrolling was another app's core product, recording line by line with automatic stitching existed, and showing the script on the outer screen of a folding phone was something any competitor could ship quickly. A plain teleprompter camera would have been a weaker copy of apps already on the store.

So we built the app around something we did not find anywhere else. In Cuefold you read the whole script in one take, and when you stumble you simply say the sentence again without stopping. The app knows the script, aligns your speech to it on the device, and assembles the last good read of every line into a clean video. We call it Clean Cut, it is the first thing the app's store description talks about, and it is reachable in the first minute. Cuefold is on the App Store and was never questioned under 4.3.

The general lesson is the one Apple states in 4.2: an app should "include features, content, and UI that elevate it beyond a repackaged website" [1]. For a 4.3 rebuild, that means:

Pick one capability the category lacks and make it the headline. Not three small improvements; one thing someone would switch apps for.
Put it in the first session. No sign-up, no paywall, no settings toggle between the person and the feature.
Say it in the name, subtitle and first screenshot. The listing is where the reviewer forms their first impression.
Consolidate your portfolio. If you have several near-identical apps, one strong app with in-app variations is both the compliant route and usually the better product.
Drop the template look. If the app was built from a template or app builder, the navigation, icon set and layouts will say so. Change what the person sees first.

When not to bother

Sometimes the honest answer is that the app is a hobby project in a category Apple has said it is no longer accepting new entries to without a meaningful difference. If you cannot name the difference, and are not willing to build one, a 4.3 rejection is Apple telling you so. Spending weeks on appeals will not change the outcome, and repeated submissions of the same app can put your developer account at risk [1].

If the app was built for you by someone who has since moved on, and you are not sure which situation you are in, we can take over the app, read the code and the rejection, and tell you plainly whether a response, an appeal or a rebuild is the right call.

Checklist before you reply to a 4.3 rejection

You know whether (a), (b), 4.2.6 or 4.1 was cited, and which situation above you are in.
You can state the app's difference in one sentence.
That difference is reachable in the first two minutes without sign-up or payment.
The name, subtitle and first screenshot make the same claim.
Any near-duplicate apps on your account have been consolidated or removed, and your reply says so.
You have a 30 to 60 second recording that goes straight to the distinctive feature.
You have decided, honestly, between responding, appealing and rebuilding, and are not appealing simply because you disagree.

Questions we get asked

What is the difference between guideline 4.3(a) and 4.3(b)?

4.3(a) is about publishing several apps that are really one app, for example a separate bundle ID for each city, team or client. Apple wants one app with the variations inside it. 4.3(b) is about submitting an app that is indistinguishable from what is already widely available in its category. The first is a portfolio problem; the second is a differentiation problem.

Should we appeal a 4.3 rejection?

Only if the app clearly offers something the comparable apps do not and the reviewer appears not to have seen it. Apple asks for specific reasons why the app complies, one appeal per rejected submission, and answers to any outstanding information requests first. If you cannot state the difference in one sentence, a rebuild is the better use of the time.

Our app was built from a template. Can we still get it approved?

Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. So the content owner submitting from their own account can help, but the app also has to offer something beyond the template. A reskin alone rarely gets through.

Can one rejected 4.3 app put our other apps at risk?

Apple says repeated low-effort submissions may lead to removal from the Apple Developer Program, and reviewers can see the other apps on your account. If you have several near-identical apps, consolidate them before resubmitting rather than after.

How long does a 4.3 appeal take?

Apple does not publish appeal times. In our experience, replying to the reviewer and resubmitting is faster than an appeal, so if you can improve the listing or make the distinctive feature easier to find, do that first and keep the appeal for cases where the app clearly complies.

Rejected under 4.3 and not sure whether to reply, appeal or rebuild? Our App Store launch and rejection rescue starts at £650 and takes 2 working days. We read the rejection against the guideline, compare your app and listing with the apps a reviewer would compare it to, and give you a straight recommendation with the reply or the rebuild plan to go with it. Send us the rejection message and a link to the app.

What to do next

Free: run your rejection message through our App Store rejection decoder.
Talk it through: book a 20-minute call and we will tell you honestly whether we are the right people to help.
Fixed price: App Store launch and rejection rescue, from £650, two working days, ending in a fix plan or the fixes made.

Sources

Apple Developer, "App Review Guidelines" (4.1, 4.2, 4.2.6, 4.3, 2.3): https://developer.apple.com/app-store/review/guidelines/
Apple Developer, "App Review" (appeals, demo videos, expedited review): https://developer.apple.com/distribute/app-review/

Your developer has vanished: a 12-point app takeover checklist

Tyche Labs — Tue, 27 Oct 2026 16:04:38 +0000

First published on tychelabs.net.

Your developer has stopped replying and the app is still live? Here are the 12 things an app depends on, in the order we check them when we take one over.

The message usually arrives as a question with a hidden emergency inside it. "Our developer isn't replying. Can you update our app?" Sometimes the developer has moved on, sometimes the agency has closed, sometimes there was a falling out. The app is still in the store and still being used, which is why nobody noticed how much of it lives in someone else's accounts.

We take over apps like this, and the first thing we do is the same every time: go through a list of everything the app depends on and find out who controls each one. This guide is that list, in the order we work through it, with what to check, what good looks like and what to do when the answer is "we don't know". Use it before you call anyone, and you will know how big the problem actually is.

Before you start: two questions

Is the app in your Apple developer account or theirs? Open the App Store listing and look at the seller name under the app's title. If it is your company, the app record is in an account you should be able to reach. If it is the developer's name or their agency, the app lives in their account and getting it back is a transfer, which we cover in point 3.

Do you have the source code? Not a zip from two years ago; the code that built the version in the store today. If you are not sure, assume not until point 5 is done.

Everything else follows from those two answers.

If this is you right now: Takeover audit, from £650 for an app, credited against your first project or first three months of a plan. Write before 2pm UK time, Monday to Friday, and we reply the same working day.

The 12-point checklist

1. The Apple Developer Program membership

Every app on the App Store sits inside a Developer Program membership that someone pays for and someone legally holds. Find out whose it is, when it renews and whether it will. The fee is 99 USD a year or the local equivalent [1]. If it lapses, "your apps will no longer be available for download and you won't be able to submit new apps or updates" [2]. We have seen apps vanish from the store because a freelancer's card expired.

Good looks like: a membership held by your company, with the Account Holder role on someone employed by you, auto-renew on and the renewal date in a calendar.

If it is theirs: you need the app transferred to your own membership (point 3). Start your own enrolment now; organisation enrolments take time to verify.

2. App Store Connect access and roles

Even when the membership is yours, the people with access may not be. App Store Connect has roles from Account Holder and Admin down to Developer, Marketing, Finance, Sales and Customer Support [3]. The Account Holder is the one role that cannot be delegated: it is "the only user that can" sign legal agreements with Apple, renew the membership, request App Store Connect API access, remove auto-renewable subscriptions from sale and create Developer ID certificates [3].

Good looks like: the Account Holder is a director or owner, at least one more Admin is on staff, the departed developer's user has been removed, and every API key they created has been revoked.

Check: Users and Access in App Store Connect, including the Keys tab. A key the old developer still holds can upload builds and change your listing.

3. The app record, and whether it needs transferring

If the app is in the developer's account, Apple allows it to be transferred to yours while it stays on sale. "During and after the transfer, the app retains its reviews and ratings, and users continue to receive updates" [4]. Both Account Holders have to act: theirs initiates, yours accepts.

The app has to meet Apple's criteria. It must have at least one version released to the App Store; it cannot be waiting for review, in review or pending release; in-app purchases must be in an approved, ready-to-submit, removed or rejected state; both accounts must have accepted their latest agreements; and the in-app purchase product IDs cannot clash with any already in your account [5].

Some things do not come across. Push notification certificates have to be regenerated (keys can be reused or regenerated), an Apple Pay merchant ID has to be recreated, TestFlight testers and builds have to be removed beforehand, and you lose promo codes and any Game Center group membership [4]. For auto-renewable subscriptions, the transferor must generate an app-specific shared secret before the transfer and share it with you [4]. Your sales reports start from the transfer date; Apple's App Analytics history does come across to the recipient [4].

If the developer will not cooperate: a transfer needs their Account Holder to initiate it, so this becomes a contractual conversation. Check what your agreement says about ownership (point 11) before you have it.

4. Certificates, profiles and signing keys

To ship an update, the build has to be signed by your team. Check who holds the distribution certificate and its private key, the provisioning profiles, and the push notification key or certificate. Apple allows only one of each distribution certificate type per team, and only the Account Holder or an Admin can create them [6]. An expired or revoked certificate means "you'll no longer be able to upload new apps or updates signed with the expired or revoked certificate" [7].

Good looks like: certificates created from a machine you control, the private keys and the push authentication key (the .p8 file) stored in your password manager, and a note of every expiry date.

If the developer has them: revoke the distribution certificate and create a new one. Nothing already on the store is affected if your membership is valid [7]. Be careful with push: revoking a push certificate stops notifications until a new one is in your backend.

5. Source code and the repository

Find the repository, not a copy. Check who owns the organisation or account it lives in, that every branch and tag is there, and that the tag or commit for the version currently in the store is identifiable. Then check what is not in the repository: configuration files, API keys, signing settings and build scripts that lived on the developer's laptop.

Good looks like: the repository is owned by your company's organisation on your chosen host, the ex-developer's access is removed, and a tagged commit matches the live build number.

If you have no code at all: ask for it, citing your contract. If it really is gone, you have two honest options, rebuilding or building a new version from what is live, and you should hear the price of both before deciding.

6. Can you actually build it?

Having the code is not the same as being able to ship it. Clone the repository on a clean machine and build the exact version in the store. Note the Xcode version, the dependencies and anything that fails. Apple's current rule is that uploads must be built with Xcode 26 or later with an iOS 26 SDK [8], so a project that was last built two years ago may not upload even if it compiles.

Good looks like: a documented build that succeeds on a fresh machine, with a list of the secrets it needs and where they come from.

If it does not build: this is the single biggest cost driver in a takeover, and the reason we insist on doing it in the audit rather than after we have quoted.

7. Backend, hosting and databases

If the app talks to a server, find out where the server runs and who pays for it. Cloud accounts, database hosting, file storage, serverless functions, email sending and third-party APIs each have a billing owner and a set of credentials.

Good looks like: every account under your company's billing with your card, two people with owner access, credentials rotated after the old developer's access was removed, and a tested backup of the database.

If the server is in their account: request a transfer of the project or account, or export the data and redeploy. Do not let an unpaid invoice on an account you cannot see be the thing that takes your app down.

8. Domains, DNS and email

The app's privacy policy URL and support URL are in its App Store listing and must keep working. Universal links, sign-in redirects, the apple-app-site-association file, and the app-ads.txt file if you run ads all depend on a domain you control. So does the email address Apple sends review messages to.

Good looks like: the domain registered to your company at a registrar you can log in to, auto-renew on, DNS in an account you own, and the App Store Connect contact email on your domain.

Check: who the registrant is, when it expires, and where the DNS is hosted. These are often three different places.

9. Third-party SDK and service accounts

List every SDK in the app and the dashboard that goes with it: payments and subscriptions, push notifications, analytics, crash reporting, advertising mediation, authentication providers, maps, customer support chat. Each one has an account, an API key in the app, and often a webhook pointed at your backend.

Good looks like: an inventory with the owner, login and keys for each, moved to accounts in your name, with the ex-developer removed. Payment and subscription services deserve the most care, because they hold money and customer records.

Why it matters for review: Apple requires your privacy label to cover third-party code in the app [9], so you need to know what each SDK collects before you can keep the label accurate.

10. Analytics, crash reports and monitoring

Somebody needs to be able to see whether the app is working. Check that you have access to Apple's App Analytics and crash data in App Store Connect and Xcode, and to any third-party analytics or crash tool the app uses. If the app is being transferred to your account, Apple's App Analytics history comes across to you and the previous owner loses access to it [4].

Good looks like: one person on your side who looks at crashes weekly, and an agreed threshold for what counts as urgent.

11. Privacy, legal and ownership

Three documents matter. The contract with the developer, which should say who owns the code and the accounts. The privacy policy, which should describe what the app actually does and live at a URL you control. And the privacy label in App Store Connect, which Apple requires to be accurate and which you can update at any time without a new build [9]. If the app is sold in the EU, trader status is required to submit updates [8].

Good looks like: an intellectual property assignment or a clear ownership clause, a privacy policy you can edit, a privacy label that matches the SDK inventory from point 9, and a list of any data processors with agreements in place.

If the contract is silent on ownership: take advice before relying on the code being yours. A transfer in App Store Connect moves the app record; it does not settle who owns the work.

12. The release process

Finally, work out how a change gets from code to the store. Who can upload a build, who ticks the in-app purchases onto a submission, what the review notes say, whether a demo account exists and still works, whether TestFlight is used, and how the backend is deployed alongside an app release.

Good looks like: a written release checklist, a successful test release to TestFlight done by your new team, and review notes that explain the app to a stranger. Apple asks for "full access to your app" including demo accounts and explanations of non-obvious features [10], and reviewers will ask again if the notes are stale.

Then do a real update. The fastest way to find what the checklist missed is to ship a small, low-risk release. Until you have done that, you do not know you can.

If there is an Android version too

Google Play has its own transfer process. Both accounts must be registered and in good standing, you need the registration transaction IDs for both, and Google says its team processes requests within 2 business days [11]. Users, ratings, reviews, subscriptions and statistics transfer; reports, test groups and promotions do not [11]. Run the same twelve points for the Play Console, the signing key and the Android build.

How we run a takeover

Our takeover audit is this checklist done for you, from £650 for an app and from £350 for a website, with a written report whether or not you carry on with us. We list everything the product depends on and help you get control of it in your own name; we build the code ourselves and run it on current devices; we check dependencies, security updates, crash reports and the store listing; and we give you a plain-English report of what works, what is at risk and what to fix first, with a fixed price for each fix.

After that, most apps move onto our App care plan at £550 a month, which covers each year's iOS update, App Review changes, crash fixes, listing upkeep, certificate and key renewals and 4 hours of changes. Apple's Developer Program fee stays with you, deliberately, so the account stays yours. We built our own apps on exactly this footing: our own membership, our own repositories, our own domains, and nothing we could not rebuild from scratch tomorrow.

If you have read the twelve points and the answer to most of them is "we don't know", that is normal. It is also the moment to act, before a renewal date does it for you.

Questions we get asked

Our app is in the developer's Apple account. Can we get it back?

Usually, yes. Apple allows an app to be transferred between developer accounts while it stays on sale, keeping its ratings and reviews. The developer's Account Holder has to initiate the transfer and yours has to accept it, and the app must meet Apple's criteria: at least one released version, not currently in review, in-app purchases in an eligible state and both accounts' agreements accepted. If the developer will not cooperate, it becomes a contractual matter.

What does not transfer with an app?

Push notification certificates have to be regenerated, an Apple Pay merchant ID has to be recreated, TestFlight testers and builds must be removed first, and promo codes and Game Center group membership are lost. For subscriptions, the previous owner must give you the app-specific shared secret before the transfer. Sales reports start from the transfer date.

What if we do not have the source code?

Ask for it, citing your contract. If it really is gone, there are two honest options: rebuild the app, or build a new version from what is live. We tell people the price of both before they choose. An app record without code can still be transferred and kept on sale, but it cannot be updated.

Can the old developer still harm the app after we take over?

Only through access you have not removed. Check App Store Connect users and API keys, the repository, cloud and hosting accounts, the domain registrar and every third-party service dashboard. Revoke distribution certificates they hold and create new ones; existing installs are unaffected while your membership is valid.

How much does a takeover cost?

Our takeover audit is from £650 for an app and from £350 for a website, agreed before we start, excluding VAT. You get a written report either way. Fixes are priced individually in the report, the audit fee is credited against your first project or first three months of a plan, and most apps then move onto App care at £550 a month.

Do we need to be on a maintenance plan afterwards?

No. Most people choose to, because the reason an app drifts is that nobody is looking after it, but the report and the accounts are yours whether or not you continue with us.

Developer gone quiet? Our takeover audit runs this checklist for you, from £650 for an app, and ends with a written report of what you control, what is at risk and what to fix first, each with a fixed price. The audit is credited against your first project or first three months of a plan, and afterwards most apps move onto App care at £550 a month. Tell us what you have: the App Store link and who built it is enough to start.

What to do next

Free: send us the App Store link and who built the app through the takeover page and we will say which route fits, with no charge for the answer.
Talk it through: book a 20-minute call and we will tell you honestly whether we are the right people to help.
Fixed price: Takeover audit, from £650 for an app, credited against your first project or first three months of a plan.

Sources

Apple Developer, "What's included" in the Apple Developer Program (99 USD per membership year): https://developer.apple.com/programs/whats-included/
Apple Developer, "Renewal" support page (what happens when a membership expires): https://developer.apple.com/support/renewal/
App Store Connect Help, "Role permissions": https://developer.apple.com/help/app-store-connect/reference/role-permissions
App Store Connect Help, "Overview of app transfer": https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer
App Store Connect Help, "App transfer criteria": https://developer.apple.com/help/app-store-connect/transfer-an-app/app-transfer-criteria
Apple Developer Account Help, "Certificate types": https://developer.apple.com/help/account/reference/certificate-types
Apple Developer, "Certificates" support page (expired and revoked certificates): https://developer.apple.com/support/certificates/
Apple Developer, "Upcoming requirements" (Xcode 26 SDK minimum, EU trader status): https://developer.apple.com/news/upcoming-requirements/
Apple Developer, "App privacy details on the App Store": https://developer.apple.com/app-store/app-privacy-details/
Apple Developer, "App Review Guidelines" (Before you submit): https://developer.apple.com/app-store/review/guidelines/
Google Play Console Help, "Transfer apps to a different developer account": https://support.google.com/googleplay/android-developer/answer/6230247

Why apps get rejected: 285 public App Review cases analysed

Tyche Labs — Tue, 27 Oct 2026 15:35:01 +0000

First published on tychelabs.net.

We read 419 public posts about App Store rejections and classified the 285 real cases by guideline and outcome. Here is what gets apps rejected, what fixed it, and the dataset.

We read 419 public posts in which developers asked for help with App Store review, and classified the 285 that describe a real rejection of their own app. The answer to "why do apps get rejected?", in the cases developers post about:

Payments and in-app purchase: 18% (50 cases). Digital content sold outside in-app purchase, and subscription screens missing the price, terms or a restore option.
Spam and copycats: 13% (38). Guideline 4.3: an app too similar to others, or to the developer's own apps.
Missing information or demo access: 13% (36). The reviewer could not log in, could not find a feature, or asked for a video.
Privacy: 8% (24). Purpose strings, sign-up walls, tracking without the prompt, privacy answers that don't match the app.
Crashes and bugs: 8% (23). Often a reviewer device with no network, an iPad, or a purchase flow with no products loaded.
Metadata and screenshots: 7% (21), automated upload checks: 6% (16), and everything else under 4% each.

By guideline number, 2.1 (App Completeness) is cited in 24% of cases, 4.3 (Spam) in 12% and 5.1.1 (Data Collection) in 8% [7]. In 63% of cases the developer quoted the guideline from Apple's message; the rest we inferred from what they described.

Outcomes are less clear than causes. In the Reddit, Stack Overflow and Hacker News threads, 72 developers came back to say what happened: 39 (54%) were approved, almost all after changing the app or listing, and 33 were still rejected at their last update. Sixteen developers in the whole dataset filed a formal appeal; one says the appeal itself got the app approved.

Where the data comes from

Source	Cases	What we read
Reddit (r/iOSProgramming, r/iosdev, r/reactnative, r/swift and five more)	112	A random sample of 140 posts with "reject", "appeal" or "guideline" in the title, 2023 to October 2026, with the poster's later comments and the top replies
Apple Developer Forums, App Review tag	106	The first post of the 156 threads on the tag's 20 most recent listing pages that mention a rejection or guideline [8]
Stack Overflow	48	Questions about App Store rejections from 2019 on, with their answers
Hacker News	19	"My app was rejected" stories from 2019 on, with comments
Total	285	134 more posts were read and left out: questions asked before submitting, waits with no rejection, Google Play, news about other companies' apps, duplicates, and cases from before 2019

Every case in the dataset links to its public source. We removed usernames, post titles and app names.

The most common reasons, ranked

Theme	Cases	Share	Main guidelines cited
Payments and in-app purchase	50	18%	3.1.1, 3.1.2, 2.1(b)
Spam or copycat	38	13%	4.3(a), 4.3(b), 4.1
Missing information or demo access	36	13%	2.1
Other or unclear	25	9%	various
Privacy: policy, permissions, data use	24	8%	5.1.1, 5.1.2
Crash or bug	23	8%	2.1
Metadata and screenshots	21	7%	2.3.x
Automated upload checks	16	6%	ITMS-91061, ITMS-91064 and others
Design and platform conventions	11	4%	2.5.x, 4.0
Intellectual property and trademarks	10	4%	5.2.x
Regulated or sensitive category	10	4%	1.4.1, 5.1.1(ix)
Minimum functionality or web wrapper	8	3%	4.2, 4.2.2
Login and Sign in with Apple	6	2%	4.8
User-generated content	4	1%	1.2
Account deletion	3	1%	5.1.1(v)

What developers post about is not what Apple rejects most

Apple publishes how many submissions it rejects under each section of the guidelines. In 2025 it reviewed 9,100,620 submissions and rejected 2,093,244 [1]. Comparing the five named sections with the cases in our dataset that cite a guideline:

Section	Share of Apple's 2025 rejections [1]	Share of public cases
Performance (2.x)	50%	41%
Legal (5.x)	18%	18%
Design (4.x)	15%	23%
Business (3.x)	11%	15%
Safety (1.x)	6%	3%

Design and Business are over-represented in public posts; Performance is under-represented. That fits what the posts say. A crash or a broken link is fixed quietly and resubmitted. A 4.3 spam rejection or a payments dispute has no obvious fix, so developers go looking for help. If you are reading this after a 4.3 or a 3.1.1 rejection, you are in the group most likely to need a second opinion, and most likely to find conflicting advice.

Got a rejection message in front of you? Paste it into our free App Store rejection decoder. It matches the guideline, shows Apple's wording and gives the usual fix, in your browser, with nothing sent to us.

What fixed it, by reason

These are fixes the developers themselves confirmed worked (50 cases), plus the advice repeated most often in replies where the outcome was not reported.

Payments and in-app purchase (50 cases)

Apple's rule is direct: if you unlock features or content in the app, "you must use in-app purchase", and apps "may not use their own mechanisms to unlock content or functionality" [3]. For subscriptions, Apple expects you to "clearly describe what the user will get for the price" before asking anyone to subscribe [3].

Confirmed fixes in the dataset:

Adding Terms of Use (EULA) and privacy policy links on the paywall itself, not only in the listing.
Stating the trial length and the billed price next to the subscribe button, and fixing a paywall layout that broke on iPad.
Attaching the in-app purchases to the first submission, and handling the case where the store returns no products instead of showing a blank screen.
Signing the Paid Apps agreement and adding banking details, so StoreKit returns the products at all.

The repeated advice for 3.1.1: sell digital subscriptions through in-app purchase even if you also sell on the web, remove links and references to web pricing inside the app, and keep Stripe for physical goods and services.

Spam and copycats (38 cases)

Guideline 4.3 has two parts. 4.3(a) says "Don't create multiple Bundle IDs of the same app"; 4.3(b) says "Don't submit apps that are indistinguishable from what's already widely available" and names dating, flashlight, wallpaper and simple timer apps among the saturated categories [3]. This was the theme with the most unresolved cases: 16 of the 22 with a reported outcome were still rejected.

Confirmed fixes: a redesigned generic icon with review notes explaining the difference; a distinctive core interface; rewritten description, keywords and screenshots plus a reply explaining the mechanic no other app has; removing third-party service names from the app name and subtitle. The pattern is that the difference has to be visible in the first screen and the screenshots, not only described in a reply. Our guide to 4.3 rejections covers when to reply, appeal or rebuild.

Missing information or demo access (36 cases)

Apple asks for "either an active demo account or fully-featured demo mode" for any account-based features [3]. The typical case is a one-time code login the reviewer cannot complete, a demo account that expired, or a hardware feature with no video. Confirmed fixes were simple: update the test account and reply in the review thread; resubmit unchanged after the reviewer mistyped the demo email. Advice repeated in replies: a demo account with a fixed one-time code, a screen recording from a real device, and step-by-step review notes for anything not on the first screen.

Privacy (24 cases)

The privacy cases split into four kinds: vague purpose strings ("we need your location"), apps that require an account before showing anything, tracking or ads loaded before the App Tracking Transparency prompt, and App Privacy answers that do not match what the SDKs collect [6]. Six of the eight with a reported outcome were approved. Confirmed fixes: making login optional and moving it to settings; showing content before asking for sign-up; showing the tracking prompt before the consent form and adding SKAdNetwork identifiers; correcting the App Privacy answers; and changing a pre-permission button from "Enable microphone" to "Continue", which is what Apple's privacy guidance asks for on a screen shown before the system prompt [4].

Crashes and bugs (23 cases)

Many reported crashes were not reproducible by the developer. The common causes in replies: the reviewer's device had no network or used IPv6, the app was tested on an iPad, or the purchase screen loaded before products arrived. Confirmed fixes: replacing a location package that crashed, handling a missing network connection before fetching products, and in one case replying with evidence that the reviewer's device was offline, after which the same build was approved. The advice: test the release build on a real device with no network, on an iPad and on IPv6, and read the crash log Apple attaches.

Metadata and screenshots (21 cases)

Apple product names in the subtitle, trademarks in keywords, "beta" in the description, screenshots that show the wrong device or a broken layout, and paid features not labelled as paid. Confirmed fixes were all edits to the listing, and several replies point out that a metadata-only rejection can often be fixed without a new build.

Automated upload checks (16 cases)

Emails such as ITMS-91061 (missing privacy manifest) arrive before human review. Apple requires privacy-impacting third-party SDKs to include a privacy manifest [5]. Confirmed fixes: bundling the SDK's privacy manifest with the correct resource path, removing an empty tracking-domains array, and replacing a plugin that referenced non-public symbols. Most were solved by updating the SDK.

Appeals and repeat rejections

Sixteen developers filed a formal appeal to the App Review Board. One reported approval because of the appeal, one was approved after changing the app anyway, ten were still rejected at their last update and four did not say. Apple describes the appeal as the route when "you feel we misunderstood your app" [2]. In this data it rarely worked on its own; a change the reviewer can see worked more often.

Where developers said how many times they had been rejected for the same submission (53 cases), the median was 2, and 24 (45%) had been rejected three times or more, up to 16. The long runs share a pattern: each resubmission fixed only the sentence in the last message, and the next reviewer found the next issue. Apple's App Review appointments (30-minute video calls) were suggested in several threads as the way out of that loop [2].

Method

Collection (27 October 2026): Reddit posts from nine iOS and cross-platform subreddits (2023 to 27 October 2026) via the Arctic Shift archive of public Reddit data [9], sampled at random from 801 posts with "reject", "appeal" or "guideline" in the title and at least two comments; the 20 most recent listing pages of the App Review tag on Apple Developer Forums (first posts only, so outcomes there are mostly unknown); Stack Overflow and Hacker News posts found by search, with answers and comments.

Classification: each post was read and coded against a written codebook: valid or not, guideline (quoted or inferred), one of 15 themes, outcome (only from the poster's own words), the fix and whether the poster confirmed it, number of rejections, framework, and whether a formal appeal was filed.

Exclusions: 114 of 419 posts (hypothetical questions, waits with no rejection, Google Play, news, duplicates) and 20 Stack Overflow and Hacker News cases from before 2019, when the guidelines used different numbering.

Dataset: 285 rows, one per case, with the source link. Free to reuse under CC BY 4.0 [7].

Caveats

This is what developers post about, not a random sample of rejections. Hard, confusing and unresolved cases are over-represented; quick fixes rarely get a post.
Outcomes are often missing. 173 of the 285 cases have no reported outcome, and the Apple forum cases are first posts only.
Inferred guidelines. In 37% of cases the guideline was inferred from the description, or left as unknown.
One reader per post. Each post was coded once, against a fixed codebook, and the coding was spot-checked; a second coder might file a few borderline cases under a neighbouring theme.
Rules change. The guidelines are updated several times a year. Check the current wording [3] before acting on an old fix.

A checklist built from the 285 cases

Every paywall shows the price, the period, the trial terms, Restore purchases, and links to the Terms of Use and privacy policy.
In-app purchases are attached to the submission and the app copes when no products load.
The demo account works without a one-time code, and the review notes say where every feature is.
A screen recording from a real device is attached for anything that needs hardware, a location or an account state.
The release build has been run with no network, on an iPad and on IPv6.
The app does something visible in its first screen and screenshots that similar apps do not.
The app name, subtitle and keywords contain no other company's trademarks and no "beta".
Purpose strings say why the app needs access, with an example; sign-up is not required to see what the app does.
App Privacy answers match what every SDK in the build collects, and each SDK ships a privacy manifest.

Questions we get asked

What is the most common reason apps get rejected?

Across all App Store submissions, Apple's 2025 transparency report shows Performance (section 2, which includes 2.1 App Completeness) accounts for about half of rejections in the five named sections. In the 285 public cases developers posted about, payments and in-app purchase was the largest theme (18%), followed by spam and copycats (13%) and missing information or demo access (13%). Guideline 2.1 was the single most cited number, in 24% of cases.

Does appealing an App Store rejection work?

Sometimes, but rarely on its own in our data. Of 16 developers who filed a formal appeal to the App Review Board, one reported that the appeal got the app approved and one was approved after changing the app; ten were still rejected at their last update. Apple says an appeal is for when you believe it misunderstood your app. If the rejection is about something you can change, a visible change usually works faster.

How many times do apps get rejected before approval?

Where developers said how many rejections they had for the same submission, the median was 2, and 45% had three or more. Apple's own report shows 387,087 submissions were approved in 2025 after an earlier rejection.

Do I need a new build to fix a rejection?

Not always. Rejections about metadata, screenshots or missing information can often be fixed by editing the listing or replying in App Store Connect. Changes to the app itself, such as a paywall, a purpose string or a crash, need a new build.

Can I use the dataset?

Yes. The CSV is free to download and reuse under CC BY 4.0: credit Tyche Labs and link to this page. It has one row per case with the guideline, theme, outcome, fix summary and a link to the public source, and no usernames, titles or app names.

What to do next

Free: paste your rejection message into our App Store rejection decoder for the guideline, Apple's wording and the usual fix.
Talk it through: book a 20-minute call and we will tell you honestly whether to reply, change the app or appeal.
Fixed price: our App Store launch and rejection rescue starts at £650: we review the build, the listing and the rejection, and in two working days you have a fix plan, or we make the fixes for you.

Sources

Apple, "2025 App Store Transparency Report" (seen 27 Oct 2026): https://www.apple.com/legal/app-store/transparency/2025/
Apple Developer, "App Review": appeals and appointments (seen 27 Oct 2026): https://developer.apple.com/distribute/app-review/
Apple Developer, "App Review Guidelines" (2.1, 3.1.1, 3.1.2, 4.3) (seen 27 Oct 2026): https://developer.apple.com/app-store/review/guidelines/
Apple Developer, "Human Interface Guidelines: Privacy" (seen 27 Oct 2026): https://developer.apple.com/design/human-interface-guidelines/privacy
Apple Developer, "Third-party SDK requirements" (seen 27 Oct 2026): https://developer.apple.com/support/third-party-SDK-requirements/
Apple Developer, "App privacy details on the App Store" (seen 27 Oct 2026): https://developer.apple.com/app-store/app-privacy-details/
Tyche Labs, "Public App Store rejection cases, classified" (dataset, CSV, 285 rows, collected 27 Oct 2026): https://www.tychelabs.net/data/app-store-rejection-cases.csv
Apple Developer Forums, "App Review" tag (listing pages 1 to 20, read 27 Oct 2026): https://developer.apple.com/forums/tags/app-review
Arctic Shift, archive and API of public Reddit posts and comments (queried 27 Oct 2026): https://arctic-shift.photon-reddit.com/

What UK app and web agencies actually charge in 2026

Tyche Labs — Tue, 27 Oct 2026 15:34:57 +0000

First published on tychelabs.net.

We read 80 UK agency websites on 27 October 2026 to find out what they publish about price. Here are the figures, the medians and the full dataset, with every number linked to the page it came from.

Most UK agencies do not tell you what they charge. On 27 October 2026 we checked the websites of 80 UK app and web agencies; 66 were live, UK-based and in scope. Only 12 of the 66 (18%) publish any price of their own: a starting price for an app, a website package, a support plan or a day rate. Another 11 publish a market cost guide, with typical ranges for the whole market, but no price of their own. 43 (65%) publish nothing at all.

Where agencies do publish, the numbers are these:

App builds: 9 agencies publish a starting price. The median is £14,000, and the range runs from £5,000 to £60,000 [2][3][4][5][6][7][8][9][10].
Websites: 3 agencies publish a starting price: £3,000 for a brochure site, £12,000, and £25,000 for a full web project [2][11][13].
Monthly support: 4 agencies publish a plan. Website support starts at £75 and £950 a month; app support at £675 and £1,000 a month [1][3][12][15].
Day rates: 3 agencies publish one: about £390, £650 to £1,200, and £950 a day. A fourth publishes £90 an hour for website support [1][7][11][14].
Market guides: across the 13 market cost guides we could verify, the cheapest band each one names has a median starting point of £15,000 and a median top of £60,000 [3][6][7][8][16][17][19][20][21][22][23][24][25].

The full dataset is a free download [18]: one row per agency, with the page each figure came from and the words it was quoted in.

Who publishes prices, and who does not

What the agency publishes	Agencies	Share of 66
Any price of its own (app, website, support or rate)	12	18%
A starting price for an app build	9	14%
A monthly support or maintenance price	4	6%
A day or hourly rate	4	6%
A website price	3	5%
A market cost guide only, no own price	11	17%
Both its own price and a market guide	6	9%
Nothing about price at all	43	65%

The pattern is regional as well as general. The 12 agencies that publish come from London (2), the Midlands (3), the South West (3), the North West (2) and Yorkshire (2). None of the 26 agencies we checked in Scotland, Wales, Northern Ireland, the North East, the South East or the East of England publishes a price of its own.

Why so few? The usual reason is that scope varies too much for one number. Scorchsoft puts it in a line: "the same idea can honestly cost £10k or £200k" [26]. That is true, but it leaves buyers with no anchor at all, and the agencies that do publish show it can be done: Bluesparrow Apps lists three app tiers at £14,000, £19,000 and £31,000 [5]; Atomic Smash answers "How much do you charge?" with "Our day rate is £950 +VAT" [14].

App build prices agencies publish

These are the agencies' own prices, as stated on their own pages on 27 October 2026, excluding VAT unless the agency says otherwise.

Agency	Region	What they publish	Source
Pixelbeard	North West	AI-assisted builds "from around £5,000 for a basic app"	[4]
Scorchsoft	Midlands	"A bespoke project under £7.5k is unlikely" (a floor, not a price list)	[8]
Magora	London	Startup MVP from £10,000; full production build £25,000 to £60,000	[2]
Fifteen Design	Midlands	Bespoke app "begins at a competitive rate of £10,000"	[9]
Bluesparrow Apps	South West	Three tiers: £14,000, £19,000 and £31,000	[5]
Foresight Mobile	North West	Simple app or MVP £15,000 to £40,000; complex £80,000 or more	[3]
Newicon	South West	Live software "from around £50,000 to £500,000+"	[10]
The Distance	Yorkshire	A product built on its own platform "usually falls between £60,000 and £90,000"	[6]
Pocketworks	Yorkshire	MVP £60,000 to £250,000	[7]

The median of the nine starting figures is £14,000. That number hides two different markets. Six agencies start at £5,000 to £15,000 and describe small, fixed-scope first versions. Three start at £50,000 to £60,000 and describe a funded product with discovery, design, a back end and a team for months. Both are legitimate. The mistake is comparing a quote from one market with a quote from the other.

Comparing quotes? Put each one through the same three questions: what exactly is in the first release, who owns the code and accounts on day one, and what does it cost per month after launch. Our free estimator gives you a range for your own app in a few minutes, so you have an anchor before the first call.

Website prices agencies publish

Only three agencies in the sample publish a website price, so treat this as three data points, not a market median.

Agency	Region	What they publish	Source
ALT Agency	Midlands	Small brochure website from £3,000 + VAT; small website with advanced functionality £4,000 to £8,000 + VAT	[11]
Creative Brand Design (CreativeWeb)	London	"Projects start from £12,000. Average project size is around £20,000 to £25,000."	[13]
Magora	London	Full production mobile or web project £25,000 to £60,000	[2]

One more agency, KIJO in Birmingham, says in its homepage FAQ that most web design projects in the city "start around £10,000", with mid-range custom builds between £12,000 and £30,000 [27]. It frames that as the local market, not its own price list, so it sits in the market column of the dataset.

Support, maintenance and day rates

Agency	What they publish	Source
ALT Agency	Website maintenance and support packages from £75 a month (up to £375); ad hoc support £90 + VAT an hour	[11][12]
Foresight Mobile	App Care plans at £675, £995 and £1,495 a month	[3]
Atomic Smash	Website support and maintenance from £950 + VAT a month; day rate £950 + VAT	[14][15]
Magora	Maintenance retainer from £1,000 a month; from £49 an hour per developer, "about £390 a day"	[1]
Pocketworks	£650 to £1,200 a day "for an agency like Pocketworks"	[7]

Two figures we did not count as maintenance: one agency quotes about £200 a month for hosting, and another quotes £3,000 to £30,000 a month for post-launch optimisation, which is ongoing development rather than upkeep. Both are in the dataset with a note.

For comparison, our own plans are public: Website care is £95 a month and App care £550 a month for one live iPhone or iPad app.

What the market guides say an app costs

Seventeen agencies publish a cost guide with market ranges. Thirteen are about apps and we re-read their figures on 27 October. Of the other four, one is in US dollars, one describes savings rather than a price band, one is about websites (KIJO, above) and one we could not re-read. The table takes the cheapest band each guide names, because that is the figure a first-time buyer is looking for.

Agency guide	Cheapest band it names	Guide date	Source
Pulsion Technology	Entry level £3,000 to £18,000	March 2026	[24]
Big Lemon	MVP £5,000 to £20,000	not stated	[21]
Appoly	From £10,000	2020	[23]
Scorchsoft	£10,000 (the same idea can cost £200,000)	not stated	[26]
Foresight Mobile	Simple app or MVP £15,000 to £40,000	not stated	[3]
Pocketworks	£15,000 to £50,000 for a self-funded startup	June 2025	[22]
The Distance	From £15,000	2026	[6]
Pocket App	MVP £25,000 to £60,000	February 2026	[16]
Magora (market column)	Startup MVP £25,000 to £80,000	October 2026	[1]
Vidatec	Simple (MVP) £30,000 to £60,000	2026	[25]
3 Sided Cube	First iOS and Android app £50,000 to £250,000	2022	[20]
Pixelbeard	MVP £60,000 to £150,000 "twelve months ago"	2026	[19]
Sonin	iOS and Android from around £80,000	May 2026	[17]

The median starting point is £15,000 and the median top of the cheapest band is £60,000. The spread is the story: the cheapest band starts anywhere from £3,000 to £80,000, a 27-fold difference for what is nominally the same thing, a first version of an app. Part of that is scope (one platform or two, with or without a back end), part is the kind of client each agency wants, and part is age: three of the guides are from 2020 to 2022, before AI-assisted development started pulling small-project prices down. Pixelbeard says the same MVP scope that cost £60,000 to £150,000 a year ago now costs 35 to 60% less [19].

Method

Sample: 80 UK agencies that build apps, websites or both, chosen to cover every UK region and a range of sizes. 59 were well-known agencies picked from our knowledge of the market; 21 were added to fill regional gaps (Wales, Northern Ireland, Scotland, the North) and were picked before anyone looked at their prices. 66 were live, UK-based and still trading; 10 sites were unreachable, redirected or for sale, and 4 were excluded (two rebranded or acquired, one sister site, one with no verifiable trading presence).

What counts: a price the agency states as its own ("our apps start from", "our day rate is", plan prices). Market commentary ("apps typically cost") is recorded separately as a cost guide. We read each site's sitemap for price, pricing, cost, package, plan, rate and fees pages, tried the common paths (/pricing, /packages, /costs), and stopped after about six pages if nothing was found.

Date: every page was read on 27 October 2026. Prices change; the CSV records the exact URL and quote so anyone can re-check.

Medians: the app median is the median of each agency's lowest published app figure (n = 9). Market medians use the cheapest band each verifiable guide names (n = 13 for the starting point, n = 9 for the top, where a top is given).

Caveats

Small numbers. Nine app prices, three website prices and four support prices are enough to show what the published market looks like, not to set a national average.
Published is not charged. A "from" price is a floor for the smallest project; most clients pay more. Agencies that publish nothing may charge more or less than those that do.
Selection. We cannot rule out that agencies willing to publish prices differ from those that do not, for example by being smaller or more productised.
VAT and scope. Some agencies quote excluding VAT and some do not say. A brochure website and a web application both count as a "website" in some lists; we kept each agency's own words.
Our interest. We are a UK agency and we publish our own prices. We have not included ourselves in the medians.

How to use these numbers

Decide which market you are in. A first version of one app with one core journey sits in the £5,000 to £40,000 band. Two platforms, a back end, integrations and a team for months sits from £50,000 up.
Ask for a price before discovery, not after. Agencies that publish prices are telling you a fixed-scope quote is possible. If an agency cannot give a range until a paid discovery phase, ask what discovery costs and what you own at the end of it.
Price the year, not the build. Monthly support ranges from £75 for a small website to £1,495 for an app plan. Add it to the build price before comparing quotes.
Check the date. Several of the guides buyers find first were written in 2020 to 2022.

Questions we get asked

How much does an app cost to build in the UK in 2026?

Among the nine UK agencies that publish their own app prices, the median starting price is £14,000, with a range of £5,000 to £60,000. The market cost guides published by 13 agencies put the cheapest band at a median of £15,000 to £60,000. A small first version on one platform sits at the bottom of those ranges; two platforms with a back end sits well above them.

How much does a website cost in the UK?

Only three of the 66 agencies we checked publish a website price: £3,000 for a small brochure site, £12,000 as a starting point with an average of £20,000 to £25,000, and £25,000 to £60,000 for a full web project. Three data points are not a market average, but they show the bands agencies work in.

What day rate do UK app agencies charge?

Three agencies in our sample publish a day rate: about £390 (from £49 an hour), £650 to £1,200, and £950 plus VAT. A fourth publishes £90 plus VAT an hour for website support. Most agencies do not publish a rate at all.

Why don't agencies publish their prices?

Usually because scope varies so much that a single number can mislead. In our check, 43 of 66 agencies published no price and no cost guide. The 12 that do publish show that fixed tiers, starting prices and day rates can be stated clearly without misleading anyone.

Can I use this data?

Yes. The CSV is free to download and reuse under CC BY 4.0: credit Tyche Labs and link to this page. Each row includes the page the figure came from and the words it was quoted in, so you can check any number yourself.

What to do next

Free: get a price range for your own app from our estimator, then compare it with the bands above.
Talk it through: book a 20-minute call and we will tell you honestly whether a quote you have looks right, even if we are not the people to build it.
Fixed price: our iPhone app MVP in 6 to 10 weeks starts at £15,000, typically £15,000 to £25,000, with App Store submission included and the price fixed once the scope is agreed in week one.

Sources

Magora, "UK software development pricing" (seen 27 Oct 2026): https://magora-systems.com/uk-software-development-pricing/
Magora, "App development cost UK 2026" (seen 27 Oct 2026): https://magora-systems.com/app-development-cost-uk/
Foresight Mobile, "How much does it cost to build an app?" (seen 27 Oct 2026): https://foresightmobile.com/blog/how-much-does-it-cost-to-build-an-app
Pixelbeard, "Build faster" (seen 27 Oct 2026): https://www.pixelbeard.co/build-faster
Bluesparrow Apps, "Costs of app development" (seen 27 Oct 2026): https://bluesparrowapps.com/costs-of-app-development/
The Distance, "App development costs: what to expect in 2026" (seen 27 Oct 2026): https://thedistance.co.uk/insights/app-development-costs-what-to-expect-in-2026
Pocketworks, "UK app development costs in a nutshell" (seen 27 Oct 2026): https://pocketworks.co.uk/blog/uk-app-development-costs-in-a-nutshell/
Scorchsoft, "App development cost" (seen 27 Oct 2026): https://www.scorchsoft.com/app-development-cost
Fifteen Design, "App development" (seen 27 Oct 2026): https://www.fifteendesign.co.uk/website-development/app-development/
Newicon, "Software development cost" (seen 27 Oct 2026): https://newicon.net/services/software-development/cost
ALT Agency, "How much will a website cost me?" (seen 27 Oct 2026): https://www.altagency.co.uk/blog/how-much-will-a-website-cost-me/
ALT Agency, "Website maintenance" (seen 27 Oct 2026): https://www.altagency.co.uk/services/development/website-maintenance/
Creative Brand Design (CreativeWeb), homepage (seen 27 Oct 2026): https://www.cbwebsitedesign.co.uk/
Atomic Smash, "FAQs" (seen 27 Oct 2026): https://www.atomicsmash.co.uk/faqs/
Atomic Smash, "Website support and maintenance" (seen 27 Oct 2026): https://www.atomicsmash.co.uk/website-support-and-maintenance-bristol/
Pocket App, "App development cost in the UK: budget ranges, timelines and what's included" (seen 27 Oct 2026): https://www.pocketapp.co.uk/app-development-cost-in-the-uk-budget-ranges-timelines-and-whats-included/
Sonin, "How much does an app cost?" (seen 27 Oct 2026): https://sonin.agency/insights/how-much-does-an-app-cost/
Tyche Labs, "UK agency published prices, 27 October 2026" (dataset, CSV): https://www.tychelabs.net/data/uk-agency-prices-2026.csv
Pixelbeard, "Agency vs in-house: the honest cost of building a dev team in 2026" (seen 27 Oct 2026): https://www.pixelbeard.co/post/agency-vs-in-house-the-honest-cost-of-building-a-dev-team-in-2026
3 Sided Cube, "How much does an app cost? (2022)" (seen 27 Oct 2026): https://3sidedcube.com/blog/how-much-does-an-app-cost-2022
Big Lemon, "How much does an app cost to build?" (seen 27 Oct 2026): https://biglemon.co.uk/blog/how-much-does-an-app-cost-to-build
Pocketworks, "App development cost UK" (seen 27 Oct 2026): https://pocketworks.co.uk/blog/app-development-cost-uk/
Appoly, "How much does it cost to develop a mobile app?" (seen 27 Oct 2026): https://www.appoly.co.uk/resources/how-much-does-it-cost-to-develop-a-mobile-app/
Pulsion Technology, "How much does it cost to develop an app in the UK?" (seen 27 Oct 2026): https://www.pulsion.co.uk/blog/how-much-does-it-cost-to-develop-an-app-in-the-uk/
Vidatec, "How much does it cost to build an app in the UK? 2026 guide" (seen 27 Oct 2026): https://vidatec.com/uncategorised/how-much-does-it-cost-to-build-an-app-in-the-uk-2026-guide/
Scorchsoft, "How much does it cost to build an app?" (seen 27 Oct 2026): https://www.scorchsoft.com/guides/how-much-does-it-cost-to-build-an-app
KIJO, homepage FAQ (seen 27 Oct 2026): https://kijo.co.uk/