Kittysplit Blog

Konta w Kittysplit - twoje Kitty bezpieczne i pod ręką

Thu, 23 Apr 2026 00:00:00 +0000

Konta są już dostępne. Zaloguj się w Kittysplit (w przeglądarce, na iOS albo na Androidzie), a wszystkie twoje Kitty pójdą za tobą. To nasza największa aktualizacja od dłuższego czasu i jest całkowicie opcjonalna.

Po co konta?

Przez długi czas Kittysplit działał bez żadnych kont i to było celowe. Brak konta oznacza brak rejestracji, żadnych haseł do zapamiętania i żadnego zbierania danych osobowych. Do tego wtedy nie mieliśmy jeszcze apek mobilnych, więc przesiadanie się między urządzeniami nie było aż takim problemem.

Ale w naszej ankiecie konta były prośbą numer jeden, a od premiery apek w zeszłym roku słyszeliśmy o nich bez przerwy. No to wreszcie są! Samo wprowadzenie kont to żadna wielka filozofia. Schody zaczynają się wtedy, gdy mają pozostać opcjonalne. Sporo się nagłowiliśmy, żeby każdy Kitty działał tak samo, niezależnie od tego, czy jesteś zalogowany, czy nie.

Twoje Kitty na każdym urządzeniu

Zaloguj się w przeglądarce albo na telefonie, a wszędzie zobaczysz te same Kitty. Koniec z przekopywaniem starych czatów w poszukiwaniu linku. Nowy telefon? Inna przeglądarka? Po prostu się zaloguj i działaj dalej tam, gdzie skończyłeś.


Zaloguj się lub zarejestruj	Twój profil

Bezpieczniejsze Kitty

Jeśli założysz Kitty po zalogowaniu, jest twój. Tylko ty możesz go edytować albo usunąć, więc nic ważnego nie zniknie przez przypadek. Twoi znajomi dalej mogą dodawać wydatki i się rozliczać, tak jak do tej pory. Dla nich nic się nie zmienia.

Twoi znajomi nie potrzebują konta

Konto to twój wybór i tak już zostanie. Zapraszaj ludzi tak jak zawsze: wyślij im link i od razu mogą zacząć dzielić wydatki. Bez rejestracji, bez kombinowania. To wciąż serce Kittysplit.

Już wkrótce: zdjęcia profilowe

Następne w kolejce są zdjęcia profilowe: wrzuć fajną fotkę, żeby w Kitty twoich znajomych być kimś więcej niż tylko imieniem. Mamy też w zanadrzu kilka innych pomysłów tylko dla osób z kontem.

Miłego dzielenia wydatków! 🐱✨

Masz uwagi albo pomysły? Odezwij się na X, Bluesky, Instagramie albo napisz maila na info[at]kittysplit.com

Załączniki do wydatków - dodawaj zdjęcia do swoich wydatków

Thu, 12 Mar 2026 00:00:00 +0000

W Kittysplit pojawiły się załączniki do wydatków! Do każdego wydatku w swoim Kitty możesz teraz dołączyć maksymalnie 3 zdjęcia. To funkcja Super Kitty, więc żeby z niej korzystać, musisz uaktualnić swojego Kitty.

Co nowego?

Do każdego wydatku możesz teraz dodać zdjęcia. Pstryknij paragon, rachunek z restauracji albo cokolwiek, co dzielicie, a zdjęcie zostanie przy wydatku i każdy w grupie je zobaczy.

Na jeden wydatek przypadają maksymalnie 3 zdjęcia, co powinno wystarczyć w większości sytuacji. Paragony, faktury z hotelu, bilety na koncert albo po prostu zdjęcie tego, co kupiłeś, żeby reszta wiedziała, na co się zrzuca.

Koniec z przekopywaniem galerii kilka tygodni później w poszukiwaniu tego jednego paragonu. Dodaj go od razu razem z wydatkiem i gotowe.

Jak to działa

Kiedy dodajesz albo edytujesz wydatek, zobaczysz opcję dołączenia zdjęć. Wybierz zdjęcie z galerii. Jeśli później chcesz je podmienić, po prostu usuń stare i dodaj nowe.

Wypróbuj

Uaktualnij do Super Kitty i dodaj zdjęcia do kolejnego wydatku. To wszystko!

Miłego dzielenia wydatków! 🐱✨

Masz uwagi albo pomysły? Odezwij się na X, Bluesky, Instagramie albo napisz maila na info[at]kittysplit.com

Kategorie wydatków - zobacz, na co idą pieniądze w twoich Kitty

Wed, 11 Feb 2026 00:00:00 +0000

Mamy dla was nową, dużą funkcję w Kittysplit: kategorie wydatków! Od dziś każdy wydatek i przychód w twoich Kitty możesz przypisać do kategorii, więc łatwiej zobaczysz, na co właściwie idą pieniądze.


Dodaj wydatek	Filtruj według kategorii

Co nowego?

Każdy wydatek albo przychód, który dodajesz do Kitty, możesz teraz przypisać do jednej z 12 kategorii:

Mieszkanie i dom - czynsz, kredyt hipoteczny, ubezpieczenie domu i podstawowe rzeczy do domu
Zakwaterowanie - hotele, wynajem wakacyjny i noclegi na krótko
Jedzenie i zakupy - wypady do supermarketu i zapasy jedzenia do domu
Restauracje i wyjścia - restauracje, bary, kawiarnie i jedzenie na wynos
Transport - paliwo, komunikacja miejska, przejazdy typu Uber i wynajem auta
Media i łączność - prąd, woda, internet i rachunki za telefon
Zdrowie - lekarze, apteka i ubezpieczenie zdrowotne
Rozrywka i aktywności - rozrywka, atrakcje, koncerty i wydarzenia
Zakupy i sprzęt - ubrania, elektronika i zakupy różne
Wellness i pielęgnacja - siłownia, spa, kosmetyki i dbanie o siebie
Finanse i opłaty - opłaty bankowe, prowizje i inne koszty finansowe
Różne - wszystko, co nie pasuje nigdzie indziej

Każda kategoria ma swój kolor, więc wzorce widać na pierwszy rzut oka.

Filtruj swoje wydatki

Pierwsza funkcja, którą wprowadzamy razem z kategoriami, to filtrowanie wydatków. Listę wydatków możesz teraz przefiltrować według kategorii i szybko znaleźć:

