Add PWA installability support for the Elastic skin

[andreiapostu]

Over the last few months I’ve been using Roundcube Webmail as my daily email client, both on desktop and mobile, and I’ve often wished it could be installable as a Progressive Web App. After looking into the topic, I found an older pull request (#9354) that attempted to introduce this feature. Looking into that PR, I realized that while the idea was excellent, the implementation had grown confusing and was never completed.

Because I believe this feature would bring real value to Roundcube users, I decided to start again from scratch and rebuild everything cleanly, keeping the scope small and focused.

---

Icon design and rationale

I designed two new icons for the PWA, one at 512×512 and one at 192×192.
In the previous PR, there were dozens of icon sizes for multiple platforms, which made replacing or customizing the logo unnecessarily complicated. My goal was to simplify maintenance while still meeting modern PWA requirements, so I limited the icon set to the two key dimensions recognized by Chrome, Firefox, and Safari.

I am open to discussion if the team prefers to reduce the set to a single image or extend it further, but I personally believe two prepared sizes are enough to ensure compatibility and crisp rendering across devices.

Both icons are PNGs created by placing the existing Roundcube SVG logo at the center of a solid background using the color #2f3a3f.
This color was taken directly from the Elastic theme styles at /skins/elastic/styles/colors.less#L41,
so that the icons visually match the identity and friendly aesthetic of Roundcube itself.

Regarding layout and spacing, I kept horizontal padding around 14% of the icon’s total width, inspired by the design recommendations from Android’s Adaptive Icon guidelines and Apple’s Human Interface Guidelines for app icons. I am not a professional designer, but I tried to create something simple and coherent Roundcube elastic design language.

Below are previews of the icon I rendered, along with screenshots of how it appears once installed on iOS homescreen.

---

Manifest details

Here is the manifest.json file added under skins/elastic/pwa/:

{
    "name": "Roundcube Webmail",
    "short_name": "Roundcube",
    "description": "Modern webmail for everyday use.",
    "start_url": "../../../",
    "scope": "../../../",
    "display": "standalone",
    "theme_color": "#2f3a3f",
    "background_color": "#2f3a3f",
    "icons": [
        {
            "src": "../images/icon-192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "../images/icon-512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ]
}

The start_url and scope fields may look unusual at first glance.
I chose "../../../" intentionally to ensure Roundcube remains installable regardless of its installation directory. Many users host Roundcube under paths such as /mail/, /rc/, or /webmail/, rather than at the root of their domain. Using relative paths ensures the manifest points to the application’s root and not to the skin’s internal folder. I’m open to suggestions on whether there might be a cleaner or more standardized way to achieve the same goal.

For theme_color and background_color, I used the same #2f3a3f tone mentioned above, again to stay consistent with the dark variant of the Elastic interface. However, this could be adjusted in the future to default to the light mode palette if the team prefers.

The manifest was placed in a new directory, skins/elastic/pwa/. For now, this directory only contains manifest.json, but it could later become the natural home for other PWA-related assets, such as a service worker.

---

About the service worker

I’m fully aware that offline access is a key capability of any complete PWA.
For now, this pull request focuses solely on making Roundcube installable, nothing more. Writing an effective service worker for Roundcube would require a deep understanding of its caching layers, authentication flow, and internal asset loading. That task is complex and deserves a dedicated discussion and its own separate pull request. My intention would be to build upon this foundation to continue improving PWA capabilities in the future.

---

Making and thinking about a PWA is not as easy as it might seem.
There are many small technical and UX details to get right, and I’m trying to think carefully about each of them. I truly believe that having Roundcube as a proper PWA would significantly improve the user experience for many people, especially those who use it daily on mobile devices.

I’ve done my best to start this process with a clean, minimal, and well-reasoned implementation, and I would be glad to refine it further with feedback from the maintainers.

[pabzm]

@andreiapostu Thank you for the contribution!

I would consider this a step forward and would be open to merging it. But I think @alecpl might more reserved, judging from the discussion in #9354, so I'd like to hear his opinion.

[alecpl]

We do have $config['product_name'] option. So, hardcoding 'Roundcube' here and in manifest.json is not the best solution. As for the application-name we could add it automatically from the code that generates meta tags. But we'll need some other solution for the manifest.json content.

I think that's my only complaint about this PR.

[pabzm]

Maybe we could introduce a make target that re-produces all relevant files from $config['product_name'] and mention that in the comment for this config option?

[alecpl]

That could work with files that don't exist in git, but if we keep them there a re-generation will create a change. So, it might be problematic for users doing deployment from git.

[pabzm]

That's right, but if someone does deployment from git, then I would expect them to be familiar with dealing with changed files. Don't you think so?

[johndoh]

IMO if this was a plugin rather than baked in then there could be something like a meta.json.dist file that gets distributed but a git ignored meta.json file in the same way we have config.inc.php.dist vs config.inc.php. Something similar shouls apply to the image folder I think so admins can define the logo with no risk of conflicts.

Also it means the solution is independent of skin which IMO it should be.

[pabzm]

if this was a plugin rather than baked in

I like that idea!