The new async/await Swift concurrency API released together with Swift 5.5 was finally unveiled during the WWDC 21 last June. This new architecture fulfilled all the expectations that we iOS developers had, who were eagerly waiting for this since the Swift first release in 2014, and whose hopes got boosted in 2017 with the Swift Concurrency Manifesto by Chris Lattner himself.

From all the new APIs and tools that were introduced, the new async/await syntax, Actors, and Tasks attracted most of the attention from the Swift community. And rightly so, these new additions improved considerably the readability of asynchronous code and the easiness when ensuring thread safety in our apps.

However, there was another mechanism introduced then that didn’t capture so much consideration even though they are very powerful when working together with async/await: Continuations.

What are Continuations?

According to the documentation, Continuations are a mechanism to interface between synchronous and asynchronous code, logging correctness violations.

More precisely, a Continuation is an object that captures the program state at a given point, being able to continue it when it is required.

This might still sound very abstract, but we can learn to appreciate it deeper when considering how Apple implements asynchronous code up until now, with callbacks and the delegate pattern.

Continuations shine with all their brightness when working with these two patterns: they act as a bridge between the old world (callbacks and delegates) and the new one (async/await to achieve a more readable and structured code) by helping to create new async functions facading the old ones.

This is helpful when facading third party libraries or Apple APIs containing these patterns, as in the case that we will see today.

Facading a delegate Based class with Continuations

In our iOS team, we like to facade some Apple or third party developers components with our own ones. The purpose of this pattern is manyfold, but three points really stand out for us:

• We improve the readability and usability of that component with an easier API that hides the details of a more complex one
• We make it easier to mock and thus improve testability in our code
• Being more loosely coupled makes it easy to replace that facaded component in case we want to use a new technology

Take for instance our LocationManager class. As pointed before, we want to simplify and hide the complexity of Apple’s CLLocationManager, that is implemented through the delegation pattern via the CLLocationManagerDelegate protocol.

To be simpler, we obtain the user location at a given moment just once, without the need to keep listening to location changes.

In spite of this, we do not hold anything against the delegate pattern per se; we take it as another powerful tool in our toolset that might be very useful for the right case.

Coming back to our case, it is essential to remark that because we need the location just once (fire and forget), we can convert our API to async/await, same way as before we used promises.

If it was required to be updated on any of the user location changes we would still have to use some sort of reactive programming paradigm as Combine or RxSwift, because there is a continuous flow to observe.

Swift Concurrency Evolution

The git history of the LocationManager file is a very interesting source to track the evolution of concurrency in Swift and our team.

After a brief period of using the raw Delegate Apple API, we started facading it by using callbacks, passing the new location to the client through a closure.

After that we discovered the power of Promises and created our own light Promises Open Source library to implement them, Pied Piper. (Again, if there was the need of being updated continuously we would have used a more Reactive approach).

Then Combine arrived, and we replaced that third-party Promises library with the Combine’s counterparts. And finally, the time has come, allegedly to stay for very long, when that returned Publisher can be kicked out and replaced by the await keyword.

The Combine Facade

As expressed, the last version of our LocationManager before async/await is implemented with the help of Combine’s Publishers and Promises:

As you can see, with the help of a promise instance property we are able to let this class client when the location is obtained, by retaining the returned publisher and reacting when updated:

From Combine to async/await with Continuations

That approach fulfilled the goals we had in mind when creating a facade: it hides Apple’s CoreLocation implementation details and provides an easier API to deal with.

But in our insatiable desire for improvement, we realised that that API can still be simpler and more readable by converting it to async/await. How can we bridge the CoreLocation asynchronous delegate pattern to it? With the help of our new friend, the Checked Continuation.

In a similar fashion to the way we return a publisher that will be updated afterward via the promise property, we will now use a checked continuation to keep the program state when the updateLocation is called, to continue once the location is retrieved:

Here we:

• Create a typealias for our continuation type to make it more readable along with our class
• Keep the location continuation in a property of that type
• When the location is requested we start a continuation asking the CLLocationManager to update the location. That continuation reference is kept with our property so it can be resumed with the right value when that is obtained. (Or with an error)
• In that manner, when we get the Core Location delegate callback with the updated location we resume our continuation with that value. That resumes the execution of the original function. If instead, we get an error, we resume it throwing it.

That way, the code to call our manager is much simpler:

Note how easy and clean is the call to obtain the location now, thanks to the new async/await syntax.

It is important to note that the continuation should be called to resume just once.

If we do not resume it the function client will be waiting forever holding the resources indefinitely

If we do it more than once “ala Reactive flow” your app will crash. No alternatives here.

Therefore, we have to be especially careful to dodge these calamities. In our case we avoid it by:

• Resuming the Continuation when CoreLocation returned an error. That way we are sure that it will be resumed at least once.
• Setting the continuation to nil right after it is resumed. That way we are sure that it won’t be called more than once. If the location is required again it will be recreated.

Checked or Unsafe?

Apple provides two types of continuations to be used: checked, and unsafe. As their name indicates, from the documentation:

CheckedContinuation performs runtime checks for missing or multiple resume operations. UnsafeContinuation avoids enforcing these invariants at runtime because it aims to be a low-overhead mechanism for interfacing Swift tasks with event loops, delegate methods, callbacks, and other non-async scheduling mechanisms. However, during development, the ability to verify that the invariants are being upheld in testing is important. Because both types have the same interface, you can replace one with the other in most circumstances, without making other changes.

Therefore, if you want to use unsafe Continuations you have to:

• Be sure that your Continuation will always resume
• Profile your app to verify that the extra checks that come along with Checked Continuations caused some performance degradation

If any of these points are not true for you I suggest staying in the safe territory using Checked Continuations, given the cost of having missing or multiple resume operations.

Recapping

In this article, we acknowledged the role of Continuations within the new Swift Concurrency Model, and why it can be relevant for us.

After briefly reviewing how Facades are crucial to achieving clean code and the history of concurrency in our application, we went forward to migrate our Core Location Facade from Combine Promises to an async syntax API with the help of Continuations.

Next, we stated the consequences of not resuming our Continuation or making it more than once, and when to opt for Unsafe Continuations instead of Checked ones.

I hope you now have Continuations as another powerful tool in your toolbox, ready to be used when migrating from Callbacks or Delegate patterns to async/await. If you have questions, remarks or suggestions let me know.

Happy coding!!

Convert Swift Facades Into async/await Syntax With Continuations was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the release of property wrappers together with Swift 5 and Xcode 11, many patterns can now be reimplemented in an easier, cleaner and faster approach. For instance, we use them at WELT to add an extra layer of logic to some UIColor instances, so the appropriate color value is provided depending on the user setting selected color mode. In the same way, we implemented a property wrapper that access Firebase Remote Config that provides the value specified by a key parameter. In this fashion we do not need all the repetitive code necessary to replicate this functionality without property wrappers.

Likewise, we wanted to implement a property wrapper that, given a key parameter, saves and retrieves a value from the UserDefaults. Furthermore, we needed to define a unique default value in case there is none stored, and we want to make it extensible to RawRepresentable values so it can be used with enums. In this post we are going to see what the heck are property wrappers, in what cases they can be useful, and how we can extend them to implement our requirements.

What are Property Wrappers?

According to the docs:

A property wrapper adds a layer of separation between code that manages how a property is stored and the code that defines a property.

That is, it is an extra layer that defines how a property is stored or computed when reading it. The main purpose of this pattern is to remove all the boilerplate code that you would have to write for each property that needs that logic. Again from the docs:

For example, if you have properties that provide thread-safety checks or store their underlying data in a database, you have to write that code on every property. When you use a property wrapper, you write the management code once when you define the wrapper, and then reuse that management code by applying it to multiple properties.

To illustrate, let’s take a look at this example:

