Eagle V5 Is in Development: What We've Been Building

If you've been following Eagle recently, you may have noticed that things have been quieter than usual.

It's been several months since our last major Blog update. During that time, we've continued maintaining Eagle V4, fixing issues, improving compatibility, and releasing necessary updates, but there haven't been many major new features or announcements.

From the outside, we understand how that can look.

Some users have even asked us directly: Is Eagle still being developed?

The answer is yes.

In fact, a significant part of our development effort has gradually shifted toward something much larger: Eagle V5.

We haven't talked about it much because V5 is still in active development, and we don't want to turn unfinished plans into promises. This isn't a release announcement, and we're not ready to share a launch date yet.

But we do think it's time to explain what we've been working on, why it has taken so long, and why we're rebuilding such a large part of Eagle in the first place.

Eagle V4 Is Still Being Maintained

Before talking about V5, we want to make one thing clear: Eagle V4 is not being abandoned.

We continue to maintain V4 and work on stability, compatibility, and issues that affect everyday use. Some ideas that were originally explored as part of V5 have also already made their way back into V4 through plugins.

AI Search, AI Actions, Eagle Skills, and Eagle MCP are examples of this. Instead of keeping these capabilities behind a future major release, we found ways to make them available to existing Eagle users earlier.

At the same time, however, years of development have made one thing increasingly clear: there are limits to how far we can continue extending Eagle's current foundation.

Eagle was first released in 2017. Since then, the product has grown far beyond what we originally imagined. Libraries have become much larger, workflows have become more complex, and the ways people want to access and work with their assets have changed significantly.

Some of the things we want Eagle to support next are no longer just feature problems.

They're architecture problems.

Why V5 Became a Ground-Up Rebuild

When we first started thinking about the next major version of Eagle, we didn't necessarily expect it to become such a deep rewrite.

But as development continued, we realized that many of the limitations we were encountering came from assumptions built into Eagle's original architecture.

Today, many responsibilities inside Eagle are closely tied to the desktop application itself. The interface, application logic, library state, and data operations were designed around a world where one desktop application was effectively the center of everything.

That model has served Eagle well for many years.

But it becomes increasingly restrictive when we start thinking about things like multiple windows, multiple users, multiple accounts, additional devices, browser-based access, AI agents, or eventually platforms such as iPad and other mobile devices.

Trying to add all of these capabilities directly onto the existing architecture would mean continuously working around assumptions that were never designed for them.

So instead of continuing to extend that foundation indefinitely, we decided to rebuild it.

Eagle V5 introduces a new architecture in which the core service responsible for an asset workspace is separated from the applications and interfaces that connect to it.

That sounds like an internal technical change, but it fundamentally changes what Eagle can become.

V4 and V5 Are Fundamentally Different Architectures

There's an important consequence to rebuilding Eagle this way that we want to be transparent about.

Eagle V5 is not Eagle V4 with its internals gradually replaced.

It is being built on a fundamentally different architecture.

That gives us much more freedom to solve problems that are difficult within V4's current foundation, but it also means that V4 and V5 are not directly compatible at the architectural level.

When V5 eventually becomes available, moving from V4 will therefore not simply mean installing a new version and continuing as if nothing changed.

We plan to provide tools that help users import and migrate their existing V4 libraries into V5. Our goal is to make that transition as practical and reliable as possible, but migration may still involve data conversion, and some workflows or behaviors may need to be adapted to the new architecture.

We think it's better to be clear about this now rather than imply that two fundamentally different systems can somehow be made perfectly compatible.

This is also part of why V5 takes time.

We're not only building a new architecture. We also have to think carefully about how nearly a decade of existing Eagle libraries, data, and workflows can move into that new architecture without placing unnecessary burden on users.

Most of Our Time Has Gone Into Building the Foundation

People often assume that a long development cycle means we're building a huge number of visible new features.

In reality, much of our work over the past months has focused on things users may never directly see.

We've been separating responsibilities that were previously tightly connected, rebuilding how different parts of Eagle communicate, rethinking how libraries are managed, and creating a foundation where multiple applications or clients can safely work with the same asset workspace.

This kind of work doesn't always produce exciting screenshots.

Sometimes months of development result in something that looks almost identical on the surface.

But underneath, the system is becoming very different.

And once that foundation exists, capabilities that would previously have required large amounts of special-case engineering become much more natural to build.

A Foundation for More Than One Window

One simple example is multiple windows.

In the current architecture, Eagle was fundamentally designed around a single desktop application managing a library.

Supporting multiple independent windows properly isn't just about opening another interface. Those windows need to share state, react to changes consistently, coordinate operations, and avoid interfering with each other.

