I've been trying to monitor the numbers of uninstall but couldn't find a reliable way.
I tried to check with APNS status but apple doesn't provide any
status in response.
I tried to find any API (to get number of uninstalls) provided by
apple but still no luck.
I started tracking for inactive users but it still is not 100%
accurate and it only gives me inactive users.
There is no delegate method which fires when the app is being deleted.
No uninstall information in appstore sales and trends as well.
Later I checked AppsFlyer is providing this capability to track numbers of uninstalls.
Can anyone explain how reliable is AppsFlyer uninstall tracking and why ?
There is no official method from Apple to track app uninstalls — this would have user privacy implications, and Apple has built their reputation around protecting user privacy. Given the history of public outrage around this sort of tracking, it's unlikely Apple will ever allow it.
AppsFlyer (and other companies that claim to provide 'uninstall tracking') use silent push notifications to do it. Essentially, they ping the device regularly and report an 'uninstall' if the push notification is not successfully delivered.
There are a couple of major issues with this approach:
It's unreliable. If the user doesn't allow push notifications, or turns them off at some point after installation, you'll get drowned in false positives.
It's against Apple's rules. The App Store Review Guidelines say this:
4.5.4 Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information. Abuse of these services may result in revocation of your privileges.
AppsFlyer actually got in some public hot water for this product last year, and I've heard through the grapevine that Apple intends to crack down on similar services at some point in the near future.
Ultimately, an uninstall is little different from a user who has the app installed but never engages with it. You're probably better off focusing your efforts on building an awesome user experience that improves acquisition and retention, rather than worrying about how to measure a metric that is specifically on Apple's blacklist.
Now Apple offer this information:
Deletions
See how many users remove your app from devices running iOS 12.3 or later. Measure App Deletions to better understand how users react to changes in your app, such as content updates, price adjustments, or crashes. Compare App Deletions by sources or groups of users to see which types of users are more likely to uninstall your app.
https://developer.apple.com/app-store-connect/analytics/
The current path in Oct 2021 to check out deletions in App Store Connect is shown as below:
Note,
That is the number of times your app has been deleted on devices running iOS 12.3, tvOS 13.0, or macOS 10.15.1 or later.
Deletions only includes data from users who have agreed to share their diagnostics and usage information with app developers.
Go to https://appstoreconnect.apple.com/
Select your app
Go to Analytics
Go to Source
Select deletion in right side dropdown
Related
I have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
I need to get monthly uninstall count for iOS using Firebase. I know that for Android, there's app_remove event that I can use even if it's not really accurate, but it's enough for now.
From iTunesConnect or Playstore, they only give user retention data like how many user still use your app after x days, or daily uninstalls, which is not what i'm looking for.
Right now, you can't track app uninstalls on iOS using Firebase Analytics. It's not a trivial change (I think most SDKs do this by keeping track of messages they get back from the APNs feedback service), but I'll put in a feature request on your behalf.
Apple has added the deletion metrics recently by which we can see the number of uninstalls. We can add filters to find uninstalls for geographic range, app versions, by device and so on.
For reference: in iTunes connect app analytics in metrics under usage we can see the deletions.
Link : https://developer.apple.com/app-store-connect/whats-new/?id=iosdeletions
As you have understood from the question's title, I would like to know, how to identify iOS device across multiple apps. Advertising identifier and identifier for vendor is not an option for me, as apps may not have AdSupport framework included, and they may not have similar vendors. MAC address of the device is also deprecated. Any working solution on this? Thanks in advance!
This functionality is explicitly disallowed by Apple. Any workaround you come up with will violate Apple's stated goal of preventing it (so you would obviously risk appstore rejection even if it "works"). You are not allowed to track devices. You are only allowed to track the vendor ID and advertising ID. Apple has steadily removed every other tool because those are the ones they intend you to use (and their limitations are intentional).
What you are allowed to do is track users by issuing them login credentials and having them log into your server. This usually works fine if the user actually wants the functionality you're providing by tracking them (for example, users don't mind logging into Facebook or Twitter). If you are tracking users or devices to achieve a goal the users don't actually want (such as targeted advertising that the user can't control, or attempts at digital rights management tied to devices), you're unlikely to find a supported or permitted solution.
I created an app which is a paid app. Now I want to make it free so more user can download the app and use in app purchase to limit some features. But some user already paid to buy my app. How can I implement in app purchase for new user at the same time keep full feature access to old user?
If you connect to your server for registering user info, you can always create an API which executes on app launch to verify that user is full access user or not.
But I am afraid your case is not the above one.
In that case you would require to sync your data (some encrypted key in this context) with iCloud and when application is launched you can verify the type of user.
Using data in iCloud is more safer as compared to keychain as it covers device format scenario. But definitely not foolproof.
Other solution can be using Apple Purchase Receipt to verify the version of previous purchase. But this is only supported since iOS7.
Checkout some opensource libs to understand the parsing of receipts:
https://github.com/rmaddy/VerifyStoreReceiptiOS
So combining multiple strategies is the only answer for your question.
You can do this by reading the App Store receipt. The receipt contains the version number and date of the original purchase.
There are two main caveats: first, this only works on iOS 7 and above. Secondly, Apple don't include code for parsing the receipt (so it's not too easy for users to hack I understand). There are, however, onen source libraries, though using a common one will be less secure.
There are no perfect solutions to this scenario.
Suggestion 1:
Roll out one last paid update. In this update, use keychain to store those IAP flags. Then in the free version, check for these flags in keychain. This will work even if app was deleted and reinstalled with the free version later. But it will not work if the device is being reset completely whether due to some iOS version updates or user's unless a backup and restore also is involved.
Suggestion 2:
Not quite a suggestion. But I have seen similar apps on AppStore have just rollout free version. Then app incurred bad reviews from those previous users!
This is a simple example, but if you're working with a database on a server (not on the phone itself), can't you use a boolean for each feature you plan on selling, and just set that boolean to true for all users currently in the database. This is assuming true means they've bought the feature, and false means they haven't bought it.
You could run this query once after releasing your updated app, and then every user after that would have a default value of false for these features you're selling.