Xylora Studios manages mobile application submissions by preparing production-ready builds, configuring store listings, and submitting packages directly through your platform accounts. Our Technology department executes the technical configuration, while your team provides account access, legal documentation, and final operational sign-off.
Account ownership and prerequisites
All public-facing applications are published under your organisation's developer accounts. Xylora Studios does not publish client applications under studio-owned credentials. Retaining ownership ensures that intellectual property, customer data, and store analytics remain entirely within your control.
Before submission begins, your team must supply:
- Apple Developer Program access: An invitation to your App Store Connect team with an Admin or App Manager role.
- Google Play Console access: An invitation to your Play Console account with permissions to create and manage releases, store listings, and app bundles.
- Active legal links: Publicly accessible URLs for your Privacy Policy and Terms of Service. These must remain live indefinitely.
- Reviewer test accounts: Fully populated test credentials for review teams, ensuring they can access all authenticated areas of the application without triggering two-factor authentication barriers.
- Regulatory declarations: Completed questionnaires regarding export compliance, age ratings, data collection practices, and target audience age brackets.
If your project package includes asset generation, our Creative department will prepare promotional graphics, app icons, and screenshot sets. Otherwise, raw graphic assets meeting platform-specific dimension standards must be provided before the submission date.
The submission workflow
App store releases follow a strict operational pipeline handled primarily by the Technology department, supported by Operations & Client Services for scheduling:
1. Pre-flight verification: The build is verified against current store guidelines (such as target API levels on Android and mandatory entitlements on iOS). Signing certificates, bundle identifiers, and provisioning profiles are configured. 2. Staging upload: Production binaries are uploaded to Apple TestFlight and Google Play Internal Testing tracks. This allows internal validation on physical hardware in a production environment. 3. Listing configuration: Operations & Client Services, working alongside your team, inputs the localised descriptions, keywords, support details, copyright notices, and marketing graphics into the respective developer consoles. 4. Reviewer guidance setup: Test credentials, explanatory demo videos (if required for complex features), and specific testing instructions are attached to the submission metadata. 5. Formal submission: The builds are dispatched to Apple and Google for automated static analysis and manual human review. 6. Release execution: Depending on your preferred release strategy, apps are configured for immediate release upon approval or phased release over a seven-day window to monitor crash metrics safely.
Timelines and review durations
Our studio operates Monday to Thursday, 09:00-17:00 GMT. Build creation, credential testing, and release setup take place strictly during these studio hours.
Platform review queues operate independently of our studio schedule:
- Apple App Store: Manual human review typically concludes within 24 to 48 hours of initial submission, though complex applications (e.g., medical devices, finance, or background location trackers) can face extended queues.
- Google Play Store: Automated and manual checks generally take between 24 and 72 hours for existing accounts, but new developer accounts can be held for up to seven calendar days.
Because external review queues are outside our direct control, submission deadlines must be factored into project milestones early. For critical launch dates, builds should be submitted to review at least 10 working days prior to your public launch event.
Rejections and failure handling
Store rejections are a normal part of the modern mobile deployment cycle. If an application is rejected during review, the studio acts based on the nature of the notice:
- Technical defects or compliance failures: If a rejection is caused by an architectural bug, crash on review devices, or missing technical entitlement, the Technology department isolates the issue, issues a patch build, and resubmits the package.
- Content or policy flags: If a rejection relates to missing terms of use, unclear business models (such as subscription clarity or in-app purchase disclosures), or user-generated content moderation policies, we outline the exact platform requirement and advise your team on the necessary metadata or legal updates.
Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site. Status updates and guidance through rejections are tracked via the Ask Xylo chat on this portal.
Submission readiness checklist
Ensure the following elements are complete before requesting a production upload:
- [ ] Apple Developer and Google Play Console invites accepted by the studio.
- [ ] Non-expiring review credentials provided and tested without SMS/2FA dependencies.
- [ ] Data privacy disclosures mapped and Privacy Policy published.
- [ ] Store metadata (app name, subtitle, description, support URL) signed off.
- [ ] Target release date and release type (immediate vs manual) confirmed in writing.