Skip to content
Skip
Documentation Gallery Blog Sponsor
3.1k

Blog

Android development is now Compose First

- 8 min read - 1529 words

Compose-First Android Development

Section titled “Compose-First Android Development”

Last week at Google I/O, the Android team announced (to audience cheers1) that all new Android UI will be Jetpack Compose going forward. The Android is Compose-first ↗ page on the developer site now states2:

Jetpack Compose is Android’s declarative UI toolkit, built for modern user interfaces, with dynamic data, rich graphics, and beautiful animations. It’s replacing the View toolkit, which has served Android development well for years, but was not designed for the latest demands and best practices.

Slide from the Google I/O 2026 What's new in Android session reading 'Compose First — all new Android UI built with Compose' with the chip 'android.widget.* in maintenance mode' below it.

The same page declares that the old View system is, without quite saying “deprecated”, moribund technology:

We now consider the View toolkit (for example, classes in android.widget such as TextView and ListView) to be in maintenance mode — this means that it will only receive highly critical fixes.

The companion announcement covers the Jetpack libraries and Android Studio’s UI tooling as well: the View-based libraries are frozen at “critical fixes only”, and any new tooling in Android Studio will target Compose only. Existing View-era tools such as the Layout Editor and Navigation Editor will continue to receive only critical fixes in maintenance mode, but will not be enhanced and improved going forward.

For anyone tracking the Android platform over the last several years, this should come as no surprise: Compose has been the recommended toolkit for new development since 2021. But it is the clearest signal yet that the long transition is now effectively over. Compose is the future, and the Android View system — like UIKit on iOS — is legacy technology.

This is the right outcome for Android developers. Compose is a modern toolkit that embraces the industry’s trend towards a declarative state-driven user interface paradigm. It is where the platform’s investment is going, and it is what new APIs will be built around.

It is also an outcome that validates Skip’s unique approach. Skip has been “Compose-first” on Android since the day we first shipped, both in Skip Lite (where we transpile SwiftUI into idiomatic Compose) and in Skip Fuse (where we bridge native Swift to Compose directly). When you write List, NavigationStack, or TextField in your SwiftUI source, the Android side of your app builds a real Jetpack Compose tree using the same components that a Kotlin Android developer would reach for. There is no parallel widget hierarchy or custom renderer, and no second-class “Compose interop” mode. The Compose tree is the Android UI, just as the SwiftUI tree is the iOS UI.

SwiftUI-First iOS Development

Section titled “SwiftUI-First iOS Development”

Apple issued a symmetric declaration four years earlier in their Platforms State of the Union3:

The best way to build an app is with Swift and SwiftUI.

WWDC 2022 slide reading "The best way to build an app is with Swift and SwiftUI."

One of the fundamental principles of Skip is that it simply doesn’t exist on iOS. The Apple side of a Skip app is the same Xcode project and App struct and SwiftUI view hierarchy that an iOS-only team would produce. While we do have plenty of platform and integration frameworks that help provide unified API surfaces between iOS and Android libraries, the Skip toolchain itself, on iOS, is invisible at runtime. Skip’s build plugin assembles and launches the Android counterpart of your app side-by-side with the iOS build, but it does not wrap or intermediate your SwiftUI views. When you write Text("Hello") in a Skip project, the iOS binary contains a Text("Hello") — nothing more and nothing less.

This is what we mean when we say Skip is not an intermediation layer on iOS. There is no abstraction between your code and Apple’s frameworks for a SwiftUI compiler to optimize through, and no compatibility layer for an OS upgrade to break. You are not running a “Skip-flavoured” SwiftUI: you are running SwiftUI.

A practical consequence showed up last summer, when Apple unveiled their new Liquid Glass design language at WWDC 2025. Regardless of how one feels about this aesthetic redesign, every existing Skip app automatically picked it up the day the first developer beta shipped. There was no Skip update required and no SwiftUI compatibility layer to upgrade. Liquid Glass is implemented inside Apple’s frameworks, and Skip apps use Apple’s frameworks directly; therefore Skip apps look like the rest of iOS automatically. The same will be true for the next design refresh, and the one after that. This sort of guaranteed future-compatibility is essential for teams that prioritize harmony with the platform and alignment with the first-party SDKs.

Why other cross-platform frameworks struggle to keep up

Section titled “Why other cross-platform frameworks struggle to keep up”

The Compose-first Android announcement, along with last year’s Liquid Glass unveiling, are both instructional opportunities to scrutinize the structural issues that other cross-platform UI tools have.

