Cookies on this site
We would like to measure how this site is found and how our ads perform, which needs analytics and advertising cookies. Nothing is stored until you choose, and either answer is one click. What these cookies are
Works with every store and social app
Any app. Any device. No SDK — with analytics built for app links.
You pick the name: appin.to/your-app. Every plan gets one, including Free.
An example, rendered live by appin.to. Paste your store link to see yours.
Instagram, TikTok and Facebook all open links in an in-app browser rather than Safari or Chrome. On iOS all three can fail the hand-off to the App Store, leaving a blank page. AppIn leaves the in-app browser before the hand-off is attempted — on iOS, and on Android where the host app uses one too, which we have measured on real devices rather than assumed.
Problem
A visitor taps your App Store link inside Instagram on iOS. The in-app browser opens, and then nothing happens: no store, no error, a white screen and a visitor who leaves. You see the click. You never see the install.
tap
same URL
Instagram does not reject App Store links. The link is accepted and the page loads — what fails is the hand-off to the App Store. That distinction decides what is worth trying: every fix aimed at the link itself leaves the broken part exactly as it was.
Setup
App Store or Play. We read the listing for the icon, name and screenshots, so there is nothing to design.
appin.to/your-slug, or your own domain. Set campaign parameters here if you want your campaigns told apart.
Bio, ad, email, QR. Device detection, the in-app browser and the landing page are all handled on the click.
Live links
AppIn runs its own public links in production: appin.to/chatgpt and appin.to/claude point at live App Store listings, checked on every build. Open one on a phone and you land in the store; open it here and you get the page a desktop visitor gets.
We hold these addresses so that nobody can squat on them, and each one opens that app’s own store listing. None of these companies is a customer, a partner or a user of AppIn.
Guides
Each page answers one search-intent question with facts we have checked — migration, in-app browsers, campaign parameters, and how we differ from named tools.
Features
Getting out of an in-app browser is the part everyone talks about. The rest of this list is what makes it an app-link tool rather than a redirect.
Campaigns
Tag a link per campaign and the stores report it back to you — Apple’s ct and pt, Play’s referrer, filled in correctly. No SDK.
Landing page
Icon, name, screenshots and description come from the store, so the page exists the moment the link does. Editable, never homework.
QR
Print it, drop it in a deck, or let the desktop page show it — so a visitor moves to their phone instead of searching the store.
Naming
appin.to/your-app rather than a random string, so the link still reads as yours in a bio, in an ad and in a screenshot.
Domain
Serve links from a domain you own — which is also the honest answer to shared-domain risk, covered in the questions below.
Analytics
Clicks by platform, referrer and outcome, including how many were rescued from an in-app browser. Clicks, not installs.
Measurement
Meta’s Conversions API, TikTok’s Events API, GA4, a server container you run, or AppsFlyer — set up once, and per link if you want.
No tags
Events are sent from our servers, after the visitor has already moved on. Nothing is added to your link and the page is no slower.
Deferred deep linking and install attribution. Both need an SDK, and on iOS the fingerprinting path they leaned on is closed. If you need them, use an MMP — and put an AppIn link in front of it.
General-purpose URL shortening. This is an app-link tool: a phone destination has to be a store listing or an allowlisted attribution link, because an open redirector is what gets a link domain blocked.
Pricing
What you pay for is how many links you run and what you can do with them — never whether the link gets your visitor out of an in-app browser. That part is the product.
In every plan, including Free
One link, with an address you choose, to see whether this works.
Free
Recommended
A handful of apps and the campaigns behind them.
$5per month
$50per year
$4.17 a month, billed yearly
Every link on domains you own.
$15per month
$150per year
$12.50 a month, billed yearly
No card needed to create an account.
Go past your clicks and your links stop until the month resets or you move up a plan. Pick a plan with room for the traffic you expect: a link that is already printed on something cannot be swapped out when it stops.
FAQ
You cannot revive a page.link URL — Firebase Dynamic Links shut down on 25 August 2025 and those addresses return 404 wherever they were pasted. Migration means replacement: create one AppIn link per destination and swap it into the places you control, which is bio links, ads, email, and any QR code you can reprint. Anything already printed on a physical surface with a page.link on it is unrecoverable, and that is true with any vendor you pick. There is no SDK and no app release involved on our side.
No. Nothing is added to your app and there is no release to cut. AppIn works on the click path, between the tap and the store, so a link you create today works with the build of your app that is already published — including for users who have not updated in a year.
No — they stack. An MMP link hits exactly the same in-app browser failure this product exists for, because an attribution SDK inside your app gives a link no way out of a webview it never reaches. Point your AppIn link at your OneLink or Branch URL: AppIn gets the visitor out of the in-app browser, and your MMP does what it does once the store opens. With AppsFlyer there is a second way round — AppIn can report the click to your account itself, under its own media source, and send the visitor straight to the store. Use one or the other for a link, never both, or the click is counted twice. We do not do attribution either way and are not trying to replace the tool that does.
No, and not by accident. Both require an SDK in your app, and on iOS the fingerprinting path they used to depend on is closed. AppIn is sold to people who do not want an MMP, so imitating one badly would be the wrong product. If you need install attribution, run an MMP and put an AppIn link in front of it.
What holds it down is a rule about where a link may point, applied when the link is created and again every time it is repointed. On a phone an AppIn link cannot go to an arbitrary address: an iOS or Android destination has to be an App Store or Google Play listing, or an https link on one of four attribution providers we allowlist by name. Only the desktop fallback takes a free-form URL. It is a rule about the address rather than an inspection of what sits behind it, and that is deliberate — it is the part that can be enforced on every link, every time, without depending on anything being reachable. Names are held on the same terms: our own and a list of brands are reserved on every domain we run, whatever plan you are on, so nobody can publish under them. Anyone can report a link to us without an account, and a link can be stopped from resolving. The risk stays real all the same: if appin.to is flagged, links on it can be interstitialed or blocked inside apps until the listing clears, and how long that takes is decided by the vendor reviewing it, not by us — we will not promise a number we do not control. What removes the shared fate outright is a custom domain, so if a link is load-bearing for your business, put it on a domain you own.
It has happened before, to a technique that worked at the time. That is why the ten methods were measured — on iOS 15 and later, and Android — rather than argued about, and why the bench that measured them is still set up: re-testing is minutes. Any fix ships on our side, because nothing about AppIn lives inside your app — no release for you to cut, and no user stranded on an old build.
No account, no card. Paste your store URL and see the link, and what one tap does on each device.
Preview a link
