The real cost of a 2,000-line screen
The most expensive file in your codebase is probably a screen. Not because that screen does anything special, but because over the years it quietly took on everything near it until it became too big to change safely.
In the Wikipedia iOS app I audited, the map screen was a single class of 2,636 lines. The root view controller was 2,214 lines, plus another 1,319 lines in a second file. The class got so full it spilled into an extension just to keep the compiler happy. This is one of the most common patterns I see, and it costs real money in three specific ways.
Every change becomes a search problem
When a screen is 200 lines, you open it and you understand it. When it is 2,000 lines, you open it and you start searching. Where is this piece of state set? What else reads it? What happens if I change this line?
A new engineer needs weeks to touch a file like that safely, and even a senior one slows down. The work is not hard because the feature is hard. It is hard because the file is hard. You lose time on every single change, and it gets worse as the file grows.
Code review stops working
Review is one of the cheapest ways to catch problems, and giant files quietly break it. A reviewer looks at 40 changed lines out of 2,600 and cannot judge the effect, because the context they would need to hold is too large. So review turns into a formality, and the bugs it is supposed to catch start shipping.
You still pay for the review. You just stop getting the protection.
Testing becomes impractical
Big screens are hard to test, so they usually are not tested. In the Wikipedia app, the five biggest screens had almost no test coverage. The riskiest, most-changed code was also the least protected. That is the exact opposite of what you want, and it is not a coincidence. Untestable code and oversized code are usually the same problem.
The fix is not a rewrite
The good news is that you do not fix this by throwing the app away.
You split one screen at a time. You take the biggest screen, pull one clear responsibility out of it into its own smaller controller, and ship that. Then the next responsibility. Each extraction is small enough to release on its own and reason about on its own, usually three to five days of work. The screen shrinks with every step, and it stops being scary. Your roadmap keeps moving the whole time, because you are shipping real, safe changes, not pausing for a rebuild.
Do this for one screen per sprint and within a couple of months the worst files in your app are no longer the ones everyone is afraid to touch.
How to know which screens to start with
You do not want to guess. Some big files are fine, and some small ones hide the real risk. The point of an app audit is to tell you exactly which files and decisions are costing you the most, and to hand you the fix in priority order so you start where the money is.
The audit is a fixed price of €790 and takes one to two weeks. You can read the full report I did on the Wikipedia app, including the screen sizes above and the plan to fix them, on the audit page.
If adding a small feature to your app takes weeks and nobody can quite say why, a 2,000-line screen is a good bet for where the time is going.