wszystkie wydatki na restauracje z waszego wspólnego wyjazdu
wydatki na zakupy spożywcze we wspólnym mieszkaniu
koszty transportu podczas waszego road tripu
dowolną kategorię, którą chcesz przejrzeć

Dzięki temu łatwo odpowiesz na pytania typu „Ile wydaliśmy na jedzenie?” albo „Ile kosztowały nas noclegi na wakacjach?”.

Co dalej?

To dopiero początek. Już pracujemy nad kolejnymi funkcjami, które wyciągną z kategorii jeszcze więcej:

Porównania miesiąc do miesiąca

Zobacz, jak zmieniają się twoje wydatki w każdej kategorii. Czy rachunki za zakupy po cichu rosną, a może w tym miesiącu wydajesz mniej na jedzenie na mieście niż w poprzednim?

Analiza trendów

Wyłapuj wzorce i trendy w wydatkach z tygodni, miesięcy, a nawet lat. Idealne dla współlokatorów, którzy chcą lepiej ogarnąć wspólny domowy budżet.

Raporty graficzne

Czytelne wykresy pokazujące, jak wydatki rozkładają się na kategorie. Wykresy kołowe dla ogólnego podziału, słupkowe do porównywania kategorii i osie czasu dla trendów.

Po co w ogóle kategorie?

Niezależnie od tego, czy mieszkasz ze współlokatorami, czy planujesz wspólne wakacje, kategorie pomagają:

zrozumieć, jak wydajecie - zobaczysz, gdzie naprawdę idą wspólne pieniądze
planować mądrzej - na podstawie wcześniejszych wydatków łatwiej zaplanujesz budżet na podobny wyjazd czy imprezę
mieć wszystko jasne - każdy w grupie widzi, ile poszło na którą kategorię

Zacznij już dziś

Kategorie są dostępne w najnowszej wersji Kittysplit. Po prostu dodaj albo edytuj wydatek, a zobaczysz opcję wyboru kategorii. Tylko tyle!

Jak zawsze chętnie poznamy twoją opinię i pomysły na kolejne ulepszenia.

Miłego dzielenia wydatków! 🐱✨

Masz pomysł, jak kategorie mogłyby lepiej pasować do tego, jak z nich korzystasz? Odezwij się na X, Bluesky, Instagramie albo napisz maila na info[at]kittysplit.com

Nowe podsumowanie i kocie awatary

Tue, 09 Dec 2025 00:00:00 +0000

Tuż przed świętami 2025 apki Kittysplit dostają aktualizację (v1.3). Skupiamy się w niej na dwóch rzeczach, które od dawna chcieliśmy poprawić:

Nowe podsumowanie, które pokazuje to, co ważne, zamiast zasypywać cię liczbami
Kocie awatary, dzięki którym wszystko wygląda przyjaźniej i weselej

Podsumowanie: przed i po

Podsumowanie to pierwsze, co widzisz po otwarciu Kitty. Przebudowaliśmy je tak, żeby szybko odpowiadało na najważniejsze pytania: ile kosztowało całe wydarzenie? Kto komu ile jest winien? Ogólnie staraliśmy się nadać wszystkiemu więcej struktury dzięki kartom z Material Design. Miejscami wyszliśmy z tym nawet poza samo podsumowanie.


Podsumowanie Kitty - przed	Podsumowanie Kitty - po


Podsumowanie Kitty - po (ciemny motyw)	Zarządzaj uczestnikami - po (ciemny motyw)

Kocie awatary dla każdej osoby

W każdym Kitty każda osoba dostaje teraz własnego, niepowtarzalnego kociego awatara. Tak, pasuje to do nazwy Kittysplit, ale są też praktyczne powody.

Obrazki pomagają ogarnąć informacje szybciej niż sam tekst. Dzięki kotom:

apka mniej przypomina arkusz kalkulacyjny
łatwiej rozpoznać osoby w większych grupach
od razu widać, kto za co zapłacił, kiedy przewijasz wydatki


Kocie awatary (przykład)

Co się nie zmieniło

Nie trzeba się rejestrować
Działa w przeglądarce, na iOS i na Androidzie
Sprytne liczenie długów
Większość funkcji za darmo

Pobierz aktualizację

Jeśli korzystasz z apki, aktualizacja przyjdzie przez App Store albo Google Play.

Daj nam znać, co o tym myślisz: pisz na info[at]kittysplit.com albo przez przycisk opinii w apce.

Kittysplit's RevenueCat Shipaton 2025 Story

Tue, 30 Sep 2025 00:00:00 +0000

We’re excited to share our story for the RevenueCat Shipaton 2025! As part of this fun hackathon, we finally took the leap and shipped our long-awaited Android and iOS apps for Kittysplit. The Shipaton challenged us to not just build something new, but to actually ship it and that’s exactly what we needed to push our mobile apps from “someday” to “today.” Below is the story we submitted for the hackathon, chronicling our journey from a simple side project born during a ski trip to launching our mobile apps.

Kittysplit: Easy splitting of group expenses

Inspiration

Kittysplit started as a side project born from a real problem we faced during a ski trip with friends years ago. We were struggling to split our expenses fairly and efficiently. Excel felt clunky and overcomplicated for what should be a simple task. When we couldn’t find an existing tool that was truly easy to use, we decided to build our own.

What began as a web-only solution has grown organically over the years. We’ve continuously improved the platform based on constant feedback from our users, who have been incredibly helpful in shaping what Kittysplit has become today. As our user base grew, one request kept coming up:

“When will you have mobile apps?”

We started working on the apps when we had time, but participating in this hackathon gave us the final push to finish and ship them to the app stores.

What it does

Kittysplit solves one problem really well: making group expense splitting effortless. Whether you’re on vacation with friends, sharing household costs with roommates, or organizing a group dinner, our app provides the simplest way to calculate who owes what to whom. No overcomplicated features, no confusing interfaces: just straightforward expense splitting that anyone can understand.

How we built it

The journey to mobile started with building an API to integrate with our existing web application. Our initial plan was ambitious: use Kotlin Multiplatform for shared business logic, networking, local storage, and calculations, and build two separate user interfaces: a Jetpack Compose UI for Android, and a native SwiftUI frontend for iOS.

