Before you build an app: six obstacles that aren't in the code

This guide collects six of them. All are obstacles we have hit on real projects, and all can be settled before the build begins. None of them is technical in the strict sense, which is precisely why they get forgotten.

1. Store accounts are not an administrative detail

Publishing an app requires two developer accounts: Apple at ninety-nine dollars a year, and Google at twenty-five dollars once. These are published, fixed prices, and they are not paid to us — they go to the platforms directly.

The obstacle is not the money. Apple explicitly requires every business to have its own account — that is the text of Guideline 4.2.6 in the review guidelines. Publishing from an agency account, or from one account pooling several clients, is rejected. This is not arbitrary strictness: the platform wants an accountable entity behind every app.

The practical consequence matters more than the rule. When the account is in your name:

• The app is yours, and so are its ratings, its history and its data.
• You can change development provider without losing any of it.
• Nobody is in a position to hold your app hostage.

Opening the accounts takes time — identity verification, business entity documents, and sometimes weeks at Apple for organisation accounts. Start on day one, not in the final week.

2. Selling inside the app needs a registered entity and a merchant account — and the build will not wait for them

This is the obstacle we have most often seen take business owners by surprise.

An app that sells needs a payment gateway. A payment gateway needs a registered business entity and a merchant account in the business's name at the payment provider. That is a banking and regulatory process, not a programming one: identity checks on the business, the kind of products sold, a risk assessment. It can take weeks, and it can be refused.

What happens in practice: the store gets built in full, tested, working — and unable to take a single shekel. The app is finished and disabled at the same time.

We went through exactly this on a store platform we built: payment fully built and tested, and held open operationally purely while waiting on the merchant account. The build finished long before the paperwork.

The rule: the merchant application opens in parallel with development, not after it. And if the business has no registered entity yet, that is the first item on the schedule, not the last.

3. Apple takes thirty percent on anything digital

A small detail that inverts an entire profit model.

• Selling physical goods — clothes, food, parts, a service performed in the real world — goes through ordinary payment, and Apple takes nothing from it.
• Selling a digital product — a subscription, a course, paid content, a feature inside the app — must go through In-App Purchase, and Apple takes its commission.

The difference is not marginal. If your core product is digital, that commission enters your pricing, your margin and possibly the viability of the channel itself. And it is said before signing, not after: a business that built its numbers on one margin may find a very different one on iOS.

4. The catalogue is the project, not the screens

Most people ask about the number of screens. The more important question is: who fills the app, and how often?

A catalogue app with five dummy products looks excellent on delivery day. Three months later, if nobody is updating it, it becomes a shopfront for stale information — which is worse than not having one, because the customer saw a price that is no longer true.

The questions settled early:

• Is the content genuinely ready — images, descriptions, prices — or is it still being gathered?
• Who inside the business owns updating it, and in which part of their week?
• Is there an existing system (till, stock) to pull from, or will everything be entered by hand?

Manual entry is not a flaw, but it imposes a condition: the entry panel has to be fast. A slow panel means a catalogue nobody updates, and a catalogue nobody updates means a dead app. On a platform we built, the entry panel was the most dangerous part of the project rather than the easiest, for exactly this reason.

5. Store review is not your schedule

Between delivering the app and seeing it in the store sits a stage none of us controls: review.

Apple usually runs between a day and two weeks. Google is often faster. And a build can be rejected on a formal point — a thin description, an unclear privacy policy, a permission with no justification — sending the cycle back to the start.

This is why we always separate the two numbers: build time is our commitment, review time is not in our hands. Anyone promising you a store appearance date either does not know, or knows and is not saying.

What can genuinely be done is to reduce the odds of rejection: a complete submission, an accurate description, a real privacy policy, justified permissions, and screenshots that match what the app does. We prepare the submission, file it and answer the review's notes through to approval — but that shortens the cycle, it does not remove it.

6. An app that is never updated gets removed

An app is not a website. A published website keeps working for years with nobody touching it. An app does not.

Apple and Google ship new operating systems every year, raise the minimum they require of apps, and change privacy and permission requirements. An app that is never updated stops working on new devices first, and is eventually removed from the store.

This is not a problem reserved for bad apps. It affects every app with nobody responsible for it after launch. That is why maintenance is priced as a standing item from the start, rather than as an emergency discovered a year in.

What gets settled before a single line of code

Nothing in that table is a programming task. And any single row of it can delay a technically finished project by months.

In short

An app is not purely a programming project — it is a project that passes through two platforms with their own rules, a payment system with its own conditions, and content that needs someone to look after it. The programming part is the clearest and least surprising of them.

The most honest question to put to any development firm is not "what does it cost" or "how long does it take", but: what will hold this project up that isn't in your hands? The answer reveals who has actually been through it.