Since the announcement of the preview Swift SDK for Android, the Android workgroup has seen a lot of interest in how it works and what’s next. Please read on for some answers to common questions about the technology and its future, and try out the new Swift 6.3 SDK nightly previews.

How Swift works on Android

Swift compiles directly to native machine code on Android, the same way it does on most other platforms. This approach produces similar performance to C and C++ code built using the Android Native Development Kit (NDK), while achieving a happier balance between performance, safety, and usability. To make this possible, Swift apps on Android bundle a native runtime that implements many of its features, including its standard library and core libraries, like Dispatch and Foundation.

However, since most Android APIs are only made available through Java and Kotlin, Swift must call into the Android Runtime (ART); that’s where the Java interoperability project’s jextract and wrap-java tools come in. These tools automatically create bindings that enable you to call Swift from Java or go the other way using the Java Native Interface (JNI), which allows Swift to seamlessly integrate with the Android platform.

The jextract tool gained a JNI mode this summer: you can watch its author Mads Odgaard’s Server-Side Swift Conference talk and try out the example weather app he submitted in the Android examples repository.

Swift on Android in production

While work is still ongoing on official Java interoperability, Android apps built using Swift have been in production for many years employing homegrown Java interop, with these apps collectively downloaded millions of times. Here are some notable examples:

• Spark - A popular email client using Swift to share code between mobile iOS/Android and desktop macOS/Windows versions
• flowkey - An interactive piano learning app built with Swift for Android for almost a decade
• MediQuo - A healthcare app leveraging Swift for cross-platform development
• Naturitas - An organic products marketplace running Swift in production

Ongoing work

Grassroots community efforts to run Swift on Android began as soon as the language source was opened in 2015, and continue to this day. The Android project board lists areas the workgroup determines important, such as easy debugging, now a high priority for us. While it may work for small examples, we need to expand and test it more and make it easy to configure and access. That will likely mean tying the debugger and Swift Language Server Protocol tool, sourcekit-lsp, into Integrated Development Environments (IDEs) like Visual Studio Code and Android Studio, another issue on our board.

An Android workflow was added to the official Swift workflows for GitHub months ago, allowing you to easily try building your Swift packages with the Swift SDK for Android, and work is underway to let you run your tests in an Android emulator too.

We are looking to onboard more contributors and have set up a video call this weekend to discuss getting started. We hope to make these contributor calls a recurring event moving forward, as more people pitch in to improve these Swift tools themselves.

Sharing Swift across platforms: logic vs UI

Swift allows you to target many platforms with the same business logic, and Swift on Android expands that much more. As we shared in our draft vision document, a prominent use case we’re focused on is sharing core business logic, algorithms, and data models across applications. The workgroup is not providing a single GUI solution, however a number of nascent community projects have approached the challenge in different ways.

Our recent post in the Swift forums lists a handful of popular and in-progress options. While the workgroup has not validated the claims on individual projects, we plan to add more info on using compatible GUI tools with the Swift SDK for Android in the coming months.

Android API versioning

Until recently, Swift on Android did not support targeting multiple Android API levels in the same app, but recent preview releases bring the familiar @available attribute and #available runtime check that you know from Apple platforms to Android:

#if canImport(Android)
import Android
import Dispatch
#endif

@available(Android 33, *)
func backtrace() {
    withUnsafeTemporaryAllocation(of: UnsafeMutableRawPointer.self, capacity: 1) { address in
        _ = backtrace(address.baseAddress!, 1)
    }
}

@main
struct ExecutableDemo {
    static func main() {
        #if os(Android)
          print("Hello from Android API 28 or later")
          if #available(Android 33, *) {
            // The following code is only run on Android 33+ devices.
            backtrace()
            print("Hello from Android API 33+")
          }
        #endif
    }
}

Try this new feature on Android and let us know how it works for you.

Learn from the community

Those using Swift on Android for many years have been sharing their experiences, as founding contributors like Readdle and flowkey have written about their work for the last decade.

The Left Bit’s Pierluigi Cifani recently wrote about their experiences, gave a great talk at NSSpain 2025 a couple months ago, and was interviewed by Swift Toolkit last month.