With V5's architecture, the application interface no longer needs to be the sole owner of the library.

Multiple windows can instead become different clients connected to the same underlying workspace.

That makes proper multi-window workflows much more realistic.

You might keep one window focused on reference material while another is used for organizing assets, or work across different views without constantly changing the state of a single interface.

It's a relatively simple example, but it illustrates why we're spending so much time on architecture rather than trying to bolt individual features onto V4.

Multiple Users and Multiple Accounts Become More Practical

The same architectural change also creates a much better foundation for multiple users and multiple accounts.

Historically, Eagle has been built primarily around one person working with a local library from one application.

That simplicity is one of Eagle's strengths, and we don't want to lose it.

But there are also many situations where people want more flexibility: switching between personal and work environments, accessing different libraries under different identities, or eventually allowing multiple people or applications to interact with the same workspace in controlled ways.

These are difficult problems to solve cleanly when identity, application state, and library operations are tightly coupled together.

V5 gives us a much better place to start.

That doesn't mean every possible collaboration feature will suddenly appear in the first release of V5. It means the architecture will no longer make those ideas fundamentally awkward to build.

That's an important distinction.

It Also Changes What's Possible Beyond the Desktop

Perhaps one of the most interesting consequences of this architecture is that Eagle no longer has to be thought of as one desktop application containing everything.

If the core workspace can operate independently from the interface, different kinds of clients can connect to it.

The Windows and macOS applications can be clients.

A browser could potentially be another client.

An iPad application could eventually be another.

And the same foundation makes broader mobile access much more realistic than it is today.

We're deliberately using words like could and eventually here. This article is about the direction enabled by the architecture, not a promise that every platform mentioned will ship with V5.

But this is one of the reasons we're willing to invest so much effort in rebuilding the foundation.

Instead of asking, "How do we somehow fit an iPad version into the current desktop architecture?" we can begin designing a system where different interfaces and devices are expected from the beginning.

AI Agents Become Clients Too

There's another type of client that barely existed when Eagle was originally designed in 2017: AI agents.

Over the past year, we've already started exploring this direction through Eagle MCP and Eagle Skills.

Today, these tools allow AI systems to search, understand, and interact with assets stored in Eagle.

But we think this is only the beginning.

In a world where people increasingly work alongside AI agents, an asset library shouldn't only be understandable by the person looking at the screen. It should also provide structured ways for other tools and agents to access the same information and perform authorized operations.

V5's architecture makes this much more natural.

A desktop application, another device, a browser interface, or an AI agent can all be thought of as different clients interacting with the same underlying workspace.

For us, this is a much more interesting direction than simply adding an AI chat box somewhere inside Eagle.

We want Eagle itself to become better infrastructure for the tools people choose to work with.

This Doesn't Mean Everything Will Arrive at Once

When talking about architecture, it's easy to accidentally make every future possibility sound like a promised feature.

That's not what we're announcing here.

Multi-window workflows, multiple accounts, additional platforms, browser access, mobile devices, AI integrations, and new collaboration models are examples of what becomes significantly more practical once the architectural constraints of V4 are removed.

They should not be read as a checklist of features guaranteed for the first V5 release.

Our immediate priority is still the foundation.

We want to make sure the architecture is reliable, the core library experience remains fast and dependable, and the migration path from V4 is something we can confidently put in front of existing users.

Only then does it make sense to build aggressively on top of it.

So, When Will V5 Be Released?

We know this is probably the question many people want answered most.

Right now, we don't have a release date we're ready to announce.

There is still substantial work ahead, and because V5 is now a much deeper architectural change than a conventional major update, we don't want to create an artificial deadline and then compromise the foundation just to meet it.

We'll share more when we have something concrete enough to be useful.

Until then, Eagle V4 will continue to be maintained, and where it makes sense, we'll continue bringing useful capabilities to existing users rather than unnecessarily holding everything for V5.

Eagle Is Still Moving Forward

If Eagle has seemed unusually quiet recently, it's not because development has stopped.

It's because a large part of our work has moved beneath the surface.

After nearly a decade of building Eagle, we reached a point where continuing to add features to the same foundation was no longer enough for the things we want to build next.

So we're building a new one.

That comes with tradeoffs. V5 will be fundamentally different from V4, and moving between them will require a real migration rather than an invisible upgrade.

But that architectural break is also what gives us room to rethink some of Eagle's oldest limitations and create a foundation for multiple windows, multiple users and accounts, more devices and platforms, AI agents, and possibilities we couldn't reasonably support when Eagle was first designed.

There's still a lot of work ahead.

But Eagle is very much still being developed, and V5 is the foundation we're building for its next chapter.