Voice over IP is a way of having phone calls via the Internet or local computer network. Calls on Face Time, Skype, WhatsApp, Messenger, or Telegram are VoIP calls. But these services are locked to itself. You can’t call somebody on WhatsApp from Skype.

Luckily, VoIP is not limited to locked services. The technology is open and widely used in combination with traditional phone services. If you want to call somebody on a regular phone number, you can make it using VoIP. Similarly, you can answer regular phone calls with VoIP.

VoIP is supported by hardware IP phones or apps. The apps exist for all platforms: iOS, Android, Mac, Windows. These apps are often called softphones. You can talk either using the built-in microphone and speaker or connect a headset. …

Earlier this week, Telephone turned 10. On December 17, 2008, I released the first version 0.8 to the public. It was on Google Code — a go-to place for hosting and publishing opensource projects.

Since then, it’s come a long way. The source code repository has been migrated two times: from SVN to Mercurial to git. The project hosting has moved from Google Code to GitHub. The distribution — from Google Code to the Mac App Store.

My original goal for Telephone was to have a streamlined softphone that would be a native citizen on the Mac. As someone who wanted to use VoIP and loved Mac, I struggled with other apps being clunky and feeling foreign on the platform. …

It’s been quite some time since the last release and I’m glad to present Telephone 1.4 to you.

Dark Mode

Dark Mode is a feature of macOS Mojave and Telephone now fully supports it.

Same as system

Historically, Telephone has been using built-in devices for playing and capturing audio unless a specific device is selected in preferences. This had been the expected behavior of Mac apps in the past and it changed over time. Now we expect an app to use the same audio devices that are currently selected in the system.

Telephone 1.3 has been released and I’m thrilled to tell you about this update.

Call history

The long-awaited call history is finally here!

It conveniently looks up names in your macOS Contacts, just as one of the app’s favorite features — contacts autocompletion — already does.

Press Tab to switch the keyboard focus between the text field and the history. Press Return to make a call. Press Delete to remove the call from the history.

With call history, it finally became possible to automatically close call windows reducing window clutter.

In the free version, only the last three calls are visible. However, the last thousand calls are saved and revealed after purchasing Telephone Pro. …

Over a year ago I stopped using NSNotifications and KVO in favor of a plain old observer pattern. Here’s what I have to say after using it for a year.

Not going back

I never regretted making this decision during this year. My APIs became more obvious and testable. I forgot about the huge decoupling of NSNotifications. I never suffer from the inconvenient KVO API and crashes because I forgot to remove a KVO observer.

Naming and roles

One can say that using the observer pattern is the same as a wide-spread delegation in iOS and Mac development world. …

After writing in Swift for about a year almost exclusively, I sometimes forget how concise it is compared to Objective-C. Especially when you use similar safety features like nullability and designated initializer declarations.

Take a look at this example of an app receipt validation. It’s a simple decorator implementing one of the steps in the validation process and its goal is to verify the receipt’s attributes.

ReceiptAttributesValidation is an immutable object that doesn’t use nil. It doesn’t have accessors to protect its internals and avoid the Law of Demeter violations. …

The refactoring in the previous article stopped at breaking down a big public method into several smaller and private ones. While the violation of the single responsibility principle on the function level was reduced, the violation on the object level stayed the same. This is a code smell that can be called Too Many Private Methods.

The fact that an object does too many things is often not obvious right away. That’s where the Extract Method refactoring performed in the aforementioned article became handy. Seven private methods of the VendingMachine started screaming too many roles of the object.

Code Rot

The single responsibility principle violation on the object level always goes together with testability problems. When a lot is happening in an object privately, there’s a desire to reveal its internals for testing. The so precious object’s encapsulation weakens leading to more complicated future refactoring and fragile tests. Both of these, in turn, result in a situation when nobody wants to change the code even when it really needs a change, making the code rot. …

A lot has been told about the guard statement since its appearance in Swift. Indeed, it simplifies code and makes it more readable. But is guard really a silver bullet?

Small Functions

A lot has been told about the function size. It’s obvious to everyone that functions should be small. They should be as small as possible. Nobody likes to read, understand, and refactor big functions. But how small they should be exactly?

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. — Robert C. …