Since we already had Android development experience, we began with the Android app and built the multiplatform part and the Compose UI for Android. We took great care to keep our client side business logic fully separate from the UI implementation by using ViewModels with StateFlow in Kotlin multiplatform. This allowed us to reuse all business logic for our iOS app. For the multiplatform payment system integration, we used RevenueCat - it turns out that Kittysplit and RevenueCat are a purrr-fect combination!

Then we started working on the SwiftUI client. Initially, it seemed quite straightforward and using our KMP ViewModels from SwiftUI code worked really well. However during the process, it turned out to be a lot more work than expected. We also realized that building our UI in Compose was much easier than in SwiftUI, and that Compose Multiplatform would save us significant development time and effort. This pivot allowed us to share not just the business logic, but also most of the UI code between platforms.

Challenges we ran into

Most of our challenges were product-focused rather than technical. The biggest question was how to translate the simple, intuitive flows that work well on the web into mobile app experiences. We spent considerable time ensuring that the mobile version maintained the same simplicity that makes our web app successful. Keeping the product simple sounds easy, but the big challenge is hiding the technical and mathematical complexity from the user and make it all work intuitively.

On the technical side, we took great care to keep our client side business logic separate from the UI implementation by using ViewModels in Kotlin multiplatform. The main challenge was realizing that building and maintaining a separate iOS frontend in SwiftUI besides our existing backend, web UI and the Android Compose app was too much work for us, as a small team of 3 people working part-time on this project. So we ditched our half finished SwiftUI app even though we already spent a lot of time on it. The switch to Compose Multiplatform was easier than expected and crucial to get the iOS app released soon after Android.

Accomplishments that we’re proud of

The user response has been incredibly encouraging. Already during the beta phase, we received a lot of positive feedback from users. Many of our existing web users are actively switching to the mobile apps, which validates that our concept translates well to mobile. And new users already say that after trying several established competitor’s apps, they are happy to have found the Kittysplit app.

What makes us most proud is that users immediately understand how to use the app. The simplicity and intuitive design we worked so hard to achieve on the web has successfully carried over to mobile. Users can start splitting expenses within seconds of opening the app.

What we learned

The technical transition from Android Compose to Compose Multiplatform turned out to be surprisingly smooth. We learned a lot about both technologies throughout the process.

Perhaps the most interesting learning curve was diving into the iOS ecosystem for the first time. We spent considerable time learning Swift and SwiftUI, only to eventually abandon that code when we switched to Compose Multiplatform. While it felt like wasted effort initially, understanding iOS development principles helped us make better decisions for the multiplatform approach.

We also learned the intricacies of iOS app publishing which was a completely new world for us as primarily Android developers.

What’s next for Kittysplit

Our immediate focus is on App Store Optimization to grow our mobile user base.

We’re committed to continuing our user feedback driven development approach. Our feature roadmap includes several highly requested additions:

Expense attachments (receipts, photos)
Expense categories for better organization
Push notifications to keep everyone updated
And much more!

The goal remains the same: keep Kittysplit the easiest way to split group expenses, whether you’re using our web app or mobile apps.

Collecting Reviews in a Compose Multiplatform App

Fri, 26 Sep 2025 00:00:00 +0000

Shipping a great app is only half the battle, earning high quality reviews is just as crucial for App Store Optimization (ASO). Ratings and reviews shape first impressions, drive conversion, and influence store ranking. For a product like Kittysplit, where trust and simplicity are everything, timely and authentic user feedback helps future users decide to install, and helps us steer the roadmap.

But asking for reviews is a delicate craft. Prompt too early and you interrupt the flow, prompt too often and you annoy users, prompt at the wrong moment and you get low‑quality or frustrated feedback. In this post, we’ll share how we integrated Google Play’s ReviewManager and Apple’s SKStoreReviewController into our Compose Multiplatform app, and how we built a cross‑platform strategy to decide when to ask. We’ll cover the technical glue, the platform nuances, and the heuristics we use to surface the prompt at moments when users are most likely to feel satisfied, not interrupted.

Implementation

We’ll start with the implementation. We define a shared ReviewService API in common code and provide platform-specific implementations that wrap Android’s ReviewManager and iOS’s SKStoreReviewController. Using Kotlin Mutliplatform’s expect/actual mechanism in combination with Koin, we’re providing the correct implementation for each platform. This keeps the call site in our Compose Multiplatform UI identical across platforms, while letting each target handle its own prompt presentation in a native, compliant way.

We’re using a freshly created Compose Multiplatform project as the base for this post. You can find a little more detailed description of how to create a new CMP project in our previous blog post here. You can find all the code on GitHub.

At first, we need to add a few dependencies to our libs.versions.toml. If you don’t know what that is, you can read up on it here. It’s a relatively new way of managing dependencies in gradle.

[versions]
# ... other verions

android-play-review = "2.0.2"
koin = "4.1.1"
kotlinx-coroutines = "1.10.2"

[libraries]
# ... other libraries

android-play-review = { module = "com.google.android.play:review", version.ref = "android-play-review" }
android-play-review-ktx = { module = "com.google.android.play:review-ktx", version.ref = "android-play-review" }
koin-compose = { module = "io.insert-koin:koin-compose", version.ref = "koin" }
koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" }
kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "kotlinx-coroutines" }
kotlinx-coroutines-play-services = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-play-services", version.ref = "kotlinx-coroutines" }

./gradle/libs.versions.toml

Next, we’re going to declare these dependencies in our compose app’s build.gradle.kts:

kotlin {
    // ... other settings

    sourceSets {
        androidMain.dependencies {
            // ... other android dependencies

            implementation(libs.android.play.review)
            implementation(libs.android.play.review.ktx)
            implementation(libs.kotlinx.coroutines.play.services)
        }
        commonMain.dependencies {
            // ... other common dependencies

            implementation(libs.koin.core)
            implementation(libs.koin.compose)
            implementation(libs.kotlinx.coroutines.core)
        }
    }
}

./composeApp/build.gradle.kts

Now we need to define an interface in commonMain that we’ll implement later in androidMain and iosMain respectively:

interface ActivityContainer

data object EmptyActivityContainer : ActivityContainer

sealed class ReviewResult() {
    data object Requested : ReviewResult()
    data object Failed : ReviewResult()
    data class RequestError(val code: Int) : ReviewResult()
}

