I am planning to submit an iPhone app for certain special purpose calculations. I want to add a legal disclaimer about the calculations somewhere so that the user can see it atleast once before starting to use the app. Should this go into the EULA that may be submitted as part of app submission process? Or should that be a one time screen shown when the app is started first time? What is the right way?
Thanks for responses.
The EULA would be submitted as part of your delivery to the App Store, so as to be displayed alongside the app’s entry in the Store (so the user can read prior to purchase).
But you’d also be well-advised to display the very same language the first time the app is launched, prompting the user to “Accept”. (Ideally, if it’s more than one page, you can make it so the Accept button is disabled until the user scrolls to the bottom of the text.)
If you want to be even more thorough, you could prompt the user to accept the EULA the first TWO times the app is run, just to be safe.
Hope this helps!
Show it first time the app is shown, or if it isn't crucial, add a mention in the app description.
Related
I have implimented SKStoreReviewController in My app. I just want to know how the functionality works. I need to satisfy below requirements.
I need to disply popup in all the 3 cases
For first 10 successful logins
After every 90 days
I don't want to disply rating popup never if he provide the rating.
How do I know if a user gave the rating and also I need to send
response to server if user gave the rating.
SKStoreReviewController submit button is active after your app is live in appStore. The submit button is automatically disable when you're running in debug mode. It's only active when you're launching your app in appStore. That is not mistake from apple or Xcode.
Thank you.
Apple provides some suggested best practices and sample code for requesting reviews.
In answer to your requirements:
This is definitely not best practice; after 10 successful logins might be a reasonable time to ask for a review, but asking each time the user logs in will probably just be annoying.
Again, asking after 90 days is probably a reasonable interval.
By design there is no indication to your app as to whether the review request was shown, nor whether a review was left.
You can link directly to the App Store page where the user can provide a review, however you still have no indication of whether the user actually left a review or simply cancelled out of the web page.
The sample code I linked to shows how to track whether you have requested a review for the current version of your app. You cannot know whether the user has actually reviewed the current version.
I want ask my users to rate my Unity iOS app using the following code
Device.RequestStoreReview()
But this function returns true when the library is present and false otherwise. I want to know whether the user
Allready rated
Clicked "cancel" or clicked "not now"
So that I don't have to ask that to the user every single session
You can make a custom UI with buttons to check if the user wants to review the app or not. If the user decides to give the review you can open the app store with Application.OpenURL. You can then save user action (reviewed, ask later, don't ask again) as a flag in PlayerPrefs. Use this flag in your app to decide when and how often ask the user for a review.
As far as I know there is no way to check if the user left the review or not but if they decide to go to app store, most will leave the review and even if they don't the app just won't ask them again. It is good enough for me.
This approach is also platform independent (as long as you can use Application.OpenURL you can forward your user to any app store/website for a review).
So I have an app which is already on the app store and i’m now trying to implement the SKStoreReviewController.
I’ve added the logic for handling and showing the dialog via the request review method. But this dialog only appears 3 times on a fresh device and on other certain devices it’s not appearing at all.
It’s almost acting like the app is live on the app store. An addendum to this is once a user rates the app, will the popup dialog be shown again?
Although, it is not mentioned in documentation: No matter how many times you call the API, the system will only show up to a maximum of 3 prompts to the same user in a 365-day period. And it will be shown once for one version.
The alert is always shown in debug. Note, a user can disable rating alert at all going to Settings -> iTunes & App Store -> In-app ratings & review.
More information here.
Ensure that your device has an internet connection. For me it did not work when my device was in airplane mode.
I am aware apple won't support exiting an application programmatically, But I want to exit my application if the user not agreed to the license agreement? Is it possible to restrict the application loading if declined? or What can I do in this case?
Do not crash or force close or find ways to close your application. If user's doesn't accept the agreement then they might not be interested in using your application eventually they will delete it. BUT, do as the protocols say, Display an agreement alert (if you already have an EULA) then point towards the same and ask user that they will have to accept the agreement in order to use the application.
Other ways could be, give a preview of some of the screens (for those who doesn't accept the EULA), if they like your screens then ask for agreement acceptance.
Hope it helps.
I would suggest you just keep re-showing the license agreement. If they pick "No", have a popup saying "You must accept the agreement to use this application", and when they tap "OK" re-direct them to the agreement confirmation again.
You can show a separate view apologizing that without the user giving consent, they will not be able to use your app. That's another opportunity to have them change their mind, by the way.
In one of my app what i did was i have shown the agreement to the user and have asked him to accept or decline it.
If the user declines the agreement then i have shown a pop up informing the user that he cannot proceed further in the app if he declines the agreement and i have kept him on the agreement screen only.
Manually if you exit the application then your app will be rejected by apple because apple does not want an app to function in that manner.
Hope this helps...
I suppose NSAssert(NO, #"The user failed to accept the EULA"); would work, perhaps within a delegate callback after presenting an alert view indicating that the application will now exit due to their declining to accept the terms. Then you could easily track the assertion failure in crash reports to determine how many people were rejecting the EULA.
I couldn't say if this will make it past app store review though.
Apple does not recommend using exit(0), but I believe it should be OK in your case, since the app should not work if the user did not accept the license agreement
But using it to exit a regular app operation is discouraged.
[[UIApplication sharedApplication]performSelector:#selector(suspend)];
But exiting app like this is not a good practice.
You can display a notice to the user, and then launch them to your website or facebook page. This will provide a break in flow as opposed to a dialog that will just appear and disappear until the user feels coerced into clicking "I Agree".
You can also set UIApplicationExitsOnSuspend to YES in your plist which will terminate the app one it goes into the background. Then you will get a full relaunch when the user comes back into the app from your website. Information on how to do this is here: UIApplicationExitsOnSuspend anything else I'm missing?
I have been reading The Business of iPhone and iPad App Development: Making and Marketing Apps that Succeed (http://www.amazon.com/Business-iPhone-iPad-Development-ebook/dp/B004TMNSJK/ref=sr_1_2?ie=UTF8&qid=1340317546&sr=8-2&keywords=marketing+iphone+apps). The book is a little old (about a year at this point, which is a long time considering how long the app store has been around).
The book claims the Apple's iPhone development guidelines/rules state that an app must be fully functional. The book says that because of this rule, a "free" or "lite" version of an app cannot display buttons that appear to be functional but, when clicked on, prompt the user to purchase the full version of the app. For example, imagine a GPS app that has a button labeled "Give me turn-by-turn directions as I drive". If you click on the button, it just pops up a dialogue that says "Buy the full version to unlock this feature". According to this book, that app would be rejected by the Apple review team.
I have an app that allows users to download extra content with an in-app purchase. I would like to display the content as "grayed out". If the user clicks on the locked content, I want to display a popup that tells them how they can get the additional content. According to the book, this behavior will be rejected.
However, since this design is so important to my app, I've spent some time reading through all of the iPhone app guidelines, including the In-App Purchases guidelines, and I have found NOTHING that leads me to the conclusion that this sort of behavior is not allowed.
Since the app review process is currently sitting at about a week, I don't want to lose a full week of app purchases because of a rejection for this. Has anyone ever heard of this rule, and if so, can you please point me to it?
Thank you.
I had a "Free" or "Lite" app recently submitted (and accepted) to the App Store, where some UITextFields were greyed out and when touched, a UIAlertView was displayed . I don't know if this would be acceptable with buttons but it seems like more or less the same thing.
I think the book is probably right. Please check this link or read below.
The two most common reasons for application rejection are issues with core functionality and crashing. Core functionality encompasses the belief that customers rightfully expect all the features described in the marketing text and release notes to work as described, and likewise that all the buttons and menu items within the application will be fully functional (i.e., no grayed out buttons or notifications that a feature will be implemented later). Before you submit your app for approval, make sure that every aspect of your application is fully functional and that the marketing text and release notes correspond to the end user experience.