Skip to main content
After exporting your iOS application from AIWA, you may choose to distribute it through Apple’s App Store. AIWA currently helps you build and export the iOS application, but App Store submission is handled separately through your own Apple Developer account. AIWA builds the app. You manage App Store distribution through Apple.
AIWA does not currently submit applications to the App Store on your behalf.

​
Where AIWA Stops

The current AIWA iOS workflow takes you through:
From that point onward, Apple’s developer and App Store processes happen outside AIWA. Conceptually:
Apple controls the requirements and approval process for App Store distribution.

​
You’ll Need an Apple Developer Account

To distribute an app through the App Store, you’ll need your own Apple Developer account. Apple manages developer enrollment separately from AIWA. For agencies, decide early who should own the application. For example:
For a client-owned product, publishing through the client’s developer account can make long-term ownership clearer.

​
App Store Information

AIWA doesn’t need all of your App Store listing information in order to build the iOS app. Apple may ask for additional information during the distribution process. This can include things such as:
  • App name
  • App icon
  • App description
  • Screenshots
  • App category
  • Support information
  • Privacy information
  • Age rating
  • Data-use information
  • Content declarations
These belong to the App Store publishing process rather than the AIWA build process.

​
App Icon and Store Assets

You’ll typically need polished visual assets for your store listing. These may include:
  • App icon
  • iPhone screenshots
  • Other store imagery Apple currently requires
Prepare assets that accurately represent the product. For example, a CRM app might show:
  • Dashboard
  • Leads
  • Deal pipeline
  • Customer details
  • Mobile navigation
A booking app might show:
  • Services
  • Booking flow
  • Customer dashboard
  • Upcoming appointments
Avoid using screenshots containing real private customer data.

​
App Description

Your listing should explain the product from the user’s perspective. For example:
Acme Client Portal gives customers one place to track projects, access files, review deliverables, communicate with their team, and monitor progress from their iPhone.
A useful description answers:
  • What is the app?
  • Who is it for?
  • What can they accomplish with it?
You don’t need to explain the underlying AIWA architecture to App Store users.

​
Privacy Policy

If your application collects or processes user information, Apple may require appropriate privacy disclosures and a privacy policy. This can become relevant when your app uses:
  • User accounts
  • Customer information
  • Files
  • Images
  • Payments
  • Location
  • Analytics
  • External integrations
Your privacy policy should reflect what the application actually does.
Don’t use a generic privacy policy that doesn’t match your application’s actual data collection and processing.

​
App Privacy Information

Apple may ask you to disclose how the application handles data. Depending on your product, this could involve information such as:
  • Contact information
  • Account details
  • User content
  • Purchases
  • Files
  • Identifiers
  • Usage data
  • Other application activity
Your disclosures should reflect the actual application and any external services it uses. For example:
Understanding your application’s data flow helps make these disclosures more accurate.

​
Device Permissions

Some apps may need access to device capabilities. Examples include:
  • Camera
  • Photos
  • Microphone
  • Files
  • Notifications
  • Location
Only request permissions the application genuinely needs. For example, a profile-photo feature may need access to photos or camera functionality. A simple dashboard app probably shouldn’t request location access unless there’s a clear product reason.

​
Explain Why Permissions Are Needed

Apple may require applications to clearly explain why certain permissions are requested. For example:
Camera access is used to upload profile photos.
or:
Photo-library access is used to attach images to property listings.
The permission should make sense in the context of the feature.

​
Payments Require Extra Attention

If your app sells:
  • Digital subscriptions
  • Digital content
  • In-app functionality
  • Other digital goods
Apple may have specific payment requirements. This can differ from selling:
  • Physical products
  • Real-world services
  • Certain external services
A Stripe payment flow that works perfectly on the web may not automatically satisfy App Store rules for every type of purchase.
Before submission, review Apple’s current payment requirements for your exact business model.

​
Test Before Distribution

Before beginning App Store submission, test the exported iOS application thoroughly. Check:
  • App launches
  • Authentication
  • Navigation
  • Forms
  • Database functionality
  • Uploads
  • Integrations
  • External links
  • Mobile layouts
  • Critical workflows
  • Error states
App Store review shouldn’t be your first real QA session.

​
Test Important User Journeys

For a SaaS app:
For a booking app:
For a client portal:
The complete customer journey should work.

​
Apple’s Review Process

Apple reviews submitted apps according to its own current guidelines and requirements. Review may involve areas such as:
  • Application functionality
  • Privacy
  • Data handling
  • Permissions
  • Payments
  • Store metadata
  • Content
  • User experience
AIWA doesn’t control Apple’s approval decision.
App Store requirements can change. Check Apple’s current developer guidance when you’re ready to submit.

​
If Apple Rejects the App

A rejection doesn’t necessarily mean the entire product needs to be rebuilt. First understand the reason. For example:
Missing privacy information
is different from:
App crashes when users sign in.
If Apple identifies a product issue, return to AIWA and address that specific problem. For example:
During App Store review, the app crashes when a signed-out user opens the Account screen. Debug this flow without changing the rest of the mobile app.
Then:

​
Updating the App Later

Your application will likely continue evolving after release. For example:
AIWA remains the product-development environment while Apple manages store distribution.

​
For Agencies

If you’re building iOS apps for clients, clarify responsibilities before launch. Decide:
  • Who owns the Apple Developer account?
  • Who owns the app?
  • Who prepares store assets?
  • Who manages privacy disclosures?
  • Who responds to Apple review questions?
  • Who publishes updates?
  • Who maintains the app?
This avoids confusion later.

​
AIWA’s Role

A simple way to understand the current boundary is: AIWA handles
  • Building the application
  • Mobile readiness
  • iOS build generation
  • Mobile source export
You handle outside AIWA
  • Apple Developer account
  • Store listing
  • Screenshots and listing assets
  • Privacy disclosures
  • App Store submission
  • Apple review
  • Public release
This makes the workflow clear.

​
Before You Begin App Store Submission

Prepare:
  • A tested iOS build
  • Apple Developer account
  • App name
  • App icon
  • Description
  • Screenshots
  • Privacy policy where required
  • App privacy information
  • Required permission explanations
  • Appropriate payment model
  • Support information
Then follow Apple’s current submission process.

​
The Complete iOS Journey

Today, the complete flow looks like:
AIWA handles the product-building and export side. Apple handles distribution.

Inviting Team Members

Invite collaborators to your AIWA workspace.