Let’s say you joined a new team and you’re expected to make some changes to an existing feature. You rightfully think that the best way to understand a feature is to check the existing tests to get a feel of possible scenarios to consider.

You then dig into the codebase and find the following test case.

let notificationScheduler = MockNotificationScheduler()
let locationProvider = MockLocationProvider()
let locationListener = LocationListener(
  locationProvider: locationProvider,
  notificationScheduler: notificationScheduler
)

locationProvider.currentLocation = .ireland
locationListener.start()

locationProvider.currentLocation = .turkey

XCTAssertEqual(
  notificationScheduler.scheduledNotification, 
  InsuranceNotification(from: .ireland, to: .turkey)
)

It’s a bit hard to see the wood for trees, isn’t it? You might have a wild guess about what’s going on here but the scenario itself isn’t obvious.

Let’s break it down.

On the first line, we have the MockNotificationScheduler.

let notificationScheduler = MockNotificationScheduler()

We go to the implementation to find out MockNotificationScheduler implements NotificationSchedulerProtocol, which looks like this:

protocol NotificationSchedulerProtocol {
  func scheduleInsuranceNotification(from: Country, to: Country)
}

It’s fair to assume that this one schedules a notification for the given from and to countries.

Moving onto the MockLocationProvider on the second line.

let locationProvider = MockLocationProvider()

We again go to the implementation and find out MockLocationProvider implements LocationProviderProtocol which looks like the following:

protocol LocationProviderProtocol {
  var currentLocation: Country { get }
  var locationUpdateHandler: ((Country) -> Void)? { get set }
}

This one is obvious. It is used for determining the current location and detecting the location changes.

The last definition is the LocationListener. Looks like this one is not a mock object and it's most likely the subject under test.

let locationListener = LocationListener(
  locationProvider: locationProvider,
  notificationScheduler: notificationScheduler
)

We check the implementation for this one and see LocationListener is a service that listens for location updates and schedules notifications when the user travels from one country to another.

So… It looks like LocationListener is observing the changes in location using LocationProvider and schedule insurance notifications using NotificationScheduler when needed.

With all this information, we can go back to the test case itself and hopefully understand the scenario being tested.

locationProvider.currentLocation = .ireland
locationListener.start()

locationProvider.currentLocation = .turkey

XCTAssertEqual(
  notificationScheduler.scheduledNotification, 
  InsuranceNotification(from: .ireland, to: .turkey)
)

At this point, we can confidently tell that the test case above is testing if a notification is scheduled when the user travels from Ireland to Turkey.

**However, would you consider this test readable?**

We had to check the internals of three components just to understand the scenario being tested. Tests in the codebase should also act as documentation so we can conclude that this is a poorly structured test.

What would have been ideal here?

Ideally, the test case itself should describe the scenario in a readable way so that…

I recently wrote a small helper to solve this problem. With Scenario, the test case above would turn into this:

Scenario("User travels to a different country and receives an insurance offer")
  .given("user is currently in Ireland") {
    locationProvider.currentLocation = .ireland
    locationListener.start()
  }
  .when("user travels to Turkey") {
    locationProvider.currentLocation = .turkey
  }
  .then("a local notification should be scheduled to offer travel insurance") {
    XCTAssertEqual(
      notificationScheduler.scheduledNotification, 
      InsuranceNotification(from: .ireland, to: .turkey)
    )
  }

So what did we gain here?

• The test is more structured and readable. We don’t have to go into the implementation to understand the scenario being tested.
• Scenario forces us to write in given/when/then format which helps the developer to better structure the test when writing it out.
• Bonus: Each block runs an XCTContext activity so we get beautiful test reports!

The approach is nothing new! Behaviour-Driven Development has been around for quite a while and some popular implementations are…

• 🥒 Cucumber is a wildly popular framework especially for cross-platform testing as it completely decouples code and scenario definition.
• ⚡️ Quick is a widely used BDD framework for Swift and Objective-C which lets you create test cases similar to those above.

(And I am sure there are others that I missed!)

So why build another helper, you ask?

Despite Cucumber and Quick being great and mature frameworks, they are big commitments. They change how you develop tests so much that it feels like you’re developing with a whole new language. Scenario on the other hand is a small helper that you can opt-in whenever you want without big commitments.

Hope you enjoyed the article! ❤️

You might have noticed that “like” or “favorite” action in social media almost never makes you wait, although there is a network call in progress in the background. The users who “like” content are generally more likely to come back and engage with more content. This is because platforms choose to optimize flows that lead to user engagement and strive to make these flows as frictionless as possible.

Consider Twitter’s like button. The heart icon immediately goes red when we tap it. This is good because we can simply like something and move on when the real work still happens in the background.

So how can we implement this? Let’s first define what needs to happen from a user’s perspective.

• The UI immediately reacts as if the action was successful. (This is why we call it optimistic.)
• We perform the network request in the background.
• If it succeeds, happy days, we already performed the update.
• If it fails, we need to revert the optimistic update.

Now, to achieve this in code, we need to know…

• what is the actual task we want to perform and how we can perform this task
• what is the optimistic update we want to perform while this task is in progress
• and how we can revert the optimistic update if the task fails

If we have all this, we can even design a generic API that aids us when implementing optimistic updates. Let’s see if we can do that.

Consider we have the following data model.

struct Post { 
  var id: UUID 
  var message: String 
  var isLiked: Bool 
}

Let’s define the task and the update we want to perform on this model.

