[WIP][Proposal] make iOS bookmark show up without address bar

[tabacitu]

You can save a Backpack admin panel to your iOS/Android home screen. To use it just like it were a native app. The problem is, when you do that now:

• [ ] the icon isn't spectacular (working on a new logo!)
• [x] when you open it up, it still shows the address bar, so it still looks like a website, not an app

They say this is all you need to make the address bar go away. And there are definitely websites that have done this, like https://calisthenicsskills.com/

But I've just tried this, and at first test it doesn't hide the address bar. I must have done something wrong. But I'll put this here, maybe someone has an idea, has done this before. I'll get back to it when I have the time.

Cheers!

[promatik]

I'm not 100% sure about iOS, the Standard, and for Android we need to add a manifest.webmanifest; https://developer.mozilla.org/pt-PT/docs/Web/Manifest

[iMokhles]

for iOS it's very simple you have to add only one line in your head 😜

<meta name="apple-mobile-web-app-capable" content="yes" />

[iMokhles]

i forgot to mention it works for me like that i added it under the title

[tabacitu]

Thank you @iMokhles , <meta name="apple-mobile-web-app-capable" content="yes" /> did the trick! It now works for me on iOS and iPadOS 🥳

@promatik any chance to make it work on Android without a manifest file 🤞? Because the way I understand it, the manifest should contain the name of the project and such - so a stock one won't be good enough most of the time, the dev needs to customize it, which is one more step... We're in lockdown here in Martinique, so it'll be a few days until I meet someone with Android to test myself 🙄😂

Also - there's something we should keep in mind if we merge this PR. If we hide the address bar we also hide the back button. That should be fine for stock operations, they all provide a back button at the top. But... what about custom operations? What about custom screens? When you go to some custom page, if you don't have a back button, you have to use the menu... Is that good UX or bad UX? Are we improving it or worsening it? 😀

[scrutinizer-notifier]

The inspection completed: No new issues

[promatik]

Good point @tabacitu, that's not a problem on Android, but it is on Apple devices. Since backpack is ready for no back button, I think it should keep the full screen on iOS and developers should make sure every non stock page works that way too.

Regarding Android manifest, it is the standard way to create webapps (shortcuts for a webpage with multi resolution icons, splash screen, theme color, shortcut title ...) Apple still don't support it, but it's a W3C standard and I hope they will someday soon since they are delaying a new world of webapps developement 😂

Anyway, implementing the webmanifest on Backpack is ok I think, because it supports scopes, so there may be a manifest for the developer page/app, and another one for Backpack, scope: "/admin" Someone answers that on stackoverflow. As long as backpack references its manifest, with its details. it's ok.

[tabacitu]

Apple still don't support it, but it's a W3C standard and I hope they will someday soon since they are delaying a new world of webapps developement 😂

I wonder why they're stalling 🤣 It can't possibly be easy to part ways with the $$$ they're making off iOS apps 😄

Anyway, implementing the webmanifest on Backpack is ok I think, because it supports scopes, so there may be a manifest for the developer page/app, and another one for Backpack, scope: "/admin" Someone answers that on stackoverflow. As long as backpack references its manifest, with its details. it's ok.

Ok I understand, that's great. We still have a problem, though:

• the manifest.json file includes things like name, short_name and start_url;
• for each Backpack admin panel, those will be different, and most likely stored in PHP configs;
• that means as soon as the route_fix or app_name are changed, that manifest file will no longer be up-to-date;
• which means we can't create a general manifest file, that everybody can use under-the-hood, without doing anything; we can maybe create a general one, but developers will need customize it as soon as they change the route prefix for example; which is... not the best DX...

Of course, we could expose a route that returns a manifest file... So that admin/manifest.json points to a route, with a controller, that returns a composed JSON file. But I'm wondering... would that added complexity be worth it?... Wouldn't that added route in php artisan route:list be annoying? Not to mention it would be super difficult to change that manifest in the controller... We'd probably need to provide a fallback to a file that the dev can easily change. So if manifest.json exists, then no longer load route. Which... seems like a lot of workarounds for a simple manifest.json file...

So I guess what I'm saying is that... Maybe the best we can do is provide a stock manifest.json, that as soon as the app & admin panel are customized, will be rendered obsolete... and I don't like that... 😔 I'll think about it...

[promatik]

I agree with everything you mentioned.

Having a custom controller to generate the manifest, besides the complexity of it, is kinda heavy, because browsers always check this file on each page load. It would be fancy for sure, but maybe the stock manifest is better 😕 It will soon be obsolete, but anyway it's up to developer to update that file, the same way he updates other files.

TLDR; I'd choose the stock manifest solution, but I'm not fully happy with too 😅

[tabacitu]

Ok fine, let's go with a stock manifest.json file then... 😔 Can you please add one to this branch @promatik ? Please test that it works well in Android and copy-paste screenshots/videos here, I have no way to do that... 😀