A community member recently contributed an example app that builds C++ using CMake and links it with Swift, using Swift’s automated JNI bridging to Java instead.

Swift 6.3 SDK nightly previews

Finally, we are happy to announce that an official Swift 6.3 SDK CI has been set up, and it is producing nightly preview releases of the Swift 6.3 SDK for Android. Please follow the Getting Started guide to install and use it.

Swift on Android has been a community effort for the last decade, growing from that initial patch to apps in production and an active group of developers. Try out the new preview releases of the Swift 6.3 SDK for Android and help us make it even better!

Ajay Kulkarni from Tiger Data (Co-founder/CEO) is on the pod this week with Adam. He asked him to get vulnerable and trace his path to becoming a CEO. They dig into the themes that have shaped his career, and explore how founder values end up forming company culture (whether you intend them to or not). From his enterprise days to building Timescale (and the rename to Tiger Data), we cover the whole journey — even the haters, because haters gonna hate. Here’s where it gets really interesting: Agents in the database! Not the hype. The real thing baby. They get into how fast you can go from idea to shipped these days, what it actually means to talk to your database, and the whole API/CLI/MCP/Skills movement.

Join the discussion

Changelog++ members save 9 minutes on this episode because they made the ads disappear. Join today!

Sponsors:

• Depot – 10x faster builds? Yes please. Build faster. Waste less time. Accelerate Docker image builds, and GitHub Actions workflows. Easily integrate with your existing CI provider and dev workflows to save hours of build time.
• Augment Code – Adam loves “Auggie” – Augment Code’s CLI that brings Augment’s context engine and powerful AI reasoning anywhere your code goes. From building alongside you in the terminal to any part of your development workflow.
• Framer – Design and publish in one place. Get started free at framer.com/design, code CHANGELOG for a free month of Pro. Rules and restrictions may apply.

Featuring:

• Ajay Kulkarni – GitHub, LinkedIn, X
• Adam Stacoviak – Website, GitHub, LinkedIn, Mastodon, X

Show Notes:

• Agentic Postgres
• timescale/tiger-cli

Something missing or broken? PRs welcome!

Share Episode ⸺ Episode Sponsor: Incident.io - https://dev0ps.fyi/incidentio
         
         "My biggest legacy at Google is the amount of systems I broke." — Sam Goto joins the show with a name that strikes fear into engineering systems everywhere. As a Senior Staff Engineer on the Chrome team, Sam shares the hilarious reality of having the last name "Goto," which once took down Google's internal URL shortener for four hours simply because he plugged in a new computer.

Sam gets us up to speed with Federated Credentials Management (FedCM), as we dive deep into why authentication has been built despite the browser rather than with it, and why it’s time to move identity from "user-land" to "kernel-land". This shift allows for critical UX improvements for logging in all users irrespective of what login providers you use, finally addressing the "NASCAR flag" problem of infinite login lists.

Most importantly, he shares why you don't need to change your technology stack to get all the benefits of FedCM. Finally, Sam details the "self-sustaining flame" strategy (as opposed to an ecosystem "flamethrower"), revealing how they utilized JavaScript SDKs to migrate massive platforms like Shopify and 50% of the web's login traffic without requiring application developers to rewrite their code.

• HSMs + TPM in production environments
• Get involved: FedCM W3C WG
• The FedCM spec GitHub repo
• TPAC Browser Conference

• Warren - Book: The Platform Revolution
• Sam - The 7 Laws of Identity and Short Story: The Egg By Andy Weir

Vite is a modern frontend build tool created by Evan You, the creator of Vue.js. It was designed to address long-standing performance bottlenecks in traditional bundlers like Webpack by leveraging native browser capabilities, particularly ES modules. The result is a development experience defined by near-instant server startup and extremely fast Hot Module Replacement (HMR).

If you’ve been building React applications for any length of time, you’ve likely lived through several eras of tooling: hand-rolled Webpack configurations, the rise of zero-config abstractions, and now the shift toward lightweight, ESM-first tooling like Vite. In 2025, the question is no longer “Which tool is better?” but “Which tool fits this team and this codebase best?”

