Ability to dynamically change app icon

[mgiuca]

Every time we build an app platform, we get this feature request with approximately one use case: letting calendar apps show the current date in the calendar icon, rather than a generic icon with the wrong date.

While web apps can change their favicon dynamically (e.g., Google Calendar does this with its favicon), there is no way to programmatically change the manifest icon, which is used by platforms as the "shelf" or system icon.

I wonder if this is feasible. Potential problems are:

• Spoofing (an app could change its icon dynamically to look like another popular app, and the user would not be explicitly told that the app icon is changing).
• Use of the feature to create a "badge" (e.g., unread count). Potentially useful, but I think we want a separate badge feature so it can show a badge in a manner consistent with the host OS. (This is something we're separately discussing.)
• Fairly limited use case. Nothing really, other than a calendar app, has a use for this. (We had an open feature request on this for Chrome Apps platform for years and nobody suggested any other use case.)

[marcoscaceres]

Yeah, the last point is why I concluded we should not do this initially. There are a limited set of apps (also clock).

WRT badge, that should be a different "Badge" or "Tasks" API.

And, yeah spoofing is a concern. Alternative: https://github.com/w3c/manifest/issues/446#issuecomment-206112421

[marcoscaceres]

(I think this is basically a duplicate of #446)

[marcoscaceres]

I mean 446... updated above.

[mgiuca]

I think this is a bit different to #446. That is really about updating the manifest (because the site has updated) and pushing out the update in a timely fashion. Solutions discussed there include notifying the user when the icon changes so they can confirm it is not a spoof.

Whereas this is about dynamically setting the icon (not title) on a regular basis (once daily or more frequently), where notifying the user wouldn't be acceptable.

[marcoscaceres]

Yeah, true. The idea of allowing random apps to update their icons quickly is not something I think anyone would want to allow... heh.... I can just imagine it :)

(THIS IS THE WEB WE WANT!)

[mgiuca]

Is this real? Where is this from? (Or did you spend all afternoon animating those icons to reify your imagination.)

[marcoscaceres]

Found it on https://giphy.com ... where the internets is beautiful.

[patrickkettner]

FWIW, IE had a meta tag called msapplication-notification, which you would give 1-5 endpoints that could provide data used in the live tile, and it would poll on a provided number of minutes. It seemed to strike a nice balance between accurate/useful icons and not the animation nightmare marcos posted :D Perhaps a event that is fired N minutes inside of the SW could allow folks to update content when needed?

[js-choi]

For what it’s worth, weather applications may be another use case. Rather than displaying a potentially misleading ☀️or 🌤 all the time, a weather application could show ⛈, ❄️, or whatever, depending on current conditions.

Clock applications have already been mentioned but are worth pointing at again. A clock icon that always shows 1:30 pm 🕜 would merely seem unpolished at best, but it may actually mislead the user at worst.

Basically, anything with an app icon that already depicts some state would benefit from updatable app icons.

[marcoscaceres]

Notifications should really be going through the Notifications API.

[bschoepke]

@marcoscaceres yea, at least on Windows, tiles use push notifications to update (which can have image payloads), so PWA's using the Notifications API could get the same treatment.

[mgiuca]

Note: I've put up a proposal for a Badging API, allowing some text or number to be displayed over the icon. This somewhat satisfies this case.

https://github.com/mgiuca/badging/blob/master/explainer.md

[jerrygreen]

@marcoscaceres well, in earlier internet gifs were allowed, and we've seen such a similar thing you've shared, on the internet, where gifs were abused. But it's all about how people will use instruments, and about the community, not about limitations. Look, here, on github, gifs are allowed. And it's quite beatufil, - I may see this good feedback you've shared. I, personally, use gif recordings to better indicate some bugs while developing my apps, and make issues with these recordings.

So I think it should not be a limitation, for PWA, to dynamically change app icon. The topic isn't about a constant circular animations like it's (mostly) in your gif. It's more about some logic.

Look at your image again. Notice a little humble calendar app?

It does change icon dynamically, every day. But still, - it's pretty much static.

For some sort of apps, like calendar, it may be quite useful, to be able to change their icon, to place some very limited but useful data. For calendar, - it's the number of the day. For some other apps it may be just some binary output, which depends on something complex. So it's not about animation but it's about very limited data output.

"some binary output, which depends on something" - that's exactly my case. That's how I've gotten here. I was thinking about some similar logic to the calendar app. And was wondering if PWA may let me do this. I don't really want getting into native development just for this little thing. But it could be quite nice to have such an ability for PWA, then I would probably turn my little pet web app into PWA.

In order to prevent obusing it should be probably being able to setting up. Like notifications for app. Same with dynamic icon change (which will be mostly useless because I believe people won't abuse it now, it's not 2005).

[NotWoods]

@JerryGreen If you want to display a binary output, could the Badging API work for you? It would also be helpful if you could give some examples of your use case. 😃

[mgiuca]

@JerryGreen Yeah, I agree it would be nice for calendar, but see my original post at the top of this thread. Calendar apps are pretty much the only use case we've had requesting this feature (other than those that are better suited to using the Badging API), over a period of about a decade. If that continues to be the only viable use case, I don't think it's worth the complexity of having this available.

[jerrygreen]

@NotWoods @mgiuca let me picture out my case...

In many universities and colleges, at least in Russia (not sure about other countries) it's normal to have part of your schedule to be determined by that fact if the week is even or odd. There are some weird rules how numbers of weeks are determined (ISO 8601). Often students forget what's the next week is (or previous was), especially after some holidays. So then I've created a little website showing the current week's status:

https://chiliz.ru

It simply prints "Числитель" or "Знаменатель", which means if the week is even or odd, accordingly. It has some logo:

^{(remind something?)}

So it has only two states and changes once a week (binary data). So this idea of dynamic icon change fits quite naturally here. For example, it may change between two icons like these (quickly created it just now just to demonstrate the idea):

Yes, again, it has something to do with dates, like calendar, though it's not a calendar. I believe there may be cases for other people, when it's determined by something else than dates, so it's not just "calendar use case", for example... Some home app indicating if anybody's home. For "Stocks" app it may indicate binary data of your positions - are they growing or failing, by stats of the last day or week... For calendar apps it's just that crucial, very important feature. But useful for other use-cases too.

^{P.S. Btw, I don't study, I've completed college several years ago (still learning though) P.P.S. «Числитель или Знаменатель» pronounced like: «chislitel' ili zhnamenatel'», short acronym is «chiliz»}

[mgiuca]

@JerryGreen I guess that fits into the calendar use case (technically what you're writing is a calendar, really?). I agree this would be useful, I'm just not sure if this one use case is enough to justify dynamic icons.

Could you use the Badging API to display a "4" or a "3" on the icon in a small circle? Would that be sufficient?

Edit: Yeah a stock ticker type of display might be another use case here. I guess we have to ask ourselves if we want to allow app icons to act as a sort of "mini window" for displaying information, or if that's just not a use case we want to be involved with.

[jerrygreen]

@mgiuca not really a calendar, though it could be some sort of a plugin for a calendar.

Badges will look very weird for this use case. With the calendar example, it's like showing a day with a badge. Same here. Badges are for "new" info, some updates. But this is not an update here. Just showing some state, not updates.

My reasoning here, if something is possible with native app, then it should be possible with PWA too.

[mgiuca]

My reasoning here, if something is possible with native app, then it should be possible with PWA too.

Unfortunately, that can't be strictly true, since a) security considerations are much higher on the web (which doesn't really apply here, though there are spoofing concerns), and b) we have to prioritize features based on what will be the most useful for developers. In an ideal world, I think we'd have this, but it still feels quite niche.

