Swift 4 tricky filters

This is a short story of a regression in Swift 4 that I've recently had to deal with. It can seem as a simple problem, but I think it's a good example of unexpected regression caused by a positive change in a language standard library. First - a bit of a context. In my current project we extensively use Eureka framework to build forms. Most of the time values in our forms are selected from a list of options. For this purpose Eureka has a special type of section - SelectableSectionType. There is also a base class Section that represents »

Deep links with no brainer

Very often in my practice deep links were something that no one cares much, they work somehow and its fine. Or there are just few of them and its really not hard to maintain. But working for a long time on one product that targets several very different markets reveals all the importance of deep links in a long run. There are always requests from marketing teams to support new kind of deep link for a new marketing campaign, to open some new screen in the app from push notification, or with some specific parameters, when existing deep link can't »

Swift enums with associated values defaults

In Swift enums are much more powerful than we got used to in other languages. One of the features that makes them more interesting to use is associated values - values that each instance of enum case can carry along with it. We can not have stored properties in the enum, so associated values is basically the only way to store additional data with enum value. Creating an enum value with associated value has a similar semantics as a method call. The difference is - we can not define defaults for parameters which represent associated values. Here is a real-life »

Adaptive text styles

Textual content is the essential part of any app and text handling in iOS has been improving through last years. Starting with iOS 7 we have dynamic types and text styles, then in iOS 8 we got self sizing cells that help a lot when you want to adopt dynamic type. With trait collections we also expanded the ways how we can adapt text to different environments. And Apple was constantly extending those APIs exposing new font styles, font wights and so on. There is one "but" here. I don't have official statistics and will be glad to be wrong, »

Inout variables with side effects

Every app has some kind of caching. Let's say our caching strategy is very simple: check if data is in the memory cache and return it if not - make a network call and cache the result when it's done For that you can write code that will probably look something like this: if let cached = store.menuPreferences { dispatch_async(dispatch_get_main_queue()) { completion(preferences: cached, error: nil) } } else { repository.getMenuPreferences({ (preferences, error) in if let preferences = preferences { self.store.setMenuPreferences(preferences) } completion(preferences: preferences, error: error) }) } Pretty simple and straight forward. But what if you need to add »

Objective-C headers in Swift framework & custom build configurations

It's already 2 years of Swift and its interoperability with Objective-C as well. When app extensions were released we've got a way to share our code across targets using frameworks. I used to build lots of frameworks since then, sometimes I even worked full-time just on frameworks. But as I had written almost none of Objective-C in around a year now and I've never dived deep enough in Swift and Objective-C interoperability in frameworks here is the lesson I had to learn hard this time. Setup Lets say you've decided to make a framework that combines all UIKit related extensions »

Frameworks, Keychain, NSCoding and Swift

One of the strategies that we use at HelloFresh to reduce compile time, improve code reuse and overall codebase health is breaking our code into frameworks. We've started with two core layers - domain and network. We broke these layers into four different frameworks: domain, generic API client, implementation of API client based on Alamofire and endpoints containing collections of requests that we can make to our API. Simply breaking these layers into frameworks already gave us a lot - it was easier to concentrate on particular parts of the code, define seams between them, cover them with tests and »

Freehand drawing

This post is a part of the series about shapes recognition. This post is also available as a part of a playground. Naive implementation of rendering user's freehand drawing is strait forward. We need to listen to touch events from view and construct the path appending lines to each subsequent point. public class LineDrawing: Drawing { public var canvas: DrawableView? public var path = UIBezierPath() public init() {} public func touchesBegan(at point: CGPoint) { path.removeAllPoints() path.moveToPoint(point) } public func touchesMoved(to point: CGPoint) { path.addLineToPoint(point) } public func touchesEnded(at point: CGPoint) { path.addLineToPoint(point) } public func touchesCancelled(at point: CGPoint) »

Dependency Injection (DI) in Swift

This post is a script of the talk that I've made on UIKonf'16. That was a first time for me to present on such a big conference and honestly I'm not even close to a public speaker so you may enjoy just reading it more. Anyway here is the video. And slides are here. For many of us Swift opened up a world of functional programming. But it is still much more object oriented language than functional. And our main tools - Cocoa frameworks - are object oriented. So probably we ourselves will still keep writing object oriented code. The »

Mixing optional binding and boolean expressions

There were few times already when I used this little-known feature of Swift in real code and it improved (in my opinion) readability a lot and much better described the intention of the code. Here is the original code from the real app: if let cutoffDate = menu?.cutoffDate where menu?.mealSwapEnabledForProduct == true { ... } else { ... } Very trivial piece of code. But it contains one problem - it communicate wrong intention. When optional binding comes first and is followed by where it may seem that we make decision based on the value in this optional and the boolean expression is secondary. But in »

~= vs Range.contains(_:)

Today I was working on simple validators that we use for forms (backed by awesome Eureka) and had to implement validator that validates string length. So I did it like this: struct StringValidator: Validator { typealias ValueType = String let stringRange: Range<Int> init(stringRange: Range<Int> = 1..<Int.max) { self.stringRange = stringRange } func validate(value: String?) -> Bool { guard let value = value?.stringByTrimmingCharactersInSet(.whitespaceAndNewlineCharacterSet()) else { return true } return stringRange.contains(value.characters.count) } } The idea is simple. Form field can have a validator with default range (1..<Int.max) that will validate any not »