Cross-platform UI frameworks generally fall into one of two camps:

  1. Pixel-painted widgets: Flutter is the most obvious example. Flutter draws its own buttons, switches, scrollbars, and navigation chrome by using Skia (now Impeller) to paint raw pixels into a canvas. The result is a single widget set that looks similar on every platform, along with optional “Cupertino” and “Material” widget sets that try to mimic the real native look and feel of the platform. Compose Multiplatform, on the iOS side, also falls into this category: while it is real Jetpack Compose on Android, on iOS it takes the same pixel-painting approach to mimicking the native UI as Flutter does.

  2. Legacy-technology bridges: React Native sits a bit closer to the platform but still maintains its own component hierarchies on each side. It exposes a limited set of platform widgets to a JavaScript runtime through a bridge. This has the benefit of using “real” components (typically UIKit views on iOS and Android Views on Android), but lays them out using their own CSS-derived styling that can deviate from evolving platform conventions.

Both approaches share the same downside: when the platform changes, the framework must catch up. Each new design language is a project and every new control variant has to be re-implemented. When Apple shipped Liquid Glass, the response from the Flutter team was straightforward about their architectural limitations in their response on the subject ↗:

As with Material 3 Expressive, we are not developing the new Apple’26 UI design features in the Cupertino library right now, and we will not be accepting contributions for these updates at this time.

A year on, Liquid Glass support has still not landed in any major cross-platform UI toolkit’s iOS layer. Flutter’s Cupertino widgets still look like iOS 18, and will be stuck there for the foreseeable future. Compose Multiplatform on iOS still renders like an Android Material Design app painted onto an iPhone screen. React Native apps inherit whatever underlying native control they wrap, but the parts of the app the framework draws itself — sheets, navigation transitions, list rows — do not change.

Skip avoids — or “skips” — this entire class of problem altogether. On Android the toolkit is Compose because Skip emits Compose. On iOS the toolkit is SwiftUI because Skip doesn’t exist there. Skip is the only cross-platform development tool that uses the platform-recommended UI toolkit on both iOS and Android; that is the value proposition.

We expand on this topic at length in our comparison of cross-platform options. The short version is that an app built with a UI framework that mimics the platform always trails the platform; an app built with a UI framework that is the platform never does.

Skip is ready on Day One, Now and Forever

Section titled “Skip is ready on Day One, Now and Forever”

Apple’s WWDC conference starts next week. We don’t know what will be on the keynote stage. There is the usual swirl of rumor and speculation, and our guess is as good as anyone else’s. What we do know is that whatever ships, Skip apps will adopt it on day one, for the same reason that we supported Liquid Glass on day one: Skip does not stand between your code and SwiftUI. And now that Android is an officially supported platform for the Swift language, we can state with confidence that nothing that happens in the language itself will ever be unsupportable on the Android side, regardless of whether you use Skip Lite’s transpiled mode or Skip Fuse’s compiled mode.

We at Skip have always said:

Squint hard enough and Kotlin looks like Swift.

Squint really hard, and Jetpack Compose looks like SwiftUI.

These two declarative state-driven reactive toolkits are aligned in theory, they just happen to be drastically different in implementation. At its essence, all Skip does is bridge the divide, allowing you to create a single unified codebase that targets both native toolkits without having to write — and maintain — your app twice.

We are excited about what is coming. We will be watching the keynote and “State of the Union” with the rest of you, and we will be ready to write about whatever lands. The one thing we will not have to write about is “when will Skip support this.” We already have the answer: day one, now and forever.

Footnotes

Section titled “Footnotes”

  1. Nick Butcher, Ash Nohe, and Daniel Galpin, What’s new in Android ↗, Google I/O 2026. ↩

  2. Android is Compose-first ↗, Android Developers, May 2026. ↩

  3. Sebastien Marineau-Mes, Platforms State of the Union, WWDC 2022 ↗. ↩

Swift on Android at the iOSoho Meetup

- 2 min read - 423 words

Last month I gave a talk on Swift on Android at the iOSoho meetup ↗ in New York. Capital One hosted the event at their 19th Street offices, Runway kept everyone fed, and the recording is now live.

The evening was a Kotlin and Swift cross-platform doubleheader. Clinton Teegarden, a Distinguished Engineer at Capital One, opened with a deep dive into Kotlin Multiplatform and Compose Multiplatform. He built a Flappy Bird style game from scratch to walk through how shared UI rendering works in CMP, with detours through iOS interop and architectural gotchas. Hearing how the JetBrains stack tackles the cross-platform problem made for a useful contrast with the Swift-first approach we take at Skip.

