<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not remove this line. File tag: apple_notif_conf-APV-20200124. -->

<apple_notifier_conf>

   <!-- Optional. Minimum delay between successive mobile push
        notifications for the same app/device pair. Each app/device
        pair is subject to constraints on the pace mobile push
        notifications may be sent to it. For this reason, a minimum
        delay is set and may be altered with this parameter. Lowering
        it too much, and subsequently sending notifications with a high
        frequency, may cause Apple's Push Notification Service ("APNs")
        to close the connection and ban (temporarily or permanently) any
        successive notification.
        Mobile push notifications fired by a trigger are not subject to
        this limit and may be sent at higher pace.
        Default: 1000 (1 sec) -->
   <!--
   <min_send_delay_millis>1000</min_send_delay_millis>
   -->

   <!-- Optional. Maximum number of concurrent connections to APNS
        services. The connection pool starts with 1 connection and grows
        automatically as the load increases. In case the expected load is
        very high, increasing the pool maximum size my be beneficial.
        For apps with development service level, this parameter is ignored.
        Default: 1 -->
   <!--
   <max_concurrent_connections>10</max_concurrent_connections>
   -->

   <!-- Optional. Timeout for connecting to APNS services. In case of slow
        outgoing connectivity, increasing the timeout may be beneficial.
        Default: 30000 (30 sec) -->
   <!--
   <connection_timeout>30000</connection_timeout>
   -->

   <!-- Optional and cumulative.
        Configuration of a specific app that should receive mobile push
        notifications. As per documentation, each app has a specific
        app ID which corresponds to the bundle ID of the app's binary.
        Each <app> block configures an app corresponding to the "id"
        attribute.
        Note that for web apps (i.e. targeting Safari push notification) the
        ID must begin with "web.", e.g.: "web.com.mydomain.myapp". -->
   <!--
   <app id="com.mydomain.myapp">
   -->

      <!-- Mandatory. Specifies the intended service level for the
           current app ID, must be one of: test, development, production.
           If set to "test", notification will be logged only and no
           connection will be established with Apple's servers.
           The corresponding logger is LightstreamerLogger.mpn.apple,
           notifications are logged at INFO level (see lightstreamer_log_conf.xml).
           If set to "development" or "production", notifications will
           be sent to, respectively, Apple's development or
           production servers. In this case the following two parameters
           become mandatory.
           Note that for web apps (i.e. targeting Safari push notification)
           the "development" service level should not be used, as there is no
           corresponding "development" client environment that can receive
           notifications. Use either "prodution" or "test". -->
      <service_level>test</service_level>

      <!-- Optional. File path of the keystore with Apple's
           certificate for the current app ID. Must be set if
           the service level is "development" or "production".
           The file path is relative to the directory that contains this
           configuration file. -->
      <!--
      <keystore_file>my_app_keystore.p12</keystore_file>
      -->

      <!-- Optional. Password of the keystore with Apple's
           certificate for the current app ID. Must be set if
           the service level is "development" or "production". -->
      <!--
      <keystore_password>mypassword</keystore_password>
      -->

      <!-- Optional. File path of the push package zip file. This file contains
           a descriptor of the web app (i.e. targeting Safari push notification),
           and is mandatory only for web apps (ignore in other cases). See
           the General Concepts document for more information on how to produce
           this file. -->
      <!--
      <push_package_file>pushPackage.zip</push_package_file>
      -->

      <!-- Optional. Specifies the list of trigger expressions that will be
           accepted. Each <accept> element is a Java-compatible regular expression
           (see java.util.regex.Pattern): triggers requested via client APIs will
           be compared with each regular expression, and accepted only if there
           is at least one match.
           Remember that the MPN Module supports, as trigger, any Java boolean
           expression, including use of JDK classes and methods, with the addition
           of field references syntax (see the iOS Client SDK for more information).
           Hence, this check is a safety measure required to avoid that clients
           can request triggers potentially dangerous for the Server, as each
           trigger may contain arbitrary Java code.
           If left commented out or empty, no triggers will be accepted.
           Please note that using an "accept all" regular expression like .*
           is possible, but still leaves the Server exposed to the danger of
           maliciously crafted triggers. Anyway, the Metadata Adapter has a second
           chance to check for trigger allowance.
           The example shown below is for a typical notification on threshold,
           where a field is compared against a numeric constant.
           Note: submitted trigger expressions are compared with this list of
           regular expressions after their named-arguments have been converted
           to indexed-arguments. Always specify fields with the "$[digits]" format,
           not the "${name}" format. -->
      <!--
      <trigger_expressions>
         <accept>Double\.parseDouble\(\$\[\d+\]\) [&lt;&gt;] [+-]?(\d*\.)?\d+</accept>
      </trigger_expressions>
      -->

   <!--
   </app>
   -->

</apple_notifier_conf>
