Your app is live. It needs someone who owns it.

Yes. I start with a code review: I get it building, map how it works, and list the risks. You’ll know what you have before any changes are made. Missing documentation or an unreachable previous developer is normal, and I work from the code itself.

I look at crash reports and the most recent changes before touching any code. Most sudden crashes come from a recent release, an OS update or a third-party service change. Finding which one tells me the fix.

Yes. I read the rejection against the store guidelines, fix what’s actually required (often privacy details, account deletion, payments or metadata), and resubmit. If the rejection is wrong, I reply to the reviewer with the evidence.

It depends on how often you release, how many third-party services the app relies on, and how old the code is. Every app needs some work each year just to stay in the stores: new OS versions, SDK updates and policy changes. On top of that come your bug fixes and features. I’ll estimate after reviewing the code.

Yes. I can stay on for regular releases, fixes and updates after the first round of work. No Yelling has worked with me this way since 2020.

Usually fix. Rebuilding throws away working, tested code and resets your users’ experience. I recommend a rebuild only when the foundation blocks what you need next, and even then, in stages that keep the app live.

That’s the main thing I guard against. I test the money-making flows first and change code in small, reviewed steps, so a problem is caught early and is easy to roll back.