My segment came next, and the talk traced the path of Swift on Android from its earliest community origins through to the official Swift SDK for Android ↗ that shipped with Swift 6.3, the culmination of over ten years of community effort. I worked through the full stack:

  • the lowest-level manual native interaction with the Android NDK and SDK
  • the synthesized Java bindings produced by the swift-java ↗ project
  • full Jetpack Compose powered apps written entirely in SwiftUI on top of Skip ↗

If you want a single place to see how all of these layers fit together, this is the talk. My segment starts at 37:09, and the Compose Multiplatform talk before it is well worth watching for context.

Turnout was strong both in person and on the simulcast, which went out to the New York Android, DC Android, DC iOS, and Dallas iOS Developers groups, each running its own watch party. Pulling off a four-way live broadcast on a single evening takes serious coordination, and huge credit goes to Paul Miard for organizing iOSoho and to Madona Wambua at New York Android Engineers, Scott Luxenberg at DC iOS, and Jared at DC Android for keeping their meetings and talks synchronized.

The audience came with thoughtful questions about debugging, packaging, third-party Swift packages on Android, and how Skip Fuse fits alongside the official SDK. I wish Q&A had run longer, but the after-hours conversation that spilled over into Old Town Bar ↗ more than made up for it.

Thanks again to Paul and the iOSoho crew, to Capital One for hosting, to Runway for the food, and to everyone who attended in person or remotely. For follow-up questions, the Swift Forums thread ↗ is a good place to start, and you can always reach us on Slack or the Skip discussion forums ↗.

A SwiftUI Block Blast Game in Skip Showcase

- 4 min read - 425 words

Easter Eggs in software are hidden delights, small features that are orthogonal to the core purpose of the product but which spark a little surprise and joy. Before they lost their collective senses of humor and whimsey, big tech companies routinely1 included easter eggs in their products, such as a flight simulator in a spreadsheet or a pinball game in a word processor.

Just in time for Easter, the Skip Showcase app has released version 2.3.6 to both the Apple App Store ↗ and Google Play Store ↗. This version contains a hidden gem: a completely native Swift and SwiftUI “Block Blast” style puzzle game.

Screenshot of Block Blast on iPhone Screenshot of Block Blast on Android

Easter eggs were historically activated via some secret gesture and sequence of actions that can only be stumbled upon by chance or learned about via word of mouth. As it turns out, modern app store policies frown on these sorts of hidden features (c.f. the aforementioned dearth of humor and whimsey), so our Block Blast game is rather conspicuously labelled “Easter Egg” at the bottom of the Showcase tab’s list of playgrounds.

Screenshot of Skip Showcase Easter egg

Games in SwiftUI

Section titled “Games in SwiftUI”

Cross-platform gaming has historically been the provenance of specialized SDKs such a Godot2, Unity3, or Unreal4. However, for casual games like board or puzzle games, these full-fledged engines can be overkill: you can just build it yourself with the view and gesture primitives that SwiftUI provides.

Our implementation of the Block Blast game is done in under 1,000 lines of pure Swift: see GamePlayground.swift ↗ for the whole thing. This code works out of the box on iOS, and on Android it builds with the newly-released Swift SDK for Android5, using Skip Fuse to translate the SwiftUI into SkipUI’s Jetpack Compose on Android and handle all the details of packaging and running the app. Shapes, gestures, haptic feedback, high score persistence, and everything: all done in straightforward declarative SwiftUI, exactly the same on Android as it is on iOS.

Now, do we think that the next Grand Theft Auto ought be written in SwiftUI? Probably not. But for a large segment of casual games and game-like experiences, Xcode and SwiftUI may be all that you need. And augmenting your project with Skip will enable you to bring it to Android and triple the market reach of your app!

Screenshot of Block Blast on iPhone Game Over Screenshot of Block Blast on Android Game Over

Download on the Apple App Store Download on the Google Play Store

Footnotes

Section titled “Footnotes”

  1. Easter Eggs in Software — https://en.wikipedia.org/wiki/Easter_egg_(media)#Software ↗ ↩

  2. Godot Game Engine — https://en.wikipedia.org/wiki/Godot_(game_engine) ↗ ↩

  3. Unity Game Engine — https://en.wikipedia.org/wiki/Unity_(game_engine) ↗ ↩

  4. Unreal Game Engine — https://en.wikipedia.org/wiki/Unreal_Engine ↗ ↩

  5. Swift 6.3 released with Android SDK — https://www.swift.org/blog/swift-6.3-released/#android ↗ ↩

