What causes an iOS webapp to freeze on the startup screen? - ios

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.

Related

How to hide page zoom bar on iPad/iPhone with iOS 13

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

Disable caching for IOS PWA

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">

How do I remove the web address in a display:standalone IOS PWA?

I'm trying to set up a standalone PWA on ios and the web address still remains
I have included the following in the index.html
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="mobile-wep-app-capable" content="yes" />
And have
included
"display": "standalone"
in the site.webmanifest
The connection to our server is over https
Are there any other checklist items that need to be included to remove the url from displaying?
UPDATE - 14/05/19:
I believe the index.html and config was fine. I now believe this is an issue to do with routing
When you add a PWA to the homescreen in IOS it sets the entry URL to the PWA as the page you are currently on. In my case, when users first enter the app, they are at www.sitename.co.uk/login
and not at the root of the page
www.sitename.co.uk/
I stumbled across online that safari's full screen PWA apps will show the URL bar after a redirection to a different domain, to prevent phishing/ make the redirection clear to users.
I can only assume that, when you add the PWA, it adds the url as some sort of 'root' and when you try and navigate beneath the root it flags this up as unexpected behaviour
And causes this sort of behaviour
/login -> No URL
/ -> URL
/edit/resource -> URL
/login/resource -> No URL
This is annoying because
a) I would want the same PWA experience for a user regardless of what screen they added the app on
b) It would make far more sense to allow all routes on the domain of the PWA to be viewed without a URL.
maybe its a bit late for this, but you could try adding a scope attribute to your manifest. That way the address bar won't be shown on IOS as long as the host is the same specified in scope.
Check this out: https://developer.mozilla.org/en-US/docs/Web/Manifest/scope

Make a link that will open a new FULL SCREEN browser on iPad

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.

Are offline HTML5 apps possible in iOS 4.3.4?

I'm trying my hand at building an HTML5 driven offline app for my iPad 2 which has iOS 4.3.4. I followed instructions I've seen on several websites to a tee, and was even able to verify using Chrome's Developer Tools that the cache is working:
Creating Application Cache with manifest http://localhost/experiments/test.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 2) http://localhost/experiments/offlineApp.js
Application Cache Progress event (1 of 2) http://localhost/experiments/offlineApp.css
Application Cache Progress event (2 of 2)
Application Cache Cached event
I have a home screen icon as well as a "startup screen" image in play. I can download the app to the home screen just fine, and I see the icon there. However, when I have the Wi-Fi off and I try to open the app I get the dreaded " could not be opened because it is not connected to the Internet" alert.
Does anyone know if something changed in iOS 4.3.4 (or an earlier version of the OS) that changed the requirements to get this feature of HTML5 working?
Thanks!
Edit
I tried this again outside of a "localhost" setting. This is my HTML:
<!DOCTYPE html>
<html lang="en" manifest="/experiments/cache.manifest">
<head>
<meta charset="utf-8"/>
<title>cache.manifest test</title>
<link rel="stylesheet" href="cache-manifest-test.css"/>
<link rel="apple-touch-icon" href="icon.png"/>
</head>
<body>
<h1>cache.manifest</h1>
<p>Let's see if this thing works...</p>
<script src="cache-manifest-test.js"></script>
</body>
</html>
And this is my cache.manifest file's contents:
CACHE MANIFEST
cache-manifest-test.css
cache-manifest-test.js
I see the proper results in Chrome's developer tools. I get the "Application Cache Cached event." It just doesn't work offline. I'm really stumped here...
Does anyone know of any pages that have full blown code I could just copy to my server and try?
Thanks...
The messages you posted from Chrome are when the page is served from localhost.
Check that it works on Chrome using the server rather than localhost.
If it doesn't, check that you are serving the correct type (text/cache-manifest) for an appcache on the server.
If you're serving the correct type on localhost but not on the server, that would explain the different behavior.
Also, I've read that the file must be named "cache.manifest" on the iPad. If you have named it something else, try that.

Resources