From the trenches, the distinction is clear. Webpack is the Swiss Army knife: versatile, battle-tested, and endlessly configurable. Vite is the laser scalpel: fast, precise, and optimized for developer experience. Both are excellent tools, but they shine in very different contexts. Choosing between them has real consequences for iteration speed, build complexity, and long-term maintenance.

Webpack vs Vite in Simple Terms

Webpack in a nutshell

Webpack is an all-purpose build system. It offers deep control over every stage of the build pipeline, from asset handling to chunking strategy to runtime behavior. That power comes at the cost of configuration overhead. Unlocking Webpack’s full potential often requires substantial setup and ongoing maintenance, particularly in large or long-lived codebases.

If you need fine-grained control, custom loaders, or highly specialized build logic, Webpack gives you the tools to make that happen.

Vite in a nutshell

Vite prioritizes speed and simplicity. Its development server starts almost instantly, HMR updates feel immediate, and the default configuration covers the needs of most modern React projects. Instead of bundling everything up front, Vite serves source files over native ESM during development and relies on Rollup for optimized production builds.

It intentionally trades maximal flexibility for a streamlined workflow that works well out of the box.

At a high level, both tools remain highly relevant. The right choice depends on project scale, architectural complexity, browser targets, and how much control your team needs over the build system.

Developer Experience: Where Speed Meets Sanity

Few things disrupt developer flow more than waiting on a dev server.

In large React codebases, slow startup times and delayed HMR updates add up quickly. Even with improvements like persistent caching, Webpack’s initial compilation can still feel heavy at enterprise scale. During active refactors, HMR delays often interrupt momentum and force unnecessary full reloads.

Vite’s advantage here is immediate and tangible. The dev server starts almost instantly, and hot updates feel truly real time. That difference compounds over the course of a workday.

“When you’re refactoring a component and waiting for HMR, seconds feel like hours. That’s where Vite shines.”

Build Performance and Optimization Control

For production builds, both Webpack and Vite cover the fundamentals: tree-shaking, code splitting, caching strategies, and modern JavaScript optimizations. The real distinction lies in how much control you want over those mechanisms.

Webpack: maximum control

Webpack still dominates when fine-tuning matters. Its plugin ecosystem allows teams to shape nearly every aspect of the build output, from chunk boundaries to custom optimization passes. This level of control is often necessary in very large applications, monorepos, or environments with strict performance and compliance requirements.

Vite: strong defaults, minimal tuning

Vite takes a “good defaults” approach. For the vast majority of React applications, its production builds are fast, predictable, and require little manual intervention. You give up some extreme configurability in exchange for simpler builds and lower cognitive overhead.

In practice, shaving a few seconds off a build can matter. Reducing mental overhead matters more. This is where Vite frequently wins.

Configuration and Maintenance: The Hidden Cost

One of the most underappreciated differences between Webpack and Vite is long-term configuration maintenance.

Many experienced engineers have inherited Webpack configurations that span hundreds of lines, layered with loaders, plugins, environment-specific overrides, and legacy workarounds that no one fully understands. Debugging build issues often means digging through configuration rather than working in application code.

Vite takes the opposite approach. Its configuration surface is intentionally small, relying on modern standards and predictable defaults. You extend it only when necessary. This makes the build system easier to reason about, easier to onboard new contributors to, and easier to maintain over time.

Webpack offers power. Vite offers peace.

Ecosystem Maturity and Plugin Support

Webpack’s ecosystem

Webpack’s ecosystem is vast and deeply mature. It supports nearly every edge case imaginable, including legacy browsers, specialized asset pipelines, and long-standing enterprise tooling. If your project depends on uncommon loaders or deeply customized build behavior, Webpack likely already has a solution.

Vite’s ecosystem

Vite’s plugin ecosystem is newer but growing rapidly. Many plugins are shared with or inspired by Rollup, and the community has embraced modern workflows and clean integrations. While it is not yet as exhaustive as Webpack’s ecosystem, it is expanding quickly with a strong emphasis on maintainability.