Official Android support in Swift 6.3

- 9 min read - 1648 words

With this week’s release of Swift 6.3 ↗, support for the Android platform is now official. The Swift SDK for Android ships alongside the Static Linux and WebAssembly SDKs as a first-class, officially maintained target. For the first time, Swift runs on every major consumer operating system: macOS, iOS, Windows, Linux, and now Android.

For us at Skip, this moment is the culmination of years of work. We have been building on the Swift Android toolchain since its earliest preview builds, and we co-founded the Swift on Android Working Group ↗ that helped shepherd it from prototype to production. Today, the technology that has been powering Skip Fuse apps in the real world is officially part of the Swift project.

What Android support actually means

Section titled “What Android support actually means”

When Swift first shipped Linux support, it had immediate broad use cases: command-line tools, server applications with frameworks like Vapor, even some desktop GUI work. Android is a different story: it is a consumer-facing, app-oriented platform. You could push a CLI binary to a device via adb (as the swift.org getting started guide ↗ describes), or write a background service library, but the real opportunity is the same one that makes Swift shine on iOS: building user-facing apps.

The Swift Android Workgroup is focused on the low-level support for the Android platform, and intentionally does not try to cover higher-level technologies that facilitate application development. That is left for projects like Skip to create, building on the foundational language support.

Swift is an outstanding app-building language. The language has the performance and low-level control you would expect from a systems language, the safety and approachability of a modern managed language, and the expressiveness of a functional language with elegant features that empower the natural and intuitive API offered by SwiftUI .

These qualities all translate directly to Android. And with Swift 6.3, the toolchain that makes this possible is now maintained, tested, and released by the Swift project itself.

The road here

Section titled “The road here”

The Swift on Android story did not start with 6.3. Community developers have been experimenting with Swift cross-compilation for Android for years. At Skip, we adopted an unofficial preview build of the Android toolchain in 2024 to power our native Skip Fuse mode. This gave us a head start, but it also meant we were building on a foundation that had evolved somewhat haphazardly over the years and lacked official backing.

That changed in February 2025, when we joined together with other developers and companies to found the Swift on Android Community Working Group ↗. The goal was to coordinate the scattered efforts and make the toolchain good enough for official release. A few months later, the Swift Platform Steering Group blessed the group as an official workgroup ↗, which marked a turning point: Swift on Android was no longer a niche interest; it had the institutional support of the Swift project.

What followed was months of hard work: cleanup, bug fixes, CI infrastructure, packaging, quality control, and harmonization with the structure of other Swift SDKs. We wrote about the initial nightly SDK announcement ↗ and the broader implications for Skip in our post on an official Swift SDK for Android. The 6.3 release is where all of that work landed.

What this means for Skip

Section titled “What this means for Skip”

When we launched Skip in 2023, the idea of writing your entire mobile app in Swift for both iOS and Android was considered audacious. Potential adopters, especially enterprises making long-term architecture decisions, had a natural concern: what if Swift on Android never becomes officially supported? How could a small team guarantee the durability of a technology that the platform vendor had not endorsed?

The 6.3 release answers that question definitively. Swift on Android is here to stay. It is maintained by the Swift project, backed by the Android Working Group, and released on the same cadence as every other Swift platform. Even if Skip as a technology were to somehow disappear, any investment made in Swift for Android development would remain on solid, officially supported ground.

This is not a small thing. It removes the single largest concern we have heard from enterprises evaluating Skip for cross-platform development. We have always said that Skip does not lock you in, and now the official SDK makes that promise concrete: your Swift code, your Swift packages, and your Swift skills all work on Android now, with or without Skip. Skip simply makes it dramatically easier to build complete, polished apps with them.

Skip Fuse on the official SDK

Section titled “Skip Fuse on the official SDK”

We have already transitioned Skip’s native Fuse mode to the final 6.3 SDK, and the Skip Showcase ↗ app built on this toolchain has been published to both the Google Play Store and the Apple App Store.

Screenshot of Skip Showcase native app
Download on the Google Play Store Download on the Apple App Store

For existing Skip Fuse users, the transition from the preview toolchain is seamless. Our Skip 1.8 release upgrades the default installed Android SDK to install and use the official Swift SDK for Android, and the new skip android sdk upgrade command will automatically upgrade to newer versions when they are released.

