I have made an angular + workbox application that now is converted using PWABuilder to Cordova project targeting ios platform.
Now my problem started with offline page, I want my application to work the same way it works on chrome browser with offline mode.
That is, even if I'm in offline mode, I'm able to use website and store the requests for later on.
But on IOS device, when I open application, then turn airplane mode or disconnect wifi and re-run an app a white screen appears. (Offline page support is disabled in manifest.js - I don't need Offline.html)
I have registered routing by
workbox.routing.registerNavigationRoute('/');
And then
// couple of following lines:
workbox.routing.registerRoute('regex with js,manifest...etc', networkFirstStrategy({cacheName} ...)
And the weird fact is that on ios this somehow can't be cached, or somethings different happens.
I'm waiting for any suggestions, or leads that can help me fix this behaviour.
Answer
The WebView as used by Cordova in the latest iOS (12.0.1) will not run Workbox because it doesn't support Service Workers.
Details
Cordova apps run in a WebView.
The app executes in a WebView within the native application wrapper... source
The WebView in the latest production iOS (12.0.1) only supports Service Workers within three specific contexts, which doesn't include Cordova apps.
At this time [the Service Worker API] is only available in Safari, applications that use SFSafariViewController, and web applications saved to your home screen. source
Next Steps
It may be possible to add Service Worker support via a Cordova Plugin. For example: cordova-plugin-service-worker.
In addition, you may also need to add Background Sync support as the latest Safari does not support Background Sync. For example: cordova-plugin-service-worker-background-sync.
The Workbox docs state that they provide a fallback strategy when Background Sync is not supported:
Workbox Background Sync...also implements a fallback strategy for browsers that
don't yet implement BackgroundSync. source
However, an open issue on Github shows that the fallback strategy may not work on iOS.
We are experiencing a pwa application with services worker and everything that surrounds this theme.
I have questions about cache. Information is currently cached and accessed when offline. This works well when we talk about Android. In IOS it seems that the cache is not shared when we add the application to the home screen (installed). It seems that IOS keeps a cache for the application accessed in Safari and the installed one (I'm talking about the same application). In android it seems that the same cache is shared for the version installed and accessed in chrome.
In IOS after adding the home screen I am forced to log in online to generate the installed application cache.
About IOS would you like to know if you have already gone through this? And what would be the best way to persist this data so that the same cache is shared in the application accessed in Safari and the installed version.
In the service worker you mention the name of the cache, until and unless you change it there or update it e.g;
const staticCacheName = 'pages-cache-v3'; it will remain same and will be shared among versions. This may be true for the Android am not sure about IOS. Please update me if you have already found a better answer. Cheers:)
If this is still relevant, then I think that you should look at my answer in this question, because you are faced with the same problem.
PWAs on iOS 12 no longer shares Service Worker cache with Safari?
I have a PWA that I've been using perfectly till I updated my phone to 11.3 (introduce Service Workers supports, so in my iPhone it was only a bookmark) and all worked like a charm.
After I've updated to iOS 11.3 I wasn't able to enter to my app because I have an external login (in other domain) so each time I try to open my open this will open a safari browser to make the auth. Before PWA in iOS the external URLs were open in the same open (without open safari). Do you know if this is the correct behavior and, if it is ok, how can I fix it?
Thanks!
I managed to fix this by removing the manifest meta tag:
<link rel="manifest" href="/tracker/site.webmanifest">
My project is a simple PWA that uses Google's OAuth for login. I was getting redirected to Safari to login and unable to go back to the app (on my home screen). Hope it works for you too, I wasted 2 days trying to find a solution.
The reply by Anand tells me that offline capable PWAs need to implement service workers, since they are supported in 11.3 (or 11.4, not sure) and NOT manifests.
Anyways, this worked for me, hope it helps others as well.
When PWAs without service works(either your browser don't support it or your app don't have one) are added to home screen, its mere a bookmark. When the browser finds a SW, then it creates a package(like apk).
How to test this - Find a PWA site without service worker in android and add to home screen. When I tried it in one of Samsung device, it showed only "Remove" option and no uninstall option. When I added a PWA which had SW, got uninstall option. I was also able to locate the apk generated by Chrome when service worker is present.
Now on iOS - 3 possibilities I could think of.
1) My theory based on above behavior on PWAs with and without Service worker, your home icon create by iOS 11.2.x is a bookmark and the new version of safari is treating it as a bookmark to open it in browser. I couldn't test this as I've upgraded to 11.3 already and don't have a pre 11.3 PWA icon.
2) If you have reinstalled the icon(by removing and adding again to home screen) and still have the issue, its probably because your manifest file or service worker files have some issue/compatibility with Safari.
Since we don't have something like Lighthouse for safari, you can validate your manifest.json and service workers in Chrome Lighthouse.
3) Check on scope attribute in the manifest file to make sure you cover your entire domain you intent to cover. If you scope covers domain.com/myapp only, domain.com/otherapp will be opened in the browser when tried to open from any source.
It seems that with the last iOS version 11.4 this issue is solved, I think that now safari shares the context between the browser and the PWA and for example from PWA cookies can be accessed throw safari.
But I think there's still an issue when you open the PWA and you are being redirect to login (safari opens) once you're log in you stay in the browser (iOS does not return to the PWA, but this is a first step)
I want to test my website on Safari on my iPad. I only have another PC. Is there a way for me to do remote debugging like ADB (Android Debug Bridge) with mobile Chrome? I searched on StackOverflow, seems there is an Adobe Edge Inspect CC, but I don't know if this is a good choice.
Thanks!
Update October 2019
This solution doesn't work for IOS 12+ (resource 1, resource 2).
Updated and tested on 24/6/2017
Using Chrome on Windows 8 and more recent:
Download and install Node
Download and install ITunes and connect it to your Device. (A pop-up should shows to your iPad to get authorization)
. Be sure to allow web inspector in your iPad
Download and install the remote webkit adapter
Using Powershell (As administrator):
npm install remotedebug-ios-webkit-adapter -g
Execute the adapter:
Using Powershell (as administrator):
remotedebug_ios_webkit_adapter --port=9000
You should get a similar output:
C:\Windows\system32> remotedebug_ios_webkit_adapter --port=9000
remotedebug-ios-webkit-adapter is listening on port 9000
iosAdapter.getTargets
...
Open Chrome and go to the following link:
chrome://inspect/#devices
Click on configure next to "Discover network targets" and add the following:
localhost:9000
Make sure to have the web page you want debug open on safari, you should see it on chrome inspector page under Remote Target
Extra step for iOS 11 Thanks to #skaurus
See monkeythedev's answer for the easiest way to debug on a Windows 8+ machine with iOS 9+. I updated my blog post using information from that answer and other sources and also recorded a screenshare. The method below should still work for iOS 8 and down, if needed.
There is actually a pretty easy way to debug a website in Safari on iOS using Firefox on a Windows machine.
NOTE: Ryan wrote in the comments below that this may only work on iOS 8 and down. I am unable to confirm, but be aware.
I wrote a detailed blog post about this, but here are the highlights:
Install iTunes to get the "Apple Mobile Device Support" and "Apple Application Support" applications that come with it. (uninstall iTunes afterward, if you want)
Connect your iOS device via USB.
Enable web inspector on iOS (available on iOS 6 and later).
Open Safari on your iOS device and browse to a website.
Open Firefox on your Windows machine and press Shift + F8 to open WebIDE, which should include the necessary Valance add-on, if you use Firefox Developer Edition (any version) or Firefox 37 and later (any channel).
For some reason, I couldn't get it to connect to my iOS device until I downloaded the ios-webkit-debug-proxy-win32 program and ran it. It opens a blank Command Prompt, but after I went back to WebIDE after opening it, I disconnected, then reconnected, and I saw debug info for the website I had opened in Safari. You may not need to do this though, as another user just had to add an exception to their firewall then disconnect/reconnect, and it worked.
The debug info available isn't as exhaustive as Chrome Developer Tools (specifically no "Networking" tab), but it was enough for me to be able to view what was going on in the Console.
2018 Update:
Since the original post, the blog post is dead & Telerik App Builder is discontinued and no longer offered. Adding this update to inform readers in case they don't read the user comments that follow this answer post. As for the blog post, for those still interested, here's a web cached copy. Regarding the blog, I think the company that blog's from has since shut down.
When I get a chance, I'll see if I have a copy of the app builder saved so that I can post it online for those still interested in using it, along with another cached copy of the blog post maybe.
Original Answer
You can try option of using Telerik AppBuilder (Windows client) as a replacement on Windows for Safari debugger on Mac when remote debugging. There's a nice blog post about the steps to do it in link below. I'd rather not repost the info as there are also screenshots and it's a lot of text. But essentially, you install app, open it, connect device via USB, then you can find it in the app and open up the developer tools/debugger for it. For non-public websites, you'll have to open up port 80 with some firewall configs documented in the post.
http://blog.falafel.com/Blogs/josh-eastburn/2014/03/04/ios-web-inspector-on-windows-with-telerik-appbuilder
The tool requires a license or you can use the trial, which becomes a basic edition afterwards. I think the basic edition will still allow you to do the debugging. I'm going to try it out myself.
You can also try these iOS apps too, you can find them in the iTunes App store. They give you a built in developer tools feature (right on iOS no remote debug) that mobile Safari doesn't offer.
MIH Tool - basic edition
https://itunes.apple.com/us/app/mihtool/id584739126?ls=1&mt=8
HTTPWatch Basic
https://itunes.apple.com/us/app/httpwatch-basic-http-sniffer/id658886056?mt=8
I gave them a try and they're at least better than the mobile Safari you get on iOS, unless one needs to target full mobile Safari compatibility. I'm guessing the pro/paid editions of those apps give you more/better features.
This question was more than 4 years ago, but I feel like it's worth to mention another option which is platform-independent which seems is not mentioned above:
VConsole
It's a JavaScript that you can inject into your page(s) which will overwrite all native console output and show it as an overlay on top of your page content, in a level of detail that is almost as good as Google Chrome's Developer Tools.
Runs well on iOS Safari, as well as on other mobile browsers - for as long as JavaScript is enabled in the browser.
How to install: https://www.npmjs.com/package/vconsole
You will need NPM tools to install it, but not actually required to use NPM to build your project. You can simply install VConsole somewhere in a separate folder, and just copy-paste vconsole.min.js from it.
Once you inject it into your page, will look like this:
<script type="text/javascript" src="vconsole.min.js"></script>
<script type="text/javascript>let vc = new VConsole(); // this will initialize it.</script>
Visually is very appealing, you will see green button in lower-right corner of your page on your mobile/desktop browser, which will open console overlay.
Very neat!
Of course, it does not provide you with ability to select an element, see calculated css etc., but if you are looking for console output and some network report, this one is really easy to use.
October 2019
AFAIK, For recent IOS versions there is no overall solution for debugging IOS from a PC.
You can however use one of the following solutions:
Display console messages in the browser itself. As described here and in Sinisa's answer.
The "remotedebug-ios-webkit-adapter" doesn't work for debugging IOS 12+. It requires extra steps for IOS 11, and works for IOS 10 and perhaps older versions as well.
I use PrePros for CSS preprocessing and it has a built in server for mobile debugging and web inspector. But this is only good for local sites even still...
In my experience it is often not an issue with mobile Safari only but Safari in general. In these cases it can help to try the normal Safari (for Windows) and see if the bugs appear there. If so, it's much easier to debug something by this way.
2021 update:
The creator of RemoteDebug here. I've built a replacement for RemoteDebug called Inspect, which packages everything together in a pleasant experience and enables easy iOS web debugging from Windows, macOS, and Linux, with a few extra features like screencasting and wifi debugging.
http://inspect.dev
There are a couple of options I've come across for debugging on iOS. They're not full step-through debuggers, but they offer a JS error log, console and some inspection tools:
1. Eruda
By adding the following snippet to the top of your page:
<script src="https://cdn.jsdelivr.net/npm/eruda"></script>
<script>eruda.init();</script>
You get an interactive set of developer tools similar to those in Chrome and Firefox. Here's a screenshot:
Available at https://github.com/liriliri/eruda
2. MiniConsole
This one I developed myself when I had not discovered another suitable option. It has less features, but it does the main things - capture JS errors, and allow you to run commands to inspect variables and object on your page.
Here's a demo:
It's activated by just placing this script tag on your page:
<script src="https://cdn.jsdelivr.net/gh/SimonEast/MiniConsoleJS#main/console.js"></script>
Open source, GPL licence. Available at: https://github.com/SimonEast/MiniConsoleJS/
3. vConsole
Another similar option that I've not really tried. Available at https://www.npmjs.com/package/vconsole with a live demo at http://wechatfe.github.io/vconsole/demo.html.
I haven't tried this on a PC, but you should be able to go to http://[DEVICE_IP_ADDRESS]:9999 to debug.
I've been doing lots of work in getting a few web apps to work offline on iOS using the HTML5 manifest. I've ran across the typical problems everyone else has and fixed them and everything seems to be working fine—except in the case where I save the web app to the desktop on my iPhone 4.
If I do this and then enable airplane mode, I get the following alert when trying to access the app via the home screen: "your-app-name could not be opened because its not connected to the internet." Accessing the app via Safari browser works fine while offline.
If anyone knows if this is an error on my part, or even the slim possibility of a work around, do tell.
Even downloading the new Financial Times web app (very well done with extensive localStorage support) results in an error when accessing it offline from the home screen.
Technical specs: Running iPhone 4 with iOS 4.3.3 (but also saw the issue in 4.3.2)
After reading the comments (especially Rowan's) I ran more tests and found the answer:
No, Apple did not disable HTML5 offline capability for web apps saved to the home screen, it works - for the most part. There is a bug that will make it not work. It doesn't seem to have anything to do with your manifest setup (unless perhaps it downloaded a bad manifest or incomplete manifest at one point.) We don't know how widespread it is but the fix is to clear your Mobile Safari Cache.
Here's the steps:
Close the web app (make sure its not sticking around in the background).
Cleared Mobile Safari cache: Settings > Safari > Clear Cache
Reopened the app (for caching).
Close the web app again (make sure its not sticking around in the background).
Enabled "Airplane Mode": Settings > Airplane Mode
Reopened the app.
It should now work offline. If it doesn't then its probably a separate manifest issue in your app. Looks like a weird bug with the browser cache - or perhaps the cache was completely full? Who knows, but that's the answer. Thanks guys.
iOS seems to be very sensitive to load issues when offline.
I was getting your "could not be opened" error when offline on a page I was working on. The problem turned out to be that the page created an iframe pointing to a site that didn't have an AppCache. Removing those iframes fixed the issue.
In my case, I handled it using window.navigator.standalone which tells you whether you're running in an iOS homescreen app. The code looked like this:
if (!navigator.standalone) insertFrames();
add this to your html:
https://web.archive.org/web/20170201180939/https://jonathanstark.com/blog/debugging-html-5-offline-application-cache?filename=2009/09/27/debugging-html-5-offline-application-cache/
I found it massively useful - even though I've created my manifest file and compared it to other people's manifests this JavaScript debugging script gave me the clue I would have never found otherwise. I apparently had syntax error in my manifest ... long story short I had to remove everything and add the paths to each file/image one by one. The end result was the same however it worked... how weird!!! does whitespace / comments affect the syntax of the file?