I have integrated Flurry Analytics into my iOS app. I haven't released the app yet so there can't be any real users except for myself. However, the second day I found that Flurry reports there are 5 new users. How is that possible? I did delete and rebuild my app to my phone several times for testing purpose, but according to Flurry FAQ, the same device should only be counted once. Does rebuild app from Xcode change the device id? or the hashing function of the device id?
Flurry relies on IDFV for metrics purposes. In the event that you uninstall the app and have no other apps on that device from that developer (meaning you), then the device will register as a new user.
On top of this, when submitting for distribution, Apple seems to run some automatic analysis on the app. This typically results in around 10 to 20 new users, though this effect is only observable in small apps.
I've found the same thing, I was developing with 3 devices yet according to their stats I had dozens and dozens of unique users. I wrote and politely asked what was going on and would they offer an explanation, they couldn't be bothered to reply. Same thing happened after releasing the app to the app store - the app registers with my server so I know how many users there are, yet the number reported by flurry versus the actual number differed by a huge amount. So I've come to the conclusion their figures are total bullshit.
If there's somebody from Flurry reading this please feel free to refute this and offer an explanation, if you can.
Related
Our Daily New User-count from Fabric is consistently bigger than the App Units per day that we get from iTunes Connect.
Fabric defines Daily New Users as
The number of new app installations across all devices seen on a given
day.
And iTunes connect defines App Units as
The number of first-time app downloads made on the App Store using iOS
8 or tvOS 9, or later. App updates, downloads from the same Apple ID
onto other devices, and redownloads to the same device are not
counted. Family Sharing downloads are included for free apps, but not
for paid apps.
What can cause this discrepancy? I can see many reasons for how Fabric could report a lower number (such as users downloading the app but never opening it, or waiting too long to open it), but not the other way around. Our average send-usage-to-developers opt-in rate is 23%, but that does not affect the App Units number if I am not mistaken.
Is your app available on both iPhone and iPad? If so, then the fact that, as you point out, Apple doesn't count downloads from the same Apple ID onto other devices might be causing this discrepancy? You can install iPhone apps on your iPad even if it's not officially supported, so the rule might still be affecting your app. Also, if your app is a paid app, then the Family sharing rules would also affect the numbers. I've actually wondered how iTunes counts new users, so thanks for that info!
I'm not sure why the numbers are consistently bigger for you on Fabric, because for my app they alternate a bit.
I hope you might have got the answer. If not follow the link below http://help.apple.com/itc/appanalytics/#/itc7bea1545f
It seems there are users who don't opt-in app analytics data.
Apple only shows data from users who have agreed to share their
diagnostics and usage information with app developers.
I want to write an iOS app that helps users concentrate on their work by preventing them from accessing particular apps on their devices for particular amount of time.
I googled around and found some "help-to-concentrate" iOS apps, but they mostly just help us to keep track of our usage of the phone (amount of time we spent on the phone, number of times we turn on the phone...). So, I do not know whether it is possible write an iOS app that can block some other apps on the device for a period of time or not?
If it is possible, can you please suggest me any keywords or Swift libraries that support this task?
Thank you.
Since Apple doesn't allow any app to access the files of other apps, it is impossible. It's just a safety measure for the users. Just use another practice to keep users "concentrated".
I am switching my iOS app which is already on the app store from paid to free. I want to know which users have paid for the app, so I can treat them differently (like not showing them additional ads). As far as I know, there's no way to get which version of the app users originally downloaded.
One thing I thought of is this. I can release an update at the same time the app goes free. Everyone who launches the game for the first time who has the update gets marked with a "Free Download" flag. The issue here is what if someone paid for the app, then didn't launch it, then updated their app. That means I will treat them like a free user even though they have paid. Thanks!
There's no way to do this with 100% accuracy without releasing a new app.
If you do use a flag of some sort, save the flag in the keychain and/or iCloud so that it will have a better chance of persisting across uninstall/reinstalls and from device to device (if you use iCloud).
Your best bet though is probably to release a new lite version of the app. It can be a pain to maintain two versions, but at least you know for sure who's paid and who hasn't.
I somewhat accomplish this with a server-side script. On initial app launch, I grab data from my server to determine if this is a paid or free install and then save this info in iCloud. It works relatively well, but it does have a drawback; a small percentage of the time the query fails. If it fails, I just set the app as being paid so as not to screw anyone over. This screws me over a bit, but I take the hit for the convenience of not having to update whenever I want to switch paid/free.
You cannot show updates or advertisement for the customers separately who bought the app for free or by paying money. Whenever you changed your paid app to free, the customers can download the application for free now.
I would like to put a free version of my ios app on appstore. This is a data driven app that remembers events on certain past dates. Can I limit the time of past event to ,lets say, 2 weeks? And if the client want to see the events added more than two weeks ago, he has to upgrade to full (for a fee) ? Is this possible, or will the app be rejected by the apple review process?
You'll probably be able to get away with this. You'll likely want to use an In-App Purchase mechanism to unlock archived events as opposed to having separate free and paid versions of the apps on the app store.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Can anybody help me out to know the possible reasons for which Apple store can reject or raise objection to submit any iPhone application.
Here are possible reasons (unofficial, from here):
Vibration. It is not permitted to use continuous vibration in your apps - short bursts as warnings is all that is allowed. Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.
Linking to private frameworks. This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework. That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.
Improper handling of editing in tableview cells. Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not. We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge. Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.
Icons. Make sure the 57 pixel icon is identical to the 512 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … the bin.
Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.
Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)
Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.
Network Reachability. If your app requires any type of network access you need to make sure it works when that access isn't available. If it doesn't it will be rejected. Apple provides sample code to test this which you can use as-is in most cases: https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html
And last, but not least:
Flatulence Don’t even try. ;-) UPDATE: sorry, this seems to be outdated by now. Apple makes a lot of money now with "fart apps": see this article.
Edit:
Here is a link to a recent article about ten iPhone Apps That Didn't Make Apple's App Store.
And a tip: Apple has a Mac app called Application Loader that you could install. Once you install it, it analyzes your app's zip file. It verifies all the certificates, icons, and other things are correct before submitting to Apple. Using the Application Loader minimizes your chances of app rejection.
Another interesting resource: App Store Roundtable: Transparency and the Approval System (appleblog.com)
Yet another edit:
New rules by February 2010: "No Swimsuits, No Skin, And No Innuendo" (source: TechCrunch article, Wobble author's blog)
By the way: during the iPhone 3.0 preview event (march 2009), an Apple spokesman told that 96% of all submitted application were approved.
Apple have now (as of 9th September 2010) published their official list of app store review guidelines:
appstore approval guidelines
(apple developer login required)
or a mirror here:
app store guidelines
Will apple want to create an app like that in the future? If (yes) reject.
Do you have a really awesome idea that apple may want to use in the future if(yes) reject
Here's the video of the SDK announcement that describes Apple published list of rejection criteria:
SDK Announcement
As others have noted, Apple also seem to have a bunch of other conditions that they don't publicise. Note that rejection notices are now covered by the NDA.
I can't confirm this but it makes sense, but people are reporting their apps being rejected for being too simple or too trivial.
Just got a bounce for handling network outages badly. If you connect to the network, be prepared to handle any error conditions that may come up.
My paid version of app was rejected by appstore.
After Purchasing and downloading app first screen was "User Agreement" and when user taps on " I agree" only then he is able to continue using app.
Apple described the reason of rejection "when user purchased app from appstore and download in phone then you must not restrict user to Agree with Agreement" instead display your agreement before downloading app in iTunes.
Amazingly, apps can get rejected for trying to keep their interface consistent with Apple's own apps. (ie, using pinch zoom/expand gestures)
There is a site I know which can help you generate great advertising ideas with iPhone. see this site:
http://itunes.apple.com/app/adpack/id359562015?mt=8
I submitted a paid app to app store but get rejected and i learned another possibility of app rejection
My app was Game Center enabled. When app starts first screen was login screen that prompt user to login through GameCenter to continue.
They rejected the app giving reason- As user will not be able to get services of your app unless he is not logged in with Game Center although he paid you to download app. You cannot restrict user to login through Game Center each time before app starts.
From 1st May,2013 onwards if we don't support iPhone 5, your app will be rejected.So iPhone 5 support is must.