Tracking user behaviour and gathering analytics is very important not only for marketing purposes but also to improve the user experience. Especially when having limited resources it allows to concentrate on most important user paths. I’ve worked on several mobile applications, some of them I’ve written from scratch, others were maintained by me, for some I did code reviews only. Most of those apps had one thing in common, they implemented some kind of analytics (Firebase, Gemius, Mixpanel or proprietary) which was hard to maintain and seemed like it was there only to satisfy some business requirement. Added without broader perspective, just to satisfy current needs.

Asynchronous operations are impossible to avoid in almost every modern application. Each time you interact with network, database, filesystem or UI, some asynchronous operation is involved. iOS provides many mechanisms to provide asynchronousness including GCD and NSOperationQueue and encourages design patterns like delegate and callbacks that promotes asynchronousness. Unfortunatelly writing asynchronouse code in Swift is not always very clean, especially when implementing more complex chains of operations.

In this short post I will explain why floating point or large decimal values should be represented as strings when transferring data using JSON. This post is based on my recent discovery when trying to fix a nasty bug, when running my app on iOS 11 beta3.

After introducing ARC memory management was simplified a lot, but still could not be forgotten. For sure every developer working with either Objective-C or Swift had to deal with retain cycles. There are lots of in depth posts about this topic and I do not want to rephrase them, so instead I will link to my favourite from krakendev. Unfortunately this post does not cover everything and I would like to mention some specific case which I encountered not that long ago.

As programmers we often have to deal with legacy code, usually not written by us, sometimes of bad quality, without unit tests, hard to modify, with high regression risk. One of ubiquitous code smells is so called static cling. It is so frequent because lots of developers “love” static functions, singletons and in fact greatly abuse those patterns.

We do so, because static code seems easier and faster to write, but in a longer run, the code written using those patterns is hard to test, not reentrant, coupled, maintaining global state and is just badly designed.