Webpack has the mileage. Vite has the momentum.

How to Choose: A Senior Engineer’s Checklist

• How large and complex is the application?
• What environments and browsers must be supported?
• Do you rely on advanced Webpack features such as custom loaders or Module Federation?
• How important are startup speed and HMR responsiveness to daily development?
• Is the team prepared for the learning curve and migration cost?

Sometimes the best tool is the one your team already understands deeply.

Conclusion

In 2025, this is not a winner-takes-all debate. Webpack remains an enterprise-ready, highly configurable workhorse. Vite delivers a modern, fast, and developer-friendly experience that fits most React projects exceptionally well.

Both belong in a senior engineer’s toolkit. The right choice depends on your application’s scale, architectural constraints, and the workflow your team values most.

What has your experience been with Vite or Webpack? Have you seen meaningful speed improvements, migration challenges, or workflow wins? Sharing those lessons can help other teams make better decisions.

The post Vite vs. Webpack for React Apps in 2025: A Senior Engineer’s Perspective appeared first on LogRocket Blog.

I recently posted a short note about moving from WordPress to Substack after ten years on WP. A number of people replied, commented, or DM’d me to express their dismay, along the lines of “why are you supporting Nazis?”. A few begged me to reconsider.

So I did. I paused the work I was doing on migration and setup, and I paused the post I was drafting on Substack. I read the LeaveSubstack site, and talked with its author (thank you, Sean 💜). I had a number of conversations with people I consider experts in content creation, and people I consider stakeholders (my coworkers and customers), as well as my own personal Jiminy Cricket, Liz Fong-Jones. I also slept on it.

I’ve decided to stay.

I said I would share my thinking once I made a decision, and it comes down to this: I have a job to do, and I haven’t been doing it.

I have not been doing my job 💔

I’ve gone increasingly dark on social media over the past few years, and while this has been delightful from a personal perspective, I have developed an uncomfortable conviction that I have also been abdicating a core function of my job in doing so.

The world of software is changing—fast. It’s exciting. But it is not enough to have interesting ideas and say them once, or write them down in a single book. You need to be out there mixing it up with the community every day, or at least every week. You need to be experimenting with what language works for people, what lands, what sparks a light in people’s eyes.

You (by which I mean me) also need to be listening more— reading and interacting with other people’s thoughts, volleying back and forth, polishing each other like diamonds.

How many times did we define observability or high cardinality or the sins of aggregation? Cool. How many times have we talked about the ways that AI has made the honeycomb vision technologically realizable for the first time? Uh, less, by an order of thousands.

Write more, engage with mainstream tech

My primary goal is to get back into the mainstream of technical discussion and mix it up a lot more. Unfortunately, to the extent there is a tech mainstream, it still exists on X. I am not ruling out the possibility of returning, but I would strongly prefer not to. I’m going to see if I can do my job by being much more active on LinkedIn and Substack.

My secondary goal is to remove friction and barriers to posting. WordPress just feels so heavyweight. Like I’m trying to craft a web page, not write a quick post. Substack feels more like writing an email. I’ve been trying to make myself post more all year on WP, and it hasn’t happened. I have a lot of shit backed up to talk about, and I think this will help grease the wheels.

Some mitigations

• Substack makes money from paid subscriptions, so I don’t accept money. Ever.
• I am told that if you use email or RSS, it benefits Substack less than if you use the app. RSS feed here.
• I will set up an auto-poster from Substack to WordPress (at some point… probably whenever I find the time to fix the url rewriter and change domain pointer)

I hope these will allow conscientous objectors continue to read and engage with my work, but I also understand if not.

A vegan friend of mine once used an especially vivid metaphor to indignantly tell us why no, he could NOT just pick the meat and dairy off his plate and eat the vegetables and grains left behind (they were not cooked together). He said, “If somebody shit on your plate, would you just pick the shit off and keep eating?”

So. If Substack is the shit in your social media plate, and you feel morally obligated to reject anything that has ever so much as touched the domain, I can respect that.

Everyone has to decide which battles are theirs to fight. This one is not mine.

💜💙💚💛🧡❤️💖,
charity.