Here we have defined a property wrapper that always provides the absolute of the set value. This way, we use the standard abs() function only once, instead of using it for every access of the property, or every getter and setter of those properties that need this logic. Similarly, the functionality is now encapsulated in its own struct, making the code cleaner and more readable.

Our case: App Settings in User Defaults

A very common pattern on iOS development is a wrapper over UserDefaults, in order to avoid the Read/Write code duplication, hide these details, and ensure testability by dependency injection. This is a perfect case to be updated with a property wrapper:

In this example, we wanted to know if the app onboarding screen was shown, in order to avoid displaying it again the second time the user opened the app. Thusly, in the RootViewModel , we add the wrapper to the property, and when the view did appear, we check that value. Note how easy it is here to access the stored value.

This code works, but it is obviously flawed. We return an optional, making the client responsible of checking whether there is a value, and providing a default value instead on every access.

Could we move this logic into our property wrapper?

Default Values

In the same way a property wrapper avoids repetitive boilerplate code, we want to encapsulate the default value logic into the wrapper itself, so it always returns a non optional and sets the client free of implementing that logic:

This is implemented in the property wrapper by adding a defaultValue property and returning it in case nothing can be retrieved from the UserDefaults. In such manner, the property wrapper returns a non optional and the client can just add the required default value in the initializer.

Now it looks much better, but, what if we want to have a unique default value for all the application? In the previous example each client, in this case the RootViewModel , is able to specify the default value they want. This is totally fine for our onboarding use case, but what if we do not want to give the property wrapper client the power to define the default value?

What if we want to have a unique default value for all the application?

For instance, imagine we have an UserDefaults setting that holds whether we want to use our backend dev environment. We need this setting to be consistent along the whole application, that is, always point to the same backend environment to avoid an unconsistent and confusing state. On top of that, the user should be able to change this value anytime, for instance, if the QA Team wants to test a task against any environment.

Again, we do not want the class where the property wrapper is applied, for instance the Network Fetcher, to bear the power of defining that default value. We want this logic to be unique and contained in its own class. For that, we take note of how Apple implements a generic key definition process of the SwiftUI Environment property wrapper with EnvironmentValues. Check these links for more information.

Going back to our example, we want to define a global unique default value for our environment setting. Given that what defines that setting uniquely is a key, we create a protocol that will act as a key to retrieve the value. This key protocol will contain a static property to hold the default value to be returned in case the setting is not yet in the user defaults.

As our pattern can return a generic value, we need an associatedtype within this protocol:

Next, we have to write an intermediate class to encapsulate the logic of retrieving the UserDefaults value given an AppSettingKey:

Note how it will return the key static default value if there is no value stored in the container.

Now that we have this proxy to the UserDefaults, we can rewrite our property wrapper to use it:

In the wrappedValue property it uses AppSettingsValues to retrieve the stored value.

Finally, we have to create a key for our specific setting case. It implements the AppSettingKey protocol and an extension of AppSettingsValues to provide the key as a ReferenceWritableKeyPath :

Once we have everything, we can use it effortlessly:

We just pass the AppSettingValueskeypath created together with the UseDevEnvironmentKey to the property wrapper initializer, and it’s ready to use. That simple!

But I have an enum!

Again, the example is doing what we want, but we are not quite there yet. As you saw, we use a boolean value to determine which environment we are going to point: if it is true we use the development endpoints, otherwise production. This is suboptimal though.

What if, on top of dev and prod, we also have a test environment? How can improve our code to handle multiple cases? Cases?, yeah, we need an enum But wait, it is not so simple, even if we can change our environment data representation from a boolean to an enum, this type cannot be stored by default in the UserDefaults. We need to make that enum conform to the RawRepresentable protocol, by specifying a string, integer, or floating-point raw type. The Swift compiler automatically adds RawRepresentable conformance when doing it:

public enum Environment: String {
  case development
  case test
  case production
}

Once we have a raw value for each case, we can store that value in UserDefaults, and when reading it, we will create an Environment instance from the raw value. This is implemented by creating its own App Setting Key protocol to enforce that the associatedtype conforms to RawRepresentable and adding a new subscript function in the AppSettingsValues class:

Note how powerful is the where keyword in swift, it allows us to easily filter out values, in this case those that don’t conform to RawRepresentableAppSettingKey

Epilogue: Testability

Without delving too deep in a topic that deserves its own post, we ensure testability by allowing the injection of the needed dependencies. The UserDefaults container is passed in the initializer of the AppSettingsValues, so we can inject it when testing. For instance, we could create our own UserDefaults instance other than .default, by initializing it with a suite name. Once we have that instance, we pass it to create the AppSettingsValues, and set this one to the property of the AppSettings property wrapper:

Wrapping Up

We went through many topics today:

• What are property wrappers and what are they used for
• How can we apply property wrappers to read and write values from User Defaults
• How can we add a default value for each use case of our User Defaults
• How can specify a unique global default value for a property wrapper key
• How can we enhance our User Defaults property wrapper to apply it to enums
• How can we ensure testability by injecting our User Defaults container

I hope you liked this story and can profit from it. If you have any question or suggestion do not hesitate to drop a message below. I would like to thank my colleagues Ivan Lisovyi and Haroon Ur Rasheed for their critical contribution on this topic.
Happy wrapping!!

Swift Property Wrappers, User Defaults and Unique Default Values was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the Product Owner’s green light for dropping the support of iOS 12 downwards, a new world of juicy possibilities emerged in our development horizon. Together with iOS 13 two major new Apple frameworks were released: Combine and SwiftUI, the new framework to design and develop user interfaces declaratively and with less code. For the former we lost no time in replacing our aged third party library and start using Combine everywhere Reactive Programming or Promises were applied. For the latter, SwiftUI, even if we could barely contain our excitement to see it running our user interface, we were more cautious given the early mixed feedback from the iOS devs community.

In this story I want to present the process we followed to start using SwiftUI in our production codebase, from the planning strategy to the actual code writing. We will see why it might be good idea in the first place, how we can do it in a safe and interesting manner and what troubles we encountered and how we solved them. At the end you will find the conclusion with our personal opinion based on experience and tips for your first rendezvous with SwiftUI.

So, same as John Rambo in the first instalment of the franchise, it was time to start walking towards our sure fate and plan how we can integrate SwiftUI in our production environment. Notwithstanding, before starting writing code, a moment of pause and reflection is necessary: why do we even need to do that? Is it just the developer’s frenzy of new technologies, or will we really profit from it?

Why?

Don’t panic, this is not going to be the zillionth post comparing SwiftUI and UIKit. But still, it is important to mention what was the drive when we decided to trigger the process.

For starters, as I said before, SwiftUI helps to create the same UI design as UIKit with significantly less code. The advantages that this produces are obvious: generally less code means better Readability, easier Maintainability, more Efficiency and substantially fewer expected Workload, that is, we will spend less working hours to achieve the same results, not only because of the amount of code required, but also because of the Live Preview used when development. So, with SwiftUI we expect to …

• Improve Readability
• Make the code easier to maintain
• Enhance the code’s efficiency
• Reduce the expected Workload

Not bad uh? I am convinced that this is just enough to sustain our decision to start using SwiftUI. But on top of that, with this new framework we will move even further in the direction of a more reactive and declarative syntax, a way that as remarked we started years ago and followed when introducing Combine. Because yeah, do you know what uses SwiftUI to implement its reactive logic? Bingo, Combine!

Apart from that, SwiftUI is allegedly easy to use, the code is clean and it can be integrated perfectly with UIKit. That means that we can conveniently migrate some parts of our UI code to SwiftUI, while the rest remains written within the bounds of the UIKit syntax.