Intermediate action segues

Storyboards segues are very cool. They are very easy yet powerful. They help to incapsulate presentation logic and move it out from view controllers. And adaptive segues are state of the art. There is only one thing (almost) left if view controller - managing segue performance using those two commonly used methods: func shouldPerformSegueWithIdentifier(identifier: String, sender: AnyObject?) -> Bool func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) And those methods are the place where we usually screw up everything with our custom logic based on tons of if or switch statements. Then we introduce different routers, coordinators and God knows »

Properties of types conforming to protocols in Swift

In Objective-C it's very natural to have a property of type that also conforms to one or few protocols. In Swift that becomes tedious cause you can not simply combine types and protocols. You can use generics: class MyClass<T: MyOtherType where T: MyProtocol> { var property: T } But you will notice soon that this approach has more drawbacks then advantages. First if you need to have another such property it will become a mess. Second is that you can not use this type in Interface Builder anymore, as well as you can not see it from Objective-C environment. »

Dependency injection with Dip

Note (15.04.16): This post is updated to reflect some of the latest changes in Dip. In some of my previous posts I wrote about using dependency injection with Typhoon framework and described some internals of analogous pure-Swift framework called Dip. Here I want to illustrate how Dip can be used in a real project using the same example that I used before. Also this post will contain a sneak peak of some upcoming extensions of Dip (probably they will be released as separate projects). You can check out source code here. Note that it uses my fork of »

IoC container in Swift. Circular dependencies and auto-injection

Note (15.04.16): This post is updated to reflect some of the latest changes in Dip. In my previous post I wrote about Dip, lightweight IoC written in Swift. Here I would like to describe how some other of it's features were implemented. They are not yet available in original repo, but you can check them out in my fork. Circular dependencies Let's say we have a server-client model where client has reference to server and server has backward weak reference to it's client. First problem is that we can not have two objects that have reference to each »

IoC container in Swift

Note (15.04.16): This post is updated to reflect some of the latest changes in Dip. In my previous post I talked about dependency injection framework for Objective-C called Typhoon. You can skip this paragraph discussing why it matters and jump straight to the point of this post. It's very easy to start to use it, yet it's very powerful (maybe even too much cause there are so much stuff you can do with it). When I first time saw it it was not love at first sight. I though: "Pfff, I don't need all these crazy swizzling and »

View controller thinning

"Massive view controller" is one of the most favorite topic for iOS developers when they talk about architecture. A lot have been said on this topic already, even more will be said in future cause unfortunately there is no silver bullet and view controller still stay massive in many projects. Recently Andy Matuschak presented here and there a live coding session on this topic. So you can see it's a well know and still actual problem. The real problem is that there are a lot of responsibility in UIViewController already defined in UIKit. So why to add even more? We »

Networking in Swift

Recently I've updated my post on how you can implement lightweight networking in Objective-C. Now it's time to look at the same problem from perspective of Swift. If you want to check out code right away you can do it on Github. As AFNetowrking is the default tool of choice for most of Objective-C developers, Alamofire became such in Swift community. But it's always useful to practice and find your own solutions. So let's look how we can do networking by ourselves and what we can achieve there using powerful Swift features like generics, structs and enums. Endpoints When you »

Swift 2. Part 1.

This year I was lucky enougth to go to WWDC as part of Wire team. For me the most exciting stuff Apple introduced this year was Swift 2. I went almost to every session about programming languages, ignoring watchOS sessions and games completely. Though the main inspiration I've got from WWDC was to learn game development using Apple tools, like new GameKit. But that's not the point of this post. After comming back from WWDC we had a tech talk at Wire and talked with our colleagues about the conference. I've presented about Swift and Objective-C and here is what »

Swift interesting features

or What Swift Language Guide do not tell you. This post contains the list of interesting features of Swift that I find while using it. To make it more interactive I've put it in a playground that you can checkout here. The list is intended to be updated in future. If you have something you want to share, pull requests are welcome. Contents: Var in for-in loop Property observers for local variables ~= operator Curried functions Subscript with more than one parameter (by AirspeedVelocity) Var in for-in loop If you have an array of reference type objects you can mutate them »

Custom UITextView in Swift

In this article I want to describe how I developed custom UITextView component in Swift using TextKit, Playgrounds and IBDesignable and IBInspectable directives. You can check out source code on github. In this component we will add "read more" behaviour to text view. It will have two modes - full mode and trimmed mode. In full mode it will behave like standard UITextView. In trimmed mode it will trim text to some maximum numbers of lines and trim text with a string (like "Read more"). When user taps on "Read more" the component will switch from trimmed mode to full »

Quick overview of Swift Playgrounds in iOS Simulator

Probably lately you've seen few posts on this subject like this or that. Both of described techiques share the same secret - how playground is run in Simulator. Actually it's quite easy, but not obviouse as all windows needed for that are hidden by default - you just need to open up File Inspector for your playground file, select iOS platform and check "Run in Full Simulator". This will run iOS simulator and run your playground almost like ordinary application. But this techniques differ in a way they present "interactivity" of playgrounds. The latter uses XCPlayground framework to render views »