App development, answered

It depends almost entirely on scope, and scope is the thing most people have not settled when they ask. A focused first version doing one job well is a very different project to a platform with accounts, payments and integrations.

Yes, and it is common. The first step is establishing what you own: the source code, the repositories, the store accounts, the backend, the domains and the credentials.

Almost always for procedural reasons rather than quality. Incomplete privacy disclosures, a login the reviewer cannot get past, subscriptions that do not restore, placeholder content, or missing test credentials.

Usually not. Cross-platform tooling is mature enough that most business apps should be built once and shipped to both stores, with the saving going into polish and the second version.

Yes, provided the codebase is in a state where that is sensible. Part of taking over an app is an honest assessment of whether extending it costs less than rebuilding the parts that matter.

A focused first version is typically three to five months including store review. Anything promising six weeks is either very small in scope or leaving out testing, review preparation and the fixes that follow real users.

Analytics and crash reporting should already be live, so the first week produces evidence rather than opinions. Install, activation, the core action, and retention at day one, seven and thirty.

No. A small friendly cohort first, so the obvious problems surface while the audience is small enough that fixes stay quiet and reviews stay forgiving.

Yes, and you should insist on that with anyone. Repositories, store accounts, backend infrastructure, domains and credentials belong in accounts your business controls from day one.

Apps need it. Operating systems update, store requirements change, dependencies age and certificates expire. An unmaintained app degrades quietly and then breaks at an inconvenient moment.