Mykola Miroshnychenko

Building your own Agentic Skill

Tue, 16 Jun 2026 18:22:32 GMT

In one of my previous posts, I covered what an MCP server is. Now I’ll explore another option for improving your interaction with LLMs & agents - more specifically, we’ll look into Skills.

There’s no better way of understanding something than by building it yourself. So in this article, we will use all of our knowledge from the previous two articles on screenshot testing, and we’ll try to create our own skill to be used by others.

What is a skill?

As previously An MCP server is a “tool” that your agent can use, while a “skill” is a modular instruction with samples to give your LLM of choice a better understanding of certain tasks you want it to perform.

Agents load skills in steps:

Discovery: Initially, an agent loads only the description and the name of the skill. All it needs to know at this point is what the skill does and when to trigger it.
Activation: Once the agent comes across a task that can be a potential match for a skill, it reads the full SKILL.md file and puts it into context.
Execution: The agent proceeds with the instructions described in SKILL.md. If necessary, the agent may choose to execute the bundled code and use files in the referenced directories.

Full instructions load only when a task matches the description, so agents can be aware of dozens or hundreds of skills, whilst using only a small fraction of context.

What’s inside

A “skill” is just what’s contained in the SKILL.md file. As per the standard, the only mandatory fields are the name and the description. After that, you should have the actual implementation of the skill - this can be anything from code samples to instructions to a truth table, etc.

Best practices for designing a Skill

There are dozens of best practices for creating a skill. But the most important one is providing as many useful details as possible without polluting the context . It can be tempting to put all of the knowledge of humankind into a SKIL L.md , but remember that your LLM has limited context. And once activated, the LLM will load the whole SKILL.md file. According to this page by OpenAI:

1 token ~ 4 chars

If your skill is massive - say 100k chars, that equates to ~25k tokens. This means you have used up 1/8th of your context window (considering it’s 200k). And if the agent loads multiple skills for a specific task, it’ll have even less for your codebase. So I think you can see where this is going. You have to be frugal with what you put in your SKILL.md .

Here’s some nice advice from the official skill documentation:

Read agent execution traces, not just final outputs. If the agent wastes time on unproductive steps, common causes include instructions that are too vague (the agent tries several approaches before finding one that works), instructions that don’t apply to the current task (the agent follows them anyway), or too many options presented without a clear default.

Skills work best when they’re specific and modular. I was thinking of making a skill for screenshot testing as a whole, but such a skill might be too broad. That’s why we’ll solve a super-specific problem like integrating screenshot testing into Github Actions with Paparazzi. I already covered this in my previous article. So it makes sense to put this knowledge inside a skill.

Photo by Josh Olalde on Unsplash

Building the skill

Ok, let’s get our hands dirty with building the skill. The name and the description are the only mandatory parts of the declaration. But we’ll also add some metadata.

name: paparazzi-github-actions
description: Integrates screenshot testing with Paparazzi in Github Actions
metadata: 
	author: Mykola Miroshnychenko
	keywords:
	  - Screenshot testing
	  - CI
	  - Continuous integration
	  - Paparazzi
	  - Github 
	  - Github Actions

Adding prerequisites

Before we start putting the execution instruction, code snippets, references, etc., it’s best to let the agent know what needs to be in place before we proceed.

## Prerequisites

Make sure that Paparazzi Gradle plugin is installed. The latest version can be checked here - <https://cashapp.github.io/paparazzi/changelog/> 
Git LFS needs to be installed. Ask the user for permission to install it if it's not installed. URL - <https://git-lfs.com/>  Command - brew install git-lfs
The project needs to have Paparazzi tests in place before proceeding.

Steps

This is the part that contains the actual execution algorithm. I like the step-by-step approach. It gives the agent a clear path to follow instead of grasping at straws. It’s also easier to structure your own thoughts like that as well.

Step 1

A Yaml file with the current Github Actions workflow should 
be in  `./github/workflows`. If it's not there - create these directories and 
inside create a `github-actions.yml` file. In such case, use 
[this reference](references/basic-github-actions-workflow.md) for a standard workflow to put inside this file.

Notice that I’m referencing the skill folder structure here - specifically the references directory.

Since we don’t want to waste our tokens, it’s best not to overload our agent with unnecessary information. The structure for a basic GitHub Actions workflow .yml file should only be read by the agent in case there is no CI workflow at all. Therefore, we don’t put the whole workflow inside SKILL.md itself, but instead into the references directory for the agent to access if needed. This saves valuable context window and tokens.

Another reason for extracting code into different directories is that the LLM might already know what to do - so your solution might be redundant. However, if you absolutely want to guarantee that the agent uses your solution - then make sure the wording is explicit, like “Use”, “Read”, “Extract”, etc.

Step 2

If the user has has an existing workflow file in `./github/workflows` - amend the 

	checkout Repo step (actions/checkout@v4) by adding `lfs:true` at the end like so: 

      - name: Checkout Repo
        uses: actions/checkout@v4
        with:
          lfs: true

Steps 3, 4, 5, 6…

I’m not going to bore you with the whole sequence of events - you get the idea. In general, this whole skill is based on my previous article . You can check out the full SKILL.md file here .

This is what the structure of our skill looks like so far.

paparazzi-github-actions/
├── SKILL.md  # Our actual instructions
├── references/workflow.yml #separate "standard" github actions workflow

Photo by National Cancer Institute on Unsplash

A skill to test our skill

Just like with your everyday coding, you can have a standardized way of testing your skill. You can do this with a JSON file called evals.json . However, testing a skill is different from testing code because you will have to check the output yourself. So, this is more akin to “fine-tuning” rather than testing.

Below is the eval.json which consist of:

Prompt: Something a real user might type which would trigger your skill
Expected output: This is the part that needs to be verified by a human. Essentially, this is the “ideal” scenario that has to be checked.
Input files: An optional argument that contains a path to assets that might be used during the test.

We’ll start with two main scenarios as of now.

