Publishing a Moodle App on Google Play and App Store: Step by Step
Publishing a custom Moodle app on both stores requires planning. Accounts, certificates, requirements, deadlines, and common pitfalls to avoid.
by Cleverson

Publishing a custom Moodle app on both stores is an operation full of bureaucratic details that determine the success of the delivery. The difference between a launch that goes out on time and one that is delayed by 3 months lies in understanding the process before starting, rather than discovering the requirements after the review has already been rejected. This guide is the complete checklist for publishing a well-done Moodle app: what needs to be ready, in what order, and at what costs.
TL;DR
- Apple App Store: Apple Developer account (US$ 99/year), stricter review process (3-14 days), requires an explanation screen for each permission.
- Google Play: Google Play Developer account (US$ 25 one-time), faster review (1-3 days after first approval), requires detailed Data Safety section.
- Total time to publish a Moodle app from start to availability on both stores: 4-8 weeks if prepared, 12+ weeks if learning along the way.
- The 4 most common reasons for rejection: data privacy, permission descriptions, minor content, institution identity.
Prerequisites before dealing with the stores
Before any store registration, three things need to be ready:
- Functional built app with the institution's visual identity (logo, splash, icon), final name defined, connected to the correct Moodle instance. This comes from the customization work β detailed in Custom Moodle App: 7 Advantages.
- Published privacy policy at an accessible URL on the institution's website. Both Apple and Google require a public link to this document during submission. The policy must cover: what data the app collects, how it uses it, who it shares it with, and how the user can remove it.
- Institution's own domain linked to a trusted institutional account (not an employee's personal account). Apple and Google prefer consistency: registered company, website with the same name, emails @ the own domain.
Without these three items, any attempt to publish a Moodle app on the stores becomes a waiting queue.
Publishing a Moodle app on the Apple App Store β step by step
Step 1 β Create an Apple Developer Program account
Go to developer.apple.com and create an account. For institutional apps (school, university, company), the registration must be as an Organization, not Individual. It requires:
- DUNS Number of the company (free, takes 5-30 days to issue via Dun & Bradstreet β start early)
- Company documents (in Brazil: CNPJ, articles of incorporation)
- Person authorized to sign legally for the company
- US$ 99/year (auto-renewal)
The verification process takes 1-2 weeks. Apple calls or sends an email confirming identity. If the institution is part of a larger network (educational group, holding), it may be eligible for a specific program (Apple School Manager for K-12 schools, for example) β worth checking.
Step 2 β Configure certificates and provisioning
In the Apple Developer Portal:
- Create an App ID with the app's bundle identifier (format com.institution.app)
- Generate a Distribution Certificate (digital signature of the app)
- Configure a Provisioning Profile for distribution
- Enable specific capabilities (Push Notifications, Sign in with Apple, etc.)
The app developer performs these steps. Important: these certificates must be under the institutional account name, not personal. Changing them later is cumbersome.
Step 3 β Prepare App Store Connect
App Store Connect is the dashboard where you manage the publication. Here you register:
- App information: name (up to 30 characters), subtitle (up to 30), description (up to 4000), keywords (up to 100 characters), primary category (Education) and secondary (optional)
- Screenshots: required for various screen sizes (iPhone 6.7", 6.5", 5.5"; iPad 12.9" and 11"). Usually 3-5 screenshots per device. Apple rejects overly promotional screenshots β prefer showing the real app in use.
- Preview Video (optional but recommended): 15-30 second video showing the app working
- App icon: 1024Γ1024 PNG without transparency, without rounded corners (Apple applies them automatically)
- Privacy policy (public URL)
- Test information: how the Apple reviewer should test the app (test Moodle URL, fictitious student credentials)
Step 4 β Submit for Review
Upload the build via Xcode or Transporter. Then, in App Store Connect, click "Submit for Review" filling in:
- Version being submitted
- Notes for the reviewer (in English β easier)
- Encryption Declaration (if using standard encryption, usually "No")
- Advertising Identifier (usually "No" for educational apps)
Review typically takes 24-72 hours nowadays. But cases with pending issues can take 7-14 days. Response comes by email: approved or rejected with a list of items.
Step 5 β Handle rejection (if any)
When publishing an educational Moodle app for the first time, it's common to receive rejection on 1 or 2 points. The most frequent:
- "Demonstrate the purpose of each permission requested" β describe in text and screenshot why the app requests access to camera, microphone, notifications, etc.
- "Account creation must use Sign in with Apple" β if the app allows creating a student account within it, Apple requires including Sign in with Apple as an option.
- "Description does not match app functionality" β the store description must exactly reflect what the app does. Exaggerated marketing is rejected.
- "Privacy policy URL inaccessible" β check that the link works and that the text covers what the app actually collects.
The response is to edit what was requested and resubmit. Each new review is faster (down to ~24h after the first).
Publishing a Moodle app on Google Play β step by step
Step 1 β Create a Google Play Developer account
At play.google.com/console, create an account. Unlike Apple, it's a one-time payment of US$ 25. For institutional apps, register as an Organization. Verification takes 1-3 days, requires:
- Valid physical address
- Credit card for the one-time payment
- Owner's identity document
- (In 2026) D-U-N-S or similar identity check for business accounts
Step 2 β Configure the app in Play Console
- Create a new app, set name, default language, type (App), and free/paid
- Accept developer program policies
- Configure app content: privacy policy (URL), category (Education), target audience (age), content rating (fill out questionnaire)
- Data Safety: describe all types of data the app collects, whether it is shared with third parties, whether it is encrypted in transit and at rest. This form is detailed and demands honesty β Google audits.
- Permissions: justify each sensitive permission (file access, camera, location)
Step 3 β Upload the AAB (Android App Bundle)
The build is generated by the developer in .aab format (Android App Bundle, successor to .apk). Upload to Play Console in the desired track:
- Internal testing: internal testers, up to 100 emails. Useful for first validation
- Closed testing: groups of up to 2000 testers, ideal for beta with selected students
- Open testing: anyone can sign up to test (public, with link)
- Production: official release
Recommended when publishing a Moodle app: go through Internal β Closed β Production gradually. Each step allows adjustments based on real feedback before the general public.
Step 4 β Configure store listing
- Title (up to 30 characters)
- Short description (up to 80 characters)
- Full description (up to 4000 characters)
- Screenshots: minimum 2 per device type (phone and tablet, optionally Chromebook). Specific sizes
- Icon: 512Γ512 PNG
- Feature banner: 1024Γ500 PNG, used in store highlights
- Promotional video: optional, YouTube link
Step 5 β Review and publication
Google Play review is generally faster than Apple β 24-72 hours for simple apps. Educational apps with minor data may take longer (up to 7 days) due to extra scrutiny from the Designed for Families program.
Once approved, the app goes to the selected track (production, beta, etc.) and becomes available in the store search within a few hours.
The 4 most common reasons for rejection when publishing a Moodle app
Reason 1 β Inconsistent data privacy
App says it collects X but the privacy policy describes Y, or Google's Data Safety says it doesn't share and the app sends data to Firebase. Both stores audit β inconsistency is detected and rejected. Solution: perfectly align what the code collects, what the policy describes, and what Data Safety declares.
Reason 2 β Permissions without visible justification
App requests camera permission but nowhere in the app is the camera used. Reviewer tests, doesn't find it, rejects. Solution: either actually use the permission with an explanation screen, or remove the permission from the app's manifest.
Reason 3 β Content for minors without adequate protections
Educational apps always serve teenage or child audiences. This triggers extra rules (COPPA, LGPD for minors): parental consent, anonymization, tracking limitation, ad restriction. Not complying = quick rejection. Solution: correctly define the age range and implement proportional protections.
Reason 4 β Institutional identity not confirmed
App name says "University X" but the developer account is under a random individual's name. Apple and Google verify this match. Solution: institutional account, with institutional documents, under the correct name.
Total consolidated costs
A typical operation to publish a custom Moodle app on both stores involves:
| Item | Cost |
|---|---|
| Apple Developer Program account | US$ 99/year |
| Google Play Developer account | US$ 25 one-time |
| DUNS Number (Apple Org) | Free |
| Privacy policy drafted by lawyer | R$ 800-2,500 one-time |
| Professional screenshots (designer) | R$ 1,000-3,000 one-time |
| Short promotional video | R$ 1,500-5,000 one-time |
| App development + customization | R$ 30-80 thousand one-time |
| Annual store maintenance | R$ 1,000-3,000/year |
Typical launch total: R$ 35-95 thousand one-time + R$ 1,500-3,500/year recurring. I detailed the development cost in Moodle Mobile App vs Custom App.
Realistic timeline
- Week 1-2: account creation, DUNS Number, privacy policy
- Week 3-6: app development/customization (in parallel with accounts)
- Week 7: store panel setup, build upload, listing adjustment
- Week 8: submission for review, rejection adjustments if any
- Week 9-10: app published on both stores
This timeline assumes an experienced team and a well-coordinated process. First time without experience usually adds 4-6 weeks of rework.
Post-launch maintenance
Publishing a Moodle app is just the beginning. Ongoing operation involves:
- Annual renewal of Apple Developer account (US$ 99) β without renewal, the app goes offline
- Renewal of distribution certificates (annual for Apple, automatic for Google)
- Periodic app updates β every new Moodle version or visual adjustment needs to be submitted (update review is faster, usually <24h)
- Responding to user reviews on both stores β good practice for store SEO and perception
- Crash monitoring via Firebase Crashlytics or App Store Connect Analytics
- Continuous compliance with new Apple/Google rules (change several times a year)
At Agathas Web we operate this complete cycle as a service: from initial account setup to ongoing publication maintenance, leaving the institution free to focus on educational content. To understand the package, it's also worth seeing the features that make the most difference for engagement β push notifications in the Moodle app and offline mode.
Related posts

Custom Moodle App: 7 Advantages Over the Official App
A custom Moodle app with your branding boosts engagement and institutional perception. See the 7 advantages and when the investment pays off.

Moodle Mobile App vs Custom Moodle App: 2026 Comparison
Custom Moodle app or the official free one? Comparison of features, costs, maintenance, and ROI break-even point to decide which to use.

Moodle Push Notifications: The Engagement Multiplier in the App
Well-segmented Moodle push notifications triple re-engagement and improve completion rates. Practical strategies, ideal frequency, and what to avoid.