interface ReviewService {
    suspend fun requestInAppReview(
        activityContainer: ActivityContainer = EmptyActivityContainer
    ): ReviewResult
}

./composeApp/src/commonMain/kotlin/com/kittysplit/reviewservicecmp/ReviewService.kt

Because Apple’s SKStoreReviewController and Google Play’s ReviewManager don’t expose whether a dialog was actually shown or acted upon, our API only reports Requested or an error. This keeps our contract honest and portable across both stores’ opaque review flows. Don’t mind the ActivityContainer interface and EmptyActivityContainer object, we’re going to explain that soon.

Android

Let’s look at the implementation for Android:

import android.app.Activity
import android.content.Context
import com.google.android.play.core.review.ReviewException
import com.google.android.play.core.review.ReviewManagerFactory
import kotlinx.coroutines.tasks.await

data class AndroidContextHolder(val activity: Activity) : ActivityContainer

fun ActivityContainer.activity(): Activity? = (this as? AndroidContextHolder)?.activity

class AndroidReviewService(val context: Context) : ReviewService {
    private val reviewManager = ReviewManagerFactory.create(context)

    override suspend fun requestInAppReview(activityContainer: ActivityContainer): ReviewResult = try {
        val activity = activityContainer.activity()
        if (activity != null) {
            val reviewInfo = reviewManager.requestReviewFlow().await()
            reviewManager.launchReviewFlow(activity, reviewInfo).await()
            ReviewResult.Requested
        } else {
            ReviewResult.Failed
        }
    } catch (error: Exception) {
        if (error is ReviewException) {
            ReviewResult.RequestError(error.errorCode)
        } else {
            ReviewResult.Failed
        }
    }
}

./composeApp/src/androidMain/kotlin/com/kittysplit/reviewservicecmp/AndroidReviewService.kt

We implemented the Android side of ReviewService using Play Core’s in‑app review flow. AndroidReviewService creates a ReviewManager, requests a ReviewInfo using requestReviewFlow().await(), and then launches the prompt with reviewManager.launchReviewFlow(...).await(). Because launchReviewFlow requires an Activity, not a generic Context, we created a small container object to be able to hand over the Activity in the Android implementation. For iOS, we’re going to use the EmptyActivityContainer, since we don’t need to pass anything there.

If something goes wrong on Android, the ReviewManager might throw a ReviewException. In case we encounter it, we’re extracting the errorCode and return it as ReviewResult.RequestError. This allows you to handle these errors separately from the generic ReviewResult.Failed. For possible values of the errorCode see the documentation here.

iOS

Next, we’re going to implement the AppleReviewService in iosMain:

import platform.StoreKit.SKStoreReviewController
import platform.UIKit.UIApplication
import platform.UIKit.UISceneActivationStateForegroundActive
import platform.UIKit.UIWindowScene

class AppleReviewService : ReviewService {
    override suspend fun requestInAppReview(activityContainer: ActivityContainer): ReviewResult = try {
        val scene = UIApplication.sharedApplication.connectedScenes
            .filterIsInstance<UIWindowScene>()
            .firstOrNull { it.activationState == UISceneActivationStateForegroundActive }

        if (scene != null) {
            SKStoreReviewController.requestReviewInScene(scene)
        } else {
            SKStoreReviewController.requestReview()
        }
        ReviewResult.Requested
    } catch (_: Exception) {
        ReviewResult.Failed
    }
}

./composeApp/src/iosMain/kotlin/com/kittysplit/reviewservicecmp/AppleReviewService.kt

We implemented the iOS side with StoreKit’s in‑app review API. AppleReviewService looks up the currently active UIWindowScene by scanning UIApplication.sharedApplication.connectedScenes and picking the one in UISceneActivationStateForegroundActive state. If an active scene exists, we call SKStoreReviewController.requestReviewInScene(scene). Otherwise we fall back to SKStoreReviewController.requestReview(). Both calls are “fire‑and‑forget” (no success callback), so we return ReviewResult.Requested after invoking them. Any exception during lookup or invocation maps to ReviewResult.Failed. This approach ensures the prompt is tied to the foreground scene in multi‑window setups while remaining compatible with older, scene‑agnostic code paths.

Koin

That’s it. All we need to do now is wire it all together to be able to use it in our common app code. We’re going to use Koin for that, but you can go with any other DI framework.

import org.koin.core.module.Module

expect fun reviewModule(): Module

./composeApp/src/commonMain/kotlin/com/kittysplit/reviewservicecmp/ReviewModule.kt

import org.koin.core.module.Module
import org.koin.core.module.dsl.singleOf
import org.koin.dsl.module

actual fun reviewModule(): Module = module {
    singleOf(::AndroidReviewService)
}

./composeApp/src/androidMain/kotlin/com/kittysplit/reviewservicecmp/ReviewModule.android.kt

import org.koin.core.module.Module
import org.koin.core.module.dsl.singleOf
import org.koin.dsl.module

actual fun reviewModule(): Module = module {
    singleOf(::AppleReviewService)
}

./composeApp/src/iosMain/kotlin/com/kittysplit/reviewservicecmp/ReviewModule.ios.kt

We’re not going in detail here, but it should be straight forward. We’re defining a reviewModule() as an expect function and provide the platform-specific implementations in the actual counterparts.

With both implementations in place, you can inject ReviewService into any ViewModel and trigger review requests at the right moments in your user flows. Pick thoughtful triggers, wire them to requestInAppReview, and you’re ready to ask for reviews without disrupting your users.

Review triggers

We gate review prompts behind lightweight heuristics so they appear at moments of success, not interruption. We track when the app was first opened, total opens, when we last requested a review, and how many expenses a user has added. We use two trigger events: when a user adds an expense and when they settle up. We prioritized the settle-up event because it aligns with a clear success moment. Our heuristics are:

Last review request ≥ x days ago
First app open ≥ x days ago
App opened ≥ x times
Current Kitty has ≥ x expenses

We apply these on both platforms, but we’re more conservative on iOS, prompting less frequently and only after stronger engagement because the app is only three weeks old, and because Apple only displays the review prompt maximum 3 times a year.

