UDP is probably the most widely used protocol for SIP. It is also used by default in Telephone. If you haven’t changed SIP transport in settings, UDP is used. Some public SIP providers or company servers may also work with TCP, but UDP still seems to be the default.

Neither UDP nor TCP transport provides encryption. The communication between the phone and the SIP server happens in the clear. One way of solving this problem is to use a VPN connection between your computer and your SIP provider or company network.

Such remote access VPN is typical for remote workers in a company. But it is not typical for a public SIP provider to offer access to their servers via VPN.

TLS as SIP transport

There is another standard transport protocol. It is called TLS, and it supports encryption. It is the same TLS that is widely used on the web where you can recognize it by a padlock icon in the browser or https scheme in the site address.

The same TLS transport that is used on the web can also be used for SIP. Of course, both the phone and the SIP server have to support it. In this update, Telephone has gotten support for it, so you might want to ask your SIP provider or IT service about the support on the server.

When TLS is used, the server presents its cryptographic certificate to the phone. The phone allows the connection only if the server’s certificate has been issued by an authority that is trusted by the phone. Telephone has a built-in list of trusted public certificate authorities in a similar way as an operating system or a web browser does.

This means that for TLS to work, the server must get a certificate from one of the public certificate authorities. Self-signed certificates would not currently work.

SRTP for voice

In SIP VoIP, the SIP protocol itself is only part of the story. It is responsible for establishing calls and controlling the call flow, but it doesn’t transmit voice. For the voice, another protocol called RTP is used.

By default, the voice transmission isn’t encrypted either. As with SIP above, one way of solving this problem is to use a VPN tunnel. In a VPN tunnel, all traffic is usually encrypted, being it SIP or RTP.

However, there is a specially designed protocol for encrypted voice transmission called SRTP, and Telephone now also supports it.

TLS and SRTP together

To negotiate its encryption keys, SRTP relies on SIP. To make voice transmission with SRTP secure, secure transport has to be used for SIP. That’s why SRTP for voice is usually used together with TLS for SIP.

In Telephone, when TLS is chosen as a SIP transport, SRTP is automatically required instead of plain RTP. If the server doesn’t support SRTP, the call will not succeed. This way you may be sure that when TLS is selected, your voice between Telephone and the SIP server will also be encrypted.

No end-to-end encryption

You need to keep in mind that the standard encryption protocols above don’t give you end-to-end encryption between two phones. In SIP telephony, your phone connects to a SIP server. And that in turn connects either to the server of your conversation partner or to their phone directly. There’s no guarantee of what happens to the network traffic after the first server decrypts it. And when a normal phone number is called, there is no guarantee of encryption in the traditional phone network.

However, encryption between the phone and your SIP server alone is also important. You often don’t have a choice but to trust your SIP server. Otherwise, you wouldn’t have chosen this provider in the first place. But it is a good idea not to trust the network between you and the server and to encrypt all communications with it.

Originally published at https://www.64characters.com on August 28, 2020.

What’s new in Telephone 1.5 was originally published in 64 Characters on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Like with traditional or mobile phones, to make calls using softphones you need a phone provider. To be able to call on a mobile phone, you need to insert a SIM card into it. The SIM card stores phone provider settings for your account. To configure a softphone, you need to enter your account settings manually. These settings you receive from your phone provider. In the simplest case, it’s a server name, a user name, and a password. Configuring a softphone is often easier than setting up an email app.

It’s already there

Many people already use VoIP at work. That phone at your desk is very likely an IP phone. An IP phone is just a computer running software. The same kind of software can be run on a normal computer or mobile phone as an app.

Many people already use VoIP at home. Some home routers like FritzBox are VoIP servers. You can plug a normal analog phone into it. You can also configure a softphone with router VoIP settings. When you answer or make a call, you’re free to choose what is most convenient for you at the moment: a normal phone or an app.

Why VoIP

VoIP gives you freedom. Many phone providers work over the Internet. You can choose almost any of them. You can choose better prices, better services, better customer support. You’re not locked to your local phone provider anymore.

Many VoIP providers offer more features than normal phone providers. You can have multiple simultaneous calls for a single phone number. You can transfer calls between colleagues. Your team members can be located anywhere in the world. No roaming fees for calling a colleague in another country. You can have those voice menus like “Press one to connect to customer support.” You can redirect incoming calls to your mobile phone during business hours and to a mailbox otherwise. You can have call conferences. You can have local phone numbers in several countries redirected to your mobile. All of that is available for big and small teams or individuals without buying expensive phone hardware.

