Proposed Roadmap & Long‑Term Vision for the Project

[Goldmaster]

Since reviving the project, I’ve been thinking about how we can strengthen its future and what a long‑term plan might look like. Of course, the direction ultimately depends on @krisu5 and the needs of the Aegis app, since the project originally exists solely to provide high‑quality icons for Aegis users. We also would plan to add Beem Development as contributors so that if anything happens, then the project can continue in an official capacity. They would not be expected to maintain or do anything, just it would simply ensure continuity.

🎯 Long‑Term Goal: Native Integration

The ideal end state would be for Aegis to include the icon pack natively. Aegis is intentionally designed to work fully offline — no syncing, no network dependency, no vendor lock‑in — and that’s one of its greatest strengths. Due to this, the app can’t fetch new icons dynamically.

However, in theory, Aegis could bundle the latest icon pack at compile time. This would keep the app offline‑first while ensuring users always have an up‑to‑date set of icons. It’s only an idea for now, but native support would make the ecosystem more cohesive and easier to maintain.

🏛️ Repository & Branding Alignment

If native integration becomes the direction we take, the next logical step would be to transfer the aegis-icons repository to the Beem Development GitHub organisation and ensure aegis icons maintainers can still contribute to the icon pack. This would make the project clearly visible as an official part of the Aegis ecosystem for new contributors and users.

The aegis-icons.github.io could also move under an official subdomain, such as https://icons.getaegis.app This would give users a clean, central place to explore available icons, fully aligned with the main Aegis website.

The Brand-assets would be transferred and updated to match Beem Development’s official style, ensuring consistency across the entire project.

The icon-set-lab may also get an update and maybe also transferred. This is however an internal tool that is designed to find inconsistencies within any icons.

Finally, misc would likely be in need of a clean-up beforehand. With some parts such as screenshots being transferred to other documentation and other parts being removed if they are outdated or no longer relevant.

🔧 Workflow & Contribution Model

Importantly, none of this would change the day‑to‑day workflow for contributors. Pull requests, icon submissions, and maintenance would continue exactly as they do now. The goal isn’t to restructure the project, but it’s simply to bring the project closer to the app it supports and make long‑term maintenance smoother.

These ideas are just a starting point, and nothing here is set in stone. I’d really appreciate hearing what others think — especially from krisu5 and the wider Aegis community.

If there are concerns, better approaches, or things I haven’t considered, I’m completely open to discussing them. The goal is simply to make the project more maintainable, and better aligned with the app it supports.

[krisu5]

The ideal end state would be for Aegis to include the icon pack natively. Aegis is intentionally designed to work fully offline — no syncing, no network dependency, no vendor lock‑in — and that’s one of its greatest strengths. Due to this, the app can’t fetch new icons dynamically.

However, in theory, Aegis could bundle the latest icon pack at compile time. This would keep the app offline‑first while ensuring users always have an up‑to‑date set of icons. It’s only an idea for now, but native support would make the ecosystem more cohesive and easier to maintain.

One thing to take consideration however in the future is that should we have external packs too or move away from that?

Even though we target Aegis users, Yubico started supporting Aegis icon packs for their Yubico Authenticator software. Based of analytics – that's now removed from the website – around 1/5 IIRC come to the aegis-icons website from Yubico Authenticator page. Just mentioning this, even though you didn't talk about ending of automatic release of external packs.

The icon-set-lab may also get an update and maybe also transferred. This is however an internal tool that is designed to find inconsistencies within any icons.

I can change icon-set-lab's ownership to my GitHub, if Beem wants to scrap it.

I don't have much else to say, vision seems good to me IMO. Sorry for taking so long to properly response to this.