I've searched the interwebs/SO far and wide and I'm having no luck.
Server is running IIS 6;
.ipa mime type is set to application/octet-stream;
.plist mime type is set to application/xml;
Server has valid Godaddy certificate installed.
The link itms-services://?action=download-manifest&url=https%3A%2F%2Fmyserverurl.com%2Fiosclient%2Fmysoftware.plist fails to install on iOS 7.1 devices. It's set to https. If I set that link to http, my phone running iOS 7.0.4 downloads and runs the application just fine. If I set the manifest to use https, both devices show the error "Cannot connect to myserverurl.com". I have tried setting the link to the IPA file in the manifest to both http and https but I am having no luck at all.
I made sure that I can put both the plist and ipa URLs in the address bar of my browser and they are both completely accessible.
Any ideas? I've been playing with this for a couple hours now and I'm not having any success.
There are several reasons why you may see the "Cannot Connect to " error; however, one other thing to check are the file permissions on your server. Specifically, right click on the folder which holds your IPA and plist and choose properties, then go to security. Add the "Everyone" user and assign full rights to it. If that resolves your issue, you can then "backpedal" to a more secure, but functional user/file permission configuration of your choosing.
Related
I am having problems on my local server when trying to serve files to an iPhone running ios13. The problems only occur with file types that cannot be rendered in the browser, by that I mean files such as epub, mobi and zip that require me to manually click on download.
Files such as text and pdf have no issue in any browser.
Safari is able to download Mobi, Epub and Zip files, but Chrome, Firefox and Edge all fail giving vague messages like “Couldn’t Download” or “Download Failed”. Try Again.
Originally I was serving the files using Nginx, X-Accel-Redirect and PHP, but I found that using a direct url had the same problem. The server is running HTTPS and HTTP2. Mime types are properly configured in Nginx.
In each case, regardless of whether the file was successfully downloaded or not, the access logs showed status code 200.
My questions are:
What could be causing the failed downloads and how can I fix it?
What other things should I investigate to shed more light on this
issue?
It seems that the SSL certificate on the local server was causing the download issues. It was a self signed certificate and it often causes warnings to be displayed in the browser.
I uploaded the epub/mobi/zip files to a server that didn’t use HTTPS and found that mobi, epub and zip files successfully downloaded regardless of the mobile browser used.
I did the same with another server using a properly signed HTTPS certificate (letsencrypt) and again found that the mobi, epub and zip files successfully downloaded regardless of the mobile browser used.
I use the cordova plugin "ionic-plugin-deeplinks" (to my knowledge also works with a plain cordova app).
On Android, links when clicked let users choice between chrome and my application.
=> I suppose that app links works
=> As I'm able to access window.IonicDeeplink and redirect the user to the right page
I'm not able to have the same behavior on iOS, when I click a link I always get the app open in Safari.
How can I find clue on issues ?
More context:
apple-app-site-association is got with a HTTP 200 (over https only), it's located in /.well-known/apple-app-site-association:
I checked TeamID and BundleID 5 times (at least);
with the branch.io validator i get all validations green:
Your domain is valid (valid DNS).
Your file is served over HTTPS.
Your server does not return error status codes greater than 400.
Your file's 'content-type' header was found :)
Your JSON is validated.
with the apple validator, I got : "Action required
Could not extract required information for Universal Links. Learn how to implement the recommended Universal Links.
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." (but some devs said that working app add the same error) what to do with that result?
when monitoring server's log while installing the app with Xcode I see a request get a HTTP 200 on apple-app-site-association
while installing the app with Xcode I got no logs referring to swcd in Xcode (I read here that I should if I had error while installing the app). Is a successful installation silent?
I followed that guide to setup entitlements, but some things feel odd with it:
Unlike the snapshot in the guide, I didn't found any *.entitlements file in my project. Should I have one with cordova? (my xCode seems to remember my setting though). Is it possible to check that installed app get entitlements?
I did set my domain in Xcode like this: applinks:mydomain.com and the switch is ON. But I never uploaded any thing from my local dev environment to apple services. Should I have? If yes, how ?
My current interrogations are highlighted but any explanations on any lack of understanding will be more than welcome!!!
Until then I started a verification for testFlight looking for more info.
while installing the app with Xcode I got no logs referring to swcd in xCode
I implemented Universal Links manually, but situation was similar. Particularly I mentioned empty swcd process log while installing the app, and it turned out that most likely iOS didn't even try to download apple-app-site-association file, like if responsible process wasn't run. In my case device restart helped and deep-linking began to work.
Thus I think restarting device is one another step in troubleshooting when you are sure about all your setup.
For anyone trying to debug this in development:
In XCode, ensure you're editing the Debug version of Signing & Capabilities.
To bypass the Apple Universal Links CDN, configure your Debug domains like applinks:?mode=developer -- adding that query string in development is important.
On your iOS Device, go to Settings->Developer->Universal Links and ensure the Associated Domains Development toggle is switched on.
On your iOS Device in Settings->Developer->Universal Links->Diagnostics, enter your Universal Links URL and ensure you get a green checkmark.
After following all of these steps, Universal Links work locally.
I am trying to upload an ipa file (call it a.ipa) into iTunes Connect via application loader. While the uploading process pending at "Verifying assets with the iTunes Store" more than 8 hours.
And validation for a.ipa is fine, uploaded another ipa also worked fine. Does anyone had the same issue? Or any suggestions? Thank you.
I've had this issue too. I was connected to a network that I think was blocking a needed port. When I disconnected from that network and tried another it worked.
I had the same problem on our corporate network. The fix was to add proxy settings and disable the protocols that were being stopped by the proxy. If you know you have a proxy in the network path, edit the file :
/Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/MacOS/itms/java/lib/net.properties
Place the following settings in the net.properties file, of course using your proxy hostname:
http.proxyHost=proxy.example.com
http.proxyPort=80
http.nonProxyHosts=localhost|127.*|[::1]|*.example.com
https.proxyHost=proxy.example.com
https.proxyPort=80
Then, go into the application loader's preferences screen and deselect all the protocols except anything that says DAV or WebDAV. This will ensure that HTTP/S is the only protocol attempted for connections.
I am new to this site, so bear with me. I just wanted to ask a quick question regarding the iOS Developer Enterprise Program. I am enrolled, and I have made a few apps that are ready for in-house distribution. I have uploaded the .plist and .ipa file to my website in a separate directory. However, whenever anybody tries to download it, they just get the error message "Could not connect to website.com". Then, when I open up Xcode and launch the console when my iPhone is connected and I try to download it, Xcode displays this: "Could not load download manifest with underlying error: (null)". The null part really throws me off. Everyone has iOS 7.1 (or mostly everyone), and the website does have an SSL certificate, so I can't figure out why it is showing that error. Any help with this would be great.
Thanks!
Was ready to give up and change SSL provider, but managed to get the reason for me. Hope this will help for someone:
Problem occurred because my server was responding 403 Forbidden for manifest download request by Safari (because this request does not send cookies required for being authorised).
You need to make sure that the website that hosts the .plist and the .ipa files uses https. This is a requirement in iOS 7.1 and above.
I've been successfully deploying, over-the-air, an iOS app that I developed for a client. I'm using my client's own Enterprise Developer credentials.
I've been doing tests from my own http server, housing all of the requisite files (.plist, .ipa, and of course the html page); and also from a combination of servers: a secure one holding the html, re-directing to another, un-secure, server holding the .plist and .ipa. All's well with all of this.
But I run into trouble when I move everything to a secure server. There, the html opens properly, but on attempt to download (by tapping on the same link that works on my un-secure server), I get a "Cannot connect to "
I've changed the URL in both the html and .plist to reflect the new actual https:// address at the secure site. The site certificate seems to be valid and recognized. Another tester has also had the same problem when trying this for me.
Does anyone have any idea what this might be about?
UPDATE - this problem can be expressed in a slightly simpler way. .ipa files will not download if they are placed on a secure (https://) server.
Versions of iOS earlier than 7.1 don't seem to care if the html and .plist manifest files are on secure or un-secure servers. But 7.1 cares -- html and .plist MUST be on https.
Why can't the .ipa be there too?
This turns out to be an easy, but hard to find, solution. If the .ipa is served by Microsoft's IIS server software v6.0 or later, the MIME-type settings must include .ipa as 'application/octet-stream'. Otherwise no file is served. Apache servers are a little smarter -- they'll deliver in any event.
So this is not really a http - https issue. I was fooled because my https attempts were all happening on IIS servers that weren't set up properly.