iOS SDK third-party (in)dependence

2019-03-25 08:17:20
Blog picture

We are happy to reveal a neat update to our iOS SDK.

Previously, Voximplant iOS SDK used CocoaLumberjack for logging and  SocketRocket for transport as external dependencies. These worked well unless projects required static linking. Thus, we’ve decided to remove them as direct dependencies of our SDK.

First, the use_frameworks! Podfile attribute is no longer mandatory to use Voximplant iOS SDK. Remember, if you use this attribute, all of the dependencies distributed as source code will be compiled into dynamic frameworks; otherwise, they will be statically linked.

With the 2.20.0 version, our SDK no longer uses CocoaLumberjack. Now, the iOS SDK uses the built-in logging system.

These decisions not only simplify usage of the SDK, but also give developers the freedom to use any logger of their choice via the VILogDelegate protocol.

Enabling file logging via CocoaLumberjack

With the 2.20.0 version, the file logging functionality has been moved to a separate module. To use it, you have to do the following:

  1. Open your Podfile and change
    pod 'VoxImplantSDK'
    pod 'VoxImplantSDK/CocoaLumberjackLogger'
  2. Instead of calling saveLogToFileEnable, use the writeLogsToFile method.
Sign Up for a free Voximplant developer account or talk to our experts

Add your comment


Your comment has been added and will be published after moderation.

Recommended posts

What is a No-code Contact Center?

What is a No-code Contact Center?

If you’re involved in evaluating cloud contact center services, you’ve likely recognized two distinct categories and a big difference in the amount of technical expertise required to implement them. You’re attracted to the ease of use offered by contact center as service (CCaaS) offerings, but their fixed functionality doesn’t fit your business needs. In contrast, a cloud contact center built on a communications platform as a service (CPaaS) offering provides unlimited flexibility, but requires expensive software development resources to build a complete solution.

Where CPaaS Deploy their Networks - a Comparison

Where CPaaS Deploy their Networks - a Comparison

A couple weeks ago, Amazon Web Services (AWS) experienced an outage in its US-EAST-1 region. As so many services rely on AWS, this outage had a broader impact, causing outages and various issues with Amazon’s own Ring services, online retailers, and even the New York City MTA. In addition, a couple major Communications Platform as a Service (CPaaS) providers also reported issues (Voximplant was not impacted), potentially impacting the communications of many of their customers.  With this in mind, now is a good time to look at how CPaaS offers leverage public cloud infrastructure and review the factors involved in providing reliable, high quality communications services. In this post we will review the public cloud infrastructure used by several major CPaaS vendors and discuss the implications of their choices.