We have a webapp that we add to the home screen from Safari. It's built with Ionic /Angular. Now whenever we switch to another page within the app, the white bar at the top appears where you can change the page zoom and access other settings (change between mobile and desktop website and access further website settings). It's covering part of the webapp and does away when you click on "Done" on the left side - until you access another page, then it re-appears. It's the same behaviour on iPad and iPhone, iOS 13.1 and 13.2 (beta).
Is there a way to prevent this from appearing?
The webapp has set the following meta tags, among others:
<meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<meta name="apple-mobile-web-app-title" content="MyWebApp">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
If the new page that you’re opening is from a different website, such as an oAuth login, I don’t think you can fix this issue yet.
However, if the new page is on the same domain, you can simply adjust your app’s scope in your web app manifest. If you don’t already have a manifest, it looks like this:
{
"name": "My web app",
"short_name": "Web App",
"description": "This is a web app",
"lang": "en-GB",
"start_url": "/app/home.html",
"scope": "/app/",
"display": "standalone"
}
That scope item means that all files, and pages, in the app directory will work in your PWA like a normal native app (ie. no popup windows). All files outside this scope will open in the normal web browser, with a back button to your PWA. It’s not ideal but it does give a much better UX than before. You can read more about the scope setting here.
I would recommend using a manifest.json generator like this one, just because they make this process so much easier. You’ll find the scope setting under the ‘start url’ box in this example.
I have the same problem... I have only been able to find a solution to remove the word "Done" from the left side of toolbar.
change any redirects from location.href='yourUrl' to location.replace('yourUrl') and it should remove the word "Done"
I cannot take credit, and I cannot find the post where i learned this.
It actually stopped the redirection out of the web-app which is a good first step. I will continue to look for a way to remove that URL bar...
Hope this helps
Related
Our website works in harmony with mobile website. That's meta tag
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=6.0" />
In order to facilitate the access of our website, we have given instructions to our customers to add them to the home screen.
However, our site, which is added to the home screen by IOS, is opened in the form of an application, not a website. Our customers want to zoom and scale through the website. These operations cannot be performed because the page is opened like an application on IOS.
Anyone have an opinion on this topic? Thanks
I built a Todo App in Ruby on Rails (With a Passenger and Nginx), i used this app as a PWA with apple-mobile-web-app-capable and apple-touch-fullscreen meta tags on my iPhone (IOS 12.3.1). When I create tasks via the browser and switch back to the PWA, they are not displayed. If i close the app very often or wait a long time, they will be displayed in the PWA. I think IOS cached the Web-page. My question is how can I disable caching for the page ? I've already tried the following meta tags, they did not work. Does anybody know how to fix this?
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="pragma" content="no-cache">
I am trying to set up App Links so that:
a) When I tap on a link on the Facebook app, it opens my app if installed
b) If not installed, Facebook should not prompt the user to be directed to the App Store, and instead open the link in the in-app browser
I have been experimenting with the al:web:should_fallback meta tag, but there have been some mixed results:
When al:web:should_fallback is set to false, scenario a) as above works correctly, as expected. Scenario b) is not fulfilled, as expected, because I've indicated that the system should not fall back to the web.
However, when setting al:web:should_fallback is set to true, even though the app is installed, scenario a) no longer works.
Why is this? I am under the impression that al:web:should_fallback controls scenarios for when the target app is not installed
Some setup details:
My website's meta tags are as follows (Actual values replaced by "_"):
<meta property="al:ios:app_store_id" content="_" />
<meta property="al:ios:app_name" content="_" />
<meta property="al:ios:url" content="_://_" />
There are no outstanding warnings on the OG Debugger
There is only one warning on the App Ads Helper, and this relates to Deferred Deep Linking, which according to the App Links iOS documentation, is no longer supported
Any insight would be greatly appreciated!
I developed an HTML5 webapp, and so far my local server tests worked fine (running in the desktop browser, iOS Safari browser, and homescreen bookmark webapp). This also holds true for the offline use (with the cache.manifest file).
When I uploaded the files to my website, I tested to confirm it still works on the desktop (Chrome shows the Application Cache logs), also works in iOS Safari. Both online and offline.
The Problem
When I bookmark the page from my website as a homescreen icon and try to launch it from there, the webapp freezes on the startup image.
What could be causing this particular issue?
Checklist:
HTML tag contains: <html manifest="cache.manifest">
HTML does contain: <meta name="apple-mobile-web-app-capable" content="yes">
HTML does contain: <meta name="apple-mobile-web-app-status-bar-style" content="black">
Not sure this would matter but: <meta name="viewport" content="width=1024, minimal-ui, user-scalable=no">
The apple-touch-startup-image and apple-touch-icon link tags are appended dynamically to the <head> tag via Javascript.
Only the necessary file-names in cache.manifest are included.
The webhost supports the manifest mimeType (no need to change .htaccess).
The website does use an .htaccess password authentication setting.
NOTE: I will investigate whether or not my use of apple-touch-startup-image & apple-touch-icon dynamically appended with jQuery could be the issue here.
It dawned on me once I listed the .htaccess password authentication bit in the checklist above.
It seems iOS's chromeless browser cannot initiate a username & password prompt at startup.
Sure enough, allowing full access to the page resolved the issue for the homescreen app. To do so, I've included this in a separate .htaccess file in the same directory the webapp is placed in:
Satisfy Any
That's it!
Although I'm not very fond of this solution, then again I wouldn't want to enter a username & password everytime I launch the webapp.
Is there anyway that I can create a link that when clicked on an ipad, it will open in a new full screen window (no address bar/tabs/etc)?
At the moment, the only way that I am aware of to open a page in safari without the safari chrome(address bar/tabs/etc) is to add the <meta> tag following to the <head> element in the source.
<meta name="apple-mobile-web-app-capable" content="yes">
Note that for this to work, the user must bookmark the page on their home screen. Apple provides a number of other meta tags as well that can add a 'native app' look and feel to the user's experience. All of which can be found in the documentation.