enum PostTask { 
  case like(id: UUID) 
} 

enum PostUpdate { 
  case isLiked(Bool) 
}

Now we need to define how we can perform this task and apply the model updates.

class PostService {
  func perform(
    _ task: PostTask, 
    completion: (Result<Bool, Error>) -> Void
  ) {
    // perform the network call
    // report the result in the callback
  }
}

This service will only perform the task and report the result. Useful but not quite there. What we need is more like a function that receives both the task and the optimistic update.

let service = PostService()

func perform(
  _ task: PostTask, 
  optimisticUpdate: PostUpdate
) {
  // perform the optimistic update here!
  service.perform(task) { result in
    switch result {
    case .success:
      // task is successful. happy days!
    case let .failure(error):
      // task has failed. revert the optimistic update!
  }
}

OK, we got the shape but there are missing pieces.

1. Generic models. If we want a generic API, we should not rely on PostTask or PostUpdate.
2. Generic service. We need a way to inject a service that can perform the given task.
3. Generic events. We need a way to broadcast important events so the updates can be performed.

This feels like we need a stateful object instead of just a function. So let’s start with a generic class.

class OptimisticUpdater<Task, Update, Error> { ... }

We tackled the first problem. Now we need a generic function that can perform the task and report the result.

enum TaskResult<Update, Error: Swift.Error> {
  /// Task is successful. Optimistic update can be kept.
  case success
 
  /// Task has failed. Optimistic update should be reverted.
  case failure(Error, rollbackUpdate: Update)
}

typealias PerformTaskFunction<Task, Update, Error> = (
  _ task: Task,
  _ update: Update,
  _ finish: @escaping (TaskResult<Update, Error>) -> Void
) -> Void

Now that we have also defined a generic function signature for performing tasks, we can move on to the next problem. We need to publish optimistic update events so that the model can be updated and changes can be propagated to the UI.

We can start with a simple enum and deliver events using a block.

class OptimisticUpdater<Task, Update, Error> {
  enum Event {
    /// Optimistic update should be applied. Task is about to start executing.
    case optimisticUpdateRequested(Update, task: Task)

    /// Task is successful. Optimistic update should be kept.
    case taskSucceeded(Task, update: Update)
 
    /// Task has failed. Optimistic update should be reverted.
    case taskFailed(Task, error: Error, failedUpdate: Update, rollbackUpdate: Update)
  }
 
  var eventHandler: ((Event) -> Void)?
}

As we also solved the last problem, if we glue everything together, we get an OptimisticUpdater implementation like this one.

Let’s see how we can use it.

let service = PostService()
var post = Post(id: UUID(), message: "Test", isLiked: false)

// 1. Create an optimistic updater:
postUpdater = OptimisticUpdater<PostTask, PostUpdate, PostTaskError> { 
  task, optimisticUpdate, finish in
                                                                       
  service.perform(task) { (result) in
    switch result {
    case .success:
      finish(.success)
    case let .failure(error):
      finish(.failure(error, rollbackUpdate: optimisticUpdate.revert()))
    }
  }
}
 
// 2: Set a callback for updater events:
postUpdater.eventHandler = { event in
  switch event {
  case let .optimisticUpdateRequested(update, task: task):
    post.apply(update)
  case let .taskSucceeded(task, update: update):
    showConfirmation(task)
  case let .taskFailed(task, error: error, failedUpdate: failedUpdate, rollbackUpdate: rollbackUpdate):
    showError(error, for: task)
    post.apply(rollbackUpdate)
  }
}
 
// 3. Use the updater to like a post:
postUpdater.perform(.like(id: post.id), optimisticUpdate: .isLiked(true))

So what did we achieve here?

• We completely separated real work from the optimistic updates.
• We isolated the logic required to perform an optimistic update in one component, which can be used to update any model.
• We don’t have to think about when the update should happen and when it should be reverted every time we use it!
• It is completely testable. See below:

var service = MockPostService()
var post = Post(id: UUID(), message: "Test", isLiked: false)
var postUpdater = OptimisticUpdater { /* use mock service here */ }
var success: Bool?
postUpdater.eventHandler = { event in
  switch event {
  case let .optimisticUpdateRequested(update, task: task):
    post.apply(update)
  case let .taskSucceeded(task, update: update):
    success = true
  case let .taskFailed(task, error: error, failedUpdate: failedUpdate, rollbackUpdate: rollbackUpdate):
    post.apply(rollbackUpdate)
    success = false
  }
}

// When the task is performed and the call is in progress
postUpdater.perform(.like(id: post.id), optimisticUpdate: .isLiked(true))

// Then expect optimistic model update post.isLiked=true
XCTAssertEqual(success, nil)
XCTAssertEqual(post.isLiked, true)

// When the response is received
service.resume()

// Then expect post.isLiked=true and success=true
XCTAssertEqual(success, true)
XCTAssertEqual(post.isLiked, true)

Thanks for reading! ❤️

Since we make lots of important decisions by looking at the analytics data (if not, you should), I will not go into “why” having accurate analytics data is extremely important.

You probably also know that it is extremely painful to manually test if analytics events are being reported correctly. It’s very time consuming to perform some actions in the app, wait for the analytics tool to receive these events and verify each. Now, multiply this with number of releases you’ll have in the future… It’s a nightmare. 😩

This time could be better spent elsewhere.

Any time you have this feeling, there’s a good chance that things can be automated. Can we automate analytics testing? Why not.

Could we write black-box UI tests? With UI testing, we could actually record the UI actions leading to a specific analytics event. These UI actions can be repeated whenever we want to generate analytics events on the portal. But the verification part would still be manual on the analytics tool we’re using. This would still require manual verification so it is probably not what we want.

Could we write unit tests? Simulate UI actions that would lead to an analytics event, check if the mock analytics layer received the event and verify the details… This could work! Let’s try it out.

Functional Reactive Programming (FRP) is almost an industry standard on mobile today. If you’re not familiar with it, here’s a great read by Daniel Lew on fundamentals. In the first part, he explains the difference between passive and reactive components. I find this really interesting. I think we should talk more about what it means to be reactive before diving into any implementation. In this post, we will repeat his switch-lightbulb experiment, then try to reflect the learnings on component design.

Experiment is very simple. We have a switch that turns the light on or off. How would you build it?

If we design a passive lightbulb:

• Switch turns the lightbulb on/off when it’s switched on/off.
• Switch knows about the lightbulb.

class Switch {
  var state: Bool {
    didSet {
      lightbulb.state = state
    }
  }
  
  let lightbulb: Lightbulb
  ...
}

If we design a reactive lightbulb:

• Lightbulb should be created with an object which reflects the state of the switch and observe it. (That object would be Observable<Bool>.)
• Neither switch nor the lightbulb knows about each other. They are decoupled.

class Lightbulb {

  private(set) var state = false
  private let disposeBag = DisposeBag()
  
  init(observable: Observable<Bool>) {
    disposeBag += observable.subscribe { [weak self] value in
      self?.state = value
    }
  }

  init(_ switch: Switch) {
    self.init(observable: aSwitch.observable)
  }
}

There’s no difference between output of these implementations from the user’s point of view. However, by using reactive approach, we decoupled the switch and the lightbulb. This is where observables come in handy. It’s easy to represent an object’s input or output as an observable so we can pass it around instead of the component itself.

Designing Components

Would we always use an observable to represent a component’s input or output? Let’s think about it.

In switch-lightbulb example, the switch produces an infinite number of on-off events and the lightbulb is expected to react to them accordingly. That’s why the following model make sense.

In this case, Observable solves our problem because both switch’s output and lightbulb’s input are event streams.

What if it was not an event stream?

Let’s say we’re designing a recipe list component. We could expect a recipe-fetcher as input, so that we can fetch the recipes with it and display them. What would this fetcher return?

• If the recipes are fetched synchronously from a database, returning [Recipe] would make sense.
• If the recipes are fetched asynchronously from a server, then we would need a type like Future<[Recipe]> to indicate that recipe list is coming from a remote source.

Could we use Observable<[Recipe]> instead of Future<[Recipe]>?

Yes, we could. But should we? Remember, observables represent event streams. In this case, we’re talking about a network request so it’ll either return a value or an error. It’s definitely not an event stream but can be represented using an event stream that receives only one value. Since observables are more than likely to receive more than one value, using Observable<[Recipe]> as return type would set a wrong expectation on receiving end and therefore, is not a wise choice.

Using the correct abstractions is extremely important in programming because developers generate a mental model by looking at them. When we look at a block of code that we’re not familiar with, we start developing a mental model by looking at names, types and connections. If we have the right model, everything becomes 10 times easier. Therefore, it’s important that we thrive for better abstractions.

Looking at the examples above, we can generalize return types as below.

Takeaway here is that:

Observable is not always the right abstraction.

One of the main goals of component design is to encapsulate certain functionality so that it can be reused across the codebase. It’s really hard to do so without clearly defined responsibility, inputs and outputs. The table above is the toolkit that should be used to achieve this.

Bottom Line

Reactivity is extremely useful when designing decoupled components with clear input and output, especially when it involves user input. But this is not as trivial as it sounds. We first should be able to observe, to be able to react. An abstraction like Observable is a great solution to this problem.

It’s also very important to know that we have other tools under our belt. Observable is a powerful abstraction but great power comes with great responsibility. We should use abstractions when they're needed, not when we can. This is very important to keep things simple and understandable. If you look at the return-type table above, you'll realize we actually can use an Observable in all those cases, but that wouldn't be very wise.

If you read between the lines, you’ll probably realize I’m not a huge fan of RxSwiftor ReactiveCocoa as it's very easy (or even advertised in some cases) to abuse their Observable / Signal implementation. I don't want to get into details now as it can be a blog post on its own. 😅

Hope this provides another perspective on FRP and popular frameworks around it.

Thanks for scrolling all the way! ❤️

Codable got everyone excited because we all love parsing JSON and it’s nice to have this tool as a part of the standard library. Now it’s time to test if it’s worthy enough to be our favorite one.

Let’s see how Codable performs under rough conditions. We’re going to parse the following JSON using Codable and then compare it against the popular Unbox/Wrap implementation.

{
  “placeName”: “İstanbul, Turkey”,
  “lat”: 41.0049823,
  “lon”: 28.7319958,
  “dateAdded”: “2018-05-25”,
  “info”: “İstanbul is a very historical city.”
}

We want our data model to look like the following.

struct Place: Codable {
  let name: String
  let coordinate: Coordinate
  let dateAdded: Date
  let info: String?
}

struct Coordinate {
  let latitude: Decimal
  let longitude: Decimal
}

Challenges:

• placeName and name doesn’t match. We need to tweak coding keys.
• Two separate keys lat and lon become a Coordinate object. Custom decoding is needed.
• We need to use YYYY-mm-dd date format for dateAdded field.
• We need to throw an error if name, coordinate and dateAdded fields are missing but info field is optional.

Implementation Using Codable

Implementation Using Unbox & Wrap

Usage

Their usage is almost the same. That is, of course, if we define decoder and encoder as a class property.

Codable:

let place = try Place.decoder.decode(Place.self, from: jsonData)
let placeData = try Place.encoder.encode(place)

Unbox/Wrap:

let place = try Place(unboxer: Unboxer(data: jsonData))
let placeData = try wrap(place) as Data

Comparison 🎯

• Codable implementation is 47 lines, whereas Unbox implementation is 39 lines for this example.
• Keys in Codable is always strongly typed (CodingKeys) while Unbox only accepts String keys.
• While decoding properties, Unbox infers the type but Codable requires the type as a parameter. However, this can be enabled in Codable as well using a simple extension like KeyedDecodingContainer+TypeInference.

// Codable:
try container.decode(String.self, forKey: .name)
// Unbox:
name = try unboxer.unbox(key: "placeName")

• Codable only supports one date encoding/decoding strategy. So if we had a UNIX timestamp property along with dateAdded, we would need to manually transform it into a Date object in init(from decoder:) method.
• Codable has lots of advanced features around keys, which are not available in Unbox/Wrap. (See: Using JSON with Custom Types)
• Unbox/Wrap is a third-party dependency while Codable is a part of standard library.

Bottom Line 🎖

While Codable requires some research and digestion before advanced usage, you can hit the ground running with Unbox in minutes. For serialization, Unbox only requires you to implement an init method which defines all the mappings.

On the other hand, Codable is black magic.

Most of the cases, it just works without any customization. Although advanced usage can sometimes be complicated due to keys being strongly typed, it’s easy to learn. Codable is like a Swiss army knife so I can’t think of any case you can’t handle with it.

I started this post thinking that Unbox is much simpler and readable compared to Codable for advanced usage, but sample code indicates otherwise. It might be time to move away from all third-party JSON parsing frameworks and make peace with Codable.

Well played, Apple.

Thanks for reading! Please let me know what you think and help spread the word. ❤️👏

Further reading: Swift 4’s Codable by Alp Avanoğlu

If you have been developing mobile apps for a while, you’ve probably heard of MVVM and VIPER. While some people say MVVM does not scale well, some others say VIPER is an overkill. I am here to explain why I think they are very similar and we don’t even need to separate the two.

Let’s first quickly go over MVVM and VIPER.

What is MVVM?

• View delivers user actions to view model.
• View model handles these actions and updates its state.
• View model then notifies the view, either with data binding or manually using delegation or blocks.

What is VIPER?

• View delivers user actions to presenter.
• Presenter then delivers these actions to either interactor or router.
• If the action requires computation, interactor handles it and returns the state to the presenter.
• Presenter then transforms this state to presentation data and updates the view.
• Navigation logic is encapsulated in router and presenter is responsible from triggering it.

For more information on these architectures, reference this great post by Bohdan Orlov: iOS Architecture Patterns

What’s our main goal?

Our first goal is to separate UI and business logic. Therefore, we can easily update UI without breaking any business rules and also test business logic in isolation. Both MVVM and VIPER assures this, but in different ways. If we look from this point of view, they are structured as follows.

While MVVM has only a view component in UI layer, VIPER separates UI responsibilities into 3 components, which are View, Presenter and Router. It’s also obvious that business layer looks pretty much the same.

Let’s see how they actually differ in UI layer in practise.

An Imaginary App: Top Movies

Imagine that we’re building a simple app using MVVM which fetches top 25 movies from IMDB and shows them on a list. The components would probably look like the following.

Information Flow:

• (View sets itself as view model’s delegate.)
• User taps on reload.
• View calls fetchMovies on view model.
• When the movies are fetched, view model notifies the delegate (view).
• updateWithMovies method gets called internally and transforms movies into presentation data and shows them on the list.

This is pretty straightforward. Let’s build the exact same app for macOS now and try to reuse code as much as possible.

An Imaginary Case: Implementing macOS Version

One thing is certain, view classes will be completely different. In that case, we can’t reuse the presentation logic that sits in our iOS app. iOS view currently transforms Movie objects into presentation data in updateMovies method. The only way to reuse that piece is to take it out. Let’s move presentation model generation to a mediator class between the view and the view model, so that we can reuse it in both iOS and macOS views.

I will call this mediator class Presenter, just by chance.

Information Flow:

• (View sets itself as presenter’s delegate.)
• (Presenter sets itself as view model’s delegate)
• User taps on reload.
• View calls reload on presenter.
• Presenter calls fetchMovies on view model.
• When the movies are fetched, view model notifies the delegate (presenter).
• Presenter transforms movies into presentation data and notifies the delegate (view).
• View updates itself.

This means that we can hook up any view that conforms to MovieListView protocol and expect it to work properly, platform independently.

We now delivered our brand-new macOS app by reusing most of the code we have for iOS.

But there’s an Apple Event coming up…

An Imaginary Case: iOS Redesign

In a few weeks, Apple announces iOS 26 and Jony Ive pulls a new trick by introducing a completely new design system. Our designers get excited and quickly come up with a new UI for iOS. Now our job will be to implement this new design and prove its usability with A/B testing, which means we’ll only show the new UI to some percentage of our users.

We’re actually in very good standing! We only need to create a new view for iOS that conforms to MovieListView protocol and hook it up with the presenter. Easy peasy.

protocol MovieListView: MovieListPresenterDelegate {
  ...
  func didTapOnMovie(at index: Int)
  func showDetailView(for movie: Movie)
}

While implementing this new class, we’ll realize that showDetailView implementations should be the same in both old and the new view. We’ll maybe copy-paste this piece from the old class at first, but then it’ll probably kill us inside because we all know copy-paste is bad.

OK — let’s move it out too. We’ll call this component Router, again, just by chance.

protocol MovieListRouter {
  func showDetailView(for movie: Movie)
}

This router will reference the current view weakly, and be responsible from pushing the detail view whenever it’s needed. But where do we keep this component? Should we compose it in the both old and new view classes? We could… But, talking from experience, views better be very dumb since they tend to change a lot.

Let’s push this responsibility to the presenter as well and let it compose the router. This way view will only be responsible from delivering user actions to the presenter. Presenter will then decide when to call the view model for a computation or the router for navigation needs.

Now that we reused the navigation logic as well, we can release in peace.

Let’s look at the final structure.

I think you got the point by now. If we rename MovieListViewModel to MovieListInteractor, we are 100% VIPER and we didn’t violate any rule that is enforced by MVVM.

Moral of the Story

Software architectures are just a set of rules. Some has less, some has more rules. Using one doesn’t necessarily mean abandoning the other one. This is true, especially when we are talking about MVC, MVVM and VIPER.

MVC 📗 → MVVM 📘 → VIPER 📙

Going from left to right, I only see an evolution process that enables scalability, not contradictions. VIPER is just the most detailed version of them all and that’s why some people consider it as an overkill. Listen to these people, they might be right!

VIPER in full has 5 components, and you might not need all of them in all cases. I think we should just use our best judgement while developing a feature instead of blindly accepting some made-up rules.

My current development recipe is as follows:

• Start with VIPER-lite, which is exactly the same as MVVM. Only use view, interactor and entities for starters.
• If you expect UI changes soon, append a presenter to your implementation.
• If you have complex/reusable routing logic, append a router.
• For each feature, have a separate file to layout class interfaces and design the communication between them before the actual implementation. This is generally considered as an overhead but it definitely helps you design better interfaces which would eventually save time.

Notes:

• You cannot define private variables in a protocol, they are only used to give hints about the expected implementation.
• Some methods like didTapOnMovie(at:) or presentation(from:) would also be private methods in the actual implementation. They are shown as a part of the protocol for demonstration purposes.

What do you think? Please leave a comment below if you have any questions or feedback. 💬

Thanks for reading!

Help spread the word. ❤️👏

Apple frameworks use delegation and observer pattern (NotificationCenter) heavily to pass information around. Although there is nothing wrong about these patterns, the actual implementation always looked a bit inconsistent to me.

Let’s look at the basic traits of these patterns first:

• Delegation: Supports 1-to-1, two-way communication.

• Observer: Supports 1-to-many, one-way communication.

Let’s look at some UITableViewDelegate methods.

optional func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat

• UITableView: Sender
• UITableViewDelegate (Mostly UIViewController): Receiver

This method is a good example of 1-to-1, two-way communication.

Since the table view requires height to be returned by the controller, communication is two-way and it can’t be 1-to-many. (Otherwise, we wouldn’t be able to decide which returned height value should be used.)

However, the following method does not return anything.

optional func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)

