Async await in Swift explained

Reading Time: 5 minutes

Async await?

Async await is part of the new structured concurrency changes which were launched in Swift 5.5 during WWDC 2021. As we already know Concurrency in Swift means allowing multiple pieces of code to run at the same time, and is very important for the performance of our apps. With the new Async await, we can define methods performing work asynchronously.

Now that “Async await” is finally here, we can simplify our code with async methods and await statements and make our asynchronous code easier to read.

Async is?

Async is asynchronous and can be seen as a method attribute, which method performs asynchronous work. As an example we can use the method below:

func getProducts() async throws -> [Products] {
    // ... perform here data request

The getProducts method is defined as async throwing, which means that it’s performing a fail-able asynchronous job. The method would return an array of custom objects Product if everything went well or would throw an error if something went wrong.

How async can replace completion callbacks

Async methods replace the often seen completion callbacks. Completion callbacks (closure) were common in Swift to return from an asynchronous task, often combined with a Result type parameter. The above method would have been written as followed:

func getProducts(completion: (Result<[Product], Error>) -> Void) {
    // ... perform here data request

Creating a method with a completion closure is still possible in Swift, but it has a few disadvantages which are solved by using async instead:

  • Developer has to make sure to call the completion closure in each possible method exit, if not doing so will possibly result in an app waiting for a result infinitely.
  • Callbacks (closures) are harder to read. It’s not as easy to read about the order of execution as compared to how easy it is with structured concurrency.
  • Retain cycles has to be avoided using weak references.
  • Implementers has to switch over the result to get the outcome, also it’s not possible to use try catch statements.

These disadvantages are based on the closure version using the relatively new Result enum. It’s likely that a lot of projects still make use of completion callbacks without this enumeration:

func getProducts(completion: ([Product]?, Error?) -> Void) {
    // .. perform here data request

Defining a method like this makes it even harder to reason about the outcome on the caller’s side. Here value and error are optional, which requires us to perform an unwrap in any case. Unwrapping these optional results(value and error) in more code clutter does not help to improve readability.

How await works?

Await as the keyword stays to be used for calling async methods. Usually, we see them as best friends in Swift as one will never go without the other. You can basically say:

Await is awaiting a callback from its buddy async

Even though this sounds childish, it’s not a lie! If we take a look at an example by calling our earlier defined async throwing fetch products method:

do {
    let products = try await getProducts()
    print("Got \(products.count) products.")
} catch {
    print("Getting products failed with error \(error)")

We can note that the above code example is performing an asynchronous task. Using the await keyword, we tell our program to await a result from the getProducts method and only continue after a result arrives. This could either be an array of products or an error if anything went wrong while fetching the products.

What is structured concurrency?

Structured concurrency with async-await method calls makes it easier to understand the order of execution. Methods are linearly executed, one by one, without going back and forth like you would with closures.

To understand this better, we will take a look at how we would call the above code example before structured concurrency arrived:

// 1. Call the method

getProducts { result in

    // 3. The asynchronous method return

    switch result {

    case .success(let products):

        print(“Got \(products.count) products.”)

    case .failure(let error):

        print(“Getting products failed with error \(error)”)



// 2. The calling method exits

As you can see, the calling method returns before the products are fetched. In case a result is received, we go back into our flow within the completion callback. This is an unstructured order of execution and could be hard to understand. This is especially true if we would perform another asynchronous method within our completion callback which would add another closure callback:

// 1. Call the method
getProducts { result in
    // 3. The asynchronous method return
    switch result {
    case .success(let products):
        print("Got \(products.count) products.")
        // 4. Call the placed method
        placedProducts(products) { result in
            // 6. Placed method returns
            switch result {
            case .success(let products):
                print("Decoded \(products) products.")
            case .failure(let error):
                print("Decoding products failed with error \(error)")
        // 5. Fetch products method returns
    case .failure(let error):
        print("Getting products failed with error \(error)")
// 2. The calling method exits

Each completion callback (closure) adds another level of indentation, which makes it harder to follow the order of execution.

If we rewrite the above code using async-await syntax, we have a more readable piece of code, and also explains best what structured concurrency does:

do {
    // 1. Call the method
    let products = try await getProducts()
    // 2. Fetch products method returns
    // 3. Call the placed method
    let placedProducts = try await placedProducts(products)
    // 4. Placed method returns
    print("Got \(products.count) products.")
} catch {
    print("Getting products failed with error \(error)")
// 5. The calling method exits

The order of execution is linear, easy to follow and easy to reason about. Asynchronous calls will be easier to understand while we’re still performing sometimes complex asynchronous tasks.

Infinite UITableView Scroll – Special Case

Reading Time: 6 minutes

When we are working with loading large data, if we load all the available items and try to display everything at once it will cause a big delay and the app will not work smoothly. The solution in cases like this is a combination of back-end and in-app solution. We should adjust the BE to work with pagination responses. The BE should give us only chunks of data and we should control the size of these chunks from the app sending the batch size. I’ve made research on this topic on the net and there are solutions but all of this is going in one direction. Using pagination, but every time starting from page 1 and loading the next pages after that. One of the best things was discovering the iOS Prefetching Protocol that I’ve never used before. This protocol is a piece of this solution.


From the BE we need at least two APIs:

The first one is an API that will return all the necessary data: starting page, optionally which element from the starting page to be focussed and the total number of elements in the database. Why is the total number of elements needed? This is because if we don’t know it we won’t know how many rows we should present. Things will become more clear when we will start coding. The suggested JSON response should look like this:

	"total_elements": 480,
	"data": [
			"id": 1,
			"name": "Test1"
			"id": 3,
			"name": "Test1"
		//elements from 60..89

	"first_page": 3,
	"per_page": 30

The second API is the API that will return the data and we will send a page number as an argument. The example JSON response is provided below:

	"data": [
			"id": 1,
			"name": "Test1"
			"id": 3,
			"name": "Test1"
		//elements from 1..29

	"page_number": 1,
	"per_page": 30

Solution explained

I read a lot of articles about infinite scrolling UITableView’s but none of this is solving my special case – an option to start in the middle, and optionally to focus on a particular row from the table inside that page. Here is how I solved this issue:

First, I’m defining few variables in the code, some static integer values – the batch size (number of elements per page), start page value that will be variable and we will fetch it from the BE, and the total number of elements – variable that will be fetched also from the BE:

In my example, I will work with a list of integer values instead of using some objects, but this could be easily adjusted with any kind of objects/models.

Also, I will use a list of used pages, and I will keep track of the already fetched pages from the BE. Here is also one useful boolean flag “isNewDataLoading”. This flag will prevent us from calling the BE if the previous BE call is not finished.

    let batchSize: Int = 30
    let totalElements: Int = 480
    var startPage: Int = 5
    var elements: [Int?] = []
    var isNewDataLoading: Bool = false
    var loadedPages = [Int]()

The first call is the initial load method. Here, I will call the BE API that will return all the necessary data to pre-populate the code variables:

    func initialLoad() {
        for _ in 0..<totalElements {
        for value in startPage*batchSize..<(startPage+1)*batchSize {
            elements[value] = value
        let toIndex = startPage*batchSize + ((startPage+1)*batchSize - startPage*batchSize)/2
        mainTableView.scrollToRow(at: IndexPath(row: toIndex, section: 0), at: .middle, animated: true)

After the initial loading is done we have to explain the UITableView data source methods.

The “cellForRow” method has a simple logic. If we don’t have fetched the value for one of the cells, the cell will show a spinner (UIActivityIndicator); in case the value for the cell is already loaded we are showing into a text label (UILabel):

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath) as! TestTableViewCell
        if isLoadingCell(for: indexPath) {
            cell.configure(with: .none)
        } else {
            cell.configure(with: elements[indexPath.row])
        return cell

The Magic

Historically all of the older solutions use the UIScrollView delegate methods and inspect the current y-offset of the table. If the user reaches the maximum y-offset the API is called with the next page.

I made research on the topic and I recognized that the Prefetch Protocol should be useful in this situation. Some of the solutions on the net used the prefetch protocol in their solutions, but it needs some modifications if we want to make our code work with different starting pages. Let’s see how it looks into the code:

    func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) {
        if indexPaths.contains(where: isLoadingCell) {
            let index = indexPaths[0]
            let page = index.row/batchSize
            if !loadedPages.contains(page) {
                //fetch new
                DispatchQueue.main.asyncAfter(deadline: + 2.0) {
                    self.getNewData(page: page)

Since iOS 10 Apple introduced the API for prefetching data in UITableView and UICollectionView. More details about the prefetching protocol can be found on the Apple Developer site:

Little explanation of the code above: If the IndexPath of the cell that should be prefetched is an index that is not yet downloaded using the row value of the IndexPath we will determine the page to which the index path belongs to. If this page is not downloaded, we will download it. The code for downloading a new page will be shown below:

    func getNewData(page: Int) {
        if isNewDataLoading {
        isNewDataLoading = true
        var temp: [Int] = [Int]()
        for num in page*batchSize..<(page+1)*batchSize {
            elements[num] = num
        let indexes: [IndexPath] = {
            return IndexPath(row: $0, section: 0)
        mainTableView.reloadRows(at: indexes, with: .none)
        isNewDataLoading = false

What is important in this method? The most important is to add the page to the list of already loaded pages, and the second thing is to reload only the rows in the table that belongs to the actual page.

The full code can be downloaded by clicking on the “Download” button below:

Feel free to add your comments or suggestion.

Providing Accessibility In Your iOS App (Basic Overview)

Reading Time: 6 minutes

As a developer, the most important aspect of your app is the user experience. No matter the type of software you are creating, it is very important that it can be easy to use and accessible to everyone. Especially the app you are developing is meant to be used by the elderly or users with disabilities.

This post won’t contain any detailed technicalities as to how to achieve good accessibility since there are already countless of blogs and websites that cover this topic in great detail. Its purpose is to cover the various topics that are important to achieving proper accessibility within your app. And with that, let’s start with the very basic.

What is accessibility in iOS?

In its most basic form, accessibility in software products is to allow everyone proper access and options to use your software no matter their disability. This covers visual, auditory impairments, as well as physical disabilities. It is important to leave the flow unobstructed and have every part of the app reachable as it’s intended for the default experience.

Initially, iOS already offers great out of the box functionalities to assist with achieving proper accessibility. As a developer, the important part is to make your app compatible with said functionalities. In some cases, it is also required by law to make your app accessible if the target audience for the app is a group of people that could have certain disabilities.

Additionally, Xcode offers the Accessibility Inspector which you can use to test out all of the UI elements and see if they are compatible with the necessary accessibility options.

Let’s first cover what iOS offers for accessibility that we would need to pay attention to.

Voice Over

The functionality of VoiceOver is to offer users certain gestures and voice-assisted tools to navigate through an app. These are easy to learn features that can greatly enhance the experience for users with disabilities.

Display & Text Size

Display & Text Size helps with scaling up the UI of the app to make the text larger and easier to read. Both of these features are very important to complete the full experience for all users.

Now, let’s cover the basic topics to make your app accessible


As previously mentioned, some of the native functions help with adjusting the look of the app so its elements are larger and easier to look at. One of the steps to ensure that is making sure that almost every screen in the app has an embedded scroll view. Even if a certain screen might only contain a single label or a button or two, the scalability options push the boundaries so far that it will need the necessary space to fill in the data.

As you can see in the example above, the difference is substantial. This is why when dealing with accessibility it’s important to avoid using fixed width and height on your UI elements (with minor exceptions). Because otherwise you will experience text truncating and cut off content.


Considering the latest trends in app design, everyone thrives for simplicity. While this is also true for accessible apps, it is also important to either make some exceptions or bring down the simplicity even further depending on the content of the app.

It is especially important not to clutter the screen with too much labels/buttons on a horizontal scale. Since the UI needs to scale up, you need to provide enough room for everything to be displayed.

One thing to note is that sometimes the scalability might break some design rules that you have about the app, but that’s completely fine. As long as everything can be accessible at all possible points, there can be some exceptions regarding that.


The default font provided by Xcode already is capable to work with scalability within the app. It’s also a good reminder that the font of choice within your app is easy to read no matter the size.

Also, it’s advised to use the regular and/or larger font weights compared to Thin, Ultrathin and Light that can be harder to see.

Additionally, if there are any visuals in the app that contain text in images, if possible it’s better to adjust the design to have all of the text in native labels so the VoiceOver can read them out for the user.


On this topic, the most important part is to use a combination of colours that contrast each other to ensure that the content is properly viewable for everyone. In its most basic form, this is usually text against a background. In some cases, you might have to pay attention to colour choices for users with colour blindness. There are various tools to compare the necessary contrast.

Do you see the number 74?

Accessibility hints and labels

All of the UI elements that you can use in Xcode that the users can interact with can have some sort of accessibility info added on them. This is important so the users can know what do those elements convey. Especially on images, where you can provide all the details about what the images contain. You can also add hints on buttons, so the user knows what action would a certain button do prior to pressing it.


In general, the topic of providing access to your apps is not an easy thing to achieve. It requires proper setup with consideration of many aspects to ensure that all users can freely use your app without any hiccups. Luckily, Xcode provides all of the necessary functionalities to create and test all of the accessibility options. As mentioned at the start, there are plenty of tutorials that cover this topic in great detail with all of the technicalities. So hopefully this will guide you in the right way to achieve that!

iOS Unit Tests – My story

Reading Time: 5 minutes

In my last job interview – almost 2 years ago – I received a question about writing unit tests inside the iOS code. With the confidence of a developer with 8 years of experience in the iOS branch, my answer and my opinion at that moment were that if the developers are high-profiled and write good code writing unit tests is not necessary. Also, my answer continued with a conclusion: if the company has a testing team why do we (iOS developers) take their job? Throwing back on the answer and from today’s perspective, my feelings about the topic are mixed: First of all, I’ve learned more about the importance of the unit tests, and secondly, I’ve continued to work in an environment where we are not obligated to write tests.

Some basics

We should consider our code as pieces of code – called UNITS. The purpose of a unit test is to make validation of our code, and this will allow us to be sure that our code meets the design and fulfil the goal.

In XCode and iOS, the Unit tests are written in a separate target. The most important thing is the XCTest framework. The basic rule is that only the methods that start with the word test will be considered as unit tests by the compiler. Here is an example:

func testFormatForCard() {
    let formatter = DateFormatter()
    formatter.dateFormat = “ddMMyyyy”
    let date = “28061978")!
    XCTAssertEqual(date.formatForCard(), “28.06.1978”)

Once a test method is written with the proper semantic, the method is associated with rhombus sign on the left side:

Unit Tests with rhombus sign

We can run the tests to see if our code is good or if something is not working. If the test passes, the empty rhombus sign is changed with a green checkmark sign:

Figure 2: Test passed

In case of a failing test we have an assertion and a red sign:

Figure 3: Failed unit test

We can see in image 3 that intentionally the programmer entered the wrong output date 29.06.1978. That’s the way we should think when writing unit tests. First, we have to write the failing state and after that, we should enter the expected correct output. If in the second case the test passes, then we have created a useful unit test for that piece of code (unit). The general idea behind is if we change something in our code, and we made a mistake unintentionally the test should fail and warn us to fix the code.

Unit Test in practice

1. Code Coverage

There is a built-in option inside XCode for checking the code coverage of the tests. The ideal scenario is that 100% of our code is covered by unit tests. But is this really necessary? Will we be better programmers if our full code is supported with tests? Can we spend better the time we spent covering the tiniest pieces of code with proper tests?

In my opinion, writing unit tests is a philosophy and knowing the principles lead us to write qualitative code. That’s, of course, our goal as programmers. Covering the most important part of the code, especially the parts of code that are often changed like networking managers, parsers are a better option than trying to be perfect and writing 100% coverage.

2. Test Driven Development

The popular blog website for programmers Ray Wenderlich emphasizes the FIRST principles as a good way to follow writing unit tests. The basics of these principles are that the test should be fast, autonomous, repeatable, the output should be either “pass“ or “fail”, and ideally, the tests should be written before coding – Test Driven Development TDD.

The recommendation by TDD is writing tests before starting to fix a bug in the code. My opinion on this topic is also a mixing approach. Depending on the time you have, if the deadline is not close on the horizon, you can write tests before coding, or before starting to fix bugs in code, but that’s not always possible, and you won’t make a mistake if you skip this step sometimes.


I can say that writing unit tests is good for every programmer on his way to becoming great. The quality of coding could dramatically improve using unit tests. The philosophy of writing tests and thinking how the code should be structured to allow the tests to pass, will make you write cleaner code, better structured, using more protocols, make reusable classes… As in the strategy games, you shouldn’t always be a slave of the principles – the most important is to fulfill the goals in a quality manner. If you have enough time and not a strict deadline of the project you can make a bigger code coverage, but something around 75% is good enough.

4 steps to start building apps with Flutter

Reading Time: 2 minutes

As a front-end developer, I was always curious about mobile apps and wanted to build one. In the last years, I was testing multiple frameworks from Ionic to React native and to be honest, I was never satisfied. Until one day by accident, I tried FLUTTER and this happened:

Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobileweb, and desktop from a single codebase.

From Flutter website

Just reading this sentence blew my mind and I was in. After two months playing around with the framework, I would say it’s the one that will take over in the next years for sure. Let’s jump and see how to start with it.

1 – Download the Flutter SDK

Download the stable version and put it in as a PATH environment variable. The download link is here.

2 – Run Flutter Doctor

flutter doctor

This command is the most important one as it checks your environment and displays a report of the status of your Flutter installation. Do not forget to check the output carefully, to be able to know what is still missing.

3 – Start Coding

import 'package:flutter/material.dart';

void main() async {
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: MyApp(),

class MyApp extends StatefulWidget {
  _MyAppState createState() => _MyAppState();

class _MyAppState extends State<MyApp> {
  Widget build(BuildContext context) {
    return Text(
           'Click me!',
           style: TextStyle(
                  fontSize: 60.0,
                  fontWeight: FontWeight.bold,

4 – Enjoy it

Making Swift networking code more readable

Reading Time: 3 minutes

With Swift 5 a new type got introduced:

@frozen public enum Result<Success, Failure> where Failure : Error {

    /// A success, storing a `Success` value.
    case success(Success)

    /// A failure, storing a `Failure` value.
    case failure(Failure)

The Result type is an enum consisting of 2 cases. The success and the failure case. Each of them can hold a generic value. The failure case, however, is limited to Types extending the Error type.

Not a big deal? Sure, but it’s the little things which add up and make a difference in the long run.

Lately, I was migrating from SwiftyJSON to native JSON parsing. Each network call was implemented in the following way:

func fetchSomething(completion: @escaping (SomeReturnValue?, SomeError?) -> Void) {
    NetworkingTool.request { (response) in
        guard response.isValid
            else { completion(nil, .somethingBad); return }
        do {
            let returnValue = try SomeReturnValue(response: response)
            completion(returnValue, nil)
        } catch {
            completion(nil, .scarry)

Looks okayish. Good. So let’s use it:

fetchSomething { (result, error) in
    guard error == nil
        else { handleError(error: error); return }
    doSomething(result: result)

Ok. But how to implement the doSomething? With an optional? This can’t be right, right? Force unwrap the result? And what about the error case? Force unwrap it? Oh and wait, what about the case where neither a result nor an error is returned? Is this even a thing? Ok, let me look up the implementation…

So a tiny bit of ambiguity paired with different people working on different parts of the network stack for different features can cause a real heterogeneous system. (Which does not imply that this is a bad system!)

If the company you’re working for is in favour of code ownership, you may not encounter this one. But so far no company I worked for was about code ownership. It’s usually your code is my code is our code, comrade. Period. There are simply too many trucks outside.

As long as code ownership isn’t a thing and you do not want to spend time on endless syntax and architectural discussions with little benefit or enforce a (new) best practice on all of your colleagues. Again. It comes really handy to have a built-in Result type which is reasonably unambiguous.

And since we all know that we’re spending more time reading code than writing, this saves us all valuable time.

Mobile App Marketing

Reading Time: 7 minutes

Almost everyone uses mobile devices nowadays. The market for mobile applications is really huge. The site has statistics that show that currently, over 6.1 million applications are existing from > 1.9 million publishers. If you have a cool idea and you finally create a mobile application, the first goal is that your application will be downloaded from the bunch of apps in stores. Your app may be exceptional, well coded, without bugs, well designed, but still, the download numbers can be poor. Where is the problem? Why?

The answer is simple: You need a great marketing strategy to succeed.

This blog post will give you some theoretical knowledge for Mobile App Marketing, an overview of the main stages of the marketing funnel, the goals and metrics you should measure, and brief overview of some popular tools.

Mobile App Markets

If we enter a mobile app world we will probably go to one of the most popular ones:

  • Android Play Store (> 2.8 million live applications)
  • Apple App Store (> 2.2 million live applications)
  • Samsung Galaxy Apps
  • LG SmartWorld
  • Huawei App Store
  • Amazon App Store

These numbers show us that the competition is strong and probably our app must compete with at least 50 or 100 other apps on the same topic as ours.

Mobile App Marketing (MAM)

There are many definitions on the internet about mobile app marketing…

“Mobile app marketing is the process of creating marketing campaigns to reach your users at every stage of the marketing funnel. Learn key mobile app marketing tactics for every stage of user engagement with your app.”

The difference between mobile app marketing and mobile marketing:

MAM creates complete campaigns for a mobile application, it follows the complete cycle – from downloading the app, first engagements, becoming a regular user, and using many in-app purchases.

On the other hand, mobile marketing is every marketing that happens on mobile devices, including advertisements on websites, the banners presented on responsive web pages, email marketing, etc.

Like the general conclusion, we can say MAM is a subset of Mobile Marketing.

Mobile App Marketing Funnel

In the terminology of marketing, we often meet the word marketing funnel. Here is one definition of what it is:

“The marketing funnel is a visualization for understanding the process of turning leads into customers, as understood from a marketing (and sales) perspective.”

An example of a Mobile App Marketing funnel

A typical marketing funnel consists following stages:

  • Awareness
  • Consideration
  • Conversion
  • Customer Relationship
  • Retention

Let’s see a little deeper the three most important stages: awareness, conversion and retention.


Even before we make our first release of the application we have to make awareness for our app. It’s not enough to start marketing after the release. The goal is to attract targeted users to your app before the production phase.

Here are a few different ways to attract new app users and raise awareness about your app:

  • Using social media
  • Launching paid advertising
  • App store
  • Websites for reviewing apps
  • Using QR codes


Conversion is maybe the keyword if we see it from a business perspective. Conversion is every step that leads to financial benefit for our application. Conversion is every paid download of our application, every user that creates a profile and completes the onboarding process, every in-app purchase inside the app. As a conversion, we could count a regular use of our app.

The strategies we could use for a better conversion include the following:

  • Providing an easy registration process, with clear and not confusing steps for finishing the onboarding process
  • App free of bugs
  • Clear UI with great UX
  • Using push notifications and inside app messages to keep users engaged and informed about new things


Have you ever had this happen to you? Downloaded an app and deleted it in the next few minutes? For me personally yes – multiple times. I can witness that the reasons were difficulties in the registration process, mandatory registration, or apps with only landing page visible and paid strategy to see all other stuff inside.

The user is our KING and we have to make him happy. To make the users happy we must find what their needs are. Understand their desires, the way they want to use the app, what time of the day they are most active, are they happy if we are sending messages in the mornings or later in the night?

It’s 5-25 times more expensive to replace a customer/user than to keep one existing.

Some of the strategies to improve retention are push notifications, in-app messaging, taking surveys, or starting loyalty programs.

Goals and Metrics

There are different tactics and strategies in Mobile App Marketing, but there are two things in general that are present everywhere: Setting up goals and measure the key metrics to know if your strategy is working properly. The goals are necessary to know what we want to achieve with our marketing strategy. For example, our strategy could be increasing the number of downloads, by improving the quality of the keywords used in the store.

There are many different app marketing metrics but I will describe only the most important ones:

Churn rate

This is the percentage of users that stop to use the app. Statistics showed that almost 70 per cent of the users stopped using the app immediately after the installation, and around 98 per cent after 3 months.

Session Length

This parameter is for the time that the user spends in the application from login to close the application. Different applications should measure and consider this metric in different ways. For example, if we have an application like the a Health Fitness Application where the user is tracking the steps or the time spent in the gym, 1-2 minutes could be enough time. On the other side, if we measure the session length for an application for a newsfeed or a complex game – 2 minutes are not enough time.

Retention Rate

This is the percentage of users that come back to the application during a period of time and use the app regularly. Knowing the statistics of the people who use the app is a big benefit because we can target those profiles of users in our marketing channels.

Lifetime Value (LTV)

This metric is related to application revenue. It represents the financial value of our app and how much each customer is worth for us.


On the market for MAM tools, the offer is huge. There are many online tools. The span of services they offer is from App Store Optimization (ASO), sending a push notification through keywords improvement strategies and A/B testing tools.

Some of the tools offer great user interfaces, a lot of beneficial statistics that can help us build our mobile app marketing strategy.

Here is a list of the most popular ones:

  • Firebase
  • Optimizely
  • App Annie
  • AppRadar
  • Google AdMob
  • Leanplum
  • Airship
  • DeepLink

Personally I have experience with few of these like Firebase and Airship which offer a ton of services. Firebase is a very powerful tool, but I will go in more detail and will compare some of these tools in my next post.

Because of the big competitions, we should be aware that a top-quality application is not enough. A good mobile app marketing strategy is a must!

What is next?

This post will continue with a comparison of some of the most popular MAM tools. We see some great examples of how these tools help big companies to improve their marketing. I will make a comparative analysis of the prices and the plans they are offering. Also at the end, I will give some suggestions on how we can use these tools to improve our mobile strategy.

Dependency injection and how I use it in Vaccination iOS app

Reading Time: 5 minutes

In programming, dependency injection is a technique where one object serves dependencies to another object. The concept is that instead of the client object to decide what kind of service it will use, another object tells to the client what service he has to use.

We can see the dependency injection as a software pattern. The fundament of this pattern is passing the service or object to the client, instead of allowing the client to find or to build the service on his own. What is the advantage of using this pattern? The main pros of this pattern are the readability of the code and code reusability.

Dependency injection – Injector example

Dependency injection is one form of the broader technique of inversion of control. The client delegates the responsibility of providing dependencies to external code (the injector) (Figure 1). The client is not allowed to call the injector code; it is injecting code that constructs the services and calls the client to inject them. This means the client code does not need to know about the injecting code, how to construct the services or even which actual services it is using; the client only needs to know about the intrinsic interfaces of the services because these define how the client may use the services. This separates the responsibilities of use and construction.

Types of DI

There are 3 types of dependency injection:

  1. Constructor injection: the dependencies are provided through a class constructor
  2. Setter injection: the client exposes a setter method that the injector uses to inject the dependency
  3. Interface injection: the dependency provides an injector method that will inject the dependency into any client passed to it. Clients must implement an interface that exposes a setter method that accepts the dependency

Vaccination app example

In the iOS world, the constructor injection is known as an initializer-based injection. This concept is realized with injecting the dependency object (or service) during initialization of the client class and this dependency is consistent/unchangeable during the life cycle of the client object.

In the previous few months, I’ve worked on the vaccination iOS application for N47 and I’ve decided to use the popular MVVM pattern inside. In the core of this pattern is the dependency injection. The components of the pattern are Model, View, and ViewModel, and each component is responsible for a different thing in the app. The point is to make the code more modular and easy to test.

The ViewModel (VM) component is a structure that contains only the data needed by the View component. The View component is presenting the data injected by the ViewModel. The ViewModel at other side is created by injecting dependency from the Model component. The main advantage of the MVVM is that we are creating views that have only one goal – presenting data. The view itself is not aware of the other task like fetching, persisting, etc.

We can see the initializer-based injection in action with the real example used in the Vaccination Demo App of N47. Let’s see first how the Details ViewModel looks like:

struct VaccineDetailsViewModel {
    let title: String
    let description: String
    let date: String?

The vaccine details view only needs title, description, and date for the vaccine. It doesn’t need more information. On the other hand, the vaccine model can contain more details about the vaccine, but this information is useless for the View. Inside the view controller (View component) we define view model property and set it via controller initializer. We can see this in the code snippet below:

 var vacineViewModel: VaccineDetailsViewModel?

class func createController(viewModel: VaccineDetailsViewModel?) -> VaccinesDetailViewController {
        let controller = VaccinesDetailViewController(nibName: "VaccinesDetailViewController", bundle: nil)
        controller.vacineViewModel = viewModel

        return controller

This type of injection is preferable because it keeps us the safety of creating incomplete objects and with that, we will avoid coding mistakes.
So when I want to create a controller that will present the details for the vaccines and the scheduled vaccines I’m using injection via initializer in this way:

let details = VaccinesDetailViewController.createController(model: vaccination.createModel())

Other DI types in action…

In the Vaccination App, I’m also using Dependency Injection via setter creating the UITableView cells.

var vaccinationData: Vaccination? = nil {
        didSet {
            guard let vaccineId = vaccinationData?.vaccineId else { return }
            guard let vaccine = VaccineManager.sharedInstance.getVaccineById(vaccineId: vaccineId) else { return }
            let language = ModuleSharedPreferences.shared.language.rawValue
            let translation = vaccine.translations[language]
            vaccineTitleLabel.text = translation?.name
            vaccineApplyDateLabel.text = vaccinationData?.date

The code snippet above shows the vaccination data object that should be set with setter if we want the cell to be populated with data. Here is the code that will do the magic:

        let cell = tableView.dequeueReusableCell(withIdentifier: VaccinesTableViewCell.cellIdentifier, for: indexPath) as! VaccinesTableViewCell
        let vaccination = vaccinationList[indexPath.row]
        cell.vaccinationData = vaccination


Dependency injection is a powerful technique. Our code becomes more readable, reusable and easy for testing. We were able to see this technique in action in a real project and it was used within the popular design patterns MVVM. Using this technique we become sure that our components/services are completed, fully created before we start to use it.

Why I loved Flutter despite being a fan of Native App Development

Reading Time: 5 minutes

In this post, I am going to write about Flutter based on my opinions. Please don’t hesitate to comment if you want to discuss, support or contradict any of the mentioned points 🙂

What is Flutter

“Flutter is Google’s portable UI toolkit for crafting beautiful, natively compiled applications for mobile, web, and desktop from a single codebase. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.” (from official Flutter website)

In the mobile development perspective, Flutter is a cross-platform mobile application development framework that is developed by Google and supports building apps for IOS and Android operating systems from a single codebase with native-like performance.

Cross-platform frameworks in general

I was always against developing apps with cross-platform tools however they are good options in terms of required resources such as they require less development time, less budget, less effort to maintain/support, etc. But for me, these factors are not much important somehow. Which things I didn’t like and made me avoid learning/developing cross-platform are:

  • Low performance, Poor UI – to be honest, I haven’t even played around with any cross-platform development. The fact which makes me come up with the ideas of cross-platform having low performance and poor UI is originated from the impressions I got from the usage cross-platform developed apps. Most of the time when I start using apps and see the bad performance and UI, unfortunately, I end up knowing that they are cross-platform developed apps.
  • It requires learning a new language – since I’m an android developer, I would rather choose to learn Swift for native IOS development so I will be able to develop for both platforms.

Dart language

Dart is a client-optimized programming language for fast apps on multiple platforms. It is developed by Google and is used to build mobile, desktop, backend and web applications. Dart is an object-oriented, class defined, garbage-collected language using a C-style syntax that transcompiles optionally into JavaScript. (wikipedia)


Dart code is capable of being compiled into machine code. For mobile application development, Flutter uses this type of compilation which is Ahead-of-time compilation. This is the reason which makes Flutter distinguish from other cross-platform app development frameworks and lets an app developed in Flutter have native-like performance.

Things I liked about Flutter development

  • Faster code writing
  • Rich in UI components – lots of flutter widgets to build eye-catching UI
  • Native-like application performance
  • Instant hot reload – see the changes within seconds
  • No need to extra code to support older Android versions


  • Less third-party libraries are available


The reason I wrote this blogpost is that Flutter caught my attention and I decided to give it a try. So I cloned the main page of the simple news application which is in the Play Store. Then I started to love Flutter because while the development process I easily found all the widgets that I needed to make the clone app look similar as much as possible to the original app. In the end, the result impressed me so much and I was convinced to learn more about flutter development.

I would also recommend you to give it a try. Especially, if you need to have MVP for your project then go for it. You will benefit from the advantages of cross-platform development such as faster development, less time to test, less effort to bugfix and maintenance and advantages of flutter such as native-like performance, great UI.

There is also one more thing I want to mention that, apps for Google’s Fuchsia OS are written in Flutter. I am not going to write about Fuchsia OS here, but briefly, it is assumed that Fuchsia OS can be Google’s next mobile OS or maybe replacement to Android OS (depending on the result of the problem between Google and Oracle). But it is hard to say how probable is that to happen. Anyway… The reason I mentioned this issue is to show you that – assuming that happened, then it is gonna be really valuable if you already know and have experience with Flutter. 🙂

Helpful resources which I think are worth to check:

Impressions from UIKonf Berlin 2019

Reading Time: 5 minutes

With little doubts in the beginning, big uncertainty and the questions in my head “Is this the right conference?”, “Should I’ve chosen another conference?”… But it happened and I’m satisfied at the end of the day with my choice. Some of my colleagues were surprised of my choice (Berlin), but yes, I can definetly say “It was not a mistake”.

So how was it?

Day 1: Social events

I’ve chosen to be with the walking tour group. There were possibilities to be in different groups like Bicycle group, Boat trip group… But this was my choice. We were split into two groups by 12 people and a local tour guide. We visited different spots, like the Memorial to the Murdered Jews of Europe, the popular Checkpoint Charlie, the Berlin French Cathedral, the Brandenburg Gate, etc…

The day finished in a big restaurant where we received our conference badges and promo materials of the conference. It was a very relaxed atmosphere and new chance to meet and introduce yourself to new developers. Some of the participants were professionally oriented and immediately started to talk about iOS topics. Some were on their way to the bar ordering german beers and the popular “wursts”. There also was a small group that played some kind of table tennis game. I’ve attended in all of these social activities.

Day 2: Opening day of the UIKonf 2019

After the opening words and the short introduction, the conference officially started. The first day consisted of 9 presentations. The strongest impression of the day was the presentation of Ellie Shin about Mock Generator for Swift and how they at Uber solved the problem of mocking. They optimized the app to build the mocks in around 10 seconds instead of the previous time needed; it was more than 1 hour.

One of the best presentations of the day was from the lovely Julietta Yaunches. She talked about consistency principles in programming, how to keep the coding style consistent and not make big changes every day, how to decide when to introduce something new in your code, etc.

It were good presentations from Kristina Fox about Internationalization of the iOS applications, and the opening presentation from Kaya Tomas about Accessibility and Inclusion in the apps. A topic I wasn’t aware before this conference.

I also have to mention the presentation of Glenna Buford about how to organize the network stack of your iOS application.

The day finished with a social event named Ambassador’s dinner. The local participants of the conference had the task to show the other participants (foreigners, including me) the typical restaurants and bars in Berlin. I was in a group that visited Hofbrau Munich Restaurant in Berlin. We had some good discussions with colleagues from all over the World. Throughout the evening we enojyed some tasty good german beer and pork meat.

Day 3: 2nd day of UIKonf 2019

The second day had 9 new presentations and 9 new speakers.

The best of the day in my opinion was the presentation of Kate Castellano. She talked about applications with backend driven UI.

Among the better presentations was of Neha Kulkarni about Advanced Colors in Swift.

I will also mention Erica Sadun. She talked about Swift Strings. In her presentation she showed best practices about using strings in Swift, interpolation of strings, etc.

Also there was a choice to visit 2 workshops on MyTaxi boat stage near the conference hall. I visited this stage and it was about the management process, recruiting and organizing the teams in MyTaxi company. The 2nd presentation was about Tips and Tricks they are using for testing their apps.

The day finished with a big party in a local restaurant near the river Spree. It was another good party. A lot of talks with colleagues, a lot of drinks, good atmosphere. All finished at 1:00 am.


I can freely say it was a good conference, perfectly organized… I didn’t regret in any moment that I’ve chosen this one in a bunch of other conferences. First of all, I’ve learned a lot of new things, I’ve heard about topics I wasn’t aware before, I saw how it would be to talk infront of 500 people.

Maybe in these events the most important thing is the social component. New faces, positive people, talks, sharing experiences, enlarge your professional contact list.

All 18 speakers

I’m not sure what was the intention of the organizers to have only women speakers. 18 speakers – 18 women. It was not explained, but we cannot complain because the speakers dealt with the challenge perfectly.

Worth the money, worth spending my time at UIKonf in Berlin. I have a feeling I will visit it for sure again in the future.

Can Siri finally understand more than the predefined Intents?

Reading Time: 3 minutes

GUI is so 90’s

Lately, I find myself increasingly annoyed to have to use my phone to perform boring and recurring tasks like look up the quote of a special cryptocurrency. Especially in some circumstances like eg when I’m home. At home, I want to feel foremost comfortable. This is hard to achieve when I have to get up to search for my phone, once again. Wouldn’t it be nice to just ask in the room and get the answers?

Wait but there is Siri, right? So what can it do for me and what can developers achieve with it today?

Hey Siri, are we there yet?

Turns out that SiriKit offers a set of predefined intents ready to be used. That’s a start. But those cannot handle my specific requests and I guess a lot of others as well. To be fully usable something like custom parametrized intents would be nice. I would like that Siri understands something like:

“Hey Siri, what’s the price of <your cryptocurrency> in <your currency>?”

To be fair. When asking this for Bitcoin and USD you would get an answer. Depending on how the question is formulated Siri would start the Stocks app in preview or get something from the Web. But when trying to get an answer for other rather “unknown” cryptocurrencies, Siri struggles. I totally get that this question may seem fairly simple for a human to process but it is certainly not that simple for Siri to filter out the domain in question and start the “right” app for the job.

Hence I would also be satisfied with something in the form of a QA for the beginning:

> “Hey Siri, cryptocurrency price”

< “For what cryptocurrency?”

> “Bitcoin”

< “In what currency?”

> “USD”

In that way, developers could assign to specific keywords (in this case “cryptocurrency price”) input dialogues to get params to process those and render a response. Something similar to URL schemas

After looking a bit deeper I stumbled upon an interesting blog post which clarified it for me:

There are also some hands on blogposts how to set up “Custom Intents”:

I’ll just wait here then

Since iOS 12 it is possible to create a custom Intent in the form of an Intents.intentdefinition file. Here app developers can specify parameters which the app can process. To stick with the cryptocurrency example: When the user is searching for a price of a cryptocurrency inside an app, the app can create an Intent with the parameters already filled out. Eg. Show the price of Bitcoin in USD. Furthermore, the app can now “donate” this specific Intent (already parametrized) to the system. This “donation” would appear on the lock screen and as a shortcut ready to be used.

This means one could assign a custom Siri voice command to trigger this Intent. It also means that if you have 5 favourite cryptocurrencies and 3 favourite currencies you would have to go through this step 15 times inside the app. Afterwards, you would need to assign 15 voice commands to those donations.

Well, honestly this is not the way I would like it to be. But it’s a start and I hope that with iOS 13 we get something like parametrized Intents for the user to trigger.

My expectations from UIKonf Berlin 2019

Reading Time: 3 minutes

After more than 6 years this will be my first conference. This time as a guest. I remember well the moments of my presentation in Baku, Azerbaijan in 2013. Stressful experience, a lot of sweat, with my suit that was one number larger than it should be. That was 2013 and the topics were economics and management. Now I’m an experienced iOS developer and going to Berlin for a conference that should give me new ideas for personal development, but also to give me directions how to think for the future challenges.

Conference generalities

The venue of the UIKonf is RADIALSYSTEM V in Berlin.

From 26-29 May 2019 in Berlin, some serious iOS developers will come from big companies that will present their experiences in the iOS World.

The motto of the conference is simple:

“UIKonf is an independent conference for serious iOS developers”


For this conference, the organizers decided to have only female speakers. All will come from big companies and with big experiences. We have female iOS developers who work or worked for Uber, Slack, LinkedIn…

Part of the speakers


The travel expenses are the cheapest for this conference viewing from my perspective. Fortunately, we Macedonians have direct flight connection to Berlin. The cost is around 150€.

The ticket to attend the conference costs 539€.

They are also offering free tickets to members of underrepresented groups in tech (this includes disabled people and generally people who are unable to attend without financial assistance).

The accommodation is something that is not completed from my side. The hotels near the conference building costs around 100€ per day.


This conference has an excellent organization.

The first day 26 May is the day for social meetings, time for visiting places in Berlin, acknowledge the other attendants and will finish with a kick-off party where the people will take their badges.

Next two days 27 and 28 May are the days when the speakers will expose their presentations. 30 minutes per presentation with question and answers part of the end of each presentation.

29 May is the last day. This is unofficial part of the conference and the people can meet with the sponsors, dissect code problems in lab sessions with experienced experts, signup for a workshop or just hang out and code with new friends.


I have big expectations. The names of the speakers, their experience, the companies they worked for are guarantees for something big and something good.

I’m going by myself and expect to meet new people, make new friendships, share experiences.

Berlin as a city is something new for me. I had heard very good things of Berlin. Good parties, restaurants, parks, two different sides of the city. I have friends that live/lived there.

With the correct size of my suit this time – it should be a good experience in my life.

WeAreDevelopers World Congress 2019 – Expectations

Reading Time: 3 minutes

Why this one?

I’m a mobile developer. In specific an iOS developer. So guess what, I love writing code either in Swift or Objective-C for Apple devices. When searching for a conference to attend in 2019 I rather had the WWDC in mind. There is one drawback, however you need some serious money and luck to get there. But in general, there are plenty of other good iOS conferences to attend (NSConf, CocoaConf, …, you name it!). 

For an overview and a brief description of iOS conferences in 2019 I found this page from Hacking with Swift very informative.

There is a very nice overview diagram of iOS conferences depending on your location and/or budget in an old post (2017) at Although outdated, most of these conferences will also happen in 2019 and pricing and location rarely (dramatically) change.

Wait, but the post is about your expectations for the World Congress 2019 in Berlin. So what happened?

Ok, let’s get to this. When searching for iOS conferences in 2019, this conference somehow slipped into the search results. And it did so because Steve Wozniak was speaking there. Well, which iOS/Mac developer wouldn’t want to see and hear the legendary Steve Wozniak, right?

Once on the WeAreDevelopers homepage I realised that Steve Wozniak was giving a talk there a year earlier. So, 2018 in Vienna. Furthermore, this conference isn’t iOS or even mobile specific. That’s another drawback. Anyway, once on the page I skimmed through this year’s speakers. Here are some of them:

  • Rasmus Lerdorf – Inventor of PHP
  • Håkon Wium Lie – Inventor of CSS
  • Andreas M. Antonopoulos – Author, Mastering Bitcoin

Well, maybe Steve Wozniak is not there, but there are a lot of high quality people from IT in general. People who had and have a tremendous impact on millions of developers out there. One can argue about the weaknesses and strengths of PHP, CSS, Bitcoin. But one is for sure. With all downsides, these technologies are used and working on a daily basis. Furthermore, there are vibrant communities behind them.

Ok then. I’am going because I would like to see a broader picture of tech then just a little piece of it.

Btw there are mobile related talks anyway.

Expectations (TL;DR)

  • Experience some good talks from people with impact
  • Get a feeling where we’re headed in the future
  • Maybe see some demos/MVPs on AR/VR, Robotics
  • Get answers where bitcoin and blockchain are going and what the state of disruption is
  • Socialising

Facial recognition technology and its effect on health insurance companies

Reading Time: 6 minutes

When I was young, I used to make fun of people who believe that other people can read their future out of hand, and I still make fun of them, but during last year I figured out that with the help of technology, it is now easy to read people’s hidden presence.

As an iPhone user, yesterday, while I was unlocking my mobile using facial recognition, I took a moment of thinking and I found how far we have reached using this technology within all business fields especially in health insurance companies. So as being one of 250,000,000 annual customer of apple (250,000,000 average of iPhone devices sold per year), I became really surprised and fascinated about facial recognition technology to the point I opened up my mouth.

Off late, apparently, that our face has not just become as a way of recognizing ourselves. In the era of computer, which sees more than we do by far and learns faster than us by far. Most important, it sees some really personal secrets. For a second my mind got frozen from happiness as finally I can imagine what the real emotion for Mona Lisa was 😀, RIP da Vinci.

Yeah…. she looks neutral!

In such an amazing computer simulation experiment at Stanford University, two researchers made the computer study more than 35,000 photos from self-identified and heterosexual people from public dating sites and after training the computer, the algorithm was able to correctly differentiate gay and heterosexual men with an accuracy reaching 81% of and 71% accuracy for women. Just from the face, the device (artificial intelligence) becomes able to differentiate, identify and predict the sample based on sexual orientation. At the end of the research, the researches wrote “our findings expose a threat to the privacy of men and women”. Moreover, if you show the device 5 pictures of the same person, its recognition accuracy jumps up to 91% and this just through the face. Such a surprisingly percentage as human mind can only reach 60% of recognition with the same number of photos. From this study, we can see, there is a direct positive relationship between increasing the sample size and level of recognition accuracy.

So from what has been stated above, we can reach a conclusion that by increasing sample size, the accuracy level increases. We can prove our conclusion by the result declared in China. This development of technology is now able to recognize the citizens in a heavily populated country like China in less than 3 seconds. Out of 1,400,000,000 citizens (sample size), this technology is able to recognize any specified citizen within the mentioned duration. Moreover, this technology has applications in different fields as many criminals have been captured using this technology within the same rate. This occurs at present. You can imagine if China develops this technology, which is currently being done, this duration will be minimized and the accuracy level will be maximized according to the above stated conclusion.

Not quite there yet in the real world, but Hollywood already is 😉. ZOOM! ENHANCE!
Selfie time: new AR technology in KFC Original+ Beijing will know what you want to eat 🍔🍟

Last year, the biology scientist Craig Venter, one of the greatest scientists in the field of biology, specifically in DNA sequencing, I have ever seen published a research in PNAS journal, illustrating that using DNA, the device can recognize 80% of the faces. If you give the device 10 DNA, for example, it can expect how 8 persons faces will look like. So, with the sample of 1000, it reached an accuracy of 80% in the expectation. So, if this is applied to eg China, you can imagine how high the percentage of accuracy will be in future. Again our face reflects our gene. If you see this issue as not a big deal, I won’t agree with you. As in 1950s we have exerted every effort just to know the structure of the DNA. So, in a nutshell, what ever is hidden in our genes, we can see it on our faces.

Official Apple TouchID Icon. It seems to be happy…

Some readers may say, it is just an identification technology similar to Touch ID and it is not going to save Titanic. I will tell them, you are right, it is not gonna save Titanic, but it is gonna save many health insurance companies. This technology will have a great effect on health insurance companies as from 30-40% of genes’ diseases (genetic disorders manifest craniofacial abnorma) have effect on faces and skulls as Hart and Hart stated in 2009. Health insurance companies can know a lot about your health without making any blood test, just with your facial recognition analysis, which you do not have any will in. This will help insurance underwriter to minimize the risk as much as possible.

To sum up, just using facial recognition technology, the devices can declare our characteristics, orientations, and also behaviors. So are you still interested in iPhone or you will turn to Android