As a quick recap of how it all works: Skip Fuse compiles your Swift natively for Android using the official SDK, giving you the full Swift language on both platforms. On the UI side, SkipFuseUI bridges your SwiftUI declarations to Jetpack Compose, producing a genuinely native Android user experience. When your Swift code updates an @Observable, that change propagates transparently into Compose’s reactive system. Your @State, @Binding, and @Environment work identically on both platforms.

For finer-grained integration between Swift the Java or Kotlin libraries, Skip offers multiple avenues: AnyDynamicObject lets you invoke Kotlin and Java APIs from compiled Swift with no code generation, and ComposeView lets you embed custom Jetpack Compose views directly in your SwiftUI hierarchy. And #if SKIP blocks let you write Kotlin inline in your Swift files, with automatic transpilation and bridging. We covered these capabilities in detail in our posts on fully native Swift apps and bringing Swift packages to Android.

The native Swift on Android ecosystem story is also advancing. Over 2,200 Swift packages already build successfully for Android, tracked at the Swift Package Index’s Android platform status ↗. Popular libraries like Alamofire, SwiftSoup, swift-protobuf, and flatbuffers work out of the box. And because Skip can also call Kotlin and Java APIs, your app has access to both ecosystems simultaneously.

A new option for cross-platform development

Section titled “A new option for cross-platform development”

For years, the conventional wisdom has been that the best mobile apps require separate Swift and Kotlin codebases. That approach delivers great results, but it is expensive. You are paying two teams, maintaining two implementations of the same business logic, and coordinating releases across two platforms. Even with the assistance of LLM coding agents, maintaining two parallel application codebases is cumbersome and rife with peril. The alternative has traditionally been to adopt a cross-platform framework like React Native or Flutter, which means leaving your native language behind and accepting tradeoffs in performance and platform fidelity.

Swift 6.3 opens a third path. You can now write your app in Swift and ship it natively on both platforms. If you are an iOS developer, the skills, the language, the frameworks, and the packages all transfer. The learning curve is not Kotlin or Dart or JavaScript. It is the Android platform itself, and Skip handles most of that translation for you.

There are two main ways to adopt this:

  • Shared business logic: Use the Swift SDK directly to cross-compile your model layer for Android, and keep the UI native on each platform. This may be the most realistic path for “brownfield” projects, where you need to incrementally begin adopting Swift in an existing Android app. It is the technique that was adopted by Naturitas and other platforms, as discussed in the excellent “Android Doesn’t Deserve Swift—But We Did It Anyway!” ↗ talk.
  • Full app development with Skip: Write your entire app in Swift and SwiftUI, and let Skip produce the Android version with Jetpack Compose. This is where Skip really shines: the entire app is a single Swift codebase, with shared metadata, resources, and abstractions of common conventions. This option is generally a good fit for greenfield projects, and is our recommended way to started with Skip.

Whichever path you choose, getting started takes minutes. Install Skip, run skip create, and you will have a working dual-platform app building in Xcode and launching on both an iOS simulator and an Android emulator. The template includes a TabView, navigation, data persistence, and a custom Compose view to show how the pieces fit together. Our getting started guide walks through the full setup.

Looking ahead

Section titled “Looking ahead”

The remaining challenges for Swift on Android are engineering problems, not existential ones. Binary size (currently around 60 MB for the Swift runtime and Foundation) will shrink as the toolchain matures. Build times will improve. Debugging support will get better. The foundation is now solid and official; the rest is iteration.

The Swift on Android Working Group, which we co-founded and actively contribute to, meets regularly to coordinate SDK development, triage issues, and plan the roadmap. This is not a one-time release. It is the start of an ongoing, community-driven effort with official backing from the Swift project.

For Skip, the 6.3 release energizes our roadmap. We are expanding SkipUI and SkipFuseUI coverage, improving build times, and working with the community to grow the list of Android-compatible Swift packages. The official endorsement of Swift on Android gives us and our users enormous confidence in the path forward.

Cross-platform Swift and SwiftUI have been a dream of ours since we launched Skip three years ago. With Swift 6.3, that dream has official support from the Swift project itself. We are excited about what comes next, and we cannot wait to see what you build.

Skip Is Now Free and Open Source

- 5 min read - 1036 words

Since launching Skip in 2023, we’ve pursued one mission: enable developers to create premium mobile apps for iOS and Android from a single Swift and SwiftUI codebase — without any of the compromises that have encumbered cross-platform development tools since, well, forever.