I think we can do it, but it will likely be a low priority.

[wwwonka]

Hmm, greetings, sorry to jump in.. So this is not achievable? I am just an enthusiast building a game as a PWA. In my game I have 5 worlds, each of which have a distinguishable color palette I was thinking of dynamically changing the icon to make it fit accordingly with the progress of my player.

Basically, from whichever world you leave the game, the icon fits, as if you still had a window opened to this world from your home screen.

Not sure how legit is this use case for you, but I felt like sharing.

[mgiuca]

Currently, no, it is not feasible.

I think there are two separate use cases:

1. Long-term permanent icon changes (e.g. a rebranding).
2. Day-to-day changes, such as a calendar, or the video game icon changing as @wwwonka suggested (haven't heard that one before!)

The challenge is spoofing. We don't want an app to suddenly change its name to the Facebook "f" and then ask you to log in to Facebook and steal your credentials.

I think #1 we want to support. We don't want businesses to be stuck on their old icon. But we'll likely need to recommend some UI that the user agent shows to ask the user if they are OK with the icon changing (so if you attempt to change an app icon to a known brand, the user knows something is funny).

2 unfortunately, I'm not sure how we can support apps subtly changing their icon regularly without exposing ourselves to the security problem.

[vincentmorneau]

I'm surprised there hasn't been more activity here since 2020. Rebranding a PWA is basically impossible now due to the inability to update icons dynamically. No one wants to ask their users to uninstall the PWA and reinstall it.

Chrome currently prompts the user when the manifest name changes and asks for explicit confirmation. Could it not be similar for icons?

How can we help moving this forward?

[vincentmorneau]

Not sure when this was added, but chrome://flags/ has

Enable PWA install update dialog for icon changes Enable a confirmation dialog that shows up when a PWA changes its icon – Mac, Windows, Linux, ChromeOS, Android, Fuchsia, Lacros

#pwa-update-dialog-for-icon

Which is disabled by default. When enabled, it triggers the same behavior as my screenshot from the previous post and asks for icon change confirmation.

[jerrygreen]

Chrome flag is cool but personally I don’t feel the need for PWA on desktop in overall, though I don’t complain. On mobile platforms, on the other hand, that’s where I want this feature and many other features that a native application already has, like updating badges via notifications and silent badges update, most notably.

Crossing fingers all those badges&icons features will be available on mobile platforms someday, hopefully sooner than later.

[mgiuca]

@vincentmorneau You're right, Chrome is working on a solution to let apps permanently rebrand (prompting when the app icon changes). That fits use case #1 from my previous post in 2020.

However, that use case is really outside the scope of the spec, as it's something that individual browsers can do when they notice the icon changed.

Only use case #2 (dynamically changing the icon with a live API with no prompt) is something we can introduce at the spec level, and I think as discussed previously, it isn't feasible from a security standpoint. Therefore I'm going to close this issue with "won't fix".

(That doesn't mean we won't support use case #1 - that is coming at least in Chrome, but it's outside the scope of the spec which is what this repo is about.)

[jerrygreen]

dynamically changing the icon with a live API with no prompt… it isn't feasible from a security standpoint

Wrong. If it’s a security hole, why native applications on Android & iOS can do change their icons dynamically?

[mgiuca]

If it’s a security hole, why native applications on Android & iOS can do change their icons dynamically?

The Web platform (including the installable apps side of it) generally holds itself to a higher security standard than native apps on Android or iOS. There are a lot of APIs that are missing or neutered on the web compared to the native Android or iOS counterparts, not because we don't want them, but because of the high security bar.

A big reason for this is that on Android or iOS, apps are installed through a store, and can be remotely taken down by the store owner if they do bad things. On the Web, apps are installed by a private decision between the user and the site operator. The browser manufacturer does not act in a policing role (other than maybe safe browsing protections for automated detection of egregious spoofing - but we don't rely on that due to defense-in-depth). So we need to have a higher degree of security built in to the platform, which in many cases means limiting the capabilities of the platform.

It's all about what is the utility of the capability (what new types of experiences does it unlock) versus the potential for harm. In the case of an API that lets you dynamically change your icon, there is a great potential for harm (install a harmless-looking app, which then changes its icon without you noticing to your bank icon, you click it, and it spoofs your bank), versus a fairly minimal benefit (Calendar and Clock apps can show the correct date/time - it doesn't unlock any new experiences).

[dmurph]

Closing the loop here a bit - we discussed this in TPAC this year and came up with a good solution for icon updating: https://www.w3.org/2022/09/13-webapps-minutes.html

We are planning on implementing this new update mechanism in desktop Chromium this year & an explainer so folks can play around with it & confirm it works for their usecases. I'll update this thread when we have an explainer.

[silasabbott]

Will this cover the use case where an app offers multiple icon designs and the user can explicitly click/tap to change the app icon?

[marcoscaceres]

There are cases where an application may offer the user the option to update the icon, but without requiring an entire manifest update.

Otherwise, it would mean that a site would need to track/generate specific versions of a manifest for each user. I'm wondering if it should be possible to somehow update an icon dynamically without needing to update the manifest itself?

(so yeah, basically what @silasabbott asked 😅)

[aetinx]

An idea is that PWAs could propagate an icon update via service worker, but with a cooldown of a couple seconds or minutes to avoid "moving images".

Another idea is instead of just propagating an icon update, service workers could have to whole manifest update, removing the need to prompt for a name update or have icons be generated on a server.

For example, in a calendar app, you could have icons stored at /path/{dayOfTheMonthGoesHere}.png, and every day the path(s) for the icon in the manifest would change.

OR, even better perhaps, you could manually change the icon right from a service worker, overriding what a manifest says.

[bockmurat]

Hi sorry for jumping in aswell, not sure if this is still needed when it's already worked on. But another use case would be any app where some kind of tracking is used. (For example: tasks, calories, glasses of water, prayer times (or next prayer), current stage in menstruation cycle)

Yes, a counter in a badge could be a solution, but not the most user friendly. -> I think it would be practical as replacement of any widget. Takes less space and users don't have to open the app for the information they need.

I understand the concerns, but what if the user gets a prompt which initially informs the user of constant updates in the image (+ reason by creator) and the potential risks. While also not allowing to change image and name at the same time (at least without being informed again, via prompt)

Also sorry for being uninformed, is there a way to contribute? I've already built the solution for my PWA, to then find out it's not supported 😅

[silasabbott]

I do see a lot of potential for abuse with dynamically-updating icons, however.

• Dynamically changing the app icon on a schedule has some good use cases and could be used to improve the user experience for some apps
• It could also be used to cause a lot of confusion for the user if used improperly (like when each icon is drastically different from the last)
• Even if the user opts-in once to the icon changing periodically, someone could still easily trick the user by changing the icon to a banking app at any point in time after gaining that consent
• A PWA could gain consent initially, and then be sold to a malicious party that would suddenly change the icon to something else

Unless we can figure out a simple way to avoid this, I don't think the tradeoffs would be worth it being able to frequently change the icon continuously. The browser might need to detect how much the icon has changed from the original, rejecting icon changes over a certain threshold—and that's probably not realistic.

With a one-time icon change however, we can prevent abuse by having the browser confirm the change with the user through a dialog or explicit action each time a PWA requests to change it. I think this is how Apple does it with their native apps.

[jerrygreen]

No, Apple doesn’t ask user each time a native app wants to change an icon. I often seen icon change for Christmas / New Year, that’s some small changes but kinda cool, making holiday atmosphere. It wouldn’t make any sense changing it if it requires some checks from user. Some other apps, like if stock is green/red, might change every hour – and it would also make zero sense asking for change each time.

On such platforms like Apple there’s one thing: if an app gets reported for malicious use, it’s probably delivers some notification for other users before they launch it, for known malicious use – if it’s minor. And probably blocks completely if it’s something big. Never seen any app tried to do such malicious stuff though. Probably the potential attacker knows this fact, therefore they don’t even try to do such malicious activity.

It is interesting though, how would Apple solve this issue for native apps when they installed outside of their store – since it’s allowed to use outside stores in EU now, and probably more countries to come. I mean, Apple not gonna review every single website, like even those which aren’t in a single way related to Apple, right? Same with Google or whatever company. So the way Apple does the regulation for their app store, – cannot fit for the web use-case. There can’t be just single party responsible for regulation for PWA.

It’s probably solvable with some decentralized system, where if one person reports it, the notice propagates to other people directly without third-parties, and if they confirm – it propagates to more and even more people, until all users of such PWA confirm that. Similar to Bitcoin mining but it’s not the CPU making a confirmation, instead a human does. Something like that. And on the other hand, if a user does a false-report, it does propagate to a couple people but since they don’t confirm, it doesn’t propagate any more. Not sure about exact details though, since I never done such a system.

[aetinx]

I do see a lot of potential for abuse with dynamically-updating icons, however.

This is almost like getting mad because websites can change their favicon and