Here, sender only notifies the receiver. Therefore, the communication is one-way and can either be 1-to-1 or 1-to-many.

In this case, is delegation a good choice?
- Maybe…

What happens if we need to notify more than one component?
- We can’t.

What if we don’t care about row selection but want to provide row height ourselves? Do we still need to provide empty implementations?
- If this was a pure Swift protocol, yes, we would need empty implementations in place for each delegate method we don’t care about, which is pretty annoying. Since UITableViewDelegate is inherited from Objective-C, we can mark methods as optional for the sake of backwards compatibility. But Swift disables this “feature” for a reason. Having huge protocols violates interface segregation principle and makes them unreadable. Table views are a huge part of my life as a developer but I still can’t remember what’s defined in UITableViewDelegate and UITableViewDataSource protocols because the list is way too long.

So… Why don’t we use observer pattern for every one-way action? We could provide the same functionality with more flexibility and it would also clear up most methods in huge delegate protocols.

An Imaginary Problem

We have a settings page which features theme selection. We want to update our home screen whenever the theme changes.

Solution #1: Using Delegation

This solution works but is it flexible enough? What happens if we have 5 tabs to be updated with this theme change?

Solution #2: Using NotificationCenter

Now we support 1-to-many communication, but we doubled the number of lines, right? This is the main problem with NotificationCenter. It is powerful but not very handy.