Over the past three years, Skip has evolved significantly. We started with a Swift-to-Kotlin transpiler and Android support for the most common SwiftUI APIs. We then founded the Swift Android Workgroup ↗ and released the Swift Android SDK to compile Swift natively for Android. We now have dozens of popular integration frameworks, interoperate with thousands of cross-platform Swift packages, and feature the most complete independent SwiftUI implementation available.

The Challenge of Paid Developer Tools

Section titled “The Challenge of Paid Developer Tools”

Until today, Skip has required a paid subscription and license key to build apps. While free apps and indie developers below a revenue threshold were exempt, businesses were expected to subscribe. This model helped us bootstrap Skip without outside investment, but we’ve always known that to truly compete with legacy cross-platform tools and achieve widespread adoption, Skip would need to become freely available.

The plain truth is that developers expect to get their tools free of charge. First-party IDEs like Xcode and Android Studio, popular integration frameworks, and essential dev tools are all given away at no (direct) cost. The platform vendors monetize through developer program fees, app store commissions, and cloud services. Framework providers typically monetize through complementary services. But developer tools? Those have historically required the patronage of massive tech companies in order to fund their ongoing development, support, and infrastructure costs.

Beyond pricing, there’s a deeper concern about durability. Developers are understandably wary of building their entire app strategy on a small company’s paid, closed-source tool. What if the company goes under? Gets acquired and shut down? What happens to their apps? We get it. While Skip’s innate ejectability offers some risk mitigation, product teams need absolute confidence that their chosen technologies will be around next week, next year, and beyond. They must remain immune from the dreaded “rug pull” that so often accompanies a “pivot”.

To keep the development community’s trust and achieve mass adoption, Skip needs a completely free and open foundation. Even if the core team disappeared, the community could continue supporting the technology and the apps that depend on it.

What’s Changing

Section titled “What’s Changing”

As of Skip 1.7, all licensing requirements have been removed. No license keys, no end-user license agreements, no trial or evaluation period.

Supporting Skip’s Future

Section titled “Supporting Skip’s Future”

Since day one, Skip has been bootstrapped. We haven’t taken venture capital or private equity investment, nor are we controlled by big tech. This independence means we control our destiny and can make the best decisions for Skip’s developers and users — a unique position in the cross-platform development space.

But independence requires community support. And that is where you come in.

  • Current subscribers: Your Small Business or Professional plan will automatically transition to an Individual or Supporter tier, respectively. You can cancel any time with no consequences (other than making us sad), but we hope you’ll consider staying on, at least throughout this transition period.
  • Individual developers: If you believe in Skip’s mission, please consider supporting us through GitHub Sponsors ↗ with a monthly contribution.
  • Companies and organizations: For businesses that want to see Skip flourish, we offer corporate sponsorship tiers with visibility on our homepage and in our documentation. Your sponsorship directly funds development of the integration frameworks essential to production apps, as well as the ongoing maintenance, support, and infrastructure. Sponsorship comes with some compelling perks! Please visit https://skip.dev/sponsor to see the sponsorship tiers.

Investing in Skip is also investing in your own team’s capabilities and competitive advantage. Your support accelerates Skip’s development and ensures its long-term success, enabling your developers to build exceptional native experiences efficiently, today and into the future.

What Comes Next

Section titled “What Comes Next”

We’re at a pivotal moment in the app development field. Legacy cross‑platform frameworks are struggling to keep pace with the rapid evolution of modern UI systems like Liquid Glass on iOS and Material Expressive on Android. The compromises that once felt acceptable in exchange for a unified codebase now result in dated interfaces, weaker user experiences, and real competitive disadvantages. Teams ready to move beyond those trade‑offs can count on Skip to champion what matters most: delivering truly native, uncompromised experiences on both major mobile platforms.

Opening Skip to the community marks the next step in its evolution. Software is never finished — especially a tool that supports modern Swift and Kotlin, SwiftPM and Gradle, Xcode and Android Studio, iOS and Android, and the ongoing growth of SwiftUI and Jetpack Compose. It’s a demanding pursuit, and we’re committed to it. But sustaining and expanding this work depends on the support of developers who believe in Skip’s mission.

Together, we will continue building toward Skip’s vision: a genuinely no‑compromise, cross‑platform foundation for universal mobile apps.

Thank you for your support, and as always, Happy Skipping!

Ready to get started? Get started with Skip 1.7 today and join the community building the future of native cross-platform development.