Design and Implementation of an iOS Mobile Log System Using WCDB

Effective logging is crucial for diagnosing intermittent online issues, but the existing log system required users to manually export logs, suffered from poor performance, and only recorded logs in debug mode, making real‑time problem solving difficult.

The new design records three types of logs—business, network, and player—without involving crash or analytics data, and adopts an active pull strategy: the server sends a pull command containing a user uid via a long‑connection channel, the client filters logs by the specified criteria, writes them daily into separate files, compresses them, and uploads them automatically.

For ease of use, a macro‑based API mimics NSLog calls. In debug builds the macro forwards to SVLogManager , while in release it falls back to NSLog :

#if DEBUG
#define SVLogDebug(frmt, ...)   [[SVLogManager sharedInstance] mobileLogContent:(frmt), ##__VA_ARGS__]
#else
#define SVLogDebug(frmt, ...)   NSLog(frmt, ...)
#endif

Three macro definitions correspond to the three log types:

Business log: SVLogDebug

Player log: SVLogDebugPlayer

Network log: SVLogDebugQUIC

Retention is handled by two strategies: logs older than three days are deleted, and the total size is capped at 200 MB; when the threshold is reached, the oldest entries are removed.

Basic context such as network environment and configuration is also stored to aid debugging, while privacy‑sensitive data (e.g., location) is omitted.

After evaluating iOS‑side databases, WCDB was chosen over FMDB and raw SQLite because it offers superior write performance (up to 180 % faster in batch writes) and acceptable read performance, thanks to its C++ implementation and deep integration with sqlcipher.

The log table is simple, containing index (primary key), content , createTime , and type , allowing easy extension for new log categories.

Database optimization includes using WAL mode, setting an autocheckpoint threshold of 1000 pages, and periodically invoking sqlite3_wal_autocheckpoint to merge WAL files into the main database, thereby limiting disk usage. Example code:

#define SQLITE_DEFAULT_WAL_AUTOCHECKPOINT  1000
sqlite3_wal_autocheckpoint(db, SQLITE_DEFAULT_WAL_AUTOCHECKPOINT);
int sqlite3_wal_autocheckpoint(sqlite3 *db, int nFrame) {
#ifdef SQLITE_OMIT_WAL
  UNUSED_PARAMETER(db);
  UNUSED_PARAMETER(nFrame);
#else
#ifdef SQLITE_ENABLE_API_ARMOR
  if (!sqlite3SafetyCheckOk(db)) return SQLITE_MISUSE_BKPT;
#endif
  if (nFrame>0) {
    sqlite3_wal_hook(db, sqlite3WalDefaultHook, SQLITE_INT_TO_PTR(nFrame));
  } else {
    sqlite3_wal_hook(db, 0, 0);
  }
#endif
  return SQLITE_OK;
}

Security is ensured by transmitting logs over HTTPS and encrypting the compressed files with symmetric keys that are themselves delivered via asymmetric encryption. Each upload command carries a unique key; the client encrypts the zip file before chunked upload, and the server decrypts it using the provided key.

To improve retrieval success, an active reporting mechanism was added: when a user submits feedback, the client automatically uploads the last three days of logs, raising the success rate from ~40 % to ~90 %.

Manual export remains available for developers during debugging, but is disabled for regular users in production.