Solution #3: Using Channels

What is a channel?

It’s nothing new. Channel is an observer pattern implementation which provides a much better API than NotificationCenter.

• Create a channel:

enum Message {
  case themeDidChange(Theme)
}

let channel = Channel<Message>()

• Subscribe to it:

channel.subscribe(self) { message in
  // Handle message here.
}

• Broadcast a message:

channel.broadcast(.themeDidChange(.light))

So using a channel, our solution would look like the following:

Final Words

• We can standardize data flow in our code by adapting channels for one-way communication and delegation for two-way communication.
• We can finally stop using NotificationCenter.
• Channel implementation is less than 100 lines of code and now is a part of Lightning framework.

Thanks for scrolling all the way!

Your opinion matters! Please let me know what you think and help spread the word. ❤️👏

I was trying to build a URL the other day. Check the following code block:

init?(userId: String?) {
  guard userId != nil else { return nil }
  
  self.path = "/user/\(userId)"
  self.url.appendPathComponent(self.path)
}

Seems legit, right?

Assume that we’re passing 23940 as userId to this initializer. Depending on the Swift version, path value would be:

Swift 2.x | path = "/user/23940"
Swift 3.x | path = "/user/Optional("23940")"
Swift 4.x | path = "/user/Optional("23940")"

Subtle, but heart-breaking.

