Most iOS (and Android) apps are written as a single module with features / layers separated by folders. If done right, modules can be extracted simply by moving whole folders to newly created modules. It’s rarely the case, though.

Modularization is known to be a good architecture decision for many reasons: better separation of concerns and features, cleaner code, easier communication and collaboration in the team.

Image for post
Image for post

With a number of modules growing, one day you will surely face a transitive framework dependency problem, which produces “ITMS-90562: Invalid Bundle” issue after uploading the build to App Store.

Disclaimer: We are using Carthage for dependency management. For CocoaPods users this issue and solution may not be relevant.

Let’s make things clear from the beginning. There is no way in which cross-platform mobile apps can match native mobile apps in performance, user, and developer experience. And they won’t ever be able to do it. Everything else is just marketing ;)

Image for post
Image for post

Native mobile apps are developed separately for Android (Kotlin) and iOS (Swift). Ecosystems are supported by Google and Apple correspondingly, so developers get the newest, the most stable, the most convenient tools (Android Studio, XCode), SDKs, and libraries for work.

There are only two issues about native mobile development: cost and consistency. If there is a problem, there must be a solution. Considerable market for cross-platform frameworks already exists. …

How many times were you thinking about writing your backend for mobile apps you are working on? And how many times have you chosen Firebase instead? Are there any better options at the moment?

Image for post
Image for post

In this article, I'll describe our experience of writing Kotlin backend for Codeforces WatchR mobile apps using Ktor, which is officially positioned as follows:

An asynchronous framework for creating microservices, web applications, and more. It’s fun, free, and open source.

Why backend is needed?

Codeforces WatchR started almost 3 years ago as a pet-project, which used official Codeforces API to simply fetch and display data from server. But with time we came up with many additional features, for which the existing API wasn't convenient or even sufficient. …

Developing breakthrough products is hard. Be it web or mobile, native or cross-platform, proof of concept, or production-ready app. By supporting several platforms, you multiply the difficulty by a factor of 2 or 3.

Image for post
Image for post

In this article, we will cover the following questions:

  • what is difficult about developing for multiple operating systems
  • why consistency is important
  • how to decrease complexity and increase the conformity of codebase

I’m going to share our experience of making native mobile applications more consistent, increasing our team’s coherence and bandwidth, and finally making our end-users happier 🤗

Inconsistent by design

As a mobile engineer with experience in both Android and iOS, I can assure you that even though these platforms look and work in a pretty similar way, development experience differs considerably: SDKs, APIs, IDEs, best practices, and even developer habits. …

Kotlin Multiplatform is a great technology in the maturing period, which means that it's not always possible to find what you need for your project and you must craft it yourself. Are you ready for a challenge?

Image for post
Image for post

In this article, I'll share a step-by-step guide of creating and publishing of KMP library for JVM, Android and iOS targets. Target, if simply put, is just a type of device where you want your library to work.


Codeforces WatchR is an open-source mobile client for Codeforces platform, where thousands of programmers compete in weekly algorithmic challenges. …

There are dozens of cross-platform technologies, which promise you "write-once run-anywhere" experience out of the box without any considerable drawbacks. But in the end, we all know it's not 100% true.

Image for post
Image for post

To be honest, there are only a few viable solutions for cross-platform application development when it comes to the mobile world: React Native, Flutter and Kotlin Multiplatform.

The latter is the youngest player in the field, but the most promising one. It's super-flexible, concentrates on sharing business-logic, ensures native UI/UX, and enables native development experience.

In this article, I want to share our migration journey of native iOS and Android apps to Kotlin Multiplatform. I'll emphasize both, pros and cons, of chosen technology + some workarounds for bugs we've faced in the process. …

Kotlin Multiplatform is one of the most interesting trends in mobile development this year. It's dedicated to sharing the code between many different platforms, including mobile ones — Android and iOS.

Image for post
Image for post

This technology concentrates on sharing the business-logic in a form of a library, which means that you have a quite limited access to platform-specific functionality, when writing shared code. Database is a part of this limitation.

There are 2 options for database management with Kotlin Multiplatform out of the box: SQLDelight and SQLighter. Starting with them from the scratch is rather straightforward. …

Have you ever felt like there are too many innovations in Swift ecosystem? And you are a little bit lost in all those new things? Don’t worry, you are not alone. At least I fill exactly the same way. But learning and constant change are integral parts of the developer’s life.

Image for post
Image for post
Dots for all

There are unlimited (if compare to your time) resources to skill up and learn. Nowadays, the problem is not about “accessing learning materials”, but about “filtering and compiling what’s important to your job”. …

After being an Android developer for 5 years, I’ve decided to try something new and finally ended up in the iOS native development. Even though Kotlin and Swift are quite similar languages, there are still some notable differences.

Image for post
Image for post

One such difference is sealed classes, which I, and probably most of Android developers, can’t live without. In short, these are special classes, which leverage inheritance along with syntax sugar to create “restricted class hierarchies, when a value can have one of the types from a limited set, but cannot have any other type” (source).

Representing UiModel in Kotlin

My favorite use case of sealed class is UiModel, which represents different states View of and for each state contains some processed data, which needs to be rendered. Let’s imagine, we have a really simple Medium client application, which can show only one hardcoded article’s title and description. …

Just imagine that you live in a big city and spend 1–2 hours commuting to work every day. Actually, you are in the overcrowded train right now, sweating along with other “happy” workers. Your train stops on the next station and all passengers “sont invités à descendre”.

You are taking the bus, but it’s also stuck in the traffic jam a few kilometers away from the office. So you finally decide just go on foot and arrive at work when your colleagues are leaving for lunch. …


Yevhenii Kanivets

Professional Mobile Engineer since 2014, passionated by #EdTech, learning and teaching. Competitive programming enthusiast. Marathon Finisher.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store