{
  "skill_name": "paparazzi-github-actions",
  "evals": [
    {
      "id": 1,
      "prompt": "I want my paparazzi screenshot tests to run on github actions. The repo already has the tests and the generated snapshots committed, but nothiing is yet done on CI",
      "expected_output": "Verifies the prerequisites first: the Paparazzi Gradle plugin is applied, Git LFS is available, and the paparazzi.snapshot { } tests each have a matching PNG under app/src/test/snapshots/images. Since there is no .github/workflows/ directory, creates .github/workflows/screenshot-tests.yml containing a checkout step with lfs: true, JDK + Gradle setup, a verifyPaparazzi<Variant> Gradle step, and an upload-artifact step that runs only on failure. Initializes LFS (git lfs install), tracks **/snapshots/**/*.png and commits .gitattributes, then — because the PNGs are already committed to history — moves them into LFS with git lfs migrate import and warns that this rewrites history and will need a force-push. Confirms tracking with git lfs ls-files.",
    },
    {
      "id": 2,
      "prompt": "My repo already has a CI workflow at .github/workflows/android.yml that builds the app and runs unit tests. I want to add Paparazzi screenshot verification to it. Do not replace my existing workflow.",
      "expected_output": "Does NOT overwrite or recreate the existing workflow file. Edits android.yml in place: adds lfs: true to the actions/checkout@v4 step in the relevant job, and ensures a verifyPaparazzi<Variant> Gradle step plus a failure-only upload-artifact step exist (adding them if missing), adjusted to the repo's module and build variant. Then performs the Git LFS setup (git lfs install, track the snapshots glob, migrate the already-committed PNGs into LFS) and verifies with git lfs ls-files.",
    }  
}

We’ll put our evals.json into a separate directory so our structure will look like this:

paparazzi-github-actions/
├── SKILL.md
└── references/
    └── workflow.yml
└── evals/
    └── evals.json

Now you can either “manually” run these prompts, or you can use an “orchestrator” skill. By “orchestration” I simply mean another set of instructions i.e. a “skill-creator” skill. This skill was developed by Anthropic with the specific intent of creating and improving new skills. It’s an incredibly thorough set of instructions - so we will cover only the basics here.

Here’s the prompt that I’m using to orchestrate the testing of my skill:

I want you to use skill-creator skill and run the evals in the paparazzi-github-actions/evals within the current project

Once the orchestrator finishes the evaluation, you’ll get a *skill*-workspace directory alongside your skill one - in my case, it’s the paparazzi-github-actions-workspace .

Depending on how many times you’ve run/improved your skill, you might get several iteration directories. In my case, I ran it only once, so I only have one. Inside, you’ll find a bunch of files providing you insight into the performance of your skill:

But the most interesting is the benchmark.md:

And the most important point is the Delta . So in my case, apparently, the success rate “With Skill” is 100% - which is reassuring. Yet in terms of the token usage and the time passed - it’s not that great. But, this is the first iteration - which means there’s a ton of room for improvement.

Now, skill optimization is another story, and it deserves an article of its own. I’ll leave you some resources that you can look into in case you’re interested.

Conclusion

While creating your skill is definitely an interesting thing to try, I feel like it’s a bit too “vague” in terms of building the actual skill and optimizing it. While writing this article, I’ve looked inside skills that were built by different companies, and it looks like there’s no single coherent standard. It seems you can put anything inside the instructions, and the way it’s actually tested is at the mercy of the “skill-creator” skill. Iterational improvement of skills is also very costly - a single iteration of paparazzi-github-actions skill took > 40k tokens. This is considering it’s tiny compared to other skills. So multiple improvement iterations might be in the millions of tokens.

What are your thoughts on this? Have you found a good way of building skills for LLMS? Leave your thoughts below.

Setting up Android screenshot testing in CI with Git LFS.

Mon, 01 Jun 2026 16:45:47 GMT

In the previous article, we looked at how to integrate screenshot testing with Paparazzi, how to create tests that are not brittle, and how we can use certain parameters to make our tests more effective.

In this article, we’ll look into another problem associated with screenshot testing - more specifically, storing the screenshots remotely. As your app grows and gets more complex, so does the number of your screenshot tests. If you’re working on a real production application, the number of images taken can easily spike into hundreds or even thousands.

Storing thousands of images in your repository is a bad idea. This will bloat your repository size, and you’ll run into problems with your remote repository provider. To solve this problem - we can use Git LFS.

Here’s a high-level overview of what we’ll do:

Understand how Git LFS works
Install Git LFS
Track Snapshots with LFS
Migrate existing screenshots to LFS
Configure CI to use Git LFS and produce a report

How Git LFS works

LFS stands for Large File Storage. Usually, LFS is used in the gaming industry, because the assets they use can easily exceed Gigabytes or even tens of Gigabytes For this purpose Git LFS was invented.

Most Remote Git Servers will limit your push file size to 50 or 100 Mb per push. And the limit for repo size on free plans can be 1 or 2 GB. Since screenshots are big files by Android standards, it’s best to allow LFS to handle this.

Here’s a diagram of how Git LFS works:

When you push your large files with LFS - the remote repository will transfer these large files to an LFS server and will then only store references or pointers to the actual files in the codebase.

So the files themselves live locally on your machine and on the LFS server.

When you need to retrieve from the remote repository - the opposite happens. The remote repo will looks through the “pointers” it has and will query the actual files from the LFS server. Then it will transfer them to your machine.

The great thing about this is that you don’t need to worry about all of this complex set up. This is all handled by remote repo providers like Github, GitLab, Bitbucket and others.

Installing Git LFS

The installation is super simple. Simply run:

git lfs install

Now we need to make LFS track the files that we want uploaded to the LFS server. In our case, it’s going to be PNG files stored in the tests → snapshots → images directory. We could specify to track specifically the files in the snapshots directory, but for simplicity, we’ll simply store all PNG files in LFS:

git lfs track "*.png"

Now running this command will start tracking files that you have NOT committed yet. Which means that we’ll need to manually “import” the existing snapshots that we already have from previous tests.

After running this command, you should see the .gitattributes file. This is the actual configuration file that tells git what to do with PNG files in your repository. Also, if we check the staging status of our file in Git with git status we’ll see that all of our PNGs have become “staged for commit”:

Let’s go ahead and add them to our commit and push to our repo with git push . If all is well, you’ll see this in your terminal:

git p
Uploading LFS objects: 100% (6/6), 162 KB | 0 B/s, done.

Verifying our LFS works

Now, to confirm that Git is no longer tracking our PNGs but only has a pointer to them, we can ask it to show the contents of the “PNG file” that we have. So let’s ask it to show any of the 4 screenshots that we have by running this command:

git show HEAD:app/src/test/snapshots/images/dev.mirosh.topusers.ui.screenshots_ScreenShotTest_testListItemWithLongNameFollowing.png

Which will show us 3 lines:

version <https://git-lfs.github.com/spec/v1>
oid sha256:fbdc1fc6eaf974dfaa6a7522a2f7e2db4d49d9b0f41c132d4a589601e23aa27d <- our pointer
size 41554 <- size of the image on the LFS server

Configuring our CI to work with LFS files

By default, CI tools that you use will actually check out the pointers to the LFS files, instead of the files themselves. But for our screenshot testing to run on the CI - we need to reference the actual files behind these pointers. Luckily, this is super easy.

In your .yaml file add the lfs:true line to the checkout repository action:

steps:
  - name: Checkout repository
    uses: actions/checkout@v4
	    with:
	      lfs: true

For our demonstration, I will use GitHub Actions to run the pipeline. Here’s the full list of steps in my .yml file:

    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Checkout Repo
        uses: actions/checkout@v4
        with:
          lfs: true

      - name: Verify Paparazzi screenshots
        run: ./gradlew :app:verifyPaparazziDebug

      - name: Upload Paparazzi failure report
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: index.html
          path: app/build/reports/tests/testDebugUnitTest/
          if-no-files-found: ignore

The last step upload the report as an artifact in case of test failure. Make sure to, of course, adjust this script according to the names of your build variants.

Running the tests on CI

Paraparazzi will only generate a report in case there is a failure of some test. So to confirm that our screenshot tests work on Github Actions, we’ll change some of our UI. In our ListItemWithShortNameNotFollowing() Preview Composable I’ll just change it to following :

@Preview
@Composable
fun ListItemWithShortNameNotFollowing() {
    val userUIModel = UserUiModel(
        id = 1,
        displayName = "Nick Mirosh",
        reputation = "1000k",
        profileImage = "",
        following = true // <- Changed
    )
    ListItem(user = userUIModel) {}
}

Now, let’s make a commit and push, and observe our pipeline…

Our ./gradlew :app:verifyPaparazziDebug task fails as expected, it will produce a report. Then our next task runs:

And we get an artifact download URL:

Artifact download URL: <https://github.com/nsmirosh/ScreenshotTestingSample/actions/runs/26213027963/artifacts/7130214525>

And after unpacking the archive and opening the index.html we get our good ol’ report:

Conclusion

And there you have it. In these two articles, we have covered everything from the basics of screenshot testing, all the way up to deploying it on your CI.

Screenshot testing definitely has its place in your day-to-day Android development. It can make your life easier during migrations, catching subtle regressions and testing scenarios you wouldn’t physically be able to test.

However, this type of testing also comes with the dangers of creating flaky tests. Screenshot testing should not be the core of your test suite.

All in all, it’s one of the “funnest” ways of verifying your UI, considering how explicit the visuals are. I urge you to integrate it into your project and play around with it - you now have everything you need to do that!

Introduction to Screenshot testing with Paparazzi.

Fri, 15 May 2026 08:20:42 GMT

Screenshot testing can be a powerful tool, but it can also wreck your tests - here's how to use it properly.

Introduction

You’ve probably heard about screenshot testing but haven’t tried it. Or you tried it and it broke everything in your workflow, so you decided it was a bad idea. There’s a lot of hype around the topic, and many teams seem to be adopting this type of testing into their workflow. Integrating screenshot testing is fairly easy. What’s NOT easy is applying it properly without messing up your development process.

In this article, we’re going to look at :

What screenshot testing is
How to integrate it into your project and CI
How to write screenshot tests that add value to your project
Where you should avoid it

Ok, first let’s look at what it is. The code that we’ll be using in this article can be found here: https://github.com/nsmirosh/ScreenshotTestingSample

What is screenshot testing?

Screenshot testing is simply the process of comparing your views with the reference images stored previously. It’s literally the process of comparing images pixel by pixel. After you have the reference (Golden value) screenshots in place, you can then run the tests to see whether your UI is looking different from what you intended. After running the tests, you will get a report with the “diffs” between your pre-recorded “golden value” and what’s actually happening in your UI.

Where screenshot testing works well.

Screenshot testing should be used for catching regressions in your UI.

In general, it is really useful when:

You have components that don’t change often
You have a shared design system or component library where one change can influence many different “consumers”.
Your app supports multiple themes, locales, fonts, or screen sizes — scenarios where it’s not realistic to check everything manually.
You’re refactoring infrastructure, and you don’t expect anything to change visually.

Where it’s a pain:

While screenshot testing may be useful in situations described above, it can also lead to very brittle tests if applied incorrectly. Do NOT use screenshot testing for:

Validating complex screens that change often.
Validating behavior of your components (you can’t do that with screenshot testing any way).
Anything that a Unit or a UI test will catch instead. Unit and UI tests are far less costly in terms of maintenance than screenshot testing.

Photo by Christian Mackie on Unsplash

The tools

There are maaany libraries for screenshot testing. Here’s a list of just a few:

Google Compose Preview Screenshot Testing tool
Cashapp Paparazzi
Roborazzi from takahirom
Dropbox Dropshots
Shot from pedrovgs
Ndtp Android-testify
Facebook screenshot-tests-for-android
QuickBird Snappy

This list is taken from Segio Sastres’s screenshot testing playground . Make sure to check it out as well if you want to learn about different frameworks.

I’ve tried 3 of them: Paparazzi, Roborazzi and Google’s own screenshot testing library. Google’s library is still in the early alpha - so I don’t consider it a viable production library. And Roborazzi - I don’t have anything against it, but I’m always happy to use a library that is developed by Square. So I’ll be covering Paparazzi.

Deciding what to test

I’ll show the appropriate scenarios for using screenshot testing and how they can make your life harder if you do it wrong.

Let’s say we’re building an app that tracks the top 20 users of StackOverflow by rating, and we can follow and unfollow them.

Some scenarios where we can apply screenshot testing to a single list item:

Following / Not Following + Short / Long name
Image Loading Error / Placeholder
Light / Dark Theme
Large font scale

Each of these can catch a real regression, and none of these states are subject to frequent change in our app.

Here are the previews generated for Following / Not Following states:

Now let’s implement the actual tests.

Set up

First, we need to set up Paparazzi.

As of the time of writing of this article, Paparazzi doesn’t support Gradle 9.3.0 and higher, so for this example, I’m using Gradle 9.2.1. If you use anything above you might run into problems https://github.com/cashapp/paparazzi/issues/2227 ``

My gradle-wrapper.properties set up looks like this:

distributionSha256Sum=72f44c9f8ebcb1af43838f45ee5c4aa9c5444898b3468ab3f4af7b6076c5bc3f
distributionUrl=https\\://services.gradle.org/distributions/gradle-9.2.1-bin.zip

After modifying Gradle, go ahead and import the Paparazzi plugin into your app-level build.gradle:

plugins {
  id 'app.cash.paparazzi' version '2.0.0-alpha04'
}

Paparazzi docs are here.

Building the tests

Paparazzi supports multiple testing frameworks . For our example, we’ll use the good ol’ JUnit.

Building tests is simple. We want to take snapshots of the 4 states of the Composable as we mentioned above. And this is what it looks like:

package dev.mirosh.topusers.ui.screenshots

import app.cash.paparazzi.DeviceConfig.Companion.PIXEL_5
import app.cash.paparazzi.Paparazzi
import dev.mirosh.topusers.ui.main.ListItemWithLongNameFollowing
import dev.mirosh.topusers.ui.main.ListItemWithLongNameNotFollowing
import dev.mirosh.topusers.ui.main.ListItemWithShortNameFollowing
import dev.mirosh.topusers.ui.main.ListItemWithShortNameNotFollowing
import org.junit.Rule
import org.junit.Test

class ScreenShotTest {

    @get:Rule
    val paparazzi = Paparazzi(
        deviceConfig = PIXEL_5,
        theme = "android:Theme.Material.Light.NoActionBar",
    )

    @Test
    fun testListItemWithLongNameFollowing() {
        paparazzi.snapshot {
            ListItemWithLongNameFollowing()
        }
    }

    @Test
    fun testListItemWithLongNameNotFollowing() {
        paparazzi.snapshot {
            ListItemWithLongNameNotFollowing()
        }
    }

    @Test
    fun testListItemWithShortNameFollowing() {
        paparazzi.snapshot {
            ListItemWithShortNameFollowing()
        }
    }

    @Test
    fun testListItemWithShortNameNotFollowing() {
        paparazzi.snapshot {
            ListItemWithShortNameNotFollowing()
        }
    }
}

Each test takes a screenshot of the Previews that we have defined previously. After we have our tests set up, we need to record the “Golden” reference images - i.e. the images we will run our tests against. To record the references, we run the following Gradle task:

./gradlew :app:recordPaparazziDebug

Make sure to replace app with the name of your module if it’s different

The generated report will land in app/build/reports/paparazzi/debug/index.html

and the individual screenshots in src/test/snapshots . Here’s what index.html looks like:

To make sure your tests and previews render the same images you can use Coil’s FakeImageLoader for testing with Coil. And you can use AsyncimagePreviewHandler for rendering Previews.

Running the tests

Ok, we have the tests set up, now let’s actually run them using the following command: ./gradlew :app:verifyPaparazziDebug

This command will take a snapshot of the current state of our views - and will compare them to the “golden” pre-saved images from the previous command.

You will see the report with the diffs between the “Golden” image and the actual result in app/build/reports/tests/testDebugUnitTest/index.html

Obviously, the test succeeded - cause we’re comparing identical images. Nothing really interesting to see here. Now, let’s break our test.

Breaking the tests

Let’s say that we decided to allow 3 lines for the name instead of 2 - just in case of a super extra long name like mine. So with that change - this is how the super long name will look like:

Let’s run the tests again. And as expected, two tests with long names fail.

And if we click the first test, we’ll see a long stack trace. However, what we care about is this:

java.lang.AssertionError: Images differ (by 1.282920%) - see details in file:///Users/mykolamiroshnychenko/coding/work/TopUsers/app/build/paparazzi/failures/delta-dev.mirosh.topusers.ui.screenshots_ScreenShotTest_testListItemWithLongNameFollowing.png

This comment is self-explanatory. Our images differ by 1.28%. But that doesn’t tell us anything in terms of what exactly failed. Let’s open the file path with the details:

But… the difference between our Composables is huge - why does it say that it’s only ~1% difference?

“Shrinking” Composables

Currently, our tests are set up to render the whole screen with our Composable. That’s why we get only 1% difference between our screenshots. To fix this, we need to apply a SHRINK rendering mode to our Test Rule. By applying this argument, Paparazzi will record only our Composable without rendering the full screen:

    @get:Rule
    val paparazzi = Paparazzi(
        deviceConfig = PIXEL_5,
        theme = "android:Theme.Material.Light.NoActionBar",
        renderingMode = RenderingMode.SHRINK
    )

We’ll need to re-record our Golden images and run the tests again:

./gradlew :app:recordPaparazziDebug

./gradlew :app:verifyPaparazziDebug

If we open the generated report, we’ll see:

java.lang.AssertionError: Images differ (by 14.988646%) - see details in file:

Now this is much closer to the truth.

And this leads me to my next point…

Tiny differences will cause failures

Now, 15% is a lot, and such a test should fail. But what if somewhere along the way, we decide to format the rating of our StackOverflow users? In cases where we have a short name, we want to display 1,000k instead of 1000k .

If we make this change, our tests will still fail - even though the difference will be an insignificant 0.32% (I ran it for you to save the reading time).

So, how can we add a bit of leniency for such cases? By default, the “margin error” for Paparazzi tests is 0.1%, or 0.1 . But, if for some reason you have a flaky test, you can adjust this by tweaking the maxDifferencePercentage parameter:

    @get:Rule
    val paparazzi = Paparazzi(
        deviceConfig = PIXEL_5,
        theme = "android:Theme.Material.Light.NoActionBar",
        renderingMode = RenderingMode.SHRINK,
        maxPercentDifference = 2.0 // 2% diff allowed
    )

With this change, any tests that have a deviation of 2% between the Golden image and the test image will succeed.

But! Use this option sparingly! In fact, try to avoid using it at all. If you do have to use it - it’s best to isolate the flaky test into its own test class, because passing maxDifferencePercentage it to our Rule will apply it to all of our tests, and we don’t want that.

Conclusion

Screenshot testing is a great tool for catching visual regressions in your app. It can help you verify parts of your app/codebase that are hard to meaningfully test with UI or Unit tests. It’s also extremely easy to set up.

However, while this type of testing is undoubtedly useful, it can also be very brittle if set up incorrectly. So make sure you’re very careful in choosing Composable / Views that will not change often and don’t have many elements. Also, remember that other types of testing tend to be “cheaper” in terms of maintenance, so do not treat this as a silver bullet for UI testing.

In the next article, I’ll explore how you can integrate screenshot testing into your CI without bloating your repository by using Git LFS.

Rapid UI prototyping with Figma + Android MCP servers.

Tue, 21 Apr 2026 07:27:11 GMT

I’m not a designer, so my designs usually suck. I will always choose to work with a professionally-made design if I have the opportunity. And now that we have agents — we can ask them to quickly build our app UI based on a Figma design.

In this article, I’ll show you how to utilize MCP servers to build UIs that look exactly (well, almost) like the Figma design.

What is an MCP server?

From Wikipedia:

The Model Context Protocol (MCP) is an open standard and open-source framework introduced by Anthropic in November 2024 to standardize the way artificial intelligence (AI) systems like large language models (LLMs) integrate and share data with external tools, systems, and data sources

Essentially, an MCP servers are tools that your AI agents can use in addition to what they have “out of the box”.

By default, Claude Code has access to tools like: bash, web search, stopping or starting tasks, spawning sub-agents, etc… You can see the full list here.

While Claude Code is powerful by default, you can make it an ABSOLUTE UNIT of a coding agent for your specific task with MCP servers. For example, to build a UI for our app, it would be great if Claude could take screenshots, launch our app, debug it, and reference design details in Figma all by itself. Enter Android and Figma MCP servers.

Installing MCP servers. Local vs Remote.

There are two types of MCP servers — Local and Remote. The names are pretty self-explanatory. Whenever you use a remote server, your agent will make an “API” call that gets routed to a 3rd party server. The local server stays on your machine.

Disclaimer:

Whenever you install an MCP server, make sure to exercise the same caution as you would with any new library. You wouldn’t install a library written by an unknown developer without inspecting it — so make sure you really know what the MCP server does as well.

Installing an Android server

Installing a server is usually pretty easy. For this example, we’ll use local Android MCP server developed by martingeidobler . There are other, more popular ones, but I found Martin’s server to be super easy to set up. Also, it has 25 Android tools, which is very helpful.

To install for Claude Code, simply run this command in your terminal:

claude mcp add - scope user android - npx -y android-mcp-server

If you use a different agent, the installation instructions are here.

You can also control the application scope of the server. More details about that here.

To verify the installation, first launch your emulator. Then, in Claude Code, run the /mcpcommand. You should see something like:

If it shows up as connected— that means Claude can now access it. Awesome, now let’s do the same thing for Figma.

Installing Figma

The installation instructions for Figma MCP for Claude Code are here.

Run this in your terminal to install:

claude plugin install figma@claude-plugins-official

Figma MCP is a remote server, so just keep that in mind.

The design

Ok, the tools are in place. Let’s take a look at what we want built. Here’s the main screen of an Android habit-tracking app that I’ve been building lately:

Pretty ugly, if you ask me. I want my app to look elegant instead. Thankfully, we can find free designs on Figma and Dribble. And God bless those designers who put out their work for us to use for free.

One such sample is the HABITA Habit Tracker UI Kit. This design is free to use, and it was developed by Hertafui.

Running it altogether

Ok, we have our MCP servers set up with Claude Code, and we found the UI that we want. Now we need to provide Claude with a link to the design. This is done by clicking Copy link to selection on the section that you want to reference in Figma.

And here’s the prompt that I’m giving Claude:

Implement this Figma design: https://www.figma.com/design/g207whsYY6odvltu0ObGgq/HABITA-Habit-Tracker-UI-Kit--Community-?node-id=3-660&t=z6JCnk8QoaLTxMNh-4

Scope:

Only apply this to HabitListScreen.kt
Do not touch other screens
Skip the “See All” button in the Figma design

Fidelity:

1:1 visual match
Try to use Figma's typography/color tokens exactly

After implementing, build with ./gradlew assembleDebug and launch on the emulator via MCP to verify.

Let’s run!

Result & Conclusion

Ok, after running for 4.5 minutes — here’s what Claude built:

Not bad. If I were writing this by hand, it would’ve definitely taken me > 20 mins. Maybe even more. However, remember that there’s always a tradeoff when you delegate to AI. If this were a production app, I would now need to spend time verifying that the code is flexible, safe, reusable, etc. But for prototyping — this is a gold mine.

In conclusion, MCP servers can be used to help AI agents perform tasks that are out of reach for them by default. In this article, we used Android + Figma MCP servers to build a new UI for my habit-tracking app. You can check out a whole bunch of other MCP servers here.

Thank you for reading!

If you want to stay up-to-date with modern Android & KMP development — sign up to my “Multiplatform Mindset” newsletter here or on my website.

Overly relying on AI diminishes critical thinking and increases cognitive debt.

Fri, 17 Apr 2026 09:31:01 GMT

I've noticed this myself.

It's very tempting to keep on pushing Claude Code or other agents to generate code for your project. But at a certain point, you notice that you're avoiding reviewing the generated code. The thought process is: "Oh, it probably got it right - I'll review it later". Spoiler - you won't.

That's why I decided I will have days where I don't use any AI at all. I will make sure that during these days I go over the code previously generated and actually think whether it makes sense to have it.

Cognitive debt is real. Here is a quote from the study: "Cognitive debt defers mental effort in the short term but results in long-term costs, such as diminished critical inquiry, increased vulnerability to manipulation, decreased creativity. When participants reproduce suggestions without evaluating their accuracy or relevance, they not only forfeit ownership of the ideas but also risk internalizing shallow or biased perspectives."

In short, use your brain more often.

Here are some studies to refer to:

https://arxiv.org/pdf/2506.08872v1

To Think or Not to Think: The Impact of AI on Critical-Thinking Skills

NSTA - National Science Teachers Association

How a $5 tub of cottage cheese exposed a million-dollar UX flaw.

Thu, 02 Apr 2026 06:46:19 GMT

I’m a massive fan of @Villa Market JP. They’re easily the best place in Bangkok for high-quality imports (and my specific breakfast obsession). But a recent late-night quest for cottage cheese turned into a masterclass in why "small" mobile UX flaws can cost a business serious money

I love cottage cheese. In fact I love cottage cheese so much I ate it for a couple of years straight for breakfast and I didn’t get bored with it. For some reason, though, cottage cheese (good one) is hard to come by in Bangkok. There are very few places that sell it here.

Yesterday evening, however, I was determined to get it and watch “The Man in The High Castle”. And there is one place that sells it - a supermarket chain called Villa Market.

So happily having strolled into one of Villa Markets I quickly approached the dairy aisle. To my horror - they were out of stock. My mind started racing as I was thinking where else can I get it right now. I immediately checked Grab to see if any other place might be selling it. Nothing… I noticed however, that Grab wasn’t searching through Villa Markets in the area. Bingo! I just needed to download the Villa Market app, and order it from another store - surely they have it there!

The clock was ticking though - it was around 9:30 pm and Villa closes at 10, so I needed act fast.

I downloaded the app, registered, received the OTP… I could feel I was getting close to my beloved cottage cheese with every step.

Now I needed to find it. This is where I encountered the first weird design decision. You had to check each store individually for the item you’re looking for. Whatever, ok, this wasn’t going to stop me.

But no so fast said the app...

The First Friction

Instead of showing me a map - I was presented with a list of addresses of stores - including those in other cities. Huh, ok, you’re not going to stop me this easily. I found a store with a street name that sounded familiar - so I knew it was somewhere close

Praise be! My cottage cheese was found! There it was, in its full glory, looking at me from Villa Market Gaysorn. Overjoyed, I swiftly added it to my cart, and was dashing towards check out.

I was at the finish line. The credit card was out. This is the moment every business dreams of—and the moment their app decided to kick me out of the store. And just as I was about to press “Pay” - a window (dialog in mobile terminology) pops-up asking me if I want to switch to store that is closer to me. Ooooh, a nice little optimization I thought. Don’t mind if I do. I press “Switch” - and my cottage cheese dissapears….. Ehhhh what?

Apparently, this “closer” store is also out of stock. What? Why would you recommend me a “closer” store - if it doesn’t have what I need? Confused, but not demoralized, I went to the home page, switched back to the store that had it in stock, found my cheese again, went to check out and BAM! That window again. But, you won’t get me this time you trickster of application!

Broken Logic = Abandoned Cart

I tap outside of the window dialog expecting the window to go away (as it should), but it doesn’t. After a dozen or so taps I understood that this app has a deadly flaw in the world of mobile development. It has the dreaded undismissable dialog. Something that you should never have in your app. Now I was getting desperate. My belief in me getting the cottage cheese started to get shaky.

Ok, there’s still one thing I can do. Let’s revoke the location permission. The app won’t know my location now, so they shouldn’t show me this dialog altogether. I run through the same flow - and you know what I see? That darned dialog window again. Whyyyy? Have they cached my location and now there’s no way to get rid of it?

At this point, I ran out of ideas. My plan of eating some cottage cheese while watching “The Man in The High Castle” that evening has been crushed. I was defeated. I had to admit that this app bested me.

There was, however, a solution that I discovered later. Deleting the app, installing it, and denying a permission from the start allows you to bypass this dialog.

What is this all about?

I wanted to spend money. The app wouldn't let me. As a developer, I see this every day: businesses spending thousands on user acquisition, only to lose them due to preventable UX friction.

It’s not just one tub of cottage cheese. It’s the LTV (Lifetime Value) of a customer. Because of this friction, I sought an alternative. In a competitive market, friction is a gift to your competitors.

3 Core UX Rules

All of these problems come down to 3 core UX rules:

1. Always show what’s happening - spinners, progress, feedback

2. Never trap the user - cancel, undo, back navigation

3. The app should be predictable - same actions → same results

How would I fix this app?

Your goal as a business is to guide your customer to check out as effortlessly as possible.

Long list of unknown addresses? A lot of people would give up at this point. Better to quickly show a map with nearby locations.

You want to offer a closer location to your customer? By all means do it - but respect their decision of declining your “offer” by allowing them to dismiss the dialog.

Your user revokes a certain permission? Track that and delete the associated data. Even if you think that keeping that data might turn out useful later - that data might be stale - exactly as this story points out.

Offer the customer to switch to a different store at checkout? Sure, but make sure that that store HAS the products that your customer has in their basket.

To be clear: I’m not bashing the @Villa Market JP dev team. They’ve built a solid service that I use regularly. My goal is simply to highlight how "corner cases" like this can derail an otherwise great customer journey.

Is your app’s checkout as smooth as it could be? Let’s find out.

Contact me

6 Legacy App Horrors That I've seen - That Might Be Killing Your Business Too.

Wed, 01 Apr 2026 19:26:19 GMT

I’ve spent years working with legacy mobile codebases. Some were stable, but most were "Jenga Towers" held together by hope and deprecated libraries.

Legacy code is a silent tax on your business and a headache for devs. Here are the top 6 horrors I’ve encountered and how I’d fix them in 2026:

Photo by Shai Lopez / Unsplash

The Mother of all requests. It starts out with a home page that keeps growing and growing… While initially it might be a good idea to pre-load data - usually the bloat expands, as the complexity of the application grows. The user is left hanging while the app is loading ungodly amount information.

👉 Solution : Instead of having your good ol’ REST APIs you can go with GraphQL. In Kotlin Multiplatform this is easily done with Apollo Kotlin or a Ktor GraphQL client.

The request stampede. Multiple REST requests at the same time, to the same server. There are specific cases where it makes sense to have multiple requests done at the same time, but very often it’s a result of poor planning.

👉 Solution : GraphQL can help here as well, by requesting only the needed data from the a single endpoint.

Photo by Aron Visuals / Unsplash

Race conditions. By far the worst thing you can have in your app is a race condition. These things are incredibly hard to pin down. In one of the legacy projects I’ve worked on we once spent an entire week figuring out the root cause for a race condition. If your app starts having sporradic race conditions - this an equivalent of a “mayday” call on an aircraft.

👉 Solution : While there are no silver bullets for this one approach is to utilize UDF to hoist the state upwards to a single source of truth.

Photo by Neil and Zulma Scott / Unsplash

Shadow Duplication. Sometimes apps get so big and the team turnover is so fast, that knowledge doesn’t get passed on. I once worked in a bug in a token refresh functionality for a legacy project, only to discover that another part of the app in the background was doing the same thing - but with a different framework.

👉 Solution : Modularization. Extract core business logic into a shared, platform-agnostic Kotlin module from the start. It makes duplication physically impossible.

Photo by Girl with red hat / Unsplash

Tight coupling (Founder’s debt). And by tight - I mean it was solid as a rock tight, and not in the good SOLID sense. Whenever you tried changing something - it felt like you’re playing Jenga. I remember working on transportation app that was initially written by the founder of the company - while he was still learning how to code. Yep, the core of the app was written by a junior developer, and left untouched for 10 years. You can imagine the delivery “speed”, to put it mildly.

👉 Solution : Thankfully, we have tools like DI tools like Koin and Hilt to fix these problems. It will take a great deal of untangling the code first, of course.

Photo by Chris Liverani / Unsplash

500k+ LOC with no tests. Sadly, about 60-70% of legacy apps I’ve encountered didn’t have any tests. Such projects follow the “don’t touch it if it works” policy. But sooner or later you DO have to touch it if you want any features developed.

👉 Solution : No quick fix here, but you need to stop the bleeding. Enforce strict CI/CD gates on test coverage for all new code. The best time to plant a tree was 10 years ago - the second best time is today.

The key point: Every hour spent untangling code from a decade ago is an hour you aren't shipping features. My approach is to keep the code flexible with DI, modularize the core and establish clean architecture, share logic via KMP, and turn that Jenga tower into a foundation.

Which of these "Horrors" is currently lurking in your production app? Let's discuss in the comments.

After a year of work (yes, a full year), my Kotlin Multiplatform course is finally ready!

Thu, 19 Mar 2026 10:36:25 GMT

This course is designed specifically for Android developers who want to move into KMP in a structured way. If you’ve been thinking about getting into KMP, this is exactly the course I wish I had when I started.

You can check it out here:

https://learnkmp.com

Also, if you want to receive monthly tips on KMP & Android to your inbox, you can join my newsletter and you will get a 15% discount on the course if you join now:

https://subscribepage.io/ODZYLC

Happy to answer any questions 🙂 promo video below 👇

Be careful with commonMain dependencies in Compose Multiplatform!

Wed, 10 Dec 2025 09:57:00 GMT

I’ve recently had a problem with importing a dependency in commonMain in CMP. More specifically I was trying out the new navigation3 component. Since I first tried out Nav3 in Android - I blindly copied over the dependency to my CMP project.

My Android CMP build was working fine - and I was happy. However, I decided to give my other target a run - specifically the iOS one. I was very surprised when I couldn’t make the project compile.

I quadruple-checked everything, cleaned gradle cache, and restarted the project around 5 times - but it just wouldn’t compile. So I went checking everything line by line.

And then I saw it:

I was importing an Android dependency in commonMain.

This seemingly minor mistake - can create a lot of pain if you’re not careful. An Android dependency that is put into commonMain.dependencies{} will resolve without issues… on Android. But the same project won’t compile when you try to launch iOS.

Sooo… if you’re working with CMP / KMP - make sure you’re not putting platform-specific libraries into commonMain!

Make your Gradle builds and Android Studio faster

Fri, 24 Oct 2025 08:29:47 GMT

Recently I've had some issues with my Android Studio - it was lagging, freezing, etc., which got me thinking about how I can improve the speed of my builds and Android Studio in general.

Here are the settings that I applied to my Gradle builds (global ones at ~/.gradle/gradle.properties), and so far they've been working like charm.

Below are the settings of my Gradle. My set up is M1 Max with 64 GB RAM.

What settings do you have to improve performance?

Avoid vibe-coded services like a plague for important projects.

Fri, 24 Oct 2025 08:19:29 GMT

I was using a certain service for my course with which I was explaining the networking part of KMP. And then a couple of weeks back the service stopped working. I looked into the issues on Github - the owner of the service said they were attacked constantly (because the service didn’t have authentication) so they’re taking steps to integrate protection. Sounds fine to me.

So the service started working again after a couple of days / week. But recently I started getting weird errors once again. I thought “huh, that’s strange” - so I started looking through the website and found the answer to my problem in the FAQ.

I followed the instructions, but requests began failing on the website as well.

And then I saw it…

At the very bottom of the page it said:

“Vibe coded with 💜”

I immediately knew I had to get rid of this service in my course or suffer the consequences. Idk what was the point of putting this message at the bottom of the page - to avoid responsibility? But either way I knew the things would go downhill from here.

The sad part is - this service has been up for a good 5 years, so it was not vibe coded in the beginning. But I guess the temptation is too much to use slop.

What is a circular dependency, and how can you resolve it? 🤔

Tue, 21 Oct 2025 11:05:09 GMT

If you’re new to DI, whether it’s Hilt or Koin - sooner or later, you’ll encounter a circular dependency (I hope you don’t, but let’s assume you will 😢).

This post is an explanation of a challenge I posted two days ago

So what is a circular dependency? 🤔

According to Wikipedia:

A circular dependency (or cyclic dependency) is a relation between two or more modules / classes which either directly or indirectly depend on each other to function properly

🔄 Essentially, it’s an infinite loop, because when one class requires another class at creation time and vice versa, you have a never-ending cycle.

How do you know you’ve run into a circular dependency? You will probably get a StackOverflowException because of the never-ending invocation of the class constructor. 💥

How can you resolve or detect it? The best way is to not have one in the first place. And Clean Architecture helps a lot here. See the carousel below for an explanation.

Are there ways to detect circular dependencies if you already have one? Yes, but it’s rather painful (and I might cover that later) - so it’s best to avoid them altogether.

Can you spot the issue in this Koin code?

Tue, 21 Oct 2025 11:00:35 GMT

In the code below we have initialization of a Koin module along with the declaration of dependencies it injects. 💉

🔍 Your task is to find the issue and share it in the comments! I'll share a post with an explanation in two days.

💡 Hint: this problem applies to all DI frameworks.

Memory leaks cost you money. Literally.

Tue, 14 Oct 2025 08:54:27 GMT

As mobile devs, we often don’t care how much memory our app uses — as long as we don’t hit the dreaded OutOfMemory exception.

Let’s be honest: we do care as professionals, but if the app consumes 100 MB more than it should, it doesn’t hurt us. The app runs on our users’ phones — we’re not the ones paying for the extra RAM.

Well… I recently learned to care the hard way with my Telegram Finance Bot.

Yesterday, Railway messaged me that my bill doubled over the last two weeks.

I got curious - what’s causing this? Memory usage more than doubled over a couple of days - even though I didn’t introduce any big features or libraries. So I started digging…

My first suspicion was that I have a memory leak somewhere . In Android we have the benefit of coroutine scopes that are scoped to a certain component - like viewModelScope, lifecycleScope, etc. These scopes do the clean up magic behind the scenes. If the component is destroyed - so is everything inside that scope. A graceful, neat solution.

Well, in a pure Kotlin app you have to manage that yourself. In my bot I would start up CoroutineScopes for each operation and didn’t think twice of it. My thinking was - well, as long as everything finishes inside that scope - the memory will be released. And that is not wrong, but you have to be very careful with what’s going on inside the lambda.

Each scope created like this (CoroutineScope(Dispatchers.IO).launch { ... }) lives independently — if you forget to cancel it or it captures large references, they’ll stay in memory long after you expect them to be gone

To be honest, I didn’t find the exact leak — but I decided to optimize my app anyway.

Here’s what helped cut memory usage in half 👇

Made my data layer a singleton with Koin. Singletons help prevent redundant instantiations, but you also need to ensure they don’t themselves hold onto stale data forever.
I switched some StateFlows to SharedFlows where I didn’t need to retain the last emitted value — StateFlow always holds one, which can keep large objects in memory unnecessarily.
Created my own application-wide CoroutineScope with SupervisorJob instead of having dozens of independent CoroutineScopes running wild.
Removed unnecessary logging in production

After these changes, memory dropped (see the graph), and my Railway bill went down too.

Moral of the story:

Don’t be reckless with memory. Sloppiness can cost you real money — especially outside mobile apps.

I just published a new video on Kotlinx Serialization + Ktor 🚀

Sun, 12 Oct 2025 07:13:00 GMT

I just published a new video on Kotlinx Serialization + Ktor 🚀

In this video, I'll be covering:
✔️ What Kotlinx Serialization is
✔️ How does serialization work in general
✔️ The advantages over other libraries like Moshi, Jackson, and Gson.
✔️ Some basic features of Kotlinx Serialization
✔️ 💻 Additionally, we'll build a KMP note-taking app that makes actual network requests and serializes data.

What if I told you that you don’t need to use expect/actual in Kotlin Multiplatform?

Sun, 12 Oct 2025 07:06:22 GMT

Platform-specific Koin modules can do the job better.

Expect/actual is great when your project is small. However, as your codebase grows, managing platform-specific dependencies quickly becomes a headache.

That’s where Koin modules shine. 💪 They let you replace expect/actual with a more flexible and scalable approach — keeping your architecture nice and clean.

Here's my KMP project where I implemented this approach.

See the slides with explanation below.

How I traumatized myself by storing all the data for my app locally.

Sun, 12 Oct 2025 06:59:41 GMT

Back when I started programming 10 years ago, I traumatized myself by storing all the data for my financial app locally.

Yes, you read that right — I had an app in production, and all of its data lived on the device.It was my first app, called "Daily Budget", and I uploaded it to Google Play just in case someone else was facing the same money-tracking struggles I was.

To my amazement, it got around 10,000 downloads. But what those poor souls didn’t know is that all of their data was stored only on their phone.

What followed were man-made horrors beyond comprehension.

Encouraged by this “success,” I kept adding more features and expanding the app. As my knowledge grew — especially around databases and best practices — so did my desire to fix things. But since everything was local, I had to migrate the data manually on the device. This was back in the days when you had to write raw SQLite queries yourself.

I did around 14 migrations before the app started to collapse under its own weight.

Keeping track of the users’ data state became impossible. I couldn’t inspect the data — I just had to pray the next migration didn’t break everything.

I walked away from that app with a lot of lessons learned (and a fair number of angry users 😅).

Biggest lesson:
👉 Don’t make early architectural decisions that are written in stone.
👉 If you must make a suboptimal choice, make sure it’s reversible later.

Otherwise… you’re going to have a bad time.

Code coverage is a bad metric

Wed, 10 Sep 2025 19:05:15 GMT

0:00

/0:58

100% test coverage… sounds safe, right? Wrong. Here’s why your coverage report might be lying to you:

Unfortunately, test coverage does not accurately reflect the extent to which the code is tested. All it does is show the amount of lines of code executed. It does not indicate that the functionality under test is actually correct.

In fact, you can achieve 100% of test coverage without actually testing anything. How? By simply not doing assertions in your tests, but still invoking the methods.

Test coverage is a good negative metric, but a bad positive one.It's useful for highlighting gaps (e.g., 0% coverage signals untested code), but it can be misleading when used to claim thorough testing.

An improvement over line coverage is branch coverage. The branch report indicates the amount of conditional statements traversed. This metric is harder to “trick” in comparison to line coverage.

However, even branch coverage does not guarantee the quality of your tests. The only way to do it is to actually write the proper assertions that verify relevant outcomes.

🚨So, don’t be fooled by high test coverage, it does not guarantee in any way that the code is safe. Write tests that verify the needed outcomes and run them often, preferrably on your CI / CD.

Focus on writing meaningful tests with solid assertions. High coverage is nice, but it’s quality testing that keeps your code safe.

Things I have never shared in public, part 1.

Fri, 29 Aug 2025 18:38:18 GMT

If I were to judge my technical level - I would say I’m an average engineer. I’m a senior engineer, but this seniority comes from experience, grueling + slow studying and a billion mistakes I made along the way - not because I learned quickly or can comprehend complex ideas easily. I’ve always been amazed and jealous of people who could understand hard things swiftly.

Very often, I would get roles where I felt I wasn’t ready and had to learn new things on the job. I would also get stressed because I didn’t want people to “find out” I’m not what I sold myself as.

I have failed many many times during interviews and had people actually walk out on me. I have probably failed around 80% of the DSA interviews I’ve had.

I was mediocre at math in school (once the math started getting hard) and I have started learning programming only when I turned 22 (my university major is Economics, not Computer Science).

I got my first job in IT in an outsourcing company. For the most part, I got it because I spoke really good English - and as I was told later by my boss, I was an “easy sell” to foreign clients. I sounded “smarter” than my peers who were technically more proficient, but had worse English.

And I got really good at English, not because I studied hard, but because my mom won a program that allowed her to study in the US for 2 years. As a child, I came along with her and simply “absorbed” the language.

So, just in case I’m giving off a vibe of someone who “has stuff going for him” -the reality is far from it :)

