Skip to main content
After exporting your Android application from AIWA, you may choose to distribute it through Google Play. AIWA currently helps you build and export the Android application, but Google Play submission is handled separately through your own Google Play Developer account. AIWA builds the app. You manage the store submission through Google Play.
AIWA does not currently submit applications to Google Play on your behalf.

​
Where AIWA Stops

The AIWA mobile workflow currently takes you through:
From that point onward, distribution through Google Play takes place outside AIWA. Conceptually:
Google controls the requirements and approval process for apps distributed through Google Play.

​
You’ll Need a Google Play Developer Account

To distribute an application through Google Play, you’ll generally need your own Google Play Developer account. For agencies, this raises an important ownership decision. If the application belongs to a client, consider whether the app should be published through:
  • Your agency’s developer account
  • The client’s own developer account
For long-term client ownership, using the client’s account may often make more sense. For example:
This keeps the store listing and future ownership associated with the client.

​
Google May Require Additional App Information

AIWA doesn’t need all of your store-listing information to generate the mobile app. Google Play, however, may ask for additional information before an application can be distributed. This may include things such as:
  • Application name
  • App icon
  • Short description
  • Full description
  • Screenshots
  • App category
  • Contact information
  • Privacy policy
  • Content declarations
  • Data-handling information
  • Age or audience information
These requirements belong to the store publishing process, not the AIWA build process.

​
App Icon and Store Graphics

Your exported application may eventually need visual assets for its Google Play listing. These can include an app icon and store screenshots. The store may also require other promotional or listing assets depending on current requirements. These assets are typically prepared after the app itself is built and tested. A practical workflow is:

​
Screenshots

Google Play may ask you to provide screenshots showing what your application looks like. Choose screenshots that demonstrate the most important parts of the product. For example, a CRM might show:
  • Dashboard
  • Leads
  • Deal pipeline
  • Customer detail
  • Mobile navigation
A booking app might show:
  • Service selection
  • Appointment booking
  • Customer dashboard
  • Upcoming appointments
Don’t use screenshots containing private customer data.

​
App Description

Your store listing will usually need to explain what the application does. A useful description should answer:
  • What is the app?
  • Who is it for?
  • What can users do with it?
For example:
Acme Client Portal helps customers track projects, access files, review deliverables, communicate with their account manager, and monitor project progress from one mobile app.
Avoid filling the listing with technical implementation details users don’t need.

​
Privacy Policy

If your application collects or processes user information, Google may require a privacy policy. That can become especially relevant when your app uses:
  • User accounts
  • Customer information
  • Payments
  • Location
  • Files
  • Camera or media
  • Contacts
  • Analytics
  • External services
Your privacy policy should accurately describe what your application actually does.
Don’t copy a generic privacy policy that doesn’t match your application. Your disclosures should reflect the data your product actually collects and uses.

​
Data Safety

Google may ask you to disclose how your application handles user data. Depending on your product, that could involve information such as:
  • Account details
  • Personal information
  • Payment-related data
  • Uploaded files
  • User-generated content
  • Application activity
This is one reason to understand your application’s data model and integrations before publishing. For example:
Your disclosures may need to account for the services involved in your application.

​
Permissions

Some Android apps require access to device capabilities. Examples may include:
  • Camera
  • Photos
  • Files
  • Notifications
  • Microphone
  • Location
If your application requests device permissions, make sure they are genuinely needed for the feature. A useful rule is:
Request only the permissions your application actually needs.
Users may be uncomfortable with an app requesting access that doesn’t make sense for its purpose.

​
Payments

Applications distributed through Google Play may be subject to specific payment rules depending on what the app sells. For example, there can be an important distinction between:
  • Physical goods
  • Real-world services
  • Digital products
  • Digital subscriptions
  • In-app features
If your AIWA application uses Stripe or another external payment workflow, don’t assume that the same implementation can automatically be used for every type of Play Store application.
Review Google’s current payment requirements before submitting an app that sells digital products, subscriptions, or in-app functionality.

​
Test the Exported App First

Before creating your store listing, test the exported Android application thoroughly. Check:
  • Installation
  • App launch
  • Authentication
  • Navigation
  • Forms
  • Database functionality
  • Uploads
  • Integrations
  • External links
  • Mobile layouts
  • Important user workflows
You want store submission to be the distribution step, not the first time you seriously test the application.

​
Testing Releases

Google Play may offer different ways to test an application before making it publicly available. This can be useful for distributing the app to:
  • Your team
  • QA testers
  • Selected customers
  • Beta users
A sensible release path is:
The exact testing and release options are managed inside Google Play.

​
Google Controls App Approval

AIWA doesn’t control whether Google approves an application. Google reviews applications according to its own requirements and policies. An app may need changes before approval. For example, Google may raise issues related to:
  • Privacy
  • Permissions
  • Store listing information
  • App functionality
  • Payments
  • Content
  • Data handling
  • Developer-account requirements
Google’s policies and submission requirements can change over time. Always check the current Play Console guidance before submitting.

​
If Google Rejects the App

A rejection doesn’t necessarily mean you need to rebuild the entire application. First understand the reason. For example, if the issue is:
Missing privacy disclosure
that’s different from:
The application crashes during startup.
If Google identifies an application issue, return to AIWA and fix the specific problem. For example:
Google Play testing found that the application crashes when a signed-out user opens the Profile screen. Debug that flow without changing the rest of the mobile application.
Then generate and test a new Android build.

​
Updating an App Later

Mobile applications continue evolving after release. Your workflow may become:
You manage the Google Play release process externally while AIWA remains your development environment.

​
For Agencies

If you’re delivering Android applications to clients, decide responsibilities before launch. Clarify:
  • Who owns the Google Play Developer account?
  • Who prepares store assets?
  • Who writes the listing?
  • Who manages the privacy policy?
  • Who handles Google review feedback?
  • Who publishes future updates?
  • Who provides customer support?
This avoids ownership confusion after the app is live.

​
AIWA’s Role

A useful way to understand the current workflow is: AIWA handles
  • Building the application
  • Mobile readiness
  • Android build generation
  • Android source export
You handle outside AIWA
  • Google Play Developer account
  • Store listing
  • Store assets
  • Policy declarations
  • Submission
  • Google review
  • Public release
This keeps the responsibility clear.

​
Before You Begin Google Play Publishing

Once your Android app has been exported, prepare:
  • A tested Android build
  • Google Play Developer account
  • App name
  • App icon
  • Store description
  • Screenshots
  • Privacy policy where required
  • Appropriate data disclosures
  • Required permissions information
  • Appropriate payment model
  • Support/contact information
Then follow Google’s current Play Console process.

​
The Complete Android Journey

Today, the AIWA-to-Google-Play journey looks like:
AIWA handles the product-building and Android-export portion. Google Play handles distribution and approval.

​
Next: Export for iOS [Agency]

Next, we’ll return to functionality available inside AIWA and cover Export for iOS. The flow is similar to Android:
  • Mobile Readiness
  • Build iOS files or download source
  • Export
We’ll also explain why you’ll need your own Apple Developer account when you’re ready to take the exported application toward App Store distribution.

Export for iOS

Export your AIWA project toward iOS distribution.