SKIP vs CMP: How We Chose the Right Tech for Our App

When I founded a company, I thought going fully native was the “safe” choice. After all, native has always been reliable and battle-tested. But as development progressed, I realized just how much time we were losing by sticking only to native solutions.

In fact, in over 60% of projects I’ve worked on, teams underestimate how cross-platform technologies can save months of development while still delivering great performance. That completely changed how I approach technology decisions for mobile apps today.

In this blog, I’ll tell you more about a situation with the client’s event app, when we were thinking between Compose Multiplatform vs Skip. We decided to go with CMP mainly because we had more Kotlin developers available at that moment, but while investigating both technologies, I learned a lot about when each makes sense.

A quick look at Compose Multiplatform (CMP)

When I first started looking into CMP, I realized it’s basically Jetpack Compose for the whole app: iOS, Android, and even desktop. The idea is simple: write UI in Kotlin once and share it across platforms.

For someone like me, who’s spent years on native iOS, it was a bit of a “wait, we can do this?” moment.

The benefits are obvious. You can reuse a lot of code, which saves time and reduces the headache of maintaining two separate apps. If your team already knows Kotlin, it’s a huge plus and there’s almost no setup. Regarding performance, CMP apps feel very close to native, which matters for apps with complex features or heavy users. And because it’s designed for multiple platforms, scaling your app later is much easier.

Some apps are already using CMP in production. For example, Klarna’s internal apps and some JetBrains tooling prototypes rely on it. It’s still growing, but it’s getting real adoption.

I also compared CMP with other options while evaluating this project.

Kotlin Multiplatform vs Compose Multiplatform: KMP is great for sharing business logic, but CMP goes further by letting you handle the UI too.

Flutter vs CMP: Flutter, on the other hand, is really fast for building apps, but it uses Dart, and the UI can sometimes feel a bit different from native.

For our team, CMP felt like the best compromise: cross-platform power, Kotlin knowledge, and a near-native experience.

What about Skip?

Then there’s Skip. When I first heard about it, I thought: “This looks perfect for iOS teams.” And it really is. Skip lets you build iOS apps faster by simplifying some of the usual boilerplate and letting you share components across projects. The catch is, it’s mostly iOS-focused, so if you need Android later, you’ll need a different approach.

Skip isn’t brand new, but it’s younger than CMP. The community is smaller, so finding answers online can be trickier. That said, I’ve seen some smaller startups and internal apps using it to prototype quickly and launch iOS-first apps. For teams that live in Swift and want to move fast, it can be a great choice.

Our internal debate

When we got the client’s event app project, the question was which tool makes the most sense, Compose Multiplatform or Skip?

We had a couple of Kotlin devs already free to jump in, so CMP looked like the easier call. But I didn’t want to just rush into it. We also looked into Skip because, honestly, it sounded really cool writing SwiftUI and getting Android for “free.” On paper, it seemed ideal for teams that are already strong on the iOS side.

The thing is, in real projects, it’s never just about the technology. Our client had a tight deadline and a fixed budget. That means every extra week of development is painful for them, and they don’t really care if we use CMP, Skip, Flutter, or whatever else. What matters to them is:

• How fast can they get the app?
• Will it perform smoothly for users?
• Can they trust us to deliver without delays?

Looking at our team setup, CMP was simply the safer choice. We had Kotlin devs ready to roll, no learning curve, and the tooling around CMP felt a lot more stable at that moment. Skip, while exciting, still felt pretty new and less tested in production. For a client app that people would actually rely on during events, going with a less mature option just felt like a bigger risk.

In the end, we went with CMP, and it worked out well. The app was delivered on time, the performance was solid, and the client didn’t have to stress about delays. But the whole process also gave me a better sense of when Skip might actually be the smarter choice, mostly in teams that already prefer SwiftUI and just need Android as an add-on.

One feature that proved CMP was worth it

One feature that really tested our decision was the live event schedule. The client wanted attendees to see sessions, get real-time updates, and mark favorites, all while scrolling smoothly through lots of items. Sounds simple, but in practice, it can easily become a performance nightmare, especially when you try to do it cross-platform.

We briefly considered Flutter for this part. Flutter is fast, and building UI is quick, but syncing live updates across platforms felt like it would require extra custom work. Also, some of the platform-specific adjustments we needed for push notifications and calendar integration weren’t as simple.

CMP handled it in a way that really impressed me. Because we could reuse the same Kotlin code for UI and the logic behind it, the live updates worked consistently on both Android and iOS. Our Kotlin developers could work on the schedule feature without worrying about rewriting it for each platform. Animations and interactions were smooth, and performance stayed near-native even when a lot of items were loaded.

This was one of those moments where I realized why CMP is worth it for certain apps. It gave us the speed of cross-platform development without the usual headaches of syncing UI and business logic separately. For the live schedule, it saved us probably a week or more compared to what we would have spent trying to get the same thing in Flutter or another cross-platform framework.

Lessons Learned

I can say this project taught me a few things I’d definitely keep in mind for the future.

First, choosing the “right” cross-platform framework isn’t only about performance charts. On paper, Skip looked great for us since we’re strong in Swift. But in reality, it came down to who on the team was available at that moment. We had more Kotlin people ready to jump in, so CMP was simply the more practical choice.

That’s something I didn’t fully appreciate before: the best tech doesn’t always win, the best fit for your team and timeline usually does.

Second, I realized that cross-platform frameworks are still evolving, and no option is perfect. CMP gives you strong UI consistency and is backed by JetBrains, which is reassuring. But you still need to accept some challenges along the way: missing libraries, edge cases, or integration details you’ll have to solve yourself.

Skip, on the other hand, is very new, so if you choose it, you need to be comfortable with less documentation and fewer real-world examples. So my lesson here: It’s not just about the promises, it’s about how stable and proven the framework feels in real projects.

Third, deadlines change how you think. If you’ve got months to experiment, go ahead and try the new thing. But if your project is already late, stick with what your team can deliver fast and confidently. I think that’s a point many CTOs struggle with, the balance between innovation and reliability. For me, this project was a reminder that reliability should come first if time and budget are tight.

And lastly, I learned that keeping an open mind is crucial. Even though we went with CMP this time, I don’t see it as “the one and only” choice. I’d still keep an eye on Skip and test it in smaller projects, because who knows, in a year or two, it might be stable enough to be a serious competitor. Being flexible about technology is, I think, the only way to keep delivering good products long-term.

Conclusion

One of the biggest takeaways from this project was seeing how much time CMP actually saved us, not just in theory. For the live event schedule feature, which had lots of sessions and live updates, building it natively for iOS and Android separately would have taken our team around 5-6 extra days, mostly just syncing business logic and rewriting UI. With CMP, we reused about 80% of the code, and the feature worked on both platforms.

Another example was push notifications and calendar integration. In Flutter or Skip, we would have needed extra custom bridging code for each platform. With CMP, the shared Kotlin code let our devs implement the logic once and adjust minor platform-specific details without major rewrites. That’s real hours saved; in this feature alone, probably a full developer week, which is huge on a tight deadline.

Even small things added up. For instance, every UI change we made for iOS automatically applied to Android, and opposite. That consistency alone saved at least half a day per screen on QA. By the end of the project, we estimated that CMP saved the team about 15-20% of total development time, which is not just a nice-to-have; that’s money saved, fewer bugs, and a calmer client.