Where to start

You can start using VoIP by asking your current phone provider. They may offer their services via VoIP in addition to the normal way. If they do, they’ll send you settings to use in an app.

If your current provider doesn’t offer that, you can search the Internet for a SIP provider. SIP is a standard protocol for VoIP that the providers and the phones support. After the registration, the provider will send you settings to use in an app.

If you have a VoIP-capable router like FritzBox at home or office, you can create a SIP account for your softphone yourself. Then you use the router’s address and the created user name and password in a softphone.

If you have an IP phone at your desk at work and would like the flexibility of calling from your computer, you can ask your company IT service to give you SIP settings for your account.

Conclusion

VoIP is a technology for phone calls over the Internet or local computer network. It is already everywhere and integrated with the traditional phone network. It gives you the freedom to choose better prices and more possibilities than the traditional phone providers usually offer. You can carry your personal or business phone number with you anywhere without roaming fees and without anybody noticing it.

What is VoIP was originally published in 64 Characters on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Fast-forwarding ten years, and my goal still stands. Telephone has become a full-featured softphone while keeping its streamlined interface and its nativeness to the Mac.

Over the years, Telephone was downloaded more than a million times. The vast majority of the feedback has been very positive, and that is what’s been keeping me going forward. I always wanted to dedicate more of my time to this app, and the introduction of subscriptions a couple of years ago finally made it possible.

Making something sophisticated and full-featured while keeping it easy-to-use is a big challenge. That is what I’m trying to do with the app, and that is what people seem to like in Telephone. History shows a lot of examples of apps getting bloated as the businesses put more and more unneeded features into them only to justify another paid update. And that’s where Telephone Pro subscription comes into play, allowing the app not to be flooded with unnecessary features.

I want to say thank you to all people who use the app! We often read these words in posts like that, but they are really true. Without you, without your positive feedback that inspires me, without your negative feedback that makes the app better, without your support Telephone wouldn’t have lasted this long.

Alexey

Originally published at www.64characters.com on December 21, 2018.

Ten years of Telephone was originally published in 64 Characters on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

This change has another practical advantage. The audio device for a call and the sound volume can quickly be changed from the sound indicator in the menu bar.

Hold the Option key while clicking the sound icon to see the extended menu that allows selecting the input device.

History context menu

Introduced in the last release call history now has a context menu.

Not only does it allow copying the phone number for a record but also deleting all call history records with one action. The standard keyboard shortcut Command-C will also work for copying phone numbers.

History facelift

Call history has received a facelift. The most important information — the names — is emphasized with a stronger font face. The secondary information is deemphasized for easier skimming through the history.

Before:

After:

Swipe to delete

Records can be deleted from the history without touching the keyboard. Swipe to the left to reveal the delete button.

Call windows on top

To make it easier to find call windows during conversations or incoming calls, call windows are now kept on top. This option can be turned on and off in the Call menu.

30 simultaneous calls

In the Pro version, the app now supports up to 30 simultaneous calls. In the free version — up to three.

QoS

QoS is a technology to give more priority to the voice traffic on the network. It makes it less likely for the voice traffic to be delayed or lost, which increases the quality of the phone calls. There are several types of QoS, and Telephone now supports the one that is called DiffServ QoS. This method works on the IP level of the network marking the packets with special numbers. These numbers can then be interpreted by other network devices giving higher priority to phone calls.

There are two major types of traffic in SIP telephony: signaling (SIP) that controls call flow and voice (RTP) that transmits the actual voice in real time. Telephone marks packets with the following DiffServ DSCP values: SIP packets are marked with the value 24 and RTP packets — with the value 46.

What should change now is that if your network supports DiffServ QoS, your call quality should increase under heavier network load. For example, when your internet connection is congested when downloading a big file.

Hardened Runtime

Hardened Runtime is a new security feature of macOS Mojave. This is another security layer — similar to App Sandbox — ensuring that the apps do only what they’re intended to do. The operating system isolates the apps from the critical system components, personal data, and other apps.

In practice, this means that if an app is compromised by malicious software, it is automatically blocked keeping the system and personal information safe.

Telephone has supported App Sandbox since its introduction in macOS Lion in 2011. And following the latest Apple security recommendations, the app now also supports Hardened Runtime.

Originally published at www.64characters.com on November 22, 2018.

What’s new in Telephone 1.4 was originally published in 64 Characters on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Telephone Pro

Thank you to all the project patrons! Without you, this release would not be possible. I love working on Telephone and want to continue making it more and more useful to you and your business.

