How to submit an app to Shiptavio

Most delays come from the same few gaps: a binary instead of source, missing screenshots, or an API still pointing at localhost. Get these ready and the form takes one sitting. Your answers stay in this browser as a draft until you submit.

Read the prohibited apps list and the asset requirements below before you fill the form.

Register with email and password, or continue with Google. Email accounts receive a 6-digit code and must confirm it before the first sign-in. Google accounts arrive verified.

The first wizard step collects how we identify the app and which stores it targets. Use the real production identifiers here. The app ID becomes part of the hosted privacy policy URL, and the bundle or package identifier is what the stores bind the build to.

• App name and a lowercase app ID with letters, numbers, and hyphens.
• Framework: Expo, React Native CLI, Flutter, or other.
• Target platforms. iOS and Android share one release credit; macOS, tvOS, and visionOS use a separate Apple platform credit each.
• Support email and, if your app has login, the demo credentials the reviewer will use.
• Privacy policy text for us to host, or a public URL you already maintain.

Send the project, not a finished build. Every app is compiled and signed with the developer account it will be published under, so an .ipa or .aab built elsewhere cannot be reused.

Add the exact build command and any environment variables the build needs, one KEY=value per line. Production URLs only. We reject localhost, 127.0.0.1, 10.0.2.2, and private LAN addresses.

This is the longest step. Apple and Google use different fields, different categories, and different screenshot sizes, so the wizard keeps them separate. The Apple listing is shared by iOS, macOS, tvOS, and visionOS; Google Play has its own.

• Name, subtitle or short description, full description, and keywords within the store limits.
• Category per platform. The lists are separate because Apple and Google name them differently.
• App icon, screenshots, and the Android feature graphic at the exact dimensions.
• Demo username and password if the app has a login.
• Reviewer notes for anything the store team might trip over.

Compliance is not paperwork for its own sake. These answers become the store questionnaires, and a wrong answer can hold up review after the build is already uploaded.

• Apple age-rating questionnaire, with an explicit confirmation.
• Google Play content rating answers for the IARC questionnaire.
• Privacy and data safety answers: what you collect, why, and whether you track users.
• Reviewer contact details, plus a demo login if the app needs one.
• The mandatory checklist: rights, production APIs, free app, account deletion, and review timing.
• The publishing consent. Your app is published under the publisher of record named there.

The last step shows what you entered. Check the app ID, the bundle or package identifier, the screenshots, and the demo login before you send it. After submission, the release appears in your dashboard with a status you can follow.

We review the app first. If it is a fit, you pay RM199 for 12 months and 5 release credits are added. The base credit is used when we start the build, not when you submit the form.

The dashboard shows the current stage and keeps a history of every change. The store review clock starts only after we upload a signed build.

1. 1. We review the submission

   A person on our team reads the source and checks the listing. If something is unclear or not allowed, we send it back before any credit is used.

2. 2. You pay for the term

   Once the app is approved, you pay RM199 for 12 months. That adds 5 release credits: your first publish plus up to 4 updates.

3. 3. We build and sign

   The base credit is used when we start the build. We compile with your build command, sign with our certificates, and upload to both stores.

4. 4. Apple and Google review

   Store review can take up to 48 working hours, and the stores control that timeline. We handle the back-and-forth and tell you what changed.

5. 5. Your app goes live

   We add the store links to your dashboard. Later updates use the same flow and one release credit each.

Open the app in your dashboard and choose Submit an update. The update form has three steps: release details, source, and confirmation. Each update uses one release credit when we start the build.

Build failures caused by the project itself are your responsibility to fix, and resubmitting the same release does not use another credit. A store rejection also keeps the same credit.