Collecting reviews is both a technical integration and a product judgment call. With a shared ReviewService and platform-native implementations for Android’s ReviewManager and iOS’s SKStoreReviewController, you now have a clean way to prompt your users for reviews from your common code. Pair that with thoughtful heuristics that favor genuine success moments, and you’ll nudge happy users to share feedback without breaking their flow, ultimately improving ASO, conversion, and the product itself.

If you try this approach in your own Compose Multiplatform app, we’d love to hear what heuristics work best for you. Feels free to contact us on social networks (X, Bluesky, Instagram) or write an email.

Firebase Analytics in Compose Multiplatform without Cocoapods

Tue, 23 Sep 2025 00:00:00 +0000

At Kittysplit, we’ve always aimed to make splitting group expenses as effortless as possible. For years, Kittysplit was a web first product. As our users took Kittysplit on trips, into shared apartments, and to events, it became clear that we needed mobile apps on both Android and iOS.

In this post, we’ll provide a hands-on guide how we wired Firebase Analytics into our Compose Multiplatform app on both Android and iOS without using Cocoapods (which is going to retire soon).

From SwiftUI to Compose Multiplatform

We embraced Kotlin Multiplatform to share business logic across platforms, initially pairing it with a native Android app and a SwiftUI app for iOS, each with its own Firebase Analytics integration.

But when we decided to fully commit to Compose Multiplatform and retire our SwiftUI app, we hit a wall: there’s no out of the box way to use Firebase Analytics in a Compose Multiplatform project. Also, Cocoapods is going to retire soon. Instead, we’ll use the Swift Package Manager dependencies directly with the wonderful spm4Kmp plugin made by François. We’re also going to use Koin to wire it all together.

Project setup

We’re going to add Firebase Analytics to a newly created Compose Multiplatform project, which we’re creating using the new project wizard in Android Studio. If you want to follow along, you can either check out the project code from GitHub or create a new project yourself.

To create a new CMP project in Android Studio, make sure you have the Kotlin Multiplatform plugin installed. You can then click File -> New -> New Project.... Under “Phone and Tablet” select “Kotlin Multiplatform”, enter a name and package for your app and click “Next”. On the next screen, make sure you have the Android and iOS boxes ticked and select “Share UI” as UI implementation. Click “Finish” to create the new project.

Dependencies

Our first step is to add the needed dependencies. To do this, we’re going to use the gradle version catalog. Locate the libs.versions.toml file and add the following lines:

[versions]
# ... other dependencies

koin = "4.1.1"
spm4kmp = "1.0.0-Beta04"
firebase-analytics = "22.5.0"
google-services = "4.4.3"

# spm
spm-firebase = "12.0.0"

[libraries]
# ... other libraries

koin-compose = { module = "io.insert-koin:koin-compose", version.ref = "koin" }
koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" }
firebase-analytics-ktx = { module = "com.google.firebase:firebase-analytics-ktx", version.ref = "firebase-analytics" }

[plugins]
# ... other plugins

spm4kmp = { id = "io.github.frankois944.spmForKmp", version.ref = "spm4kmp"}
google-services = { id = "com.google.gms.google-services", version.ref = "google-services" }

./gradle/libs.versions.toml

You can now sync your project with the gradle files to pull in the dependencies. With this out of the way, we’re going to declare the dependencies in our build.gradle.kts files. We’ll start with the root build.gradle.kts file. Add this line:

plugins {
    // other plugins

    alias(libs.plugins.spm4kmp) apply false
    alias(libs.plugins.google.services) apply false
}

./build.gradle.kts

This just tells gradle to resolve the plugin, but not apply it. This is useful if you have a multi-module gradle project and only want to apply the plugin in a single submodule.

Now we’re going to set up the gradle.build.kts of our composeApp:

plugins {
    // other plugins

    alias(libs.plugins.spm4kmp)
    alias(libs.plugins.google.services)
}


kotlin {
    // ...

    listOf(
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "ComposeApp"
            binaryOption("bundleId", "com.kittysplit.firebase_analytics_cmp")
            isStatic = true
        }
        // This is the important part:
        iosTarget.compilations {
            val main by getting {
                cinterops.create("nativeIosShared")
            }
        }
    }

    sourceSets {
        named { it.lowercase().startsWith("ios") }.configureEach {
            languageSettings {
                optIn("kotlinx.cinterop.ExperimentalForeignApi")
            }
        }

        androidMain.dependencies {
            // ...
            implementation(libs.firebase.analytics.ktx)
        }

        commonMain.dependencies {
            // ...

            api(libs.koin.compose)
            api(libs.koin.core)
        }
    }

    swiftPackageConfig {
        create("nativeIosShared") {
            minIos = "16.0"
            dependency {
                remotePackageVersion(
                    url = uri("https://github.com/firebase/firebase-ios-sdk.git"),
                    products = {
                        add("FirebaseAnalytics", exportToKotlin = true)
                        add("FirebaseCore", exportToKotlin = true)
                    },
                    packageName = "firebase-ios-sdk",
                    version = libs.versions.spm.firebase.get(),
                )
            }
        }
    }
}

./composeApp/build.gradle.kts

That’s all dependency juggling. We added koin as “regular” multiplatform dependency of commonMain. For the Android implementation of Firebase Analytics, we added the Android library to androidMain. To be able to use the iOS Firebase Analytics in our iosMain implementation, we used spm4Kmp to declare the dependency. Notice the exportToKotlin = true, this tells spm4Kmp to export the dependency to kotlin, which means we can use it directly in iosMain code.

When you sync the project again, you’ll notice a new folder: ./composeApp/exportedNativeIosShared. This is the generated swift package which we’re going to add as a dependency to the iOS app next. Open XCode and navigate to the project dependencies:

XCode: iosApp -> PROJECT (iosApp) -> Package Dependencies

Click on the little “+” sign and then on “Add Local…”. Now select the aforementioned folder and click “Add package”. Once done, you’ll see all dependencies of Firebase Analytics and Firebase itself in your package dependencies on the lower left of your XCode window.

Firebase setup

To function properly, you need to register your Android and iOS Apps with Firebase. We’re not going to explain this in detail in this blogpost. Essentially, you need to provide a GoogleService-Info.plist file on iOS and a google-services.json file on Android. You can find an in depth guide for Android here. The guide for iOS is located here. Please note that you only need to follow the steps to obtain the aforementioned files, all other parts are covered in this blog post.

