This is the first time I upload an app to apple app store. After weeks for reviewing, finally, I get my app listed on apple app store. But the problem is, now seems like my app app-store page is only viewable from iTunes. When I try to open it in a browser, it will shows "Connecting to the iTunes Store...". Why is it my app can't be the view from the browser? Why did another app can? How to fix it?
Short answer: It seems, you cannot fully predict the behavior of an app store link for a certain user. You being redirected doesn't mean other people will be redirected right away as well. Your app's country/language availability, users' app store region and language settings, the specificity of the app store link (which has optional components and alternative styles), and the browser cache all seem to have a say.
Added details: After experimenting with this a lot, it seems to me that the behavior of the link (or rather the response from the Apple server to requesting it) depends on the language/country version being requested, my own current country/language defined in iTunes/my app store account, plus some caching issues. So, whether a preview page is shown in the browser, or iTunes is attempted to be opened right away depends on several factors and doesn't always have the same result (for different users). In fact, two consecutive attempts to open the same URL can have different redirect behavior.
I noticed that a full app store link like https://itunes.apple.com/us/app/keynote/id361285480 more likely leads to the preview web page, if the app is available in the language/country referenced ("us" in the example) and there is no prior request cached in which I clicked through to the app in iTunes. If the app isn't available in the referenced location, or any other information is missing in the link for the Apple server to identify a particular language version on the preview website, or there is cached data that makes Apple confident enough to redirect you to iTunes directly (or it's Friday 13th and the moon is right behind the sun by pure chance...) then you may see a redirect instead.
For posting app store links in the likes of Facebook, Apple's app linker seems to produce URLs with the nicest preview snippets (and not: "Connecting to the iTunes store"), when putting in the right country. So, these generated URLs seem to be most complete/specific.
If your app is intended for a specific region, AppStore connect will still give you a URL with .../us/... in it. Changing it to the respective local region seems to fix the problem for me.
For an example,
given URL: https://apps.apple.com/us/app/yourcompany/id123456
If the app is for Norway region, change the URL to: https://apps.apple.com/no/app/yourcompany/id123456
Related
I want to implement deferred deep linking in my iOS app as a means of tracking referrals. When a user of my app wants to refer a friend, I'll generate a URL that has a unique referral code. When the other person receives the link and opens it, I want it to take them to my app's page in the App Store. Then if they install my app, when it first opens, I need a way for it to read the referral code from the original URL.
I've found may pages about deferred deep linking on the web but none that really explain how to do it. Instead, these pages all end up telling you to install some third-party code or use some commercial service. This isn't what I'm after. I want to learn how to do this myself.
There are lots of old pages out there that recommend convoluted and error-prone solutions, like tracking the user's IP address, putting the referral code into the clipboard, or somehow obtaining it from a cookie in a web view. I don't think these are the correct solutions to be using in 2022.
If anyone can recommend the appropriate resource, I'd appreciate it.
If it is the case that Apple simply doesn't want us to do this and doesn't provide any support for it, then I'd like to know that too. I was under the impression that they did, but maybe I'm wrong.
Thanks,
Frank
Apple's Universal Links allow for this (would understand the difference between the typical URL Scheme and Universal Links as threshold). This assumes you're willing to do some lifting server-side along with other hurdles on the iOS side, largely administrative.
A benefit of Universal Links and the server-side work is that you're provided a fallback webpage if a user does not have the app installed. Since the app should open if downloaded, you could typically just redirect to the app store from this URL. In this case, though, before any redirects, you could execute an operation to decode the unique params passed in the URL and persist it in a remote data store. The data encoded needs to be required and verifiably unique during your registration -- email seems ideal.
If that's feasible, your standard registration flow could require email verification with a link to the app as a mandatory entry point (think slack magic link). When the user submits his/her email to verify, you could first check that email against your data store to see if it maps to any previously decoded referrals saved from the flow above. If so, you could generate a unique link for this email to your app with params that will direct the deferred/deep link.
The good news is, I found a solution. I could construct a web page that redirects the user to the app store, but before doing so, copies some text into their clipboard (without telling them or asking them to do anything). Then later if they install my app I can get the text by pasting from the clipboard. I tested this idea and it works.
The bad news is, starting with iOS 16, Apple now asks you for permission to paste. So if you try to do this, your user will launch your app and immediately get promoted with a message asking them to allow a paste from Safari. I expect most users will deny the request and just the fact that they saw it will erode their trust in the app (I know I wouldn't trust an app that tried consume my clipboard without a direct command from me).
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.
I have to create an iOS app, which needs to know a referral code right after the installation. The code comes from an email or from a link in the browser. The goal is to make the app have the referral code no matter it is already installed on the user's device or it is being installed by the clicking of the link.
What I know already:
I have to register an URL scheme with my app, for example myapp://
I have to handle opening by this URL, recognizing the referrer code from it (myapp://refcode=123)
I have to have a web service, which detects (with JavaScript) if the user's device can handle my URL scheme or not (like this: https://stackoverflow.com/a/6599773/511878)
If the app is not installed, I can send the user to the App Store to download it, otherwise I can open the app by this URL and transfer the information into it
What I miss: How can I immediately call this URL after installation?
I was sure this is impossible to do until this morning, when I've found that Apple's TestFlight is doing exactly the same. I've got an email containing an invite to some app, clicked on the link, and because I did not have TestFlight installed on that device so far, it brought me to the App Store, where I clicked install. The device installed TestFlight app. After this I've clicked the Open button in the Store, which immediately showed the invite for me.
I think the solution can't be that it recognized me, and picket up the invite from the server based on my user account, because I might have multiple invites, so it had to know which exact one to show.
EDIT: Video of this happening: http://gk.lka.hu/x/tf.mov
So the question is: How can I transfer information into an app which is being installed after a link is clicked without reclicking the link?
I'm a developer at Branch and we recently built this system for others to use. If you want to build a similar system from scratch, here is an example of what you'll have to do:
The web service you described above must capture some information from the user, such as IP address, OS, OS version, screen size, etc., before redirecting to the App Store. It should associate this with the link that was clicked, or at least the refcode from the link (http://yoursite.com/redirect?refcode=123).
After your app is downloaded, the first time it opens, send up the same info (IP Address, OS, etc.) up to your server. If your server sees these params and that they're the same as what you grabbed in step 1, it should pass back refcode=123 to your app.
Your app should then handle the 123 refcode however you see fit (e.g. open to the appropriate view controller, apply the referral code, etc.).
Hopefully that helps. It's definitely harder than it sounds to build from scratch..
How can you solve this scenario:
User is using Safari on iOS. They click a link on a website that says
"View Profile on our app". The user does not have the app, they are
taken to the app store to download the app. After they open the app,
the app immediately loads the profile screen (instead of the main
screen).
Currently in order for us to solve this problem, when the app is installed we immediately open Safari to grab the session cookie, if it matches the one on the server we load the right screen. However, Apple is now rejecting our app (and others) for loading Safari at startup.
What is a valid solution that won't get rejected by Apple?
(Also note that we were exploring IDFA - which would have worked - but Apple is rejecting apps that use IDFA if the app isn't using Ads)
This is definitely possible without the IDFA.
Basically, create a URL endpoint on your server that will 302 to the App Store on GET. When a user clicks this link, collect IP Address, OS, OS version, device model, screen size and other parameters and store it as a browser fingerprint.
Then, after the user installs your app, send the same array of meta data to your server as a device fingerprint. Your server can then match this device fingerprint to the browser fingerprint. If there's a match, you can be very certain that the user originated from your link.
Just to give you an idea of numbers, we (at Branch) give this service away for free and now process hundreds of millions of these match queries per day. We've seen that if a user will install, 99% of them will do it within the first 60 minutes. Just empirically, we estimate that this mechanism, with a short window of 2 hours is very close to 100% accurate.
For an added benefit, if you collect IDFA, you can drop a cookie on the browser on redirect and then store the matched pair to the IDFA to create a semi-permanent alternative to the fingerprinting mechanism I mentioned above. If someone clicks your link again, and you've got a cookie stored in the browser, you'll know who they are when they send their IDFA back to your service on install because you've seen that story play out before.
The best solution requires IDFA, which you are in fact allowed to collect for the purpose of deferred deep linking. The "Apple IDFA Scare" was a bit overblown in the media, and Apple revised its T&Cs to make it more clear. Apple also allows you to collect IDFA if you are an advertiser, for attributing installs, or for attributing post-install actions. In other words, you don't have serve ads in your own app in order to collect IDFAs.
Here's a link to the current Apple policy (https://developer.apple.com/news/?id=08282014a ), and this article from AdExchanger goes into a little more detail (http://www.adexchanger.com/mobile/apple-throws-a-bone-to-app-marketers-blesses-idfa-for-attribution/ )
I setup a Mobile App using the developer's panel and added all the correct information as mentioned in the tutorial video on the Facebook SDK page.
It's a native iOS app so I supplied the bundle ID and the App Store ID. I've installed the SDK and Facebook is registering installs whenever I run it on my device.
However once I tried to use the "Promote" feature to setup install ads it keeps getting rejected by Facebook on the grounds that the URL is bad. The URL works fine as I've tested it multiple times. The URL is generated by Facebook itself using the App ID.
I've tried submitting it again after changing the creative, but I'm assuming I've been blacklisted since it immediately is disapproved.
What can I do?
Is your app limited to a certain region or country?
My ad was also disapproved and this is what I got:
"The destination URL of this ad violates our Ad Guidelines or could not be reviewed. Please check the URL you have submitted to ensure that it is free of any spelling errors and that it complies with our Advertising Guidelines. Please note that all sites must be viewable and functioning properly, regardless of the viewer's location. Additionally, sites are prohibited from linking to proprietary file types (.pdf, .doc, etc,) initiating automatic downloads, or trapping a user's browser in any way (e.g., pop-ups of any kind).
"
In my case the only logical explanation would be the availability of the app, as it is only available in one country. I link directly to the app store so that should not be a problem...
Sorry for my reply, i know it's not very helpful, but there is so little info on the web about it. I need to do detective work in order to understand what is happening.
I had the exact same thing. I think Facebook changed a ton of stuff in their ads dashboard. I created a new ad yesterday and it was finally approved. Try again.