Recent Chrome/Android forces "install" instead of simple desktop shortcut

Developers
#1

Did we unintentionally introduce PWA compatibility for https hosted wikis in v5.3.8? I didn’t find any mentions of this in the changelogs for v5.3.8 or v5.3.7.
When using the “Add to home screen” option in a mobile browser (Chrome on Android) in tiddlywiki.com or one of my own wikis on Tiddlyhost, I now see the dialog to install it as a PWA:

Screenshot_20250923_081924_Chrome
Screenshot_20250923_081924_Chrome1080×1207 105 KB

In tw.com v5.3.7 and v5.3.6, it was only possible to add to home screen as a shortcut, not PWA:

Screenshot_20250923_082003_Chrome
Screenshot_20250923_082003_Chrome1080×1165 90.9 KB
Screenshot_20250923_082036_Chrome
Screenshot_20250923_082036_Chrome1080×1171 107 KB

If others can confirm this, I would consider this a regression. PWA compatibility is a nice thing to have out of the box (previously modifications like this or plugins were necessary to achieve it). But since there is no obvious way to turn it off, on some browsers it is impossible to create a shortcut to a wiki, which was possible with earlier versions. The simple shortcut has some advantages over PWA – e.g. it can lead to a specific sub-page, and makes using external links easier – there might be situations where user would choose shortcut over PWA.

Apparently it is possible to configure a website so that the user is given a choice between PWA and shortcut:

Screenshot_20250923_083018_Chrome
Screenshot_20250923_083018_Chrome986×538 104 KB

If this is possible in TW, this would be the best choice. Otherwise, I think we should go back to “shortcut only”, and allow to choose “PWA only” via custom modification or plugin.

Edit 2025-09-29: I think I was wrong to assume that v5.3.8 causes the issue. I’m seeing the same issue (unable to create simple desktop shortcut, forced to “install”) on my older wikis on Tiddlyhost. I now think that the issue is caused by Chrome/Android forcing the “install” for some sites without a manifest, and that the archived TW versions somehow avoid this (by having a different url structure?).

#2

This an interesting point as I have been experimenting with editing the index.html so the user has the option to install or add a shortcut. However, this is dependent on the browser (e.g. Chrome behaves differently to Brave) but it is also handled differently by Android and iOS. As well as changes to index.html you need a manifest, a service worker file and probably some icons too.

#3

I have dreamed of the ability to turn any single file wiki into a pwa for ease of adoption and deployment. primarily to solve saving issues and local access issues as a result I will have a look into this.

  • I can’t imagine how it would really be a pwa
#4

I might have been unclear. As far as I understand the “PWA compatibility” here is only the presence of a manifest that makes (some) browsers show the “install app” option instead of “create shortcut” option. It only changes how the website is displayed (PWA with reduced UI in a separate window vs. shortcut opening URL in a new normal browser tab), it doesn’t have anything to do with how the wiki is saved. At least this is what a simple modification like the linked one above can achieve, and something that could possibly get into the core without much effort and notice.

#5

If I’m not mistaken, there’s one other big difference. An installed app will run whether or not there’s connection to the server, whereas a shortcut will only work if the user can connect to the server.

#6

I think there might be a discrepancy in what is/deserves to be called a proper PWA (e.g. works offline), and what is the minimum requirement so that browsers will allow the “installation” of a PWA (with merely different UI than a normal bookmark/shortcut, maybe some changes to how long it is cached?).

In case of tw-com, “installing” it does not make it work offline. It works the same as this modification, merely providing a valid manifest, so that browsers display the “install” option.

#7

Interesting. Thank you. I had seen that thread and filed it away for “some day”, but had always assumed that if you created a manifest, you created a real offline app. Thinking about it again makes it clear that this was naive. You’d at a very minimum need to change to local storage to get anything to work. Thanks for the correction.

#8

Let’s keep in mind that except for following links tiddlywiki.com is a single file wiki and can be downloaded and operate off line as long as you have a working saver. When you do this you effectively fork the wiki and will not receive any further updates however it looks like an installed app.

#9

There is more to this PWA story. You also need a ‘service worker’, some js to handle things like caching of resources like images for offline use. Beware, there are some tutorials around but some seem to be AI generated text that copy half a story from elsewhere. I have found this one more comprehensive Progressive Web App Tutorial 2025: Service Worker Setup and Offline Functionality | Markaicode - AI Insights & Coding Excellence

The Dev Tools in Chrome is quite useful but beware many websites talk about Lighthouse having. PWA audit function. That now seems to be deprecated. However the Network and application tabs provide a good insight to what’s going on - and if you’ve got any errors.

#10

I dont know how to code service workers or connect to them via browser add ons but I can truely see a lot of features that assist with “Host/Desktop” intergration. I will read the tutorial, but doubt my script kiddy skills are enough. Of course adding features to keep them safe makes sense too, but there is plenty to do to lock it down, without breaking functionality like whitelists, a form of API key, limiting it to file:// wikis and other methods. The top requirements would be;

  • Open path in filemanger
  • Open path/file by association eg a word doc
  • Execute file/path given idealy full command line permitting parameters.
  • Create file in location with the following contents or “save as” to location stored in wiki but outside browser permissions.

I understand this was a feature for Timimi at one point.

#11

So I had added my node TW as a webapp to my iPhone through Safari. Originally did it ages ago, probably 5.3.7 or maybe even 5.3.6. As a test just now, I deleted that and re-added it. Same behavior, ie, I end up with a big “N” icon (my TW is called “NemoBrain”) and I got to call it whatever I wanted (it’s “NemoBrain”, but the default was the site title AND subtitle), and it happily loads everything over the network as needed (I dont get the splash screen, it’s just blank for a few seconds). Exactly as I’d have expected if it were a tab in a browser. The most irksome thing tbh is that the icon I’d have expected to see (the favicon.ico image, as listed in $:/SitePreviewUrl is ignored.

I mention all this to give context to the second test - I got a brand new Android phone today. So I did the equivalent thing - loaded the node URL in Chrome. The terminology talks about installing it as an app, but the practical result is the same as on the iPhone - it’s an icon on the home screen, which loads the TW over the network as needed. It’s default name was “Tiddlywiki”, which was a bit lame, but same as on the iPhone it was editable on install.

The biggest difference at a glance is that the android setup respects the icon for the phone home screen, and also shows it while the page is loading.

In short, for what I understand a PWA to be, this is not acting as that. It’s acting how I expected - a browser tab which the OS pretends is an app by hiding the normal browser widgets (technically called “chrome”, which Google co-opted for their browser name, thus adding to browser confusion everywhere!)

#12

The issue seems to come from Chrome/Android and not TW v5.3.8, and is only incidentally not seen in archival older TWs. See my edit of the initial post.