Wanted to attach a parameter to the Twitter intent URL created:
https://tech.cymi.org/tweet-intents
And prompt IOS user to activate media upload (e.g. open their camera app) to take a picture
I'm guessing the default Twitter intent URL doesn't allow it and a script should be created but not sure which direction to take
For security purposes I don't think they exposed that - as per the intent docs https://developer.twitter.com/en/docs/twitter-for-websites/tweet-button/guides/web-intent you are limited to just those parameters. iOS alone btw has one of the strictest security measures such as no video autoplay, user-activated actions to prevent automation; basically any interference with user comfort and engagement is deeply guarded that even with such intent query it would likely not work as needed. You could possibly create a file input field and when pressed you can have it access the camera and append that to a webhook where you can proceed with your project but as for the intent mechanism in itself I think you are limited.
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).
I am trying to track down these URLs because I would like to integrate them with the Shortcuts (previously workflow) app. My end game is to make queries that will perform certain functions that I can call from a google home device. In simpler terms, I want to make google home more "Apple friendly."
I have not found anything that is too current out there on the URL schemes. I saw that sending a SMS message was triggered with sms://<PhoneNumber> , but I am not sure how up to date that information is.
I plan on adding features to search Apple Music (by triggering a workflow). I am also planning on adding text message features.
I am also looking into making an app for google home, but I still am in the learning stage with that. Any advice on making google home more Apple friendly would be greatly appreciated.
This is a constantly changing list given the number of features being added or third-party apps. Here's a list that does a good job of staying up-to-date: https://ios.gadgethacks.com/news/always-updated-list-ios-app-url-scheme-names-0184033/
I'm trying to run an affiliate project for my app and Apple's 24 hour cutoff makes it a bit difficult. I'm wondering whether there is a way to implement one's own tracking?
I first was thinking a landing page with a phone number input form. Upon submission we'd use something like Twillio to send the user the app store link via SMS and also store the phone number together with the affiliates code from the landing page URL. I then saw that Google somehow let's you track adwords in relation to app installs and thought that perhaps there might be a way that doesn't involve this phone number indirection... Anyone know how they do it?
To be or not to be
The main question here is nature of your intention.
It reasons necessary accuracy / limitations you have on iOS. I see two variants.
100% Accuracy
If you need 100% accuracy, you can use SFSafariViewController - it's view is rendered by another process and it has shareable cookies between your app and Safari. It's iOS 9+ only 100% way to attribute installs. Also you can go with explicit attribution (email, phone number etc.) requested from user after app install. It might be needed if business model relies on this process (like each install is paid out to user account etc.)
You can get an idea and do implementation following this link
<100% Accuracy
If you want to provide greatest UX possible (but it's not critical) or gather analytics (but it allows some kind of deviation) you can go with some approximation techniques, like gathering IP addresses, location etc from requests to your affilate link. The flow can be following:
Your landing page contains dynamically generated link
Upon clicking on link, user metadata is stored (ip, location, device info - whatever can be grabbed from User-Agent or another info available to your web service)
User is redirected to App Store
Upon install and run, app queries your service with device info and ip.
Your web service now decides on attribution. Matching algorithm can include any necessary amount of variables / conditions. Like "Same IP + Device Type + No more than 5 minutes since clicking the link".
This way you don't request any user info (email, phone number) but you're already able to track attribution. Correctness percent is subject to tuning.
Edit #1
This approach might be helpful to you, it's used to attribute login, however you can use modified for analytics.
Edit #2
If you're really wondering, how AdWords does this, you might be interested in install tracking step-by-step guide. It's explicitly stated (section "Instructions for tracking iOS app installs (first open)", p.14) that you should either use AdWords tracking code (this tutorial describes how) or setup server-server integration. So, going back to original questions:
..there might be a way that doesn't involve this phone number indirection?
Yes
Anyone know how they do it?
There are lots of techniques (as well as measurement pixel built on top of mentioned above SFSafariViewController), described in these docs:
Google SDK,
3d-party SDKs
I have an iOS app that is linked to Google Analytics via the iOS SDK for GA
I want to find out from GA, how a single user (who I know has signed up at a specific time, and hence would have gone through some signup sequence of screens) has gone from screen to screen post the signup process
What is the best way to do this in GA? I can see a Behaviour Flow in terms of graphical data, where can I see the actual text log or some kind of line by line data for the same?
Thanks
Maybe it is possible with setting user specific values/keys in GAIDictionaryBuilder,
BUT based on Privacy policy: http://www.google.com/analytics/tos.html
You will not (and will not allow any third party to) use the Service
to track or collect personally identifiable information of Internet
users, nor will You (or will You allow any third party to) associate
any data gathered from Your website(s) (or such third parties'
website(s)) with any personally identifying information from any
source as part of Your use (or such third parties' use) of the
Service. You will have and abide by an appropriate privacy policy and
will comply with all applicable laws relating to the collection of
information from visitors to Your websites. You must post a privacy
policy and that policy must provide notice of your use of a cookie
that collects anonymous traffic data.
We're trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many installs occur from their referral link. Basically similar to TapStream's product.
Consider this example:
So, UserA shares their link, “ourappURL.com/refer?id=userA”, on any
network they want. UserB clicks that link, which will take them to
Safari and then bounce them to the App Store page where UserB
downloads the app.
When UserB opens the app, the app checks which referral ID they came
in on (if any). In this example, the referral ID would be “userA” as
that’s the ID that was in the referral link. The app then sends this to
our servers and we award UserA with a referral credit.
I'm trying to break this issue down into its core parts. I believe the first part is getting the web page for the user's referral link to save the referral ID to the device somewhere that the app can access it. But I'm not sure this is possible because of the sandboxed nature of iOS.
I know this is fundamentally possible because many ad providers offer the ability to track installations from an ad campaign (see Mobile App Tracking for example).
We have also attempted to do this ourselves and I will try to break down the different steps here.
Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).
Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.
The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.
The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.
Here is a summary of the steps:
User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
User 2 visit Web Page P
P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
User 2 goes to the app store and downloads your App A
User 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.
Hope this help!
Edit 04/24:
Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.
Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.
Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.
It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.
During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.
Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.
We've successfully used the clipboard (NSPasteboard) to achieve this: the web page that processes the redirect to the app store does a paste to the mobile device's clipboard before letting the user download the app. Once the app is installed, it uses NSPasteboard on first launch to check for an appropriately coded string. This string can contain the text of interest or, more securely, a token used to fetch interesting data from the backend. In Objective C:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
The clipboard can be cleared once the app is done with it, to avoid repeating the same action.
There is a good solution here: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
Basic workflow:
User selects domain link on web.
Link sets referral ID to cookie.
User redirected to app store.
On app launch, load referral page in SFSafariViewController.
Referral page checks for cookie and if it exists calls a deeplink into the app with the referral ID.
My answer from HERE
Apple no longer supports Deep Links. It is now called Universal Links and works a bit differently.
Source
Now that Apple no longer supports URI schemes for deep linking, developers must implement Universal Links in order to deep link properly on iOS. If you are already using URI schemes, check out our blog on transitioning to Universal Links.
From: HERE
And HERE is another article on Universal Links and what they are.