Our documentation is changing, please click here to enjoy it!

Skip to end of metadata
Go to start of metadata

Have a splashcreen in your app ?

Allowing a content to be displayed in your splashcreen can affect the inapp behaviour.

For this reason, a method exists to prevent the display of any Accengage content once the splashcreen is loading. Please check this page for more information (Prevent in-App message display)

4.1 Basic display

In-app messages are messages, in various formats, that your application can display while the users are browsing within your application. These messages can be targeted just like Push Notifications, can be triggered in real time based on the user behaviours and their events (see "events" paragraph") and can be displayed in specific parts of your app if need be.

Their purpose is to stimulate a certain behaviour from your users, as they are probably just a click away from this behaviour, while push notifications primary objective is to drive users back inside the app.

In-app messages can appear in various formats (banners, interstitials, native alert-box...) and be composed of simple text, or html content.

You can customize the design of their templates, and you can adapt their content remotely thanks to the Accengage dashboard.

Once a user clicks on the in-App messages, you can decide of various actions to trigger, such as redirect to a deeplink, a landing page, send an email etc...


The Accengage SDK allows the display of in-App notifications very simply.

There is no additional code to write to support in-App notifications.

There are five different default in-App notification templates : 

  • Text Banner : this in-App notification will appear as a view with a height of 50. It will contain a title and a text body. By default this banner will appear at the bottom of the page. The color of the background is black and text is white.
  • WebView Banner : this in-App notification will appear as a view with a height of 50. It will contain a webView that will display the content of a URL. By default this banner will appear at the bottom of the page. The color of the background is black by default.
  • Text Interstitial : this in-App notification will appear in full screen. It will contain a title and a text body.
  • WebView Interstitial : this in-App notification will appear in full screen. It will contain a webView that will display the content of an URL and which will be clickable.
  • WebView interstitial with NavBar : this in-App notification will appear in full screen. It will contain a webView that will display the content of a URL. It also displays a navigation bar and can be browsed.
  • Native Alertbox : this in-App notification is displayed as a native alertbox. It freezes the navigation, and contains, a title, a content, and can propose 1 to X buttons.


If you are wondering how to set up in-App campaigns, please find our tutorial about it.

4.2 Advanced display customization


In the sections below, you will see how to :

  • Customize the behavior and appearance of those in-App notifications
  • Prevent them from being displayed in irrelevant moments (such as splash screen, purchase funnel...)
  • Transmit custom parameters to your app or analytics when these in-App messages are displayed or clicked

In-app message display customization

The Accengage SDK lets you customize many aspects of the in-app messages, such as the design, format, size of the templates, their position within a view, the display animation etc...

Please read the following to craft the best experience for your users.


XIB files

The In-App Notification views are created using xib files that are provided with the SDK. The content that you will create remotely within the Accengage dashboard (Actions > In-app messages) will be displayed within these views.

You can modify those xib files (add other elements, change color, font etc...) or preferably add new xib files, as long as you keep the tag info. 

5 xib files are provided for iPhone retina 3”5 portrait :

  • text notification : BMA4SiPhoneTextNotifView
  • webView notification : BMA4SiPhoneWebViewNotifView
  • Interstitial text notification: BMA4SiPhoneIntersticialTextNotifView
  • Interstitial webView notification: BMA4SiPhoneIntersticialWebViewNotifView
  • Interstitial webView notification (with navBar) : BMA4SiPhoneIntersticialWebViewWithToolBarNotifView


These 5 files are also replicated for :

  • iPhone Landscape :
    • Landscape : with suffix -landscape
  • iPad :
    • Portrait : with suffix -iPad
    • Landscape : with suffix -landscape-iPad

To choose a custom position of an overlay In-app, add transitions animations and more, you need to set an In-app Notification data source object. Your object must adopt the `BMA4SInAppNotificationDataSource` protocol.

In-app view edition

By default the SDK loads the view from the XIB file. You can customize the loaded view programmatically.

You must not modify the subviews references and tags of the loaded view

 You can also create the inApp view programmatically. To do this you need to respect the following requirements.

 First of all, there are two types of inApp messages : TextMessage & WebMessage . You can check the type by this way :


Here is the list of the required/optional subviews of each message type :

 Required subviewsOptional subviews
  • Text label  :  UILabel  with tag BMA4SInAppOverlayViewBodyTag
  • Close button  :  UIButton  with tag BMA4SInAppOverlayViewCloseTag

  • Web view  :  UIWebView  with tag BMA4SInAppOverlayViewBodyTag
  • Close button : UIButton with tag BMA4SInAppOverlayViewCloseTag

  • Go Back Button : UIButton with tag BMA4SInAppOverlayViewBackTag

  • Go Forward Button : UIButton with tag BMA4SInAppOverlayViewForwardTag

  • Reload Button : UIButton with tag BMA4SInAppOverlayViewReloadTag

  • Stop loading Button : UIButton with tag BMA4SInAppOverlayViewStopTag

  • Open in Safari Button : UIButton with tag BMA4SInAppOverlayViewSafariTag

  • Loader : UIActivityIndicatorView with tag BMA4SInAppOverlayViewActivityTag

  • Toolbar : UIToolbar with tag BMA4SInAppOverlayViewToolbarTag

Example :

Changing the default position of an overlay in-app

By default, in-app banners are displayed at the bottom of the screen.

Each time the SDK will show an overlay In-app, your data source object will be asked to return a `BMA4SOverlayInAppPosition` option.

If your data source object returned BMA4SOverlayInAppPositionCustom option, it will be asked to return the origin point of the in-app view.

Animated transitions 

By default, the SDK applies a Fadein animation when in-app messages are displayed. You can disable the default animation for a specific in-app message or for all in-app messages by implementing this method : 

You can also apply custom transition animations by implementing the following methods :

For more details, please check the BMA4SInAppNotificationDataSource documentation. 

HTML5 video inline playback

Inline video playback is supported starting from version 6.4.1. To play a video inline, add a display custom parameter acc-inline-media to your in-app message.

Full in-app customization

Accengage dashboard and SDK allow you to create fully customized in-app notifications. This sample shows how to use the custom parameters to achieve this.

On the SDK side, you can retrieve the parameters using the above mentioned BMA4SInAppNotificationDataSource callback method BMA4SViewForInAppMessage:defaultView:

The BMA4SInAppMessage object contains the following properties:

displayCustomParameters - parameters specified on the Accengage dashboard for a specific in-app message

clickCompletionHandler - block to execute when the user clicks on your custom in-app. You can also pass the button ID as a parameter if it corresponds to your use case.

displayCompletionHandler - block to execute when your custom in-app is displayed.

dismissCompletionHandler - block to execute when your custom in-app is dismissed.

You should only use these properties if you're fully customizing the in-app display. Note that in this case the display rules such as capping and pressure are not managed by the SDK.










4.3 Handling actions

InAppNotification observers

You can be notified when the SDK displays or closes an inAppNotification or when a user clicks on it.

 You can add an observer like this :

    Custom parameters

    You can set up in-app messages in the Accengage dashboard so that custom parameters are transmitted to your application when the in-app message is displayed, or clicked.

    This can be useful if you would like to redirect the user to a deeplink, trigger a feature, or if you would like to transmit the information to your analytics.

    You can be notified when the SDK sends data, by adding an observer like this : 

      You can also use the previously mentioned inapp notification observers to extract custom parameters. 

      The custom parameters filled in Accengage Back Office will be present in the userInfo dictionary of the transmitted NSNotification object.

      Prevent in-App message display

      The Accengage SDK will display your in-app message as soon as all conditions you've specified in the Accengage dashboard are met. Therefore it can be useful sometimes to prevent the display of in-App messages, when it is irrelevant, for instance during the splash screen, if an ad is displayed, or if the user is performing a critical action.

      For this reason, the Accengage SDK provides a "Lock" option.

      Be careful always to unlock the In-App message display at the relevant time, as this is a common mistake.

      You can prevent the display of any inApp notification, by calling :

        To reenable the inApp Notifications, you can call : 

          You can enable/disable inApp notifications at any time.

          If you want to lock inapp notifications at startup (while displaying an ad, or during a splash screen for instance), set the lock before launching the SDK.

            This lock does not affect push notifications.

            To activate the locks on push notifications, follow this link : Push notifications .

            • No labels