I am really struggling to get the Generate Strong Password - Function done inside ma app...
This is my website: https://wishlists-app.de/ . I already set up Associated Domains and Autofill Credential Provider inside my app like this:
I think that's all I need to do on my App's site, right? I know I have to do something with Apple-App-Site-Association but this is the part where I struggle and can't find any good tutorial...
I followed this guide but I have no idea how to realize the 2nd step. I have no idea how exactly I have to create this Json-File and "add" it to my website. My provider is all-inkl.com. The tutorial isn't very "newbie"-friendly on this nor is the Apple-Documentation, so I hope someone can help me out here.
And is there something else I need to do? I already set all the textField.textContentType but right now when selecting the passwordTextField Xcode is telling me this:
Cannot show Automatic Strong Passwords for app bundleID:
com.ckbusiness.Wishlists due to error: Cannot save passwords for this
app. Make sure you have set up Associated Domains for your app and
AutoFill Passwords is enabled in Settings
Does adding the Association-File fix this issue or is there something else to do ?
Via the documentation:
Adding support for universal links is easy. There are three steps you
need to take:
Create an apple-app-site-association file that contains JSON data about the URLs that your app can handle.
Upload the apple-app-site-association file to your HTTPS web server. You can place the file at the root of your server or in the
.well-known subdirectory. Prepare your app to handle universal links.
Prepare your app to handle universal links.
easy is Apples description. Not mine.
You need to get the correctly formatted apple-app-site-association file (that's the exact name) uploaded to your web directory at preferably a sub-folder called .well-known. That's the first place iOS will look, the root is the second place iOS will look. The file MUST be served via https.
Related
I'm stucking at Domain is incorrectly set up; please use the nameservers below as your NS record.But before setup NS record, i want confirm something because the custom domain i'm using is belong to my client.
So when user click mydomain.com (not .app.link or anything from Branch), does app open? If user don't have app, does AppStore open?
2nd question: How do i edit AASA file? I want some link open app, some link open web.My current path in AASA file: "paths": ["/catalog/*", "NOT /blog/*.html", "/blog/*"]
Any domain, be it branch link or not needs to configured in the android manifest file so as for it to be a supported link for the app.
All supported links will open the app directly (if the user has the app).
For ios, these have to be declared in associated domains.
All App Links and Universal links help in improving customer experience by directly opening into the app.
It is possible to edit the AASA file as per your use case. You would need to raise a ticket to support#branch.io regarding your request and this will be answered to.
You can look into our documentation here so as to understand better : https://help.branch.io/using-branch/docs/advanced-settings-configuration#section-change-link-domain
Our app sign-in flow involves redirecting our users to another app to sign in and authenticate followed by a redirect back to our app to complete the sign in process.
The redirect back to our app from the authenticating app is achieved by the calling of a universal link, this should always redirect the user back to our app, however for a select few users it seems to be opening safari and redirecting them to a page on our website instead.
We have a page set up on our site to handle just such an eventuality, the instructions on the page tell the user to click the 'open in app' link at the top of the page (the banner which ios inserts on all universally linked webpages) in order to open our app and complete the sign up procedure. However for some of these users this banner does not appear! It is as if there is no universal link set up at all. This means the users are unable to complete the sign up procedure and enter our app.
I've checked our universal link at the branch.io validator (https://branch.io/resources/aasa-validator/#resultsbox) and the results came back saying that everything was valid.
I also checked the link using apples 'App Search API Validation Tool' which returned the following message in the 'link to application' section:
Error no apps with domain entitlements
The entitlement data used to verify deep link dual authentication is from the current released version of your app. This data may take 48 hours to update.
Now this would seem to imply that we need to wait 48 hours from our most recent deployment for our universal link to become active, however the fact that the link works for the majority of people (including ourselves every time we have tested it) would imply that this is not the case.
We originally had our apple-app-site-association file uploaded at only the root of our webserver but I've now also uploaded it to .well-known/ just to be on the safe side though the issue still seems to be persisting.
Here is an anonymised version of our apple-app-site-association file:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "1F5A4778Y4.com.Tested.Step",
"paths": [ "*", "NOT /privacypolicy/", "NOT /faq/", "NOT /terms/"]
}
]
}
I have retained the capitalisation which we have in the above file (the com.Tested.Step is capitalised in our actual apple-app-site-association file) I have not seen any other app id's which contain capitalisation in their reverse url section like this, could this be causing the issue?
So far we have managed to get some information from a few of these users and there seems to be no consistency in the app version (It seems happens equally to users of iOS 10.x and iOS 11 beta) and the issue is not resolved by the users deleting then reinstalling the app.
My question is thus is there anything which could suggest, given the above information, why some users are not being redirected to the app via the universal link? And furthermore are not seeing the banner at the top of safari offering to 'open in app'? Could this have anything to do with the error which was being returned from the App Search API Validation Tool?
Thanks in advance and please let me know if you require any additional information/clarification on any issues.
Update:
I've just discovered that the users in question having the issue seem to be not making calls to the apple-app-site-association file on our site, even after deleting the app and then reinstalling.
As your edit suggests, it sounds like these users are not successfully scraping the apple-app-site-association file on initial install.
The "App Search API Validation Tool" is not the "Universal Links Validation Tool" (which doesn't exist from Apple), so the results from this tool have no connection to whether Universal Links work or not. Officially, it is comparing your website's apple-app-site-association file to your app's listing on the App Store, so if the version of your app that is publicly available does not yet have Universal Links entitlements, that will cause these errors. However, Universal Links will still work fine with local builds. The version of your app in the App Store does not need to have Universal Links implemented in order to test what you are trying to do.
Your server may not be properly responding to all requests for the apple-app-site-association file, or there could be network issues on the user's end. You'd probably want to dig into logs, or attempt to test it at scale to see where things are failing.
Alternatively, look into a hosted deep link service like Branch.io (full disclosure: I'm on the Branch team) or Firebase Dynamic Links to absolve you of the responsibility 😉.
The use case is, essentially, this:
the user create some content and uploads it to our server.
our server responds with the URL.
the user sends the URL (eg via text message) to another user.
the other user clicks on the URL. If they have the app installed, they should be taken to the content in the app. If they don't have it, they should still be able to view the content on our site (eg in safari).
This is easy enough, and we have that working, except our URLs are long and we'd like to use shortened URLs. With shortened URLs, the problem is it always opens in Safari, instead of the app, unless we setup a custom domain. (This is described in many places, including here: iOS Universal Links and URL Shorteners).
The docs for google URL shortener indicate that they have overcome this somehow:
Even though App Indexing for iOS is available only in limited release, you can still enable iOS app deep links with goo.gl by implementing App Indexing for iOS. While these deep links may not begin appearing in Search results, they will start working with goo.gl links.
So I installed the app indexing for iOS into our app on a test device and ran it. Then I created a short link but it still opens in my browser, not my app.
Does this really work as advertised? Do I have to wait longer? Install the indexer on more apps? Will a created link open in the app right away, or does the content have to be indexed?
...Or am I missing something else?
Related:
Google app indexing for iOS and universal links
UPDATE:
The only way I can see this actually working without a custom domain is if Google added every app they indexed to their apple site association file. All I see is google apps there, so obviously that's not the case.
Stack overflow won't let me link it because it thinks it's a link shortener, but it's close to this:
https://goo. gl/apple-app-site-association
You are exactly right: for this to work, Google would need to add your app to their apple-app-site-association file. Unfortunately that would be impossible even if Google wanted to do so, because Apple puts a size limit of 128 kb on that file.
Integrating the App Indexing SDK was a good thought, but doesn't solve this issue either.
What you need is a (free) service like Branch.io (full disclosure: I'm on the Branch team). This is specifically designed for exactly what you're trying to accomplish, and takes care of all the housekeeping tasks you are running into. You'll be able to create branded short URLs that take you to your app (if installed) or website fallback (if not installed), and the AASA file will be generated automatically for the short URL domain.
Using my iPhone i noticed that when i open a youtube link like http://m.youtube.com/..., this is redirect to the native Youtube app.
I would like to do the same thing but using my custom url scheme, so i would like to have a custom url, if my app is installed in the device this is redirected in it, or if it's not installed, to do something else.
I've tried to register as a custom url scheme the "http://" url scheme, but the is not listening for these urls.
edit-
I've already tried to register my custom url scheme, i want to use an html page, in that page i want to put my custom url scheme, but the problem is that i can't detect, from the web page, if the app is installed in the device
Take a look to the Associated Domains.
If I understand well your question you need to define your own domain that will be associated to your app. Every time an app will find that specific domain the OS will check if any installed app can handle it.
You need to add the capabilities as specified by Apple here
Hope it helps
For that you need to create your custom URL Schema for that you can open via another app.
Following is the Tutorial where you can create your own URL Schema and use into your app.
Here is tutorial.
You can define custom url schemes that will open your app, but you can't make your app the designated handler for certain domain names so that opening that domain in Safari will launch your app automatically.
And One thing for more detail this solution given into this question also.
Happy coding.
You need to add your custom URL schemes in Info.plist. With this schema you can launch your app.
In the plist we need to mention the URL which is accessible public. Is it possible to keep that out of web root so that no one can hit that path using web browser. This means I want to keep .ipa not accessible through a web URL.
That's not possible, unless you do something like have the URL point to a script which goes off and reads from the IPA outside the web root and then spits it out. But that would still mean people could access it.
Basically, if you expect an iOS device to be able to access the file, then anyone can just inspect the plist and get the URL and download the IPA directly. Remember though, they can't really do much with it. Why don't you just block access to the plist file to only authorised people?