Last but not least, we listen to our yearning to try something that might change we way we think and develop User Interfaces for many years to come. And we wanted to do that in real fire production code, the best arena to learn with the mistakes encountered along the way, both ours and those caused by such an early stage tool as SwiftUI.

Alrighty! We have now a why, what is missing to start working with it? Of course, a how!

How?

What a good question, how can we start writing our UI in SwiftUI? There are not many alternatives at this point, either we wait for new UI features to pop out from our backlog, or we migrate some of the already existing screens. The second option is less risky and more convenient to mitigate the learning curve pain of adapting this new technology. Basically, we just want to rewrite a simple yet custom screen. We want to find some challenges along the way, the key to learning something new.

Either we wait for new UI features to pop out from our backlog, or we migrate some of the already existing screens

The biggest caveat of this approach is the apparent lack of added value, or at least short term added value, outside of the devs team. After all, we are just replacing one screen … with the exact same screen. Thankfully, we have a negotiated time budget for technical improvements.

Given the clear benefits of refactoring the existing UIKit based Views to use SwiftUI (contained risks, smooth learning) and being able to endure the few drawbacks that might bring, we opted for that option. Thus, we then had to find an existing screen that matches our criteria, simple, but yet with some custom complexity.

The Stocks view is perfect for that. A table with custom designed cells that represents displaying a data model retrieved from a backend endpoint, together with a pull-to-refresh control that triggers the refresh of the screen content:

Thanks to UIHostingController, it is painless to integrate this SwiftUI view back into the UIKit Navigation Controllers architecture.

Challenges

The development process of the basic features of this screen is very straightforward: the former UIKit UITableView is now replaced with a SwiftUI List, the cells are easily buildable with an HStack that composes the Texts. Those in turn, are rendered with different background colours that are applicable as view modifiers. It is here where SwiftUI supposedly excels and I can certify; what it used to be many lines of UIKit based code, it is now just a bunch of much more readable declarative code lines. In particular, the concept of having a single entry point for describing a view, is just awesome and much simpler to read and build. Plus one, SwiftUI!

What it used to be many lines of UIKit code, it now just a bunch of much more readable declarative code lines.

Granted that, It is when we bring our rebel side and try to go off road that we start suffering, especially if, still supporting iOS 13, are obliged to work with the first version of the framework.

For instance, at this time SwiftUI does not include a refresh control that mimics the action of the former and beloved UIKit’sUIRefreshControl, so we ourselves have to build it. Or better said, we can rely on this external library that achieves it by introspecting the hierarchy of the relevant UITableView that stands behind the SwiftUI scenes.

Introspect is a word that you will hear very often while working with SwiftUI: the first resort to be used in order to implement something not supported out of the box by SwiftUI will be to introspect the underlying elements behind the SwiftUI components, most likely UIKit ones, to modify them according to our requirements. SwiftUI-Introspect might be the first tool in your toolset when the time comes. The downside of this approach is obvious, apart from having to rely on an external dependency, with any new version of SwiftUI new changes in the implementation might come and break your flow. But still, until the iOS SDK includes all these components, there is not much we can do.

Likewise, ase we wanted to remove the extra separators that appear below the list by default, we had to modify the tableFooterView property of the table view appearance on appear, and reset it on disappear:

.onAppear {

UITableView.appearance().tableFooterView = UIView()

}

.onDisappear {

UITableView.appearance().tableFooterView = nil

}

Another tweak to the UIKit underlying element to achieve our visual demands. Note that this happens only on iOS13, on iOS 14 by default there are no separators under the list.

Furthermore, the biggest challenge we face when working with SwiftUI is coming up with an architecture that binds our data to the view in a reactive way.

The true difficulty here resides not so much in implementing those bindings, but in shifting the mindset paradigm away from the UIKit-friendly architectures, such as MVC, VIPER or even MVVM. Now SwiftUI forces us to change our attitude into a new way of thinking, where of course the main premises of Clean Code stay, but declarativeness and reactiveness prevail. And while SwiftUI together with Combine provide the right tools for building a small sized codebase, for a larger, more complex, feature scalable and modular App it falls short.

For a larger, more complex, feature scalable and modular App SwiftUI falls short.

To illustrate without delving too deep, it is difficult to find a solution to persist our (complex) App State that is scalable, and at the same time easy to mutate along the different views. The given State property wrapper used by SwiftUI should be used with simple struct types (Int, String, Array …) and not be shared with other views.

In like fashion, it is not possible to split a large app state into smaller ones, for instance, to be used in different modules. With a more modular approach, each package would only have access to the state elements relevant to its functionality, making the architecture much more encapsulated and safe. As a consequence of these points, and also because of the lack of tools and documentation on the subject, it is very difficult to test a SwiftUI view or its side effects. This is very important; testability is a sine qua non condition for our business logic implementation.

Consequently, and thinking long term, we use The Composable Architecture to address these issues. TCA is a open source library that provides:

A few core tools that can be used to build applications of varying purpose and complexity. It provides compelling stories that you can follow to solve many problems you encounter day-to-day when building applications, such as, State management, Composition, Side effects and Testing

While TCA is optimal for SwiftUI, it can be also used together withUIKit, as well as on every other Apple platform (iOS, macOS, tvOS, and watchOS). If you want to know more about it plus more Swift functional programming topics, visit their Video/Blog site pointfree.co.

In that manner we solve the problems we enumerated before: we can now create our Stocks View in a separate, encapsulated and fully testable module, that fits perfectly into our modular App.

In short, when working with SwiftUI we faced these obstacles:

• Lack of tools to display complex design elements (Refresh Control, List separators …)
• No scalable and composable App State
• Cumbersome Testability

For now we used Introspect and TCA to solve these issues, but we are confident that SwiftUI itself improves with future versions as it did with SwiftUI 2 on iOS 14.

The Aftermath

In this story I just described how we introduced SwiftUI in our production code. We did it to learn and to have a more declarative, readable, efficient, smaller and easier to maintain code. Besides, I explained how migrating a simple screen would be the easiest entry point to start dealing with it. And furthermore, we know now what are the main challenges when venturing into this up-to-now uncharted territory, and what weapons do we have to emerge victorious.

I would like to thank my colleague Ivan Lisovyi for the huge contribution to this topic. As always, if you have any suggestion, correction or comment drop a message below.

Happy SwiftUIting!!

SwiftUI in WELT: First Blood was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yeah, it happens. Time flies. “Tempus Fugit” as the cool people used to say. It could be a new grey hair or wrinkle when facing the merciless mirror, the sudden realisation that your team did not win the league in few years or an iOS library written for iOS 8. And the sooner we accept that fact, the sooner we can cope with it and go on with our lives. Accept the things I cannot change, don’t look back and all this. Only that there is something we can change here. We can retake our decrepit library, give it some energizing love and resurrect it with a fresh and youthful look.

On NMT we use any given chance to encapsulate an implemented feature into a library, and if time and privacy allow it, publish it Open Source for the common good. The proof is in the pudding: back in 2016 we extracted the Homescreen Navigation of our WELT News App into LazyPages, a highly customizable library that helps you to show a scrollable list of view controllers synchronized with an index menu. With Lazy Pages you can lazy load your view controllers, instead of having them all in memory when creating it.

But, as time is impermanent, so is the UX & UI Design of a product whose owner is eager to improve. For a time we opted for a kinda like Burger Menu to navigate among the sections of our app, to later realise that the original Lazy Pages approach produced more traffic and optimized our app’s user experience. It was time then to open the storehouse of memory searching for Lazy Pages again.

The advantages of both modularising your architecture and publishing Open Source are common knowledge nowadays, so I won’t delve into these topics here. Instead, I’d like to focus on the why and how we can bring these old libraries back to life.

Why?

Of course, as with any other aspect in our lives, the big question comes: why? Why spending even a tiny bit of our precious time in that? Well, for us the answer was easy; we needed that functionality again, and we needed it in production. That means that, as any other piece of our code, it had to be adapted to the latest requirements.

