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 app development teams,” and honestly, it really is. Skip helps you build iOS apps faster by reducing boilerplate and letting you reuse components across projects. The trade-off? It’s mostly iOS-focused, so if you plan to expand to Android development later, you’ll need a different strategy or framework.

Skip isn’t brand new, but it’s younger than Compose Multiplatform, and the community is smaller, so finding answers online can sometimes be tricky. Still, I’ve seen startups and internal teams use it effectively to prototype quickly and launch iOS-first apps. For teams that live in Swift and want to move fast with iOS app projects, Skip can be a solid choice.

Our internal debate

When we got the client’s enterprise event app project, the big question was simple:
Which cross-platform framework actually makes the most sense, Compose Multiplatform or Skip?

We already had experienced Kotlin Multiplatform developers available, so CMP looked like the obvious choice. But I didn’t want to jump in blindly. Skip also caught our attention because the idea of writing SwiftUI and getting Android “for free” sounds great on paper, especially for teams that are already strong on the iOS development side.

But here’s the thing: in real enterprise mobile app development, it’s never just about the technology.
Our client had a tight deadline, a fixed budget, and zero tolerance for risk. They didn’t care if we used CMP, Skip, Flutter, React Native, or anything else. What mattered to them was:

• How fast can the app be delivered?
• Will the mobile app perform smoothly for thousands of users?
• Can the team deliver reliably without introducing new risks?

Looking at our team structure, CMP was simply the safer, more scalable call. We had Kotlin devs ready to move immediately, no onboarding, no learning curve, and the ecosystem around Compose Multiplatform felt far more mature for production use. Skip is promising, but the community is smaller and less proven, which increases the risk for any enterprise-grade project.

For a real app that people would rely on during live events, choosing a less-tested framework just didn’t align with the client’s expectations around performance, stability, and delivery predictability.

So we went with Compose Multiplatform, and it paid off. The app shipped on time, ran smoothly on iOS and Android, and the client didn’t have to worry about delays or technical surprises. And now, after going through that evaluation, I have a clearer picture of when Skip might make more sense: mainly for iOS-heavy teams who just need an Android version as an add-on.

‍

One feature that proved CMP was worth it

One feature that really validated our decision was the live event schedule. The client needed attendees to browse sessions, receive real-time updates, and mark favorites, all while scrolling through a dataset that could get pretty large.

On paper it sounds simple, but anyone who has built enterprise-grade mobile apps knows this kind of feature can turn into a performance trap, especially in cross-platform setups.

We even considered Flutter for this part. Flutter is undeniably fast, and building UI is quick, but when we looked closer, syncing continuous live updates across both platforms would’ve required custom logic, extra infrastructure, and more engineering hours. And some of the platform-specific needs, like push notifications, calendar integrations, and system-level behaviors, weren’t as straightforward in Flutter as they looked during evaluation.

CMP handled this feature in a way that surprised me.
Because we reused the same Kotlin code for the UI and the logic behind it, both Android and iOS stayed perfectly in sync. Our Kotlin developers built the entire schedule module once, not twice, and didn’t have to worry about inconsistencies creeping in. Animations stayed smooth, real-time updates were stable, and performance remained near native even with large lists and constant data changes.

This was the moment where CMP really proved itself.
It gave us cross-platform speed without enterprise risk, letting us ship a real-time feature that would’ve easily taken an extra week or more if we had gone with Flutter or split it into two native implementations.

And if you want to see the kind of cross-platform apps we’ve delivered for other teams, including large data-heavy apps and high-traffic enterprise projects, you can check out the Aetherius portfolio to get a better sense of what CMP enables in real projects.

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.

If you’re evaluating cross-platform technologies and want to see how this applies to your own project, you can explore our cross-platform app development services or dive deeper into our portfolio: both show how we support enterprise teams needing reliable delivery without disrupting existing workflows.

And if native development is still the right answer for your use case, we’ve got dedicated iOS developers and Android developers who build enterprise-level apps with clean architecture and long-term maintainability in mind.

Whichever route makes sense for your app or your internal team needs, we can help you scope the fastest and safest way forward.