I'm working toward adding PWA functionality to a web app for a client. However, I'm getting variattions between my test app and my implementation. on all apple devices, my client app has a readonly url bar that I cannot seem to get rid of. I created a stand alone test app with angular and added on the pwa functionality using Angular's pwa package as outlined here.
Here are the varying results. test app is on the left, and client app is on the right:
The apps as the appear install on my mac
The supporting manifest files
As far as I can tell everything is the same but I'm getting different results. What am I missing?
The only difference I can think of to explore at the moment are the hosting environments. The test app is on netlify and the client app is on an AWS setup through CloudFront.
Here are the headers that are being returned by the index page for each:
This was due to the manifest file not living on root of the site. It was instead inside of an offline folder.
Related
Is it possible to verify the apple app site association file was properly requested and configured for an instance of an installed IOS app? Ideally, we could easily verify that Universal Links are working properly for an instance of a device and installed application for the purpose of debugging. As an alternative, we could leverage a metric that confirms this association occurred properly for the purpose of alarming.
Background
Clicking on a URL associated with an IOS application that has been properly configured Universal Links enabled sometimes does not immediately launch the associated app.
I am aware that there are a few known cases where the app does not launch when it should (eg. Source App use redirect URL for attribution, Association files fail to load etc), but it is not clear at a glance if this behavior is an actual widespread issue and it is not clear how to debug it.
What I have tried?
Followed all steps listed for Support Universal Links to ensure Universal Links are properly configured
Verified URL host with Branch.io AASA Validator
Confirmed there is no Web Server errors when serving these AASA files from /.well-known/apple-app-site-association
Confirmed this behavior works most of the time*
*As an alternative to debugging, we have considered a metric that confirms this association (if it exists)
I am new to adding universal links to iOS applications. I have read some materials but still have a few questions below. Any pointer will be greatly appreciated!
When exactly Apple will crawl my domain and inspect the [domain]/apple-app-site-association content? I have a new domain, and I'm wondering how Apple's crawler can discover it?
What's the recommended way to test universal links locally before publishing the first version of my app?
Is version control for universal links not possible? For example, the app 1.0 version only supports \item universal link, but app 2.0 version supports one more schema \details . If I specify both paths in apple-app-site-association, then the 1.0 app will break when user navigate to \details. (Edit: I noticed that if the app appropriately set it to be unhandled, then we can still fall back to browser.)
Thanks!
When a device downloads an app, it looks for an entitlements file to list out your associated domains. When it finds that your app has associated domains, it will check those domains for the aasa and download it onto the device. The aasa for that app will only be downloaded on install and update so changes you make will not effect all of your apps.
For testing you can host your AASA on a testing domain or on your production domain. It's up to you but you have to remember to update your entitlements file when you push it to production to ensure that you have the right domain configured. Every time you rebuild the app, it should re-download the aasa so testing shouldn't be too difficult. Always remember to paste the link in notes and not type it into Safari. Universal links only work when they are tapped, not typed in.
For your example you should make sure your new AASA is published at the exact time you publish your app. You should probably use a separate testing domain to host your AASA. You can just include both domains in your entitlements.
Branch actually has testing environment and AASA hosting built in if you'd prefer not to handle all of that on your own. They also leverage URI schemes in cases where Universal Links don't work.
I had an issue with an Angular2 app (that makes use of Angularfire2) where a FirebaseListObservable was loading considerably slower on mobile Safari compared to any other browser when deployed to production. The production domain was a custom one - not one provided by Firebase.
Running an iOS simulator using XCode, I could see the below error in the Safari web browsers's console.
The solution was to look at the firebase-auth info message, not the errors themselves.
To fix, I had to add my custom domain to the Firebase console to the list of 'OAuth redirect domains'. At the time of writing, this can be found here: https://console.firebase.google.com/project/[YOUR_PROJECT_ID_HERE]/authentication/providers
I have a Qlikview dashboard that I need to present and I've created a site that loads the Qlikview server onto the browser and runs it from there.
I now need to create an iOS app that does this. But the requirement is that the dashboard shouldn't open on the browser. The server should be loaded and run from the app itself. Is there any way to do this?
PS, I'm completely new to iOS App development and any help will be appreciated.
Yes. While saving it as a shortcut and opening it in the browser would be simple, using Apache Cordova is the best way to develop a smartphone app with HTML5/CSS/JavaScript. From the website:
When using the Cordova APIs, an app can be built without any native
code (Java, Objective-C, etc) from the app developer. Instead, web
technologies are used, and they are hosted in the app itself locally
(generally not on a remote http server).
And to make things better, it's open source.
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?