But even if we are not going to use it, maintaining our Open Source libraries is very convenient. Firstly, because that way it could still be used by the community. Likewise, keeping a product up to date would encourage other users to contribute, and in that manner, leverage the necessary effort to sustain a well looking product.

In addition, our personal or brand name will still be linked to a well maintained product, avoiding the bad impression produced by the unfortunate “last commit three years ago”.

I still don’t wanna do it!

Ok ok, there are cases when we do not want to spend time on it. Maybe our project is redundant because Apple already provided that functionality in a later version of the SDK, as they did with Combine for Reactive Programming. Or perhaps the huge amount of required effort to migrate from ObjC to the latest Swift version or to make it compile with the newest SDK makes it simply not worth it.

In that case there is still something we can do instead of deleting it. We can archive it. That means that we are not actively working on that project, and likewise we won’t accept any further contribution. It makes it read-only:

Just because a repository isn’t actively developed anymore and you don’t want to accept additional contributions doesn’t mean you want to delete it. Now archive repositories on GitHub to make them read-only.

Just like that we can quickly show our userbase that the library is no longer being updated so they should use it at their own risk, and by the same token it will probably need a bit of refurbishing before using it.

But be wary of this option; as stated above, archiving means that no further contribution is allowed in your repo. It could be the case that you don’t have time to enhance your owned library, but any other kind fellow developer might be eager to do that. If we archive it they won’t be able to do it anymore.

The Quest for Eternal Youth

Yeah, you convinced me, I want to renovate or maintain that old library of mine. What should I do? Can you provide me a checklist to achieve it? In order to update our library, we should:

• Migrate it to the last Swift Version
• Make it compile with the last iOS SDK
• Use new technologies
• Convert it to a Swift Package and support Swift Package Manager
• Update your README file and draft a Release
• Add it to the Swift Package Index

Here we go! Firstly and foremost, we have to …

Migrate it to the last Swift Version

Yup, if we are going to make it, we have to eat that frog first. So in the case that we have an old Swift version or, even worse, if our library is still in Objective C, we have to migrate to the last Swift version so it can benefit of all the advantages of the language. We are many developers that would prioritise a Swift codebase over Objective C almost blindly, among other reasons because of the easiness of the package integration and future usage. That brings us to the next topic , it …

Should compile with the last iOS SDK

Yeah, if we migrated to the last Swift version this step was probably required, but notwithstanding it is worth remarking it. Your library should be buildable with the last OS SDK version so it can be usable in any project. Needless to say, this does not mean that we should supporting older iOS versions, we can still set our minimum deployment target to a previous value. We will delve into this when talking of SPM, but now that we are using the latest iOS version, we can …

Use the newest technologies

Together with newer versions of the iOS SDK, new features and technologies APIs are shipped by Apple, APIs that can be integrated in your library replacing or enhancing your old codebase. For instance, if you used reactive programming with RxSwift you can now use Combine, getting rid of one big dependency and thus decreasing the build time. If you were using ARKit, you can now use the brand-new Depth API introduced in ARKit 4, thus making your package much more attractive for the community.

Once we have our codebase ready, it is time to …

Convert it to a Swift Package and support Swift Package Manager (SPM)

Whether your library is older than Xcode 8 or you preferred not to support it due to its early stage, now it is essential that your package is installable through Swift Package Manager. With Lazy Pages we were as far as to remove the support for CocoaPods, in order to simplify the installation process.

SPM is the standard tool build by Apple to distribute Swift packages. It is fully integrated in Xcode and automatically manages all the dependency’s dependencies, what makes the process painless and transparent. Here you can delve deeper into how to create a standalone Swift Package, or convert your existing codebase.

If you already have your shiny new Swift Package, you should …

Update the README file and draft a new Release

After the changes above it is very likely that the information in the README.md file should be updated. Your requirements are different now: you require higher versions of Xcode, iOS and Swift, and furthermore, it should be stated how to install it via SPM.

Moreover, if the changes forced your to modify your library’s public interface it is time to edit your usage code snippets, to include the new additions.

Similarly, a new library version should be drafted, with a proper tag version, title, and a short description mentioning whether this new release included breaking changes, so your users can decide to install it or postpone the effort of adapting to the new modifications.

All your hard work deserves to be acknowledged. You can finally …

Add it to the Swift Package Index

These days, with the immense amount of information and resources available in the internet, it is likely that your library gets lost it is not somehow indexed. To avoid that, you can of course write a blog post about it, send it to your favourite iOS developer community newsletter, or add it to the Swift Package Index.

Swift Package Index is the place to find Swift packages, indexing at the moment 3,486 packages and 53,590 versions, and growing everyday. To add your package there, check their Master List repository to submit it. As they say:

Please feel free to submit your own, or other people’s repositories to this list. There are a few requirements, but they aren’t onerous.

That’s it!

That was it, not so tough right? Now your team and the community are thankful for your shiny package, that can be used again as if it were totally new.

In this post we have seen why and when it is important to maintain and keep our libraries up to date, how to do it, and when it is not worth doing it. Even in the latter case we can do something with it.

Certainly i might have missed some important steps along the process, if you think so or have any other suggestion please add a comment here.

Carpe Diem!

Bring your old iOS Library back to Life in just few easy Steps was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous stories Warhol and Warhol II I talked about how we can easily detect the user face features and render our desired overlay on top of them thanks to Warhol, a library of my own. For that I used the Apple Vision Framework, that among other things supports the detection of items such and face and face landmarks. Furthermore the Warhol client shall not deal with Vision at all, as it is hidden behind the library interface thus alleviating the effort of the client implementation.

During Warhol’s development process something came to my mind. Wouldn’t it be cool if, on top of the user features, we could detect face expressions as well? So, not only detect where is the user’s eye, but also when they wink it, open the mouth or smile. The use cases for this functionality are numerous; no more swipe left or right on Tinder but wink left or right, help disabled users to interact with our app via face gestures or make your videogame character jump by opening the mouth.

Unfortunately Vision does not offer such feature, but do not fear, thanks to ARKit we can obtain information about the pose, topology, and expression of a face that ARKit detects in the front camera feed. These capabilities were introduced on iOS 11 and requires a device with TrueDepth camera. This camera replaces the front one on the iPhone X and later, being capable of capturing 3D information for Face ID authentication and Animoji.

With that goal I developed Wink. Wink is a light reactive library written in Swift that makes easy the process of Face Expressions Detection (blink, smile, mouth open…) on IOS. It detects a default set of user face expressions using the TrueDepth camera of the iPhone, and notifies you on real time using Combine, Apple’s reactive framework. That way, the Wink client does not need to know anything about ARKit, only if they want to extend the set of Face Expressions detected.

Wink is a light reactive library written in Swift that makes easy the process of Face Expressions Detection (blink, smile, mouth open…) on IOS

Wink provides a view controller with the camera view, and a Combine AnyPublisher that gets updated whenever the user changes the expressions. We can then add that UIViewController to our view hierarchy and react to any any new user face gesture. In case we do not want to show the camera view, we can just hide it or resize it and place according to our requirements.

Behind the Scenes

In this section we are going to see how Wink uses ARKit to to detect the user face expressions. If you wanna start using Wink right away in your app, go directly to the next passage.

As in any other AR experience with SceneKit, we need to create an ARSCNView instance, that will be added to our FacialExpressionDetectorViewController view.

After that we set the delegate to our class, that will receive the view’s AR scene information with SceneKit content. Once we have added the view to our hierarchy and set the delegate, we call to run the session with a face tracking configuration in viewWillAppear:

In the same way, we should not forget to pause it when the view will disappear.

