Apple iOS and Mac OS X considerations

The development environment for Apple iOS and Mac OS X is Xcode.

To reference the UltraLite header files and library it is convenient to create a user-defined build setting set to the location of the SQL Anywhere installation directory. For example, set SQLANY_ROOT to /Applications/SQLAnywhere17. To create this setting, open the project editor's Build pane and click Add User-Defined Setting and enter the name and value.

To find the UltraLite include files, add $(SQLANY_ROOT)/sdk/include to the User Header Search Paths (USER_HEADER_SEARCH_PATHS) build setting.

UltraLite for Apple iOS and/or Mac OS X does not support the following MobiLink client network protocol options:

• certificate_company
• certificate_unit
• client_port
• identity
• identity_password
• network_leave_open
• network_name

FIPS-certified encryption standards are not supported.

To use end-to-end encryption when synchronizing Apple iOS and Mac OS X UltraLite clients with a MobiLink server, you must encapsulate your public keys in a the PEM encoded X509 certificate (as opposed to a PEM public key file). To create a PEM encoded X509 certificate with an E2EE private key use the certificate creation utility, createcert.

When developing UltraLite applications for the iPhone, you must include the certificate in the Resources folder in your Xcode project. UltraLite synchronization logic searches for the certificate file in the Main Resource Bundle (mainBundle) of the iPhone development package if the trusted_certificates or e2ee_public_key options are assigned.

The Xcode debugger (GDB) has support for stepping through and breaking on longjmp() calls. Applications typically do not use longjmp, but the UltraLite runtime library does internally (sometimes, when an error is signaled, for instance). This may cause problems when tracing through application code and stepping over UltraLite calls. If you step over an UltraLite call and get an error from the debugger: Restart the program, set a breakpoint after the problematic line and, instead of stepping over the problematic line, use the Continue command - this will have the same effect because the debugger will stop at the following breakpoint, but should avoid problems related to longjmp calls. The most likely place to encounter this is when using OpenConnection to open an existing database or determine that the database doesn't exist (an error is signaled when the database doesn't exist).