The patronage allowed me to spend much more time in evolving the app but didn’t make it possible to work on it full-time, which I’d love to. The call history introduces the first pro feature to the app, with more to come. All patrons have automatically become Telephone Pro subscribers. As before, the subscription supports ongoing development, and now also unlocks the full call history.

Answer calls from notifications

Another often requested feature was answering calls from the notifications, and it’s there! It is also possible to decline calls from notifications, but because of the macOS limitations, it is rather obscure. You need to click and hold the Answer button to show the Decline button as another possible action. And as before, just click the notification itself to activate the corresponding call window and bring it to the front.

This feature also should help with a problem with multiple monitors or many open windows. Sometimes it can be hard to find the window of the currently ringing call, but the notification is always at the same place, easy to find and reach.

New app icon

The old icon was… old. Bought as part of an icon set back in 2008 it served its purpose for good ten years, until 2018. Again, thanks to the project supporters, I could finally spend some time on the new one, and here it is. Many of us are used to the black Telephone icon, so I kept the color.

Color status indicators

This is one of those small but convenient features. Just quickly glancing at the app window it is now clear if the phone line is currently available for incoming calls or not.

What’s next

Now, I’ll be focusing on other features that you often ask for: hide the Dock icon and show only the menu bar icon, calling scripts on new calls, new contact search that displays phone types, showing company names next to contacts, better phone number formatting, IPv6 support, and many others.

Your feedback is always welcome! I read all suggestions and problems that you send me. Feel free to contact me anytime.

Originally published at www.64characters.com on January 15, 2018.

What’s new in Telephone 1.3 was originally published in 64 Characters on Medium, where people are continuing the conversation by highlighting and responding to this story.

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. I’d say, it’s the same from the implementation point of view, but different on the higher level.

The problem with the word delegate is that the role is not very specific. Just by looking at a type called StoreDelegate it is not immediately clear what to expect from it. Is it supposed to handle Store events? Is it supposed to provide additional information for the Store?

The fact is, Cocoa and Cocoa Touch APIs tend to have overblown delegates. Just look at the UITableViewDelegate! It configures rows, handles selection events, reorders rows, manages table view focus and much more.

Interface segregation principle

The UITableViewDelegate API promotes the violation of the Interface Segregation Principle. The principle suggests that no client should be forced to depend on methods it does not use. The interfaces should be split into smaller and more specific ones. It makes the whole system more decoupled and thus easier to refactor, change, and test.

In a project, you come across some UITableViewDelegate implementation and ask yourself, what exactly it does. And you don’t know! It may do anything from what that huge protocol declares.

The first step in solving this problem could be to split that big protocol into the smaller ones. There could be:

UITableViewRowConfigurationDelegate
UITableViewAccessoryViewConfigurationDelegate
UITableViewHeaderFooterConfigurationDelegate
UITableViewSelectionDelegate
UITableViewDisplayDelegate
UITableViewRowEditingDelegate

and so forth.

You might argue that it’s too many types. I would say it reveals the truth instead of hiding it from us. It shows the real situation in which a table view may depend on objects with so many different roles.

In fact, if we were the designers of the UITableView, that would be a signal for us to decompose the UITableView itself into several objects, each of which having a distinct role and a single delegate.

Event targets

I personally still don’t like that every decomposed protocol is a delegate. (Or if everything was an observer as I started to name them a year ago.) One of the typical roles of Cocoa and Cocoa Touch delegates is event handling. Such types can be called event targets. This is how the list of decomposed protocols looks now:

UITableViewRowDelegate
UITableViewAccessoryViewDelegate
UITableViewHeaderFooterDelegate
UITableViewSelectionEventTarget
UITableViewDisplayEventTarget
UITableViewRowEditingEventTarget

The word delegate is kept only for the configuration roles (by the way, do you have a better name?). And the expression event target is only used for the event handling role.

Now the implementations responsible for configuration can be separated from those responsible for events.

Event sources

Imagine you wanted to react when the list of audio devices in the system changes. You make your use case implement, say, an AudioDevicesChangeEventTarget protocol. But which name do you give to a type that produces those events? The system libraries may just provide a low-level C API with function callbacks. You build a wrapper and name it what? A DevicesChangeNotifier? Could be, but I like how well an EventSource plays with an EventTarget:

AudioDevicesChangeEventSource
AudioDevicesChangeEventTarget

Conclusion

We can’t change the UIKit API, but we could design our own APIs better. The overblown delegate protocols promote the violation of the Interface Segregation Principle making our systems more coupled and harder to refactor, change, and test. Making smaller delegate protocols and picking more specific names for them improves the app architecture.

