LEMON Manuals: Even more car manuals for everyone: 1960-2025
Home >> Mercedes Benz >> 2024 >> Sprinter 3500XD Van Cargo Extended, RWD >> Repair and Diagnosis (Single Page) >> TMC Recommended Practices >> Onboard Vehicle Electronics >> RP 1227 - Mobile Device Communication API >> RP 1227 - Mobile Device Communication API >> 26. Non-Windows Cross Platform Addendum >> 26.2 IOS™
April 5, 2026: LEMON Manuals is launched! Read the announcement.

26.2 IOS™

Since iOS™ is a case-sensitive system like UNIX™, all RP 1210 files (main INI, vendor INI, and Library files), along with directory names, will be in all lower case letters. The DOS FAT file naming convention will also apply (file names with eight characters in front of the period and three characters after the period).

Due to the sandboxed nature of applications on iOS™ and the complexities surrounding version management and application testing, it will not be the responsibilities of the VDA vendor to create an install for the RP 1210 files, only to provide a static library that can be linked as part of the application at compile time.

  1. 26.2.1. Accounts, Groups, Files, and Permissions 

    Because the driver and related INI files are distributed with and installed by the application and are not shared between applications, it is the responsibility of the application to package the files for delivery. Any INI files used by the driver shall be placed in the root application storage path for iOS™ and Android™.

    One INI that corresponds to the file normally referenced in RP121032.ini  should be used for determining device capabilities. Internally used INI files should be named, vendorname_xyz,  where xyz are unique names, to avoid file conflicts.

  2. 26.2.2. System APIs 
    • Since there is no common "MessageBox"  function in iOS™, all error text from the VDA library or application executable should be sent to the standard iOS™ log functions. These logs can be viewed in the development environment such as using console.app when connected to a Mac for debugging.
    • There is not a need for user environment variables at this point.
  3. 26.2.3. API Changes 
    • The most notable of the changes are that the Windows™ call GetPrivateProfileString ()  is not present on an iOS™ device, meaning INI file processing routines must be written.
    • On iOS the vendor provides a static library including the standard RP1210 header file and a file which the application can link at compile time.
    • Instead of CR/LF (ASCII 0x0D/0x0A) line endings which are seen on DOS/Windows™, the line ending character for INI files will be a single LF character (ASCII 0x0A) commonly called a "newline" character.
    • RP1210 INI section names and variable names are not case sensitive. Application RP1210 INI file parsing can take care of this, just like the Windows™ call GetPrivateProfileString ()  did.
  4. 26.2.4. RP1210 Static Library Files 

    Where Windows had Dynamic Link Libraries (DLL files), it is recommended that the vendor use static library which contain executable code. The vendor should provide a header file and binary a file for application developers to use.

    To include a library in an application add the master header file directive in the application code as follows:

    Fig 1: Software Code
    G13956551
  5. 26.2.5. RP1210 Includes, Type Definitions, and Function Declarations For iOS™ 

    For iOS™, the vendor shall provide a static library file including the standard RP1210 header file which the application can link at compile time. Dynamic linking is not allowed for security reasons.

    Function pointers should be used in the code to refer to the RP 1210 calls. Then the function pointers can be set to the unique static name for each vendor's product API using the VENDRX unique name as described in Section 6.2, API File Naming Conventions.  This allows the vendor's product API to be chosen at runtime based on the selected device.

    Typedef's for function pointers:

    Fig 2: Software Code
    G14784463

    Global function pointers:

    Fig 3: Software Code
    G14784464

    The following code block is a generic function to assign function pointers for Vendor X's API. It replaces the LoadLibrary ()  and GetProcAddress ()  calls that are used for systems that support dynamic loading, and is required to initialize the function pointers to the correct vendor APIs on mobile platforms where static libraries are required. To facilitate assignment when multiple vendor libraries are linked to an application, this function might contain a switch statement such as switch (VNDRX.  In RP 1210D, Unix, Linux And Unix Variants it is required that driver file names shall be lower case. In keeping with that approach, the unique name prefix shall be lower case as well.

    Fig 4: Software Code
    G14784465

    To allow multiple vendor and product libraries to be linked together under one application, all symbols except for stdc++  library symbols will be name-spaced or prepended with a vendor specific name to prevent symbol collisions. The following names anywhere in the symbol name will be reserved:

    Reserved names for vendors include any combination of upper and lower case of that vendor's name:

    Vndrx 

    Vndrx 

    VNDRX 

    Reserved names for products prepended to API calls:

    vndrx_ 

  6. 26.2.6. Linking under iOS™ 

    For vendor drivers, a single static library will be provided and linked:

    Iibvendor_rp1210.a 

    In addition the OS X/iOS standard C++ library must be linked as well:

    libc++.t 

  7. 26.2.7. Single Application - Multiple Connections 

    Due to the sandboxed nature of applications on iOS™ and tight constraints imposed by Apple on loading of dynamic libraries, RP 1210 drivers will not be shared across applications and will only support the SA/MC operation defined in Section 26.2.  A static library will be created to facilitate this. In other words, the first application to gain access to the device shall have exclusive rights to open multiple client connections. If other applications subsequently try to load RP 1210 and attempt to access the device, they shall fail with an "ERR_DEVICE_IN_USE  " error code. It is anticipated that in standard use cases, a single application would make more than one client connection with different protocols in order to send/receive data on multiple buses. MA/MC Multiple Applications/Multiple Connections shall not be considered here as part of this addendum.

  8. 26.2.8. Limited Pass-Thru Mode 

    On resource constrained platforms and devices, an application developer should not expect to create applications that process all messages, from all protocols, 100 percent of the time. The developers should design their applications with filters enabled, in order to get satisfactory performance. This is especially true over Bluetooth connected devices.