Implementation

This completes the boring part. We’re going to look at the implementation next. Our goal is to create a simple interface that allows us to track events to Firebase Analytics from view models, but also from Composables.

We’re starting by creating a simple interface inside commonMain, which we’re going to implement in androidMain and iosMain:

package com.kittysplit.firebase_analytics_cmp.analytics

interface Analytics {
    fun init()
    fun logEvent(name: String, params: Map<String, Any>?)
}

./composeApp/src/commonMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/Analytics.kt

For the Android implementation, we’re going to use the kotlin Firebase SDK in androidMain:

package com.kittysplit.firebase_analytics_cmp.analytics

import androidx.core.os.bundleOf
import com.google.firebase.analytics.FirebaseAnalytics
import com.google.firebase.analytics.ktx.analytics
import com.google.firebase.ktx.Firebase

class AndroidAnalytics : Analytics {
    private lateinit var firebaseAnalytics: FirebaseAnalytics

    override fun init() {
        firebaseAnalytics = Firebase.analytics
    }

    override fun logEvent(
        name: String,
        params: Map<String, Any>?
    ) {
        val args = params
            ?.map { it.key to it.value }
            ?.toTypedArray()
            ?.let { bundleOf(*it) }

        firebaseAnalytics.logEvent(name, args)
    }
}

./composeApp/src/androidMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/AndroidAnalytics.kt

As you can see, the implementation is straight forward. All we have to do is to convert our parameter map to a Bundle, which is often used in Android to pass data around.

On to the iOS implementation. We’re going to use the native iOS Firebase Analytics SDK in iosMain:

package com.kittysplit.firebase_analytics_cmp.analytics

import FirebaseAnalytics.FIRAnalytics
import FirebaseCore.FIRApp

class AppleAnalytics : Analytics {

    private val firAnalytics: FIRAnalytics.Companion = FIRAnalytics

    override fun init() {
        FIRApp.configure()
    }

    override fun logEvent(
        name: String,
        params: Map<String, String>?
    ) {
        firAnalytics.logEventWithName(name, params as Map<Any?, *>?)
    }
}

./composeApp/src/iosMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/AppleAnalytics.kt

Dependency injection

All that is left to do now is to wire it all up using koin. We’ll have to create a module that provides our AppleAnalytics if we’re running on iOS and the AndroidAnalytics implementation if we’re running on Android. That’s where kotlin’s easy to use [expect/actual declarations] https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-expect-actual.html come in.

In commonMain, we’re only declaring our module as an expect function, which is comparable to an interface where the implementation are provided per platform:

package com.kittysplit.firebase_analytics_cmp.analytics

import org.koin.core.module.Module

expect fun analyticsModule(): Module

./composeApp/src/commonMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/AnalyticsModule.kt

Next, we’re providing the implementations for Android:

package com.kittysplit.firebase_analytics_cmp.analytics

import org.koin.core.module.Module
import org.koin.dsl.module

actual fun analyticsModule(): Module = module {
    single<Analytics> {
        val analytics = AndroidAnalytics()
        analytics.init()
        analytics
    }
}

./composeApp/src/androidMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/AnalyticsModule.android.kt

And iOS:

package com.kittysplit.firebase_analytics_cmp.analytics

import org.koin.core.module.Module
import org.koin.dsl.module


actual fun analyticsModule(): Module = module {
    single<Analytics> {
        val analytics = AppleAnalytics()
        analytics.init()
        analytics
    }
}

./composeApp/src/iosMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/AnalyticsModule.ios.kt

It’s important to call init on our implementations, to make sure they’re ready to go when they’re injected. Now we have to make sure that koin knows about the module we’ve just created. We’re going to do that by starting koin when our application starts. On Android, we can easily do that in the MainActivity:

package com.kittysplit.firebase_analytics_cmp

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.activity.enableEdgeToEdge
import androidx.compose.runtime.Composable
import androidx.compose.ui.tooling.preview.Preview
import com.kittysplit.firebase_analytics_cmp.analytics.analyticsModule
import org.koin.compose.KoinApplication

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        enableEdgeToEdge()
        super.onCreate(savedInstanceState)

        setContent {
            KoinApplication(application = {
                modules(analyticsModule())
            }) {
                App()
            }
        }
    }
}

./composeApp/src/androidMain/kotlin/com/kittysplit/firebase_analytics_cmp/MainActivity.kt

To make it work on iOS, we need to start the koin application in the MainViewController:

package com.kittysplit.firebase_analytics_cmp

import androidx.compose.ui.window.ComposeUIViewController
import com.kittysplit.firebase_analytics_cmp.analytics.analyticsModule
import org.koin.compose.KoinApplication

fun MainViewController() = ComposeUIViewController {
    KoinApplication(application = {
        modules(analyticsModule())
    }) { App() }
}

./composeApp/src/iosMain/kotlin/com/kittysplit/firebase_analytics_cmp/MainViewController.kt

Now we’re ready to inject our analytics implementation anywhere we need it. To test it, we’re going to use it to track the tap on the “Click me!” button from the example:

package com.kittysplit.firebase_analytics_cmp

// ... imports
import com.kittysplit.firebase_analytics_cmp.analytics.Analytics
import org.koin.compose.koinInject

@Composable
fun App(analytics: Analytics = koinInject()) {
    MaterialTheme {
        var showContent by remember { mutableStateOf(false) }
        Column(
            modifier = Modifier
                .background(MaterialTheme.colorScheme.primaryContainer)
                .safeContentPadding()
                .fillMaxSize(),
            horizontalAlignment = Alignment.CenterHorizontally,
        ) {
            Button(onClick = {
                analytics.logEvent("button_clicked", null)
                showContent = !showContent
            }) {
                Text("Click me!")
            }
            AnimatedVisibility(showContent) {
                val greeting = remember { Greeting().greet() }
                Column(
                    modifier = Modifier.fillMaxWidth(),
                    horizontalAlignment = Alignment.CenterHorizontally,
                ) {
                    Image(painterResource(Res.drawable.compose_multiplatform), null)
                    Text("Compose: $greeting")
                }
            }
        }
    }
}

./composeApp/src/commonMain/kotlin/com/kittysplit/firebase_analytics_cmp/App.kt

