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.
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 ;)
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?
An asynchronous framework for creating microservices, web applications, and more. It’s fun, free, and open source.
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.
In this article, we will cover the following questions:
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 🤗
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?
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.
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.
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.
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.
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.
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.
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).
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. …