Related Articles

• Observer Pattern
• Composite Observer
• Dependency Injection in Swift
• Dependency Injection in View Controllers

Overblown Delegates was originally published in iOS App Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

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. It explicitly declares its designated initializer and prevents an accidental initialization with an initializer inherited from the parent.

The object’s API doesn’t allow an incorrect usage. The client can only create an object using a single (in this case) initializer and tell the object to do work.

And here’s the same class implemented in Swift. Note also how the possibility to use a where clause in optional bindings allowed us to remove one method (assuming we wanted to keep methods small).

And what do you think about Swift’s brevity? Do you miss Objective-C’s verboseness in your code?

Other Articles

• Too Many Private Methods
• View Event Testing in Swift
• Humble Object Pattern in Swift
• Dependency Injection in View Controllers

The Conciseness of Swift was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Big Building Blocks

Another problem that arises when the principle on the object level is violated is the bigger object size. In object-oriented programming, the software is composed of building blocks represented by objects. The smaller and more focused those blocks are, the easier it is to build a structure from them and, more importantly, to adapt the existing structure to the new requirements.

Extract Class

How can the new VendingMachine’s code smell be eliminated? An object does more than one thing if there are several reasons for it to change. The VendingMachine will have to be changed if the overall vending process changes. This seems to be its primary responsibility. The object will also have to be changed if the details of the inventory implementation change. And that is a candidate for an extraction.

The VendingMachine now depends on the Inventory expressed as a protocol. Not only is the inventory logic now encapsulated in a separate, smaller piece of code—the SimpleInventory object—but the VendingMachine has also become more testable. It is trivial to write a test double implementing the Inventory protocol and use it in tests instead of a real inventory.

Conclusion

The single responsibility principle helps structure code better. It stimulates the creation of smaller and more composable building blocks. The principle can be applied on several levels. Applying it on the function level makes it easier to reveal the principle violation on the object level. Adhering to the principle on the object level keeps the objects small, self-contained, and better encapsulated. Building complex and testable structures from such objects becomes much easier.

Related Articles

• Why Swift guard Should Be Avoided
• View Event Testing in Swift
• Humble Object Pattern in Swift
• Dependency Injection in View Controllers
• Dependency Injection in Swift

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. Martin, Clean Code book

More specifically, Robert C. Martin recommends keeping functions not more than six lines long and definitely not more than ten lines.

Following this simple rule makes magic. The code suddenly becomes more understandable. What previously was a thirty-line function with several indentation levels and intermediate variables that had to be kept in the head is now ten functions, each having a self-documenting specific name.

Single Responsibility

A lot has been told about the single responsibility. It applies not only to objects but to functions as well. It’s not a secret to anybody that functions should do one thing and one thing only.

Yet this is violated over and over again. The function size seems to play the major role here. So if a thirty-line function is refactored to be ten three-line functions, the following of the single responsibility principle on the function level is automatically improved.

One Level of Abstraction

Not that much has been told about functions having one level of abstraction. It is another instrument that helps creating functions with single responsibilities.

What does it mean? In short, high-level code, like controlling the whole process, shouldn’t be mixed with small details, like variable increments or Boolean checks.

Example

This example is taken from The Swift Programming Language book.

Of course, the vend(itemNamed:) function is just an example of using the guard statement but one can often see similar functions in the production code. This function has all three problems described above.

1. It is pretty long, sixteen lines, multiple parts separated by empty lines.
2. It does several things. It gets an item by name, validates parameters, and it implements the logic of vending an item.
3. It has several abstraction levels. The high-level vending process is hidden among the finer-level details like Boolean checks, usage of specific constants, math operations, etc.

How could the function look like after refactoring?

The total number of lines increased, but it should not be forgotten that the number of lines is not an end in itself. The refactored code provides a number of benefits compared to the old one.

1. The main vending function is now short and contains only high-level steps of vending an item. If the reader is not interested in the details, she can understand the vending process by quickly looking at this high-level function.
2. The functions have more respect for the single responsibility principle. Some of them could be broken down even further, but even in their current form, each one is more understandable and readable. They separate the old bigger chunk of code into smaller, self-documenting pieces.
3. Each function operates on a single level of abstraction. The reader can easily move between these levels as needed. How does the vending process look like? The item is determined by name and validated, the deposit is reduced, the item is removed from the inventory, and dispensed. How the item is validated? The count and the price are checked. How exactly the count is checked? The count is compared to zero. If small details don’t interest the reader, they can always be skipped.

