Pre-Submission Checklist for Mobile Publisher Apps

Before You Start

Complete these preparation steps before beginning your iOS or Android submission.

• Experience Cloud site readiness: Your Experience Cloud site must be production-ready with no test pages. Test the site on mobile web to ensure all features work correctly.
• App Store account verification: Your Apple App Store Connect and Apple Developer accounts must be verified corporate or organization accounts, not personal accounts. For Android, begin Google's account verification process (identity, corporate, and website verification) as early as possible. This process can take two to three weeks and will block app release if incomplete.
• Login flow verification: Verify that your site login flow works correctly and prompts users with the OAuth Allow or Deny screen on initial login. If you use a custom login page, ensure that your custom login controller preserves the StartURL parameter provided by Salesforce. See Best Practices and Known Issues for login troubleshooting.
• User account deletion: If your app collects user data or allows user registration, you must provide an in-app method for users to delete their account or data. This capability is required by both Apple and Google. See Allow Experience Cloud App Users to Initiate Deletion of Their Data.
• Team permissions: All key team members (Salesforce Admin, App Store or Google Play Owner, Experience Cloud lead) need the "Manage mySalesforce Apps" permission enabled in your Salesforce org to receive email communications from Mobile Publisher about status updates and required actions.
• Test user credentials: Set up valid test user credentials for your Experience Cloud site. Apple and Google reviewers use these credentials to test your app. Incorrect or missing test credentials are the most common cause of app rejections.
• External Client App naming: Select a unique External Client App (ECA) name that is shown to end users at initial login. You enter this name in the Mobile Publisher setup.

Distribution Decisions

Understand your distribution options before beginning setup. There are two separate decisions: distribution method and distribution type.

Distribution Method determines who manages the submission process:

• Fully Managed: Mobile Publisher manages the entire process from build to go-live, including handling rejections. You grant Mobile Publisher access to your App Store Connect and Google Play Console accounts.
• Binary Upload (default as of Summer '25): You have more control over store listings and can manage multiple languages, but you handle the final submission steps and rejections. Mobile Publisher still requires access to your accounts. See About Distribution Methods for Branded Mobile Apps.
• Binary Handoff: You manage everything, including re-signing the app. Mobile Publisher doesn't need access to your accounts. Contact your Account Executive for details.

Distribution Type determines who can access your app:

• Public: Your app is available to everyone on the App Store or Google Play Store. Most customers should choose public distribution.
• Private: Your app is available only to specific users or organizations using enterprise device management (Apple Business Manager for iOS, Google Workspace for Android). See About Private Distribution for Branded Mobile Apps.

Important Once you publish a private app, switching to public distribution is very difficult and may require creating a completely new app with a new Bundle ID (iOS) or Package Name (Android). Choose carefully.

Mobile Publisher Workflow

Understanding the submission workflow helps you plan timelines and know when you can make changes.

• You submit to Mobile Publisher, not directly to Apple or Google. Mobile Publisher builds your app and submits it to the stores on your behalf (for Fully Managed and Binary Upload methods).
• Beta approval is required before live review. Any change you submit generates a new beta app that must be approved (within Mobile Publisher setup) before proceeding to live review.
• Beta approval doesn't guarantee live approval. Beta review is less strict than live review. Apple and Google apply more stringent requirements during live review.
• Making changes after submission. You can make changes to app metadata, URLs, and other fields after your beta is approved or after your app is live. If you need to make changes before beta approval or during live review, open a Salesforce support case to request that Mobile Publisher reject the current submission so you can update it.
• Mobile Publisher doesn't control review timelines. Build extra time into your project plan for delays and possible rejections. First-time submissions commonly receive at least one rejection for policy violations.
• Testing your app: Use the Publisher Playground app to test your Experience Cloud site login and other functions, and to capture screenshots for your app submission.

Important For Fully Managed customers: Don't make changes directly in App Store Connect or Google Play Console unless Mobile Publisher documentation specifically instructs you to do so. The Mobile Publisher setup UI is your source of truth.

iOS Pre-Submission Checklist

1. You've confirmed that your Apple App Store Connect and Apple Developer accounts have the correct permissions. See Membership details.
2. You've invited the Mobile Publisher user to your App Store Connect account and assigned the App Manager role with access to Certificates, Identifiers & Profiles. See Invite Salesforce to Your Apple Developer Account.
3. You've created a placeholder app in App Store Connect. Its name exactly matches the App Store Name entered in your Mobile Publisher project setup. A mismatch causes a rejection before the app reaches Apple review. See Create a Placeholder App in App Store Connect.
4. You've answered the data privacy questions in App Store Connect. All permissions enabled in your Mobile Publisher project (camera, microphone, and location are on by default) must be reflected in your privacy answers. See Prepare Your App's Information for iOS.
5. You've created a web-accessible privacy policy URL that is reachable from within the app. The URL must begin with https:// and can't be a PDF. The privacy policy must reference your app name or the developer entity shown in App Store Connect. See Privacy Policy Requirements for Branded Mobile Apps.
6. You've provided reviewer login credentials in App Store Connect, both under Test Information in the TestFlight tab and in the App Store tab. These credentials must be for a working Experience Cloud test user.
   

   Important Incorrect or missing test credentials are the most common cause of beta and live app rejections. If your security policy restricts Apple reviewers from accessing your production org, provide a sandbox URL and sandbox credentials.
7. You've accepted all Apple licenses and Terms & Conditions. Only the Apple Account Owner can accept these.
8. If you distribute your app in the European Union, you've provided your trader status in the Business section of App Store Connect to comply with the Digital Services Act. This became required in 2024 for new app submissions and updates.
9. You've carefully selected the countries where your app is available. Don't select "All Countries" unless you have an ICP filing number for mainland China. Apple requires this filing for distribution in China.
10. If you're enabling iPad support, understand that this decision is permanent and can't be reversed. Once you build and submit an app with iPad support enabled, you can't disable it in future versions.
11. You've entered a unique External Client App (ECA) name in Mobile Publisher setup. This name is displayed to end users at initial login. See Create an External Client App to Connect Your App.

iOS Common Rejection Reasons

Understanding Apple's most common rejection reasons helps you avoid delays. See Common Reasons Why Apple Rejects Apps for details.

• Guideline 2.1 - App Completeness: Apple rejects apps with incorrect login credentials, test pages visible in the app, or incomplete functionality. Ensure your test credentials work and your Experience Cloud site is production-ready.
• Guideline 2.3 - Accurate Metadata: Screenshots must show the app in use, not just the login screen or splash screen. App descriptions and screenshots must accurately reflect the current version.
• Guideline 4.2 - Minimum Functionality: Apple expects mobile apps to offer more than what's available on mobile web. Consider adding native features like biometric login, push notifications, or a bottom tab bar for navigation to differentiate your app.
• Guideline 5.1.1 (v) - Data Collection and Storage: If users can register or you collect user data, you must provide an in-app method for account deletion. See Allow Experience Cloud App Users to Initiate Deletion of Their Data. This guideline also covers privacy requirements when sharing collected data with third parties. If your app tracks users or shares data with third parties, enable App Tracking Transparency by configuring User Tracking in the Mobile Publisher setup UI.

Android Pre-Submission Checklist

1. You've completed Google's account verification process (identity, corporate, and website verification). This process can take two to three weeks, so begin it as early as possible. Incomplete verification blocks app release.
2. You've completed Google's government ID verification for your Google Play Console account. This is a mandatory requirement that blocks your app from releasing if not completed.
3. You've confirmed that your Google Play Console account has the correct permissions. Account Owner permission is required for certain actions.
4. You've invited the Mobile Publisher user to your Google Play Console account and granted the Service Account User role. See Grant Permission to Distribute Your Branded App.
5. You've created a placeholder app in Google Play Console. Its name exactly matches the app name entered in your Mobile Publisher project setup. See Create a Placeholder App in Google Play Console.
6. You've answered all declarations in the App Content section, including Data Safety questions. For baseline answers, see Google Data Safety - Experience Cloud App. Your answers must match the permissions enabled in your Mobile Publisher project and the statements in your privacy policy.
7. You've created a web-accessible privacy policy that is reachable from within the app. The policy must include an app-specific section that references each permission your app requests (camera, microphone, and location are enabled by default) and names the app or developer entity listed in Google Play. See Privacy Policy Requirements for Branded Mobile Apps.
8. You've provided reviewer login credentials underApp Content | App Access and kept them current.
   

   Note Google regularly re-reviews published apps and validates credentials. Missing or stale credentials can result in app removal from the Play Store.
9. All beta tester email addresses are Gmail or Google Workspace addresses. Google doesn't accept other address types for beta testing.
10. You've accepted the Google Terms of Service in Google Play Console.
11. You've entered the correct Google Play Developer Account ID in Mobile Publisher setup. This ID must exactly match your account ID. To find it, go to Account Details in Google Play Console.
12. You've entered a unique External Client App (ECA) name in Mobile Publisher setup. This name is displayed to end users at initial login. See Create an External Client App to Connect Your App.
13. If you're using private distribution, you have a Google Workspace (G-Suite) account with your organization domain, and all app users are part of that organization. Private distribution does not provide a beta app unless you use Google Workspace.
14. You've created a draft release in Google Play Console under the Production track.

Google Play Policy Notes

• Data Safety questions: Answer these questions accurately. Your answers must match the permissions enabled in your Mobile Publisher project and the statements in your privacy policy. Any inconsistencies can result in rejection or app removal.
• Advertising ID and Government app questions: Only answer "Yes" if these categories actually apply to your app. Most customers should answer "No" to both. Advertising ID applies only if you display ads in your app. Government app applies only if the app is for use by a government body (national, state, city, or local).
• Reviewer credentials: Google regularly re-reviews published apps and validates that login credentials still work. Keep your test user credentials current to prevent app removal from the Play Store.