Why am I writing about this? Because I also have perfectionism (not the good kind), and it’s holding me back in many ways. And this is my way of battling it and confronting my fears of not being perfect in front of my peers.

P.S. I'm not completely disregarding my achievements - but just saying that I'm far from perfect.

Understanding engine differences, limitations and configurations + KMP integration.

Fri, 29 Aug 2025 16:47:49 GMT

Comparing Flutter, KMP, and React Native in 2025. How They Work. Advantages and Disadvantages.

Tue, 26 Aug 2025 09:13:51 GMT

Instead of looking for that latest AI tool, learn things that genuinely make you productive.

Fri, 08 Aug 2025 18:21:07 GMT

Learn how to blind type. If you’re still looking down at your keyboard when typing - you are much slower than you can be. There's a bunch of websites for this. Here is one, for example.
Learn Vim (or emacs). Ever since I learned VIM, I rarely touch the mouse. Editing, navigation, commenting, copying, deleting - Vim is the answer There’s a website where you can practice that too - vimgolf.com . There's also a wonderful IdeaVIM plugin that you can use in AS and IntelliJ.
Learn IDE shortcuts. You can use standard ones, or assign them yourself - whatever works for you. Here are AS shortcuts .

These are the things that improved my productivity. What about you? Anything that has increased your productivity?