Once we have setup the ARSCNView that will display the AR experience and run the session, it is time to start detecting the face expressions and pass them to the client. We do this through the ARSCNViewDelegate methods:

Firstly, we have to return a new node with the representation of face topology in the our scene view for each 3D anchor, that is, the position and orientation of something of interest in the user’s face. If these concepts are too advanced for you or you need to refresh them, this tutorial is perfect to get familiar with the ARKit basics.

Now that we have a node for each anchor, ARKit will let us know whenever the node was updated, that is, when new information was obtained from the scene view:

Here we refresh our nodes with the face anchors, and proceed to detect the facial expressions from the ARFaceAnchor:

To better understand this, we need to know what is aFacialExpressionAnalyzer in Wink. A FacialExpressionAnalyzer is a struct encapsulating the data needed to detect one specific face expression:

It contains the Wink FacialExpression object that represents the gestures in the user’s face (mouthSmileLeft, mouthSmileRight …), the AR object that it corresponds to, and the minimum valid coefficient to accept a facial expression as actually happening. As pointed before, Wink comes with a default set of analyzers:

that is created and assigned inFacialExpressionDetectorViewController:

As we will see later, it is very easy to extend this functionality with our own with having to modify the code, thus following the Open-Closed Principle:

“Software entities should be open for extension, but closed for modification”.

Going back to detectFacialExpression(from anchor: ARFaceAnchor), we see how we compactMap the analyzers into face expressions whose current value is higher than the minimumValidCoefficient, meaning that the user is actually doing that gesture as much as our requirements accepts them. Once we have the array with the current Face Expressions, we send it through the Combine'sPassthroughSubject object.

Let’s Play!

This was all very interesting, but to the developer who wants to roll fast it will be probably not so useful. After all, the purpose of Wink is to ease the process of face expression detections without the need of dealing with the compelling but arcane world of ARKit.

To start using Wink in your screen’sUIViewController, create a new instance of FacialExpressionDetectorViewController and add it to the former through the usual process of view controller containment:

You might then want to place it as you wish adjusting the constraints, or hide it if you don’t want the camera view to be shown. In this case we add it to the upper left corner of our view:

After these steps, it comes the climax of the movie; we have to subscribe to the User Face Expression changes, sinking the Combine publisher that come with the FacialExpressionDetectorViewController:

In our sample app we are just describing the current face expressions with the help of a FacialExpression extension, in your case here is where you react to the user face expression changes to trigger the desired action:

In this debug sample you can see how Wink detects my face expressions, and how the client react to them displaying a description of the retrieved gestures. The statistics and the web are part of the Wink debug mode, they can be of course be disabled in production.

That’s it! The process of using Wink is very straightforward, just four steps:

• Create an instance of FacialExpressionDetectorViewController
• Add it your view controller
• Place or hide the camera view according to your requirements
• Subscribe to changes and react to them

Advanced

Detect More Expressions

With the process above we can detect those face expressions included in the standard default set of Wink Face Expressions to be detected. But, what happens if we want to detect a gesture and it is not there? What if we want to detect when the user’s left eye is wide open? Very easy! Thanks again to the open/closed principle we can add this functionality without having to modify Wink’s code:

We create a new FacialExpressionAnalyzer with the new Wink FacialExpression , the AR BlendShapeLocation that should be detected and the minimum accepted coefficient to consider that gesture as actually happening. For a complete list of BlendShapeLocationyou can detect, or in other words, new user face expressions, please refer to the Apple Documentation.

Change the Minimum Valid Coefficient for a Face Expression

Yeah, it is that easy. In the same way, we can modify the minimumValidCoefficient of the default analyzers to meet our specific requirements:

We create a new analyzer with the expression we want to modify, assign it a new coefficient, and replace the old analyzer with the new one. In this case, we will accept a hint of a left smile (0,2/1) as valid, we feel so generous.

Recap

That’s all friends! Now you can react in your app to any user’s face expression input to develop new functional, helpful and funny features interactions. After reading this post we know:

• How you can detect and react to the user face expressions through Wink
• How can it help you
• How it uses ARKit to detect the Face Expressions behind the scenes
• How you can react to the User Face Expressions in your app using Wink
• How you can extend Wink to detect more Face Expressions or change the minimum valid coefficient of one of the default ones

To know more about Wink and start using it, Check here for the link to the GitHub Repo Page You can easily integrate it with Swift Package Manager, or just dragging the source files into your project.

And of course any contribution, suggestion or question are more than welcome, either here in the comments or opening an Issue in the GitHub Repo.

Happy Winking! And remember:

Wink! Or How your Users can interact with your iOS App by changing their Face Expressions was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hide your Implementation Details to make your Code cleaner and safer

Our iOS Team at WELT got recently very good news, we could set our App iOS Deployment Target to 13.0. That means not only that we should not support old versions anymore, but also that we can start using the cool APIs that were introduced in that version, especially SwiftUI and Combine.

With Combine we can write functional reactive code to process values over time through a declarative Swift API. It can be compared to other takes on this approach for Swift, such as RxSwift and ReactiveSwift.

Tip: If your app still cannot fully support Combine because the minimum deployment target is lower than iOS 13.0 don’t worry, you can start migrating it by using OpenCombine. According to their docs:
The main goal of this project is to provide a compatible, reliable and efficient implementation which can be used on Apple’s operating systems before macOS 10.15 and iOS 13, as well as Linux and Windows.

That way, given that their API is exactly the same as Combine, it will ease the migration process to Combine in the future; ideally you will just have to replaceimport OpenCombine with import Combine.

Coming back to Combine, for now two concepts are essential for those familiar with the RxSwift syntax or similar:

• Observables are Publishers in Combine. They expose values that can change.
• Observers are Subscribers in Combine. They subscribe to receive all these updates.

With this in mind, let’s see one example where we can use it.

Combine and MVVM

Combine, as any other reactive framework, is especially adequate to implement a MVVM architecture: the View Model encapsulates the processing and exposes the UI data, that can change over time. The View subscribes to the View Model to receive these updates and react accordingly, refreshing the UI and showing the new values to the user. Together with all the chaining operators that the reactive frameworks provide, it makes the code more declarative and thus readable.

In this example, we want to show the user a sport event result. As it changes over time, reactive programming is ideal for our case.

The first version of our ResultViewModel with Combine would be something like this:

Our View Model listens to the result updates from the fetcher implementing the delegate method, used for simplicity sake in our example (we could very well be using reactive programming in this layer as well). Once a new result has arrived, we use a PassthroughSubject that broadcasts new data to downstream subscribers, in this case the view, so it can accordingly refresh the UI:

Here, we subscribe to the View Model updates on the result, react refreshing the label when a new value is received always on the main thread, and store the AnyCancellable object in a Set, so we do not lose the reference.

Abstraction!

The example above works fine, we are implementing the business logic as required: every time the result changes it is reflected in the UI. But correct as it is, the code is still very faulty.

Why? because with PassthroughSubject we are exposing the implementation details of our operation. That is bad by reason of generating a dependance between the client, in this case the View, and the implementation, making it easy to break by any change or modification in the latter. Imagine for instance that the View Model needs to keep a buffer of the most recently published element for tracking purposes. In that case we cannot use the PassthroughSubject, but CurrentValueSubject instead. The View Model API will change.

But more importantly, with PassthroughSubject, we give the power to the view to send events through it, something that is clearly not its task. It should just listen, not update it. Our code isn’t safe.

This is when AnyPublisher comes on the scene. According to the Apple docs:

Use AnyPublisher to wrap a publisher whose type has details you don’t want to expose across API boundaries, such as different modules. Wrapping a Subject with AnyPublisher also prevents callers from accessing its send(_:) method. When you use type erasure this way, you can change the underlying publisher implementation over time without affecting existing clients.

This is exactly what we want:

