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/SQLAnywhere12. To create this setting, open the project editor's Build pane and click Add User-Defined Setting and enter the name and value.
To use end-to-end encryption when synchronizing Mac OS X and iPhone UltraLite clients with a MobiLink server, you must encapsulate
your public keys in a PEM encoded X509 certificate (as opposed to a PEM public key file) and supply an E2EE private key. To
create a PEM encoded X509 certificate with an E2EE private key, it is recommended that you use the certificate creation utility,
createcert. After you obtain an E2EE private key, specify the -x option when you start the MobiLink server and assign the
key to the e2ee_private_key option. To synchronize the UltraLite client database with the MobiLink server, run the UltraLite
synchronization utility, ulsync, and assign the E2EE public key to the e2ee_public_key connection option. Extracting the public
key from the certificate is necessary when using both iPhone and non-iPhone clients together. When developing for iPhone UltraLite
clients, the UltraLite Synchronization utility searches for the certificate file in the Main Resource Bundle (mainBundle)
of the iPhone development package if the trusted_certificate or e2ee_public_key options are assigned. You must include the
certificate in the Resources folder in your Xcode project.
The following encryption standards are not supported:
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).