We've all heard of extension functions in Kotlin, but have you used an infix function?

Thu, 07 Aug 2025 17:29:18 GMT

An infix function provides better readability for operations that require two arguments/objects.

It also operates the same way as an extension function. This means you can reference the fields of the receiver (in this example it's the Session class) implicitly without calling "this".

In the example below, I use the belongTo() function both with and without infix notation. As you can see, the infix function removes the extra parentheses. Infix makes expressions a bit more readable, and it can make a difference in a large codebase.
The only requirement for the infix function is that you must have a receiver (Session) and a parameter (Chapter).

𝗦𝗵𝗼𝗿𝘁𝗲𝗻 𝘆𝗼𝘂𝗿 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗹𝗼𝗼𝗽 𝗳𝗼𝗿 𝗳𝗮𝘀𝘁𝗲𝗿 𝗿𝗲𝘀𝘂𝗹𝘁𝘀!

Wed, 06 Aug 2025 11:09:48 GMT

This actually applies everywhere in life - not just in programming. But in programming - it’s crucial to shorten your feedback loop.

Recently, I’ve been working with some obscure Google services - Google Play Asset Delivery and Google Play Feature Delivery. Both are not very popular services and the documentation is kind of terrible (didn’t expect that from Google tbh).

Here’s the problem, though - you can’t debug the code with these services. Because you have to bundle the assets and the modules (as split apks) together, you can’t debug through Android Studio. Therefore no access to the debugger. So the quickest feedback loop is thrown out the window straight away.

Here’s how I went from an incredibly slow feedback loop to less than 1 minute to get feedback.

Uploaded signed builds to Internal Testing (~10+ minutes to feedback, considering the build was 1.5 GB)
Uploaded unsigned builds to Internal App Sharing after the app was approved (~5 minutes feedback)
Swapped production assets/modules for test modules/assets, which are 6x less in size (~3 minutes feedback)
Used bundletool for local testing before uploading to Play (~2 minutes feedback)
Wrote a script that adds/removes resources locally, builds the bundle, converts it to APK, and then pushes it onto the device (<1 minute feedback)

At around point 5 - that’s where the productivity skyrocketed.

Fast feedback loop == faster improvement == faster results.

Auto-Incerement your builds

Mon, 04 Aug 2025 18:43:25 GMT

One irritating thing about Google Play Console is that it will show you need to increment the versionCode AFTER you have uploaded and it has processed your build. I’m currently working with very large .aab and APK sizes for testing - and it takes quite a while to process the build. It’s extremely frustrating to see that you forgot to increment your build version after making and uploading the build.

So I found this straightforward solution on Stack Overflow that auto-increments your build version on Android with each compilation - and it works like a charm

If you’re using Kotlin for Gradle - you can use my gist here.

And that’s it - each time you rebuild the app, it will auto-increment the build number, and you will no longer run into these dumb “please use other version code” errors.

NoSuchMethodError - a headache in a multi-module project.

Wed, 16 Jul 2025 12:13:14 GMT

Lately, I’ve been working with a legacy multi-module project in Android. I aimed to complete all the application initialization in my newly created module.

However, the legacy module had an Application class of it’s own with quite a bit of logic.

I faced a problem - how do I initialize the legacy application class, since you can only have one in Android?

Well, I decided to simply make the legacy Application an ordinary class and pass Context from my Application into the former application.

This worked beautifully on debug. However, when the time came to make a release build, the app started crashing with NoSuchMethodError. It couldn’t find the method I created to initialize the legacy Application class. I knew the problem was due to optimizations / obfuscation being done, but I couldn’t understand why. My Application was clearly calling this method during initialization. I added the proguard (optimization) rules to keep the method, turned off minifyEnabled, etc. Still - nothing helped.

Well, after hours of debugging and scratching my head - I finally got it. I correctly specified the proguard rules and minification… but in the wrong module.

Sure, my newly created module was clearly referencing the legacy code. However, the legacy module knew nothing about it. Since modules are treated as separate gradle projects - all code that’s not used within the module itself will be deleted during optimization.

Solution?

Specify the method/classes you want to keep in your proguard-rules.pro file INSIDE the module where this method/class exists. That way, this code won’t get removed during optimization.

Ktor engines

Thu, 10 Jul 2025 13:25:16 GMT

Ktor has many engines, but each one comes with its own unique challenges + configurations. This is the price that must be paid for being a highly flexible framework.

The Ktor team has done a wonderful job. The fact that Ktor can work with so many platforms is amazing.

I'm sharing a part of the slideshow that I'm using in networking section of my KMP course and I hope you find it useful!

Source sets or How KMP organizes multi-platform code.

Thu, 03 Jul 2025 11:32:02 GMT

One of the core aspects of KMP is source sets, which help us organize multi-platform code. In order for the app to compile properly and interact with platform-specific APIs, it's important to familiarize yourself with this concept. I've put together this post to help you understand this better. What have you struggled with in KMP? Let me know in the comments 👇

Breaking UI changes in Android 16.

Tue, 01 Jul 2025 13:38:13 GMT

Fellow Android developers - beware! Breaking changes in Android 16. 🚨 Android will ignore the orientation attribute in your Manifest starting from Android 16.

So if your app is forcing this and you're targeting the latest Android - your UI might get messed up. While this is, of course, not fun for those who will have to re-do their UI - I see this as a positive change. Many devs abused this by forcing certain orientations in their apps - not realizing that configuration changes can still happen.

You can read more about this here:

The future is adaptive: Changes to orientation and resizability APIs in Android 16

Build adaptive apps that support various screen sizes and orientations, promoting consistent user experiences across different Android devices.

Android Developers Blog

💡

No need to worry too much, though. This will only affect devices with the smallest dimension of >=600 dp

Kotlin’s :: operator and kewl things you can do with it

Tue, 01 Jul 2025 13:29:45 GMT

Kotlin has many concise operators, but one of the “confusing” ones is the:: operator.

You’ve probably seen it a bunch of times in projects you’ve worked in. Java has it as well. The :: operator is called the callable reference operator. It gives you a reference to a function, property, or a constructor without invoking it. This has many applications, but in this post I’ll show you just a couple of popular applications.

You can see the carousel below for examples. So, we can use :: (callable reference operator) for…

Passing functions as parameters. Then we can treat this reference as any other lambda. In our case, we will get a reference to the isEven() function. Getting a reference to a function is extremely useful for writing concise and clear code.
Callbacks. Another popular use case of the :: operator is callbacks. Similar to our previous example, we can use this operator to reference a callback that we have defined elsewhere in our file.
Reflection. Reflection is immensely handy in many use cases, such as dependency Injection, logging frameworks, and various libraries. The :: operator allows us to reference constructors, member variables, and other parts of our class. For example, you can do MyClass::class to access class metadata, or User::name to get a property reference. These are just a few ways you can use the ::operator in Kotlin — and I barely scratched the surface.

What’s your favorite use of the :: operator?