Mobile Publisher for Experience Cloud FAQ

The Publisher Playground app is available to do preliminary testing for your Experience Cloud app. To learn more, see Preview Your Mobile Experience Cloud Site with Publisher Playground (Beta).

The Playground app supports most of the features and functionality of the fully branded Mobile Publisher for Experience Cloud app. You can ensure the in-app experience of your mobile Experience Cloud sites is up to your standards before making any purchasing decisions.

• Persistent login
• Face ID / Touch ID
• Push notifications
• Upload a file
• Download a file
• Share a file

To learn more, see Preview Your Mobile Experience Cloud Site with Publisher Playground (Beta).

Make sure that you have an active Experience Cloud site and an External Client app (ECA) installed in your production org. Typically, you log into the production org first, and then you switch over to your sandbox org to make sure that you have matched licenses in production and sandbox orgs. To learn more, see Match production and sandbox licenses without a sandbox refresh.

To make sure that Switch Experience Cloud Site option is available, make sure that the the Sandbox Site field in your Mobile Publisher UI Setup page contains your sandbox URL.

If you want to remove the Switch Experience Cloud Site option from the context menu, leave the Sandbox Site field blank.

First, always test access to files and images in your Experience Cloud site within a mobile web browser on a supported mobile device. It’s also important that you’re logged in correctly to your branded Experience Cloud app or the Publisher Playground app to test opening files. If you’re logged in correctly to your branded Experience Cloud app or Publisher Playground app, you’re prompted with an OAuth session Allow/Deny dialog. If you don’t see this prompt, you’re likely logged into the mobile browser webview, and sometimes functions such as files, push notifications, and linking behavior don’t work as expected. Make sure that you’re logged into your branded Experience Cloud app or Publisher Playground app, and check with your internal team to set up the login flow.

Make sure that your org has push notifications and notification types set up correctly. Salesforce suggests starting with a basic test such as using @mentions from Chatter. Keep in mind that the end users must be logged in correctly. And to receive push notifications, they must tap Allow when they see the Deny or Allow prompt. The end user’s mobile device must also be registered to receive push notifications. You can verify if a mobile device is registered under the User Details page in Setup.

There isn’t a specific time frame for receiving a beta version of your app. Salesforce has no control over the time that it takes Apple or Google to review and approve your beta app submission. Many factors can affect when you receive the beta version of your app, such as your line in the app submission approval queue. Salesforce monitors the approval process for customers and informs them when there are issues with the app and provides next steps. Plan at least 1 week from submitting your beta app for approval to receiving a response.

Customers can often be surprised when their existing beta app is canceled. Whenever you or Salesforce changes your app in Mobile Publisher, you must resubmit a request for a new version of your beta app.

The screenshots must show your branded app in use to meet Apple’s app approval criteria. Apple can reject your app for images that aren’t related to the app, blurry images, or images that aren’t the correct size.

The screenshots must show your branded app in use to meet Apple’s app approval criteria. Apple can reject your app for images that aren’t related to the app, blurry images, or images that aren’t the correct size.

Beta testers are individual testers that you select to test the beta version of your app. For testing on Android, make sure that the email addresses of your beta testers have Gmail or G-Suite email addresses, or your app can be rejected.

Mobile Publisher regularly releases new versions of your branded app to keep it up to date. To receive these updates, your login credentials must remain valid so Apple can log in and approve the updated version of your branded app.

If your app is rejected due to login issues, update your login credentials in the App Store or provide them to the Mobile Publisher team via email.

Don't use temporary login credentials that are set to expire. If you must change your login credentials, notify your Mobile Publisher team.

If intermediate authentication URLs, such as MFA verification pages or external identity provider (IdP) pages, aren't configured in URL Management, they now automatically open within the login screen on both Android and iOS. You don't need to add these URLs to your URL Management configuration. For example, an MFA URL like https://login.salesforce.com/id/apex/MFAVerification or a SAML IdP URL like https://sso.company.com/auth/saml/login loads within the login flow automatically. For more information, see Manage How URLs Open from Your App.

Android previously validated only the domain when determining whether a URL was an Experience Cloud site URL. This caused links to other sites on the same domain to be incorrectly opened within the app. Android now validates both the domain and the specific Experience Cloud site path, matching iOS behavior. To configure how these external links open, add them to the appropriate URL Management field in Setup for Mobile Publisher. See Manage How URLs Open from Your App.

Mobile Publisher for Experience Cloud doesn’t support advanced deep linking authentication. For example, a logged-in user taps on a link and is automatically authenticated to another site or portal. Mobile Publisher doesn’t support this example along with any other type of biometric encryption to achieve advanced deep linking authentication.

Mobile Publisher supports biometric login encryption.

You can temporarily remove an app from sale or permanently decommission an app that is no longer being used from the app stores. For more information, see De-list or Remove Apps from App Stores.

To transfer your app for Apple, see App transfer overview and Initiate an app transfer.

To transfer your app for Google, see Transfer apps to a different developer account.

To submit and distribute your branded app, Mobile Publisher needs certain pieces of information from your Apple or Google developer accounts.

For Apple, see Record Your Apple Developer Team Account.

For Google, see Create Service Account User and Find Your Google Play Developer ID.

See Grant Permission to Distribute Your Branded App.