Suppose the code for an order-taking app is finished on the 20th of the month, with a launch announced to the sales team for the 1st. The build compiles, internal testing is done, the final development invoice is settled. But the company has no Apple developer account yet, nobody has requested a D-U-N-S number, and the privacy policy has not been written. The launch will not happen on the 1st, and the delay will have nothing to do with code quality.
This is the most common way a mobile project stalls at the finish line. Budgets and stack choices are documented everywhere, including in our Morocco mobile app development pricing guide. The last mile, on the other hand, gets treated as paperwork you handle on the way out: “we put the app on the stores”. It is really an administrative and compliance process, with its own documents, identity checks, review queues and grounds for refusal.
Two weeks between “the code is ready” and “the app is downloadable” is an optimistic plan for a first release. Four to six weeks is more realistic when the developer accounts still have to be created.
Why submission is the most underestimated line in the plan
Three causes stack up. First, an IT specification document describes features, almost never a release procedure, so there is no “submission” line in the schedule and no named owner. Second, part of the delay depends on neither you nor your vendor. Apple and Google review the app when they review it, and a refusal sends the submission back into the queue.
Third, the administrative steps run in series, not in parallel. Get a D-U-N-S number, then have the legal entity verified, then confirm the address, then and only then create the app listing. Each step waits for the one before it, so three days lost at the start show up in full at the end.
Developer accounts: who should own them
The developer account belongs to the company that operates the app, not to the agency that builds it. That sounds obvious and it is still the most expensive mistake in the process: an app published under a developer’s personal account becomes hard to recover the day the relationship ends, and transferring an app between accounts has its own conditions. Have both accounts created in the company’s name, with a generic email address you control rather than an employee’s inbox.
On Apple’s side, the Apple Developer Program costs 99 USD per year. Enrolling as an organization requires a D-U-N-S number from Dun & Bradstreet, free of charge, but it can take several working days to obtain, and the legal name and address must match your company registration exactly. That is where Moroccan SMEs usually get stuck: a trade name used in daily business but different from the one on the commercial register is enough to fail verification. Apple also expects the person enrolling to have legal authority to bind the company.
On Google’s side, the Play Console account is a one-time 25 USD fee. Identity and address verification has become stricter, and a recently created “personal” account normally has to run a closed test with a small group of testers for two weeks before it can request production access. For a company, an organization account avoids that detour. Plan the payment method too: both fees are in foreign currency and need an international card, which is not always immediately available in a small company.
Mandatory disclosures, personal data and Law 09-08
Both stores require a publicly reachable privacy policy URL before you submit. A dead link, a placeholder page, or a copy-paste of the website policy that says nothing about the app, its permissions or its SDKs, are classic rejection reasons and entirely avoidable.
The sensitive part is consistency. Apple makes you declare, data type by data type, what the app collects. Google asks for the same thing in the Data safety form. Those declarations have to match what the code actually does, third-party SDKs included. Firebase Analytics, Crashlytics, an ad network or an embedded support widget all collect identifiers and usage data even if nobody on your team thought about it. Ask your development team for the exact list of SDKs in the build before you fill anything in.
Then there is the Moroccan layer. A CNDP-compliant app privacy policy states the purpose of the processing, the data collected, the retention period, the rights of access, rectification and objection, the contact for the data controller, and the question of transfers outside Morocco, which in practice applies to any app whose backend runs on a foreign cloud. Law 09-08 requires a prior declaration of the processing, and the receipt number belongs in the policy. The procedure is covered in our CNDP Law 09-08 compliance checklist; check the current version of the forms on the CNDP website before filing. One detail that keeps being forgotten: if the app lets users create an account, it must also let them delete it, and both stores now look for that.
Real review times and rejection reasons, store by store
App Store
Apple states that the large majority of submissions are reviewed in under 24 hours. That is often true for a minor update. For a first release, allow more room, especially when in-app purchases are being reviewed at the same time. The refusals keep landing on the same points: app incomplete or unusable by the reviewer (guideline 2.1), typically a login screen with no demo account provided; excessive data collection or forced registration for features that do not need it (5.1.1); minimum functionality, the wrapped-website case (4.2); no “Sign in with Apple” when the app already offers a social login (4.8); digital content paid for outside in-app purchase (3.1.1). After that come metadata rejections: screenshots that do not meet the spec, a mention of Android in the iOS listing, a support URL that does not resolve.
An App Store rejection in Morocco almost never has a local cause. The rules are the same as everywhere, applied by a reviewer who has a few minutes and whatever handset is on the desk.
Google Play
Play review time varies more: a few hours for some updates, several days for a first submission, sometimes longer when the account is new or the app requests sensitive permissions. The usual blockers are permissions that need justification (background location, SMS, call log, access to the list of installed apps), a Data safety form that is incomplete or contradicted by the code, a target API level below the minimum required for the current year, or a regulated category such as finance, lending or health that calls for extra documentation. Check the expected target API level in the console before you compile the final build. That rejection is purely mechanical, and it always arrives at the worst moment.
In-app purchases and payment: what gets complicated in Morocco
The base rule is easy to state: digital content or services consumed inside the app (subscriptions, credits, unlocking features) go through the store’s in-app purchase system, with the matching commission. A physical good, a service delivered outside the app, or an order paid on delivery can use something else, a CMI gateway for instance. The boundary is not always intuitive, and this decision belongs in the specification stage rather than the night before submission, because it affects the business model directly.
Before committing to a subscription model, two concrete checks: the currency and price tiers available for Morocco in App Store Connect and the Play Console, and the payout conditions (accepted bank details, tax forms, receiving foreign currency). Talk to your bank, and to your accountant if the amounts are meaningful, before you display a price in the app.
Checklist: publish mobile app Morocco without losing weeks
Prepare these alongside the final weeks of development, not afterwards:
- Developer accounts on Apple and Google in the company’s name, D-U-N-S obtained, generic email address, international card available.
- Publisher identity consistent everywhere: legal name, address, contact phone, a support URL that actually works.
- Privacy policy online, specific to the app, aligned with Law 09-08, including the CNDP declaration number.
- List of third-party SDKs from the technical team, so the data declarations do not contradict the build.
- Demo account that is valid and does not expire, plus reviewer notes: how to reach the gated screens, which code to use if signup goes through SMS.
- Visual assets in the formats required at submission time, icon included, screenshots with no placeholder text and no real customer data.
- Store listing in the language your users read, age rating completed, category chosen, description free of promises the app does not keep.
- Signed build, coherent version and build numbers, debug traces removed, tested on a recent device and on a three or four year old one.
- Account deletion reachable inside the app, and through a web link if you publish on Play.
- A named owner on the company side who holds access to both consoles and can answer a reviewer the same day.
If you get rejected: fixing it without losing two weeks
A refusal is not a punishment, it is a ticket. The lost time almost always comes from the reaction, rarely from the decision itself. Start by reading the guideline number quoted and the screenshot attached, then classify the problem: build, metadata, or interpretation. A metadata rejection is fixed without recompiling, which changes the schedule impact entirely.
When the reason rests on a misunderstanding, a feature the reviewer could not find or a regulatory constraint read the wrong way, reply in the App Store Connect resolution center with a short explanation, screenshots and the exact path to reproduce. That is usually faster than a fresh submission and the conversation stays attached to the same case. Where the reading of the rule is genuinely debatable, an appeal process exists; keep it for real disagreements. On Play, correct the declaration or permission at issue, document how the app uses it, and use the appeal form if the decision looks wrong.
The habits that cost money: resubmitting an identical build hoping for a different reviewer, answering three days later, or letting vendor and client wait for each other while nobody decides. A reply sent the same day often resolves in 24 to 48 hours. A week of silence costs a week of launch.
Frequently asked questions
How much does publishing on both stores cost?
Account fees are 99 USD per year for the Apple Developer Program and a one-time 25 USD for the Play Console. The rest of the cost is time: legal copy, visual assets, data declarations, review round trips. It is marginal next to the development budget, but it is not zero, and it covers neither backend hosting nor maintenance.
Can you publish an app in Morocco without a registered company?
Yes, an individual account is possible on both stores. Two consequences: your personal name can appear as the publisher on the listing, and a recently created personal Play account has to go through the closed testing phase before it can access production. For a commercial activity, an account in the company’s name is easier to hand over and more credible to users.
How long does it take between submission and going live?
With verified accounts and a complete package, a few days is often enough on both stores. With accounts to create, a D-U-N-S to obtain and a privacy policy to write, think in weeks. Each rejection adds the fix time plus another trip through review.
Does the app have to be declared to the CNDP?
If the app processes personal data of users in Morocco (customer accounts, phone numbers, geolocation, order history), the processing falls under Law 09-08 and the prior declaration applies just as it would for a website or a CRM. Check the right form and any exemptions on the CNDP website.
Before you announce a launch date
The useful shift is to treat submission as a deliverable, with its documents and its owner, and to plan it when the specification is written rather than after final acceptance testing. Announce the date to the market once both stores have approved the app: the actual release can then be triggered whenever you decide.
At Arrowlancer, submission is part of our mobile app development projects: creating and configuring the accounts, a CNDP-compliant privacy policy, data declarations, store listings, and the fixes and resubmission if a refusal comes back. If your app is nearing completion and the store question is still open, tell us your launch date, because it determines the order of everything else. What follows comes right after, and our mobile app maintenance budget guide gives the figures to expect once the app is live.