Firstly, beware of this issue if you’re working on a super-old project which still uses Swift 2.x for some reason, and planning to migrate.

Secondly, we could use a guard-let instead of a guard-check statement here to fix this issue. However, it’s not convenient to have guard statements everywhere, especially when you simply want to print stuff.

I created the following struct to overcome this problem:

public struct Printable<T>: CustomStringConvertible {
    
    public let value: T?
    
    public init(_ value: T?) {
        self.value = value
    }
    
    public var description: String {
        if let value = value {
            return String(describing: value)
        } else {
            return "(null)"
        }
    }
}

Note: Yes, we could also print “nil” instead of “(null)” but I think the latter is more expressive. You can always choose this one or the other.

Whenever you have optionals, you simply wrap them in a Printable struct as below.

self.path = "/user/\(Printable(userId))" // "/user/23940"
print(Printable(userId))                 // "23940"

Or, in a more complex example:

struct User: CustomStringConvertible {

  let id: String
  let firstName: String?
  let lastName: String?
  
  var description: String {
    var string = id
    string += ", \(Printable(firstName))"
    string += ", \(Printable(lastName))"
    return string
  }
}

let user1 = User(
  id: "23940", 
  firstName: "Göksel", 
  lastName: "Köksal"
)

let user2 = User(
  id: "23941", 
  firstName: "Sıla", 
  lastName: nil
)

print(user1)
print(user2)

Without Printable struct, these objects would print below;

"23940, Optional("Göksel"), Optional("Köksal")"
"23941, Optional("Sıla"), nil"

With Printable, it prints;

"23940, Göksel, Köksal"
"23941, Sıla, (null)"

The latter seems much cleaner.

Alternatives

Global “describe” Function

func describe<T>(_ value: Optional<T>) -> String {
  switch value {
    case .some(let wrapped):
      return String(describing: wrapped)
    case .none:
      return "(null)"
  }
}

Optional Extension

extension Optional {
  
  var stringValue: String {
    switch self {
      case .some(let wrapped):
        return String(describing: wrapped)
      case .none:
        return "(null)"
    }
  }
}

Credit: Alp Avanoğlu

Comparison

var url1: URL? = URL(string: "www.google.com")
var url2: URL? = nil

// `Printable` struct:

print(Printable(url1))  // Prints "www.google.com"
print(Printable(url2))  // Prints "(null)"

// `describe` global function:

print(describe(url1))   // Prints "www.google.com"
print(describe(url2))   // Prints "(null)"

// `stringValue` extension on `Optional`:

print(url1.stringValue) // Prints "www.google.com"
print(url2.stringValue) // Prints "(null)"

Moral of the Story

If you are annoyed by logs like Optional(www.google.com) on your console, you can start using one of the alternatives.

Thanks for dropping by! And, as usual, help spread the word. ❤️👏

I was planning to write “short” and simple articles about my findings from day-to-day Swift experiments for a while now… 🕵

Here goes the first lightning article! 🚀

Problem: Intermediate clutter that comes with map, flatMap and filter functions

Let’s say we have the following requirements in an imaginary project:

There are 6 frames for an animation in format animation_<index>.jpeg available to download.

- Download animation frames using Request objects.

- Discard every second frame for better performance.

In a real world, we would most probably have more frames but think of this as a simplified example.

Instead of using a for loop for these 6 frames, we will go functional and use map, flatMap and filter methods.

let frameIndexes: [Int] = Array(1...6)

let imageRequests: [Request] = frameIndexes
  // Optimize by filtering every second frame:
  .filter { $0 % 2 == 1 }
  // Transform frame number to image name:
  .map { "animation_\($0).jpeg" }
  // Transform image names to URLs:
  .flatMap { URL(string: "https://www.somehost.com/\($0)") }
  // Transform URLs to request objects:  
  .map { Request(url: $0) }

This is much more readable than having a for-loop. But how about performance? Let’s dig into details by going over this code block line by line.

• filter block runs 6 times for each frame index in the array.
• A new array gets created with 3 filtered frame indexes.
• map block runs 3 times for each item.
• A new array gets created with 3 image names.
• flatMap block runs 3 times for each item.
• A new array gets created with 3 URLs. (Assuming URL creation will be successful on each image name.)
• map block runs 3 times on each URL.
• A new array gets created with 3 request objects.

Call order will look like this:

filter
filter
filter
filter
filter
filter

// A new array is created.

mapToName
mapToName
mapToName

// A new array is created.

flatMapToURL
flatMapToURL
flatMapToURL

// A new array is created.

mapToRequest
mapToRequest
mapToRequest

// A new array is created.

Although we only need the resulting array at the end, we created 3 more intermediate arrays, which has absolutely no use. This happened because filter, map and flatMap are eager functions that calculate immediately.

It’s not a problem for a small data set, but it can be problematic when dealing with a huge data set.

Solution: Using LazyCollection

Using a lazy collection, we can get rid of intermediate array creations in between. There is a lazy property defined on RandomAccessCollection which Array conforms to. lazy basically provides a lazy implementation of the same array, using LazyRandomAccessCollection<T> type, which only calculates values when in need.

Let’s implement the lazy approach now.

let frameIndexes: [Int] = Array(1...6)

let lazyImageRequests = frameIndexes
  .lazy
  .filter { $0 % 2 == 1 }
  .map { "animation_\($0).jpeg" }
  .flatMap { URL(string: "https://www.somehost.com/\($0)") }
  .map { Request(url: $0) }

Easy, right? We keep the same declarative way of transforming values from one to another, but achieved good performance just by adding .lazy after frameIndexes.

It will perform better because nothing will be executed unless we access an element. We have 2 options at this point:

• We can use the lazy collection just like normal array and calculate each value as we access them.
• We can go over the elements of lazy collection one by one and store them in a normal array.

We’ll go with the second option to inspect the call order.

var imageRequests: [Request] = []

for request in lazyImageRequests {
    imageRequests.append(request)
}

// We could also use:
// lazyImageRequests.forEach { imageRequests.append($0) }

After this for loop, call order would be:

// Item 0:
filter

// Item 1:
filter
mapToName
flatMapToURL
mapToRequest

// Item 2:
filter

// Item 3:
filter
mapToName
flatMapToURL
mapToRequest

// Item 4:
filter

// Item 5:
filter
mapToName
flatMapToURL
mapToRequest

Bottom Line

If we don’t use lazy;

• We iterate over the original array 4 times.
• We create 3 redundant intermediate arrays.

If we do use lazy;

• We iterate only once.
• We get each element calculated through the pipe as we access them.

Note on Caching

Beware that if we go over lazyImageRequests one more time, each item will be calculated again. So if you plan to access these items more than once, it’s recommended to cache them in a traditional array, just like we did in the example above.

Note on Array Conversion

We can also use the Array initializer to convert a lazy array to a normal array as below.

let imageRequests: [Request] = Array(lazyImageRequests)

I am not sure about the internals of lazy collections, but the code above doesn’t print the same call order as the for loop, for some reason. So keep in mind that using Array initializer for this purpose may not be as performant as expected.

If you’d like to try it out, implementation is available on LazyCollections repo.

Thanks for dropping by! And, as usual, help spread the word. ❤️👏

In the last two years, I’ve had chances to experiment with architectures like MVC, MVVM and VIPER. What’s common among those is the V component, which represents the views in our application. In a perfect world, view component should only do the following:

• Delivers any user action (touches) to business layer.
• Listens for state changes and updates itself.

Nothing else. Unlike their differences, view component is actually the same in all architectures. It is dumb, isolated and therefore easily replaceable.

But honestly, are they? Look at any of your implementations and tell me… In most iOS applications, they are actually the strongest component. We inject every smart component (like view model, presenter and interactor) into view controllers. That means if a view controller dies, those smart components die too. View is actually the dumb muscular guy who dictates the whole flow with its lifecycle. Shouldn’t it be the other way around?

I don’t think there is a problem with architecture definitions, but I can’t say the same for how they are advertised and implemented.

What are we really trying to achieve?

If we abstract it further, an ideal architecture should look like this:

Assuming the UI component is designed by the book and Core includes all business logic, we can actually remove UI and replace it with anything… Like a test suite.

If we achieve this, we can simulate every use-case with a test suite without needing any UI at all. Let’s have a look at login use-case:

Login (from user perspective):

• Enter username and password.
• Tap on login.

Login (in test suite):

core.dispatch(LoginCommand(username: "goksel", password: "123"))

This would be cool, right?

Enter “Core”

Our goal is to design a business layer that represents our app’s state without needing any UI component at all. Obviously, this is not possible unless we stop relying on view lifecycle. So we need another layer, which would simply be the source of life for our app. I’ll call this layer “Core”.

In our products, we generally have features like login, sign-up, movie-list, movie-detail etc. All of these features should ideally be self-functioning components which can be represented with a class. This class will contain that feature’s current state and will be able to process incoming actions to produce a new state. By doing this, we’ll have an isolated component for each feature, and all of those components and transitions will be managed by core.

The final picture would look like this:

As shown in the diagram;

• Core is simply a box that represents our app.
• Actions are the changes that happen on the system. They travel through Core and trigger state changes on components.
• Components contain business logic for features and are able to process actions.
• Subscribers can be anything. It can be a console app. It can be an iOS app. It can be our test suite.

Simple, right?

Talk is cheap. Show me the code.

It sounds good in theory (as always) but would this be easy enough to implement as well? Let’s implement a simple login screen with 2-factor authentication and see.

Requirements:

• Allow user 60 seconds to enter the security code. Pop back on timeout.
• Verify security code with a web service once user taps on login button.
• If verification is successful, push home component.
• If verification is not successful, show an alert.
• Show loading indicator when a network request is in progress.

Easy peasy. Let’s dive in.

1- Define the State

What makes the state of this component? What data do we need to render it on the screen?

• We need a flag to show/hide loading indicator.
• We need to keep track of timer status.
• We need to keep track of the verification process.

struct LoginState: State {
  var isLoading = false
  var timerStatus: TimerStatus = .idle
  var verificationResult: Result<Void>?
}

2- Define Actions

What changes can occur on this screen?

• Timer tick
• Tap on verify button

enum LoginAction: Action {
  case tick
  case verifyOTP(String)
}

3- Define the Component

Now we can define the component itself. All components will have a state and a process function. When an action is dispatched to core, all components will receive and react to it if necessary. If the state changes as a result of the dispatched action, component subscribers will be notified with the new state.

Note: State is a readonly property on Component class, however, it can be updated using commit function. This is by design and to avoid too many state updates. So to change state; create a copy, make all the changes and call commit. This will set a new state, and notify all subscribers.

class LoginComponent: Component<LoginState> {

  override func process(_ action: Action) {
    guard let action = action as? LoginAction else { return }
    switch action {
    case .tick:
      self.tick()
    case .verifyOTP(let code):
      self.verifyOTP(code)
    }
  }

  // ...

}

So this simply is our component. By overriding process function, we can react to incoming actions when necessary. As you may have guessed, the real magic happens in tick and verifyOTP functions.

Let’s take a closer look: 🔍

func verifyOTP() {
  // Get a copy of the current state:
  var state = self.state

  // Start loading before network call:
  state.isLoading = true

  // Publish state:
  commit(state)

  // Start network call:
  service.verifyOTP { result in

    // Update state with response:
    state.isLoading = false
    state.timerStatus = .finished
    state.result = result

    // Publish new state (and navigation):
    switch result {
    case .success():
      // Navigate to home if success:
      let nav = BasicNavigation.push(HomeComponent(), from: self)
      self.commit(state, nav)
    case .failure(_):
      self.commit(state)
  }
}

Although this function does async work internally, it doesn’t have a completion block because state propagation is done by committing a new state to the component.

4- Subscribe to the State

So from a UI point of view, nothing is async. View just gets a new state whenever it’s available and update itself. For example, LoginViewController would look like this:

class LoginViewController: Subscriber {

  var component: LoginComponent! // Injected by previous component.

  func viewWillAppear(animated: Bool) {
    super.viewWillAppear(animated)
    component.subscribe(self)
  }

  func viewDidDisappear(animated: Bool) {
    super.viewDidDisappear(animated)
    component.unsubscribe(self)
  }

  // MARK: - Actions

  func verifyTapped(field: UITextField) {
    core.dispatch(LoginAction.verifyOTP(field.text))
  }

  // MARK: - Subscriber

  func update(with state: State) {
    guard let state = state as? LoginState else { return }
    // Update UI here.
  }

  func perform(_ navigation: Navigation) {
    // Perform navigation here.
  }

}

5- Define “Core”

Core can be defined in global scope as below.

let core = Core(rootComponent: LoginComponent())

That’s it. After this point on, we are free to dispatch any action. 🎉

Bottom Line

Core can be seen as a Redux, Flux and MVVM hybrid. If we structure an app with Core, we’ll have Redux-like communication and state propagation. However, the component itself is very similar to MVVM’s view model which is very straightforward and easy to adapt.

Main differences between Core and Redux

• Redux is static. It expects you to define a big fat structure that expresses the app state in compile time. This can be challenging if you have reusable controllers that you present here and there a number of times. Especially in cases where your application flow is altered by server responses, you cannot easily define your app state in compile time without hacking the architecture. Core is dynamic. You only need to define the state and actions for the component you are working on. Component transitions can be handled dynamically.
• In Redux, there is no standard way to implement navigation between components. With Core, you get native navigation support.
• Redux focuses on application state, whereas Core focuses on isolated component state. In this regard, I find it easier to work in isolation on one component rather than getting lost in huge application state.
• In Redux, since the state is global, it’s easy to forget to do state clean-up when a screen is popped from the navigation stack. In Core, since every component stores its own state, when you remove a component from the tree, state gets disposed along with it. This is handled internally by navigation mechanism.

Why should I use it?

Because you get many things for free by doing roughly the same amount of work compared to other architectures.

• Separation of concerns: Each and every box in Core diagram has a purpose and a clear definition.
• Easy to reason about: It forces you to model your components in a way that they become easy to reason about. By defining a state for each component, you are also documenting them.
• High testability: Since UI is just a reflection of the state stored in the core, you can test your components easily by replacing UI with a test class. This test class would simulate the user and dispatch actions into core then validate the resulting state.
• Reusability: You can develop business logic with no UIKit dependency at all. Therefore it becomes highly reusable between different platforms (iOS, macOS, watchOS, tvOS).
• Detailed bug reports: You can record user actions with a simple middleware implementation and attach action stack to your bug reports. This would help you reproduce the same exact state that crashed the app and save a lot of time. I mean… A LOT.

However, this is not to say that Core is superior to every other architecture. There are no “right” way to solve problems in software development; it’s always about requirements and trade-offs.

So to choose the “right” architecture:

• Always keep yourself up to date but avoid Hype Driven Development.
• Define your problem well and choose the right trade-offs to solve them.
• And lastly… Avoid Massive-View-Controller — no matter what.

Thanks for dropping by!

Swift implementation for Core is available on GitHub. Give it a try!

You are very welcome to share your opinions here or submit issues on GitHub. Help spread the word. ❤️

Architecting iOS Apps with “Core” was originally published in NSIstanbul on Medium, where people are continuing the conversation by highlighting and responding to this story.