That’s it! You’re now ready to track events from anywhere in your Android Compose app. There’s one little thing we need to fix. You might have noticed that your preview is not showing any longer. That’s because koin is not initialized. Luckily, there’s a fix for that: we’re going to provide a fake instance of our Analytics for previews:

package com.kittysplit.firebase_analytics_cmp.analytics

import org.koin.dsl.module

fun noopAnalyticsModule() = module {
    single<Analytics> {
        object : Analytics {
            override fun init() {}

            override fun logEvent(name: String, params: Map<String, String>?) {}
        }
    }
}

./composeApp/src/commonMain/kotlin/com/kittysplit/firebase_analytics_cmp/analytics/NoopAnalyticsModule.kt

Now all we have to do is wrap our previews with a little helper:

@Preview
@Composable
fun AppPreview() {
    KoinApplicationPreview(application = { modules(noopAnalyticsModule()) }) {
        App()
    }
}

Now you should see the preview again.

We hope this little guide helps you in your multiplatform endeavours. We had a lot of fun implementing the Kittysplit apps in Compose Multiplatform.

Building Kittysplit's Mobile Apps in Compose Multiplatform

Thu, 18 Sep 2025 00:00:00 +0000

After 13 years as a web only application, Kittysplit has finally made the leap to mobile. We initially planned to build separate Android and iOS apps using Kotlin Multiplatform for shared business logic, but Compose Multiplatform’s recent stability changed everything. Here’s how we went from web only to native mobile apps.

From Web only to Mobile: A 13 Year Journey

Kittysplit started as a web application back in 2012. For over a decade, we maintained it exclusively as a webapp. The web platform allowed us to provide universal accessibility. Anyone could create or join a Kitty simply by opening a link in their browser, regardless of their device type. This cross platform compatibility is crucial for group expense sharing, where participants often use different devices and operating systems.

Growing Demand for Native Apps

However, user requests for dedicated mobile apps grew year after year. We felt that we needed to address this demand, so we looked at the available options for the implementation. We evaluated React Native, Flutter, Kotlin Multiplatform, and Compose Multiplatform to determine the best approach for our small development team.

Because we already had experience with Android development, we chose Kotlin Multiplatform as our foundation. Our initial plan was straightforward: develop the Android app first using Android Compose, while implementing all business logic in a shared module in Kotlin Multiplatform. This would allow us to share the core functionality across platforms: networking, business logic, calculations and local storage. We planned to build the iOS app using SwiftUI after completing the Android app, leveraging the already written shared business logic.

The Power of Kotlin Multiplatform

Kotlin Multiplatform proved to be an excellent choice for our architecture. We implemented all networking, local storage, and client-side calculations in the shared multiplatform code. Additionally, we moved all our ViewModels into the shared codebase, ensuring consistent business logic and state management across both platforms.

The implementation was straightforward: Kotlin provided almost everything we needed out of the box. For local data storage, we used SQLDelight, which allowed us to write type-safe SQL queries. We integrated the RevenueCat Purchases multiplatform SDK for handling Super Kitty upgrades. To enhance the Swift interoperability for our planned iOS development, we used SKIE from TouchLab. For dependency injection, we chose Koin, which worked seamlessly across our multiplatform setup. This foundation gave us confidence that we could maintain a single source of truth for our core functionality while building native experiences on each platform.

Compose Multiplatform Goes Stable

As it’s often the case in software development, the SwiftUI frontend turned out to be more work than we initially anticipated 🙈. We had been following Compose Multiplatform’s development for some time. Given the challenges we were facing with SwiftUI, we decided to experiment with it for a few days. Compose Multiplatform for iOS had recently reached stable status in May 2025.

We managed to migrate our app to Compose Multiplatform within just a few days, which was much faster than we expected. The resulting app ran smoothly on our iOS devices and felt really well.

This led us to ditch the native SwiftUI frontend entirely and go with Compose Multiplatform instead. It would save us months of work, both now and in the future. With only one codebase to maintain, we can spend our time improving the app and adding new features rather than implementing everything twice.

Kittysplit on iOS

The Migration Process: From Android Compose to Compose Multiplatform

The actual migration process was surprisingly straightforward. We started by importing the new Compose Multiplatform dependencies and migrating to multiplatform resources, which was mostly just copying a few files to the new structure. The main code changes involved removing usages of the Android Context throughout our codebase.

Fortunately, we had already been using multiplatform libraries from Sentry and RevenueCat, so those integrations continued to work without any changes. For Firebase Analytics, we used the expect/actual mechanism to provide platform-specific implementations. We also needed to make our deep links work on both platforms, but the patterns were similar enough that it didn’t require major restructuring.

Most of our existing Compose UI code worked with minimal adjustments, and the shared ViewModels we had already implemented in Kotlin Multiplatform integrated seamlessly. Within just a few days, we had a fully functional iOS app that felt genuinely good.

Looking Forward

We’re excited about the future of Kittysplit’s mobile apps with this technology stack. Kotlin Multiplatform and Compose Multiplatform have given us the perfect balance of development efficiency and native performance. With a single codebase to maintain, we can focus on what matters most: building features that make splitting expenses even easier for our users. We’re already working on several improvements and new features that would have taken us much longer to implement across separate platforms. The mobile app journey has finally found its ideal technical foundation, and we couldn’t be more excited about where it’s headed.

Kittysplit w telefonie: poznaj nasze apki na Androida i iOS

Wed, 10 Sep 2025 00:00:00 +0000

Po ponad dziesięciu latach działania wyłącznie w przeglądarce Kittysplit wreszcie ma natywne apki mobilne na Androida i iOS! Od startu w 2012 roku pomagamy znajomym, współlokatorom i ekipom wyjazdowym dzielić wydatki uczciwie i bez zawracania głowy, do tej pory przez naszą aplikację webową.

Dlaczego apki? I czemu akurat teraz?

Od zawsze chcieliśmy, żeby dzielenie wydatków było jak najbardziej dostępne. Przez lata nasza aplikacja webowa dobrze się sprawdzała: każdy, kto ma przeglądarkę, mógł bez problemu ogarniać wspólne wydatki w grupie. Ale słuchaliśmy, co do nas piszecie, i wiemy, że wielu z was po prostu woli wygodę osobnej apki w telefonie.

