iOS UI Automation Tests at Babylon

This article is based on the talk I gave at iOS Astronauts meetup that was held on 03.10.2018 at Babylon. You can check out this talk and other videos as well as join the meetup group here. Probably every iOS developer nowadays knows what UI tests are and how to write them. Sometimes we don't even have to write them ourselves because Xcode can do that for us. Of course, the result is far from ideal and probably you don't want to keep it as it is in your tests, but point is that it's not hard to »

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 »

Extending native code with JavaScriptCore

This week there were a lot of articles around the web about React Native and its place in a current iOS dev ecosystem. I was also playing with JavaScript lately, but in somewhat different context - JavaScriptCore. JavaScriptCore is a really great way to make your apps extensible by your users. There are some cool live examples of awesome tools leveraging it. As developers we are in a better position than our users as most of the time we can extend and patch our tools to our needs using native code. But our users can not. For example if you »

Going back to the roots

As Roy Marmelstein said in his recent presentation at dotSwift - "We love to be excited". Can not agree more. When we read a blog post that describes the concept or architectural pattern that is somewhat new for us and feels exciting we tend to accept it as something good. We can go really far away this rote and sometimes we don't notice that we already have all the tools to solve the problems they address. For iOS developers this tool is a framework that we inevitably use every day - UIKit. That's what I was thinking about »

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 »

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) »

View controller thinning. Dependency injection.

In my previous post I described how you can break business and presentation logic in small PONSO's to achieve better separation of concerns and think view controller. To wire up dependencies, particularly those PONSO instances with view elements and actions I heavily used Interface Builder. In this post I will show how you can do the same using IoC-container instead of Interface Builder. As example of such IoC container implementation I will use Typhoon framework. To checkout the full code you can use this repo. First lets start with defining what IoC-container ("Inversion-Of-Control-Container") is. I will not dive »

View controller thinning. Behaviors and Interface Builder.

In previous post I showed how you can move some presentation logic from view controller to view. Now view controller is responsible only for business logic, in this case making login request and handling its result. But now you would say: "You just moved presentation logic from controller to view. Now you have Massive View!" And you will be right. Though view is a perfect place for presentation logic that leads to that view should know everything about its subviews and it will probably change when we change something in its subviews. So in this post I will »

View themes

In my previous post you could see that I've used ColorTheme and ThemedView protocol to easily customize view appearance. Though that solution works I was not satisfied with it from very beginning. Here I try to find another solution. What I really didn't like about my that solution was a check of tag type (if let tag = tag as? FormTextField.ThemeColorTag). Usually I try to avoid any kind of type checking. But here I have nothing to do but to check the type of tag. The problem is that I tried to define some base protocol for color them. That »

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 »

Path to Carthage. Real-life experience.

When it comes to dependency management in Cocoa world you have three options: Cocoapods Carthage Don's use dependency management First one, Cocoapods, have been around for quiet a long time already and is default tool for most of developers. It was designed from the beginning not just as dependency management tool, but as ecosystem for third party open-source components. It is easy to use in most cases. But it can be very painful to manage especially when it comes to customization and your lack of Ruby experience. Once I had few very hard days trying to make it work for »

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 »

Lightweight networking in Objective-C

AFNetworking is the most popular networking library for iOS. Chances are high that it's the first pod you add to your Podfile. It's used as a standalone network layer and as a part of some other frameworks, like RestKit. For me it has earned it's popularity for few reasons. It's well maintained, what is very important for open source project (thought it still has long living issues). And it has well thought architecture and interface, so it is easy to use and extend to your needs. When we perform a request using AFNetworking we can receive serialized JSON object, either »

Testing Sync Engine

Here is a small presentation that I've made about two weeks ago for our Wire team that provides some overview of Sync Engine testing (by Sync Engine we call our in-house framework that does all networking and data base management). It covers main problems we have to solve and what we still have to do and how we plan to do it. If you want dive deep in code and know i.e. how we deal with Core Data in our tests - checkout this great article for by Daniel Eggert. »

Info.plist preprocessing

This is quiet interesting XCode feature I was not aware of until last week. Maybe you will find it not so interesting and definitely will not use this on everyday basis but sometimes it can be helpfull. For example it can be convenient for separation of production and test configurations (some of them). In project Build settings you can find section called "Packaging" and there are several keys we are interested in: Preprocess Info.plist File (INFOPLIST_PREPROCESS) Info.plist Preprocessor Prefix File (INFOPLIST_PREFIX_HEADER) Info.plist Preprocessor Definitions (INFOPLIST_PREPROCESSOR_DEFINITIONS) To enable Info.plist preprocessing »