Conclusion

The guard statement is a handy instrument for reducing the number of nested structures in functions. The problem lies not in the instrument itself but in its usage. The guard statement promotes the creation of bigger functions that do several things and act on multiple levels of abstractions. By writing small and focused functions, one can find herself not needing the guard statement at all.

Related Articles

• Too Many Private Methods
• View Event Testing in Swift
• Humble Object Pattern in Swift
• Dependency Injection in View Controllers
• Dependency Injection in Swift

Why Swift guard Should Be Avoided was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to VIPER states that a presenter contains view logic for preparing content for display and reacting to user inputs. This definition reveals two problems.

First, if the presenter prepares content and reacts to inputs, this sounds very much like a Single Responsibility Principle violation.

Second, this approach imposes a circular dependency between the presenter and the interactor. This is often considered to be a design smell, which leads to further implications. For example, inability to compose the graph of objects using the constructor dependency injection.

The idea of handling events in a presenter is not new to VIPER and surely has its use. But can it be improved?

Flow of Control

The Clean Architecture, the architecture which VIPER applies to iOS development, illustrates the typical control flow. An event starts in a controller, goes through an interactor, and ends up in a presenter.

The controller here is not necessarily a view controller. It’s just some object, other than the presenter, that is the first one along the way of handling events. To avoid confusion, it’ll be referred to as an event handler in this article.

On the diagram, it can be seen that the event handler depends on the interactor to implement the use case. The interactor depends—via the output port it defines using a protocol—on the presenter to deliver the result.

Each object focuses on a single concern. The dependencies of each object can be passed in the constructor providing the maximum safety and help from the compiler.

Breaking Circular Dependencies

Although the concerns are now separated, circular dependencies still exist when the whole object graph, including the view, is taken into account.

The whole graph looks like this: view–event handler–interactor–presenter–view, and it can’t be composed in the initializers. To create the view, an event handler has to be created, which requires an interactor, which requires a presenter, which requires a view. How can this be resolved?

Factories and observer pattern can become handy for breaking circular dependencies.

Instead of taking an already instantiated interactor object, the event handler can depend on a factory that knows how to create interactors. The first thought could also be to make the event handler create interactors directly. However, that would undermine all dependency injection advantages, testability being one of them.

Example

The example shows how a GPS tracking app could present track summary and handle a track name change actions. Because this article is about the event handling, presenter tests will not be shown here and can be found in the previous article.

Business Logic

The interactors are basically commands. The code that executes them may not care about how they are created. Therefore, the interactors have only one method.

There are two interactors conforming to this protocol.

The TrackSummaryInteractor is responsible for preparing the track summary data for display.

The TrackNameUpdateInteractor is responsible for updating the track name in the store.

Both interactors need a persistent store, which is represented by a protocol. The concrete implementation of the persistent store is not interactors’ business and out of the scope of this article.

The track summary data structure contains an identifier that might not be displayed to the user but is used for updating the track name.

It is trivial to test the interactors by writing test doubles that implement the boundary protocols.

Presentation

The TrackSummaryPresenter is responsible for preparing data for presentation.

View

The view is defined as a protocol inheriting the presenter’s output protocol. It is not uncommon for the more complex views to inherit multiple protocols declared by several presenters.

The protocol defining the view events is to be implemented by the view observers. The view parameter makes it possible to break the circular dependency.

Due to its tight coupling with the view, the view controller, as discussed before, represents the view to the outside world. It’s the view controller who implements the TrackSummaryView protocol.

The view controller is very humble, passively accepting the data for presentation and delegating event handling to the observer. Because of the constructor injection, the view controller can’t be created without an observer by mistake.

The event handler object acts as a view observer.

To improve testability, it doesn’t create the interactors by itself, but rather depends on factories to do that.

The event handler can be tested easily.

If needed, the test doubles can be created manually.

Composing all objects together.

Conclusion

The becoming more and more popular VIPER architecture combines both presentation and event handling logic inside a presenter. This leads to often unwanted circular dependencies, puts two responsibilities into a single object, and may over time grow into the Massive Presenter problem. The event handling and presentation logic could be separated using The Clean Architecture event flow approach. As a result, the objects become smaller, more testable, and responsible for one thing only.

Related Articles

• Humble Object Pattern in Swift
• Safer UIViewController Creation When Using Storyboards
• Dependency Injection in View Controllers
• Dependency Injection in Swift

View Event Testing in Swift was originally published in iOS App Development on Medium, where people are continuing the conversation by highlighting and responding to this story.