Szybki dostęp: do wspólnych wydatków bez otwierania przeglądarki
Płynniejsze działanie: wszystko dopasowane specjalnie do telefonów

Wciąż ten sam Kittysplit, który lubisz

Bardzo się cieszymy z apek, ale spokojnie: Kittysplit działa tak samo jak wcześniej. Dalej stawiamy na:

Prostotę: żadnych skomplikowanych funkcji, których nie potrzebujesz.
Brak rejestracji: tworzysz Kitty bez zakładania konta.
Uczciwy podział: kilka sposobów, żeby sprawiedliwie podzielić wydatki.
Darmowe podstawy: najważniejsze funkcje nadal są za darmo.
Apka nie jest obowiązkowa: apki mają po prostu ułatwić życie w telefonie, a Kittysplit w przeglądarce zostaje z nami.

Przeglądarka zostaje

Lubimy, kiedy macie wybór. Choć bardzo się cieszymy, że wreszcie możemy wam dać apki, chcemy to powiedzieć wyraźnie: wersji webowej nigdzie nie porzucamy. Rozumiemy, że nie każdy chce instalować kolejną apkę, a dla wielu z was wygoda przeglądarki jest po prostu nie do przecenienia.

Wersja webowa Kittysplit dalej będzie dostawać tyle samo uwagi, aktualizacji i nowych funkcji co apki.

Pobierz już dziś!

Nasze nowe apki są już dostępne w App Store i w Google Play. Niezależnie od tego, czy korzystasz z Kittysplit od lat, czy dopiero nas poznajesz, zajrzyj do apki, a jeśli wolisz, dalej korzystaj z wersji w przeglądarce.

Albo korzystaj dalej z naszej aplikacji webowej na kittysplit.com

Co dalej?

Premiera apek to dopiero początek. Już pracujemy nad poprawkami i nowymi funkcjami, które biorą się z waszych opinii.

Chętnie usłyszymy, co myślicie o nowych apkach i co jeszcze moglibyśmy ulepszyć! Jak zawsze chcemy, żeby dzielenie wydatków było jak najprostsze i bez stresu, a teraz na jeszcze większej liczbie urządzeń.

Adsense jest zepsuty

Thu, 28 Mar 2024 00:00:00 +0000

Już kilka lat temu mieliśmy kłopoty z oszukańczymi reklamami w Adsense. Tak oczywiste oszustwa jak fałszywe ostrzeżenie o wirusie z 2018 roku chyba zniknęły, ale pojawiły się inne oszukańcze reklamy.

W zeszłym roku napisała do nas osoba, która chciała anulować swoją subskrypcję, tyle że Kittysplit nie ma żadnych subskrypcji. Szybko się zorientowaliśmy, że ta osoba padła ofiarą oszukańczej reklamy, która wyświetliła się jej podczas korzystania z Kittysplit na telefonie.

Jak to oszustwo działało

Schemat jest prosty: reklama pokazuje ogromny zielony przycisk START i udaje, że jest częścią Kittysplit. Ale przycisk prowadzi na zewnętrzną stronę, która prosi o dane karty kredytowej. Strona udaje, że opłata dotyczy jakiejś usługi Kittysplit (np. rozliczenia ze znajomymi albo korzystania ze strony). Na początku jest za darmo albo prawie za darmo, ale potem zaczyna pobierać miesięczną subskrypcję, od 20 do 60 €/$/£, za usługę, której nikt nie chciał.

Oto zrzut ekranu takiej zwodniczej reklamy:

Kiedy dowiedzieliśmy się o problemie, szybko zareagowaliśmy i zaczęliśmy blokować takie reklamy w centrum weryfikacji reklam Adsense. Przez jakiś czas wyglądało na to, że to pomogło, ale reklamy wracały w różnych wariantach, zawsze z dużym, jaskrawym przyciskiem START, CONTINUE, NEXT, DOWNLOAD albo podobnym.

Kilka miesięcy temu odezwała się kolejna osoba, którą też oszukały te reklamy. Znowu blokowaliśmy wprowadzające w błąd reklamy, raz za razem. Spędziliśmy wiele godzin na blokowaniu tysięcy reklam i setek kont reklamodawców, licząc, że to rozwiąże problem. Ale to się po prostu nie kończyło: nieważne, ile razy blokowaliśmy te reklamy, po kilku dniach wracały.

Dlaczego postanowiliśmy wyłączyć reklamy, żeby chronić osoby korzystające z Kittysplit

Okazuje się, że nie da się wyłapać wszystkich złych reklam, a niedawno oszukano trzecią osobę. Uznaliśmy więc, że tego już za wiele, i w zeszłym miesiącu wyłączyliśmy wszystkie reklamy. Kittysplit jest więc teraz wolny od reklam (hurra!), dopóki nie znajdziemy innego rozwiązania reklamowego albo Adsense nie naprawi problemu. Wiemy, że i tak nikt nie lubi reklam, ale to dzięki przychodom z reklam darmowe Kitty mogą dla ciebie zostać darmowe.

Tracimy przez to pieniądze z reklam, ale dla nas ważniejsze jest, żeby chronić ludzi przed oszustwami nieuczciwych reklamodawców.

Ale dlaczego to wciąż się dzieje?

Prawdziwe pytanie brzmi: dlaczego Adsense wciąż pozwala tym reklamom wracać? Wyraźnie łamią zasady Adsense (Misrepresentation - Misleading ad design): reklamy, przy których trudno zorientować się, że to reklama, są niedozwolone.

Dlaczego więc Adsense wciąż je wyświetla? Takie reklamy powinno być dość łatwo wykryć i zablokować. No weźcie, mamy 2024 rok, jesteście Google, macie AI i w ogóle. To, że każdy właściciel strony spędza niezliczone godziny na blokowaniu każdej reklamy z osobna za każdym razem, gdy po dniu czy dwóch wraca, to oczywiście żadne rozwiązanie. Google i Adsense muszą to załatwić po swojej stronie!

Google twierdzi, że do blokowania reklam używa uczenia maszynowego i AI. Ale nawet najbardziej prymitywna AI w 2024 roku powinna bez trudu rozpoznać wielki, tłusty zielony przycisk z napisem „CONTINUE”. A reklamy dalej wracają.

Co jest nie tak, Adsense?