• Hide type details
• Prevent callers from accessing send(_:)
• Be able to change the publisher implementation over time without affecting clients

Oh, but wait, we can still push it a little bit forward into the Abstraction Realm right? We can create a protocol for the View Model, thus hiding more details (the Data Fetcher for instance) and enhancing testability by replacing it easily with a mock when unit testing it. For more info about Protocol-Oriented Programming in Swift, check this link.

Consequently, we can already implement our new version of the View Model:

This way we are just exposing an AnyPublisher object, so the clients can subscribe but not update as intended. With eraseToAnyPublisher() we achieve exactly that, to expose an instance of AnyPublisher to the downstream subscriber rather than this publisher’s actual type, an action that we call Type Erasure: we hide implementation details by exposing a more abstract type, a technique that can be applied thanks to polymorphism. Now the View has the right access level to the Publisher.

Another Turn on The Screw?

As Henry Miller in his superb novella, you might still want to push it a little bit forward. Why not using Publisher instead of AnyPublisher? Isn’t it even more abstract? At least it sounds so …

The answer is no, Publisher and AnyPublisher are different things, with different purposes: with Publisher we cannot achieve Type Erasure as with AnyPublisher. The former is a protocol with associated types, therefore it can be used when you define a function that has generics as part of the definition, such as a Protocol Extension, e.g. when creating a custom Combine operator. An example from here:

extension Publisher {
public func compactMapEach<T, U>(_ transform: @escaping (T) -> U?)
-> Publishers.Map<Self, [U]>
where Output == [T]
{
return map { $0.compactMap(transform) }
}
}

Conclusion

Now that iOS 14 is released, it is more likely that you will be able to drop older iOS version, thus being able to migrate to (or start using) Combine. When doing that, we should as always be conscious of writing a readable, maintainable and safe code that uses Abstraction when possible. Apple goes in the same direction, and adds Type Erasure to our toolset. There is no excuse to avoid ensuring Abstraction when writing your implementation with Combine.

To recapitulate, in this article we have seen:

• How we can ease the future reactive migration process to Combine by using OpenCombine with earlier iOS versions
• How we can use Combine to implement a simple MVVM solution
• How we can support Abstraction and Protocol-Oriented Programming with Combine
• Why we cannot use Publisher in the place of AnyPublisher

I would like to thank my colleague Ivan Lisovyi for his splendid insight and contribution about this topic, without which this story would not have been possible. As always, if you have a question or contribution please drop a message below.

Happy Abstraction!

Ensure Abstraction in your iOS App Codebase when using Combine was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today I’ll cover a different topic than usual. In fact, i am not going to mention the word Swift (oops, just did) or iOS in the whole article. On this occasion I will talk about a personal project I developed while enjoying my summer holidays in the south of Spain: my personal website.

Why a personal website?

To be honest, the main reason why I created my own website was to learn the technologies involved in the process. We as mobile developers sometimes see the web and its environment as something obscure and arcane. Nothing further from the truth. As we are going to see, the development of a simple and good looking web page is a very straightforward process, given the cool technologies we can use.

On top of that, as a Software Developer, having your own website is a perfect scenario to showcase your skills, projects, and experience at one single place. If not your personal website, you can choose to create something less egotist as a blog focusing on your area of expertise. These are popping up like mushrooms these days, some of them really well curated and visually pleasant.

What do we need?

Once we know what (a simple personal website) and why (to learn, to enhance my professional image), we need the how, and as Nietzsche suggested,

“He who has a why can bear almost any how”.

So in order to successfully achieve our task, we need three steps:

• A Domain
• The Website itself
• A Hosting Service

The Domain

Even if that is not necessarily the first step in chronological order, it is allegedly the most exciting, envisioning your own website URL in the browser address bar.

The domain name should be simple and short, avoiding double or special characters, such as dashes and hyphens. If you do not have the misfortune of sharing your name with a popular baseball player as in my case you should stick to .com as top-level domain, otherwise I would go with your country one, or something easy to remember. In my case, it was my name + surname + country top-level domain: cesarvargas.es: short, catchy and memorable. Of course, all these tips are very good but we depend on the domain availability: it could be taken, or cost a large sum of money:

“Everybody has a plan until they get punched in the mouth.” Mike Tyson

Once we dodged that punch and came up with an available domain name we should purchase it promptly, before our best frenemy does it.

There are nowadays many Internet domain registrar companies with similar services, I went for GoDaddy because already had an account. It is allegedly the largest domain provider, with its simplicity and pricing as their largest strengths. The cheap prices can be deceiving though, as they would charge for something as simple as privacy. On top of that, be ready for a ton of spam if you are not renewing your domain and their continuous tries to upsell you.

In the other hand, if you feel brave and want something more powerful, you should take a look at Google Domains or Amazon Route 53

The Page

Once we have a domain, it is time to develop the website itself. As you may suspect this is the longest task but do not fear, in our case it will be uncomplicated.

As far as we are concerned, we just need something simple. It will show the same content to all users and all contexts. It will rarely change, maybe we will edit our bio or project texts but once performed, it will be very stable. Oh wait, we just defined a static website!

A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user’s web browser exactly as stored, in contrast to dynamic web pages which are generated by a web application.

Consequently, a static web page displays the same information for all users, from all contexts, subject to modern capabilities of a web server to negotiate content-type or language of the document where such versions are available and the server is configured to do so. Wikipedia

So, what are the advantages of a static web page compared to a more dynamic web application?:

• It is safer, being so simple it has fewer vulnerabilities.
• More performant, faster.
• Fewer dependencies, no databases, no CMS. Fewer headaches.
• Cheaper, we just need a cloud storage.

Of course, dynamic web applications are a must if we want something more complex, with queries and other dynamic functionality, but given that we do not need that, we can safely go for a static one. The biggest restriction we have is that any personalization or interactivity has to run client-side, which can be cumbersome. But again, that is not something we should worry about here.

Yes! we want a static website, and we will accept any external help to achieve our task. We will make use of Jekyll. According to their repo, Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind GitHub Pages, which you can use to host sites right from your GitHub repositories.

It was recommended to me for its simplicity and ease of configuration. Furthermore, as we will see, it is well known and supported in the community, where you can find free and paid templates that match your case.

So, once we have the technology, we need the most important part, the content. And again, in search of simplicity, we will download a template and adapt it to our requirements instead of creating it ourselves. Take a look at Jekyll Resources, where you can find a handsome case that matches your scenario. But we should not constrain ourselves only to a preset Jekyll Theme, if we already have an HTML site we can easily convert it to Jekyll following the process described in this article.

Alright! We have a theme, but the content is not personalized for our story, we should add our information so our moms can proudly show it to relatives and friends. And here it is where the perks of Jekyll come to shine. If the template was flexible enough, the content is easily customizable by adding the visible properties defined in the _config.yml A ton of HTML or CSS variable are defined there, together other main predefined ones

# Site settings
title: César Vargas Casaseca
url: https://cesarvargas.es

# Google webmaster tools
google_verify:

# Color settings (hex-codes without the leading hash-tag)
color:
 primary: 0d0c0c #80B3FF
 primary-rgb: “255,70,49” #”128,179,255"

#texts
main: This is a just a text to be shown in our awesome website

And if we want to add more flexibility to our project by including other customizable elements, we can just add it to the relevant file using the template language Liquid. Jekyll will then traverse the files looking for something to process. Take a look here and here for more information.

Summing up this step a bit, in order to achieve a static website with Jekyll we have to:

• Download and install Jekyll
• Download a Jekyll Template theme, or convert any other HTML one to Jekyll
• Customize it by adding your wished variables or creating new ones. Adjust texts, colors and other elements

The Hosting

Nice! We have a super fancy website that runs smoothly … locally, on our computer. The next step is to host it externally, so it can be accessed everywhere. And we want to do it easily and cheaply, without a strenuous process to deploy or expensive tiers for just hosting a static webpage. Besides that, it should blend effortlessly with Jekyll, and be able to set the domain from an external provider without further endeavour.

The answer to all our wishes is Netlify. Netlify is a cloud computing company that offers hosting and server less back end services for static websites. It features continuous deployment from Git across a global application delivery network, server less form handling, support for AWS Lambda functions, and full integration with Let’s Encrypt.

It is free for our case, the UI is very intuitive and deployments are rapid. As I mentioned above, the deployments are to be done with Git, so if you did not do it before, we should store our project into a GitHub repository. Once we’ve done that, we can login to Netlify with our GitHub account and specify that everytime we push to master the webpage is deployed. It is that easy! Furthermore, it supports Jekyll very smoothly, we just have to add our Build command jekyll build in the Build Settings. You can get to know more about how Jekyll is integrated with Netlify in this interesting post.

And finally we just need to connect our domain with the hosted website in Netlify. For the purpose of using Netlify DNS, we are going to change the domain names in GoDaddy or any other domain provider to the custom hostnames assigned to your DNS zone in Netlify. It can take a maximum 24 hours to complete this task depending on the registrar. Once it is finished, your domain will be pointing to your hosted website in Netlify and will be available everywhere. So, in order to host your web in Netlify …

• Login to Netlify with your GitHub account
• Host your webpage project in a GitHub Repo
• Specify your website GitHub Repo in your Netlify Settings
• Add the Build Command in Build settings, in our case jekyll build
• Push to master (or any other specified branch) to deploy
• Connect your domain to your Netlify DNS zone

The Icing on the Cake

With that you should now have your own website up and running, accessible through your domain from anywhere in the world. At that moment I still felt brave enough to try to improve it a little bit. For instance, I registered my website in Google Search Console. Search Console tools and reports help you measure your site’s Search traffic and performance, fix issues and make your site shine in Google Search results. You can do the same with Bing, or any other SEO tools that you might find convenient. Do not forget, our goal was to learn, play and have fun, and these tools are a warranty for that.

In addition, our product would feel orphan without a proper way to track its traffic and activity. Google Analytics is the most widely used website statistics service, but there are others such as Matomo or Woopra, with a bigger emphasis on privacy or easiness of usage.

And if you feel like you could earn some nickels monetizing your website, you can display some ads on it. Take a look at Google AdSense for an easy ad integration. In short, if we want to improve our web, we could …

• Enhance our SEO with Google Search Console or Bing Webmaster Tools
• Track our traffic and activity with an Analytics tool, such as Google Analytics
• Monetize our content displaying Ads

Conclusion

In this post we have learned that basic web development should not be difficult. We have seen the differences between static and dynamic websites, and when to use each of them. We picked up contrasted tool for each step along the process, and described ways to refine our project learning new technologies and products.

As always, if you have any suggestion please drop a message or a margin note. Here you can see my final outcome: https://cesarvargas.es

Happy web creating!

Jekyll & Netlify: A Web Love Story was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

We as developers are usually advised to search in the Open Source Community before adding new functionality. The odds are that most likely some other engineer faced the same problem and, in a remarkable act of charity, published their solution so we can also reuse it. Or perhaps we are that caring developer, who content with their work, decided that more people should benefit from it.

In any case, we should make sure that the component will adhere to the Common Reuse Principle (CRP): Don’t force users of a component to depend on things they don’t need. Oh ok, could you elaborate on that? Yeah, sure.

The CRP in Depth

Whenever we have a use case, some set of classes collaborate amongst themselves to achieve their goal. A very common case is a Factory class and the types it generates, they are tightly coupled. Being so dependant on each other, the CRP states that they belong together in the same component.

Classes and modules that tend to be reused together belong in the same component.

Until here everything is fine, if this is the case of our analysed component we should not worry. The issue arises when we flip the coin and state the principle inversely; it provides us even more valuable information. It tells us which classes should not be kept together in a component: those that are not reused together.

Why Not?

Because once we are using another component, we have a dependency for the whole component, for all the classes. Yeah, maybe we are only using one class of it, but still we are going to suffer all the inconvenience of a big dependency:

• Every time that component changes we will need corresponding changes.
• Or maybe they keep a clean interface so no changes in our side are required, but for sure we are going to have to compile the whole component again and again.

The latter was the major drawback for us at WELT, especially when compiling on a slower machine, as the virtual ones assigned in a remote based CI solution.

An Example

In WELT News we convert the HTML text into NSAttributedString to be displayed in our Articles Views. At first we tried the built-in framework to carry out this operation, having something like this:

And it worked fine, but unfortunately very slow. Moreover, since the execution should be performed on the main thread, the UI was blocked until it finished, which was not acceptable for our stakeholders.

Luckily we got to know DTCoreText, a project that duplicates the Apple method, only doing it 18x times faster. We were very happy with that approach, so we decided to integrate it in our library.

The dilemma popped up when realizing that DTCoreText uses DTFoundation behind the scenes, a collection of utility methods and category extensions that Cocoanetics is standardizing on.

So DTFoundation includes a lot of classes that are not related to our use case. Just to render our text faster we have to compile classes related to a large variety of topics such as SQLite, ZIP files, AWS …

Even if these components might eventually be useful to us, we are currently not using them, and therefore shouldn’t have to include them. We should not compile them in our project, as it will slow build times.

We might argue that these frameworks will only be built once, since every dependency manager and CI will enable us to cache and reuse them. Even with that, it is worth to decrease the compilation times for that first time, or cut down the size of the cache. On top of that, if the component is updated because of an unrelated change and we are always up to date with our dependencies, it will compile every time it needs to update.

The Solution

The CRP tells us that when we depend on a component, we should aspire to depend on every class in that component. As Robert C Martin points in Clean Architecture, we want to make sure that the classes we put in a component are inseparable- that it is impossible to depend on some and not on the others.

In other words, classes that are not tightly bound to each other should not be in the same component. That goes against the Umbrella Toolset libraries that contains big collections of utilities applied to a big number of different topics.

To avoid the caveats mentioned above, we plan to extract the classes reused together to achieve the use case of HTML conversion into NSAttributedString into their own component. This way we will only have to compile the necessary number of classes reused together to achieve our goal.

Its first cousin, the ISP

This probably all sounds very familiar to you. Most likely it reminds you of the Interface Segregation Principle, the I from SOLID:

Clients should not be forced to depend upon interfaces that they do not use.

Indeed, the ISP advises us not to depend on classes that have methods we don’t use, the CRP advises us not to depend on components that have classes we don’t use. The foundation behind them is the same:

Don’t depend on things you don’t need!

We are usually told, don’t reinvent the wheel. And rightly so. If there is already a proven open source solution to our problem which is backed up by a large community of users, it would serve us well to use it.

But before adding the dependency blindly to our codebase, we should stop and analyze the component, to make sure that we are not going to be dependant on things we do not need. This will give us time, and time is our most valuable asset.

So, just as when Socrates strode through the city’s central marketplace and declared provocatively, “How many things I don’t need!”, we should, in our life as in our code, confidently assert:

Don’t depend on things you don’t need!

The Common Reuse Principle on iOS was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

More and more we see how the iOS community strives for more modularized architectures. And it is obviously not just a fad. The benefits are clearly evident, the most immediate being much shorter compilation times given that you can just focus on the working framework. Furthermore, you are aiming for a cleaner architecture, one much more readable and testable. On top of that, you can just reuse your component in any other application, or exchange it as you wish.

But same as when creating your object oriented design you rely on the SOLID principles to make it easy to maintain and extend, when constructing your components architecture you always must bear in mind these three points:

• APD: The Acyclic Dependencies Principle
• SDP: The Stable Dependencies Principle
• SAP: The Stable Abstractions Principle

In this first article we will focus on the ADP, The Acyclic Dependencies Principle.

The Acyclic Dependencies Principle

Allow no cycle in the component dependency graph

The theory is simple, our dependency graph should not contain any cycle. If there is one cycle, we are just creating a big monolithic component causing exactly what we wanted to avoid in the first place: longer compilation times and other effects caused by a highly coupled architecture, such as the morning after syndrome. How can we avoid that? Let’s look at an example on iOS with the MVVM architecture.

An Acyclic Dependency Architecture

Let’s suppose that we modularized the architecture of an IOS application that uses MMVM. Model-View-ViewModel (MVVM) is a structural design pattern that separates objects into three distinct groups: Models, Views and ViewModels. Because we are super impressed with the benefits stated above, we are going to create a Framework for each of them.

Our application is simple, the UI will display distinctive elements depending of the User Permissions in the User Profile, and it will be the responsibility of the ViewModel to discern what to show:

This is a directed graph, we can follow the dependencies with the arrows. Moreover, there are no cycles in it, it is a Directed Acyclic Graph (DAG). It is awesome.

Here we have 4 components, obviating the View or some Routing layer that are not relevant for our case. The UserProfileViewModel depends on the User struct in the Model to get the information. This one at the same time depends on the PermissionsManager to enrich its data with its given permissions.

The Misdeed

Now, the Interaction Designer has come to us with a new feature, we will show a totally different view depending on the User Permissions. That way, they will sell more subscriptions because we show more promotional content directed to a non-paying user.

Once they let us know this new task, it is time to design our approach. We will create a Factory class that will provide the right View Model depending on the User Permissions. After some deliberation, the “expert” in our team decides that it should be included in the Permissions Manager framework, given that everything related to the permissions is its responsibility. (please forgive this atrocious architecture).

Alright, so it is! The factory is implemented in the PermissionsManager, and our architecture looks like this now:

We do not have an acyclic graph anymore, there is a cycle between ViewModel, Model, and PermissionsManager. We are doomed! Instead of three components, we have a big one that should be compiled entirely every time we modify any of them. Besides, given the tight coupling, one change might have consequences in any of them. Not good. Actually awful.

Break it!

Once we are aware of the dreadful consequences of the last addition, it is time to break the cycle. To accomplish that we have two different strategies:

Apply the Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions, you asshole.

We will create a protocol revealing the functions that provides the Permissions to the User Model. The Permissions Manager will implement that protocol, but will be hidden to the model, thus inverting the dependency between the Model and the PermissionsManager:

It might look odd having a component with only a protocol on it and no executable code, but this is a necessary and common practice in other languages such as Java and C#. Robert C. Martin, Clean Architecture.

Create a component between them.

To break it, we could create a component between the ViewModel and the PermissionsManager. The ViewModelFactory depends on both ViewModel and PermissionsManager, hence breaking the previous cycle:

You can combine both strategies to end up with the cleanest approach, one that ensures you a good maintainability and flexibility when adding new features to the project.

Wrapping it up

Now that modularizing our apps is in vogue and with good reason, we should be aware that before adding new components we have to stop and think. Are we improving our architecture? Are we actually achieving the goals we strive for with our separate modules? Or are we just having the same monolithic structure although with fancier looks? We should be open to this reflection not only at design time, but also when refactoring the current solution if it shows the most common pitfalls of a non-clean architecture.

If you want to know more, I refer you to the bible on these matters, Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C Martin) There you will find more examples about this and the other principles I mentioned above.

And of course, in case you have more questions or suggestions please drop a comment below or send me a message.

Break the cycle, man!

The Acyclic Dependencies Principle on iOS was originally published in Axel Springer Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Add your Filter Overlay without having to deal with coordinates in Warhol

Some time ago I talked about Warhol, a library of my own that detects a Face from a Camera or Image input and passes the related information to the client. That way, the latter can draw on top or process the face data to accomplish its requirements.

I find it very convenient because the application using Warhol can forget about the cumbersome process of dealing with Vision and AVFoundation frameworks of Apple, focusing of what really makes an application different.

With the same goal in mind, to make the developer’s life easier, I proposed then that we can go one step forward in this path and include in the library one of the most common usage of Face Detection, to draw (silly) images on top of each feature. How cool would it be if the client could just pass an image for each feature and forget about drawing on top and the coordinates! That way they could compose a face overlay with a minimum of hassle.

With that ambition I started the ball rolling.

The Process

To draw the images we will follow the same approach we implemented when first developing Warhol: The drawing, in this case the image drawing, is performed in a transparent view that is added on top of the camera. The Face Detection engine updates the View Model containing the Face Data and asks the data to draw with setNeedsDisplay Then draw(_ rect: CGRect) is called in our view where the drawing magic happens.

As I pointed earlier, the client should only be required to provide an Image for each Face Landmark. They can forget about coordinates or other extra information and focus on the design looks.

It is therefore Warhol’s task to deal with the coordinates, so we can can draw the provided image on the right place. Given that we obtain the landmark area as an array of points, we should first convert it into the rect where the image will be draw:

Once we have the target rectangle, we can add the image with layout.image.draw(in: rect). The outcome is:

Oh it looks ok, but that is not probably what the client wants. Given that the provided eyes area are actually kinda small, we should arrange a way to resize it, so it can be bigger (or smaller) according to the app input. The latter should be also customizable in relation to each Landmark, some items can be bigger while others not. To tackle that, I created a SizeRatio struct with which the developer can express how big the image should be in relation with the original feature area:

Notice how we can specify a different width and height ratio. This is especially relevant for the eyes case, where the width should be the same as the original but the height much bigger.

Once we have the SizeRatio, we resize the rect increasing the area but keeping the center point the same as the original:

Now it looks much better, we made the eyes bigger but the nose the same size:

Yeah! That’s acceptable. We found the perfect size for the eyes. The nose did not need any processing.

Real time updates

At this point the outcome was good, but there was one further concern. Since for simplicity sake I was using UIKit to draw the image instead of CoreGraphics, the image refresh might be slow when the features area change, as when the eyes blink or the mouth opens. UIKit is built on top of CoreGraphics, that is a more low level Framework, consequently providing more flexibility at the cost of more complexity. For instance, with CoreGraphics with can draw in a background thread because it is thread safe, which is not possible with UIKit. Happily, UIKit proved itself to be quite reliable for this case:

That is nice! The layout updates at real time without any perceptible delay.

Features Offset

We are almost done, but there is one more functionality widely used in Instagram Filters that I could add to my project:

In this case, the filter images for the eyes are not placed exactly on top, but a little bit below. To handle this case, I added an offset property in the ImageLayout struct. Using it, we can draw them where we wish:

Wrapping it up

So this is it! In this story we have seen how you can use Warhol now to:

• Create a Face overlay by adding filter images just by specifying the face feature where they should be placed, without having to deal with their coordinates.
• Change the size of each of them at wish to create more visual effects.
• Ensure that the Overlay is refreshed in the camera accordingly on real time, without any visible delays or poor performance.
• Place the image layouts with an offset in relation with the Face Feature, to add more flexibility to your filters.

As I mentioned in the previous story, there is plenty of room for improvements and new features in the field of Face Detection. In the next future I will be focusing on ARKit to animate facial expressions in real-time. Only devices with TrueDepth Camera (iPhone X onwards) will support it, so for the rest of them we will keep using the Vision Framework as described here.

As always, comments and proposals are more than welcome, just drop me a comment or message here. And of course, I would love you for the contribution to Warhol. PRs are appreciated with new ideas, improvements, fixes, and suggestions. This project is under MIT license and in case of issues please use the dedicated section in GitHub.

Happy Overlay!

Warhol II: Compose your Overlay on Top of the Detected Face Hassle-Free for iOS was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.