As you may have seen in some apps an alert pops up asking the user to rate the app in itunes and usually the alternatives you get to choose from is something like: Sure which opens the rate page for the app. The second option is No Thanks which closes the alert and the third option usually is maybe later which displays the alert later.
I was wondering how to do this.
I want the alert to be displayed after say the app has launched 20 times if that would be possible.
And how can I create an maybe later alternative which displays the alert maybe 15 launches of the app later?
And a final question is there a special link for the apps rate page? So when you click the sure button or whatever it will take your directly to the rate page.
I've used this: https://github.com/arashpayan/appirater. You can look at my fork as well for a specific mod I needed.
[EDIT: comment re NSUserDefaults]
I suggested this link because it is a full, working implementation of what you describe that is easily integrated into existing apps. I've used (and modified) it myself. NSUserDefaults is a general purpose mechanism for persisting app state. I agree with the others that it's a very useful thing to learn and use, it's just not a full answer to your question. If you choose to roll your own implementation of a rating system (nothing wrong with that) you will most likely use NSUserDefaults to store the relevant info.
Check out my answer for this similar question. I provide two different links you can use for taking the user to the "rate this app" screen in the App Store.
Direct "rate in iTunes" link in my app?
You can use NSUserDefaults to save the launch count (increment it in application:didFinishLaunchingWithOptions:), then save the user's choice another preference key. If the user says later, you could reset the counter back to zero.
I don't think there is a special rating link, but you can link to your app's specific App Store page. This was incorrect, as TomSwift points out; see Direct "rate in iTunes" link in my app?
I wrote a library for doing this with minimal effort on your part:
https://github.com/nicklockwood/iRate
I'd recommend using a library rather than rolling your own solution. It may seem like a simple problem but the library takes care of a whole bunch of extra stuff, like ensuring that the user is prompted for each new installed version, that they are reminded after a certain time if they decline, that they aren't prompted to go to the app store unless they have a network connection, etc.
Related
I am a newcomer to application development and I'm wondering if the concept I have can actually be created.
My concept involves creating an app that has the ability to embed another app within itself.
I'll do an example which is also a very bad one but you'll at least get the point.
Picture an app on the iphone that's called "Kwesi's app". Once you tap on it, it opens up a page with 3 icons. A facebook icon, a gmail icon and a hotmail icon. Now tap your finger on the gmail icon and instantly your gmail opens up withing "Kwesi's app" and you have full access. There is also a button in the top left corner that says "Main Menu". Once you tap the "Main Menu" icon, you go back to the three icons and can now rinse and repeat.
I hope this example is clear enough.
The question I seem to be coming back to is, would it be possible having an application that embeds or links you to other apps in that manner? I can only guess that it'd be really weird since they'd have to be installed seperately on your phone but I don't want that. I want one app that can handle an already set amount of apps within itself as the above example shows.
Thank you very much for reading and any thought would be very much appreciated.
/Kwesi
No, that is not possible in iOS for security reasons. But you have the following choices to modify your idea:
Register a protocol for the app : This will allow you to send data between applications using protocols. However, if the app wasn't made by you and doesn't have a protocol, then you can't use it.
Using this idea, it is possible to open an application. For example, opening Facebook with "fb://" or evernote with "evernote://". I am sure there are other applications that have these protocols. Just be aware that you don't have control on the application in this case. You can only open it and send data to it.
Since your example was about Facebook, Gmail. Then I would suggest using their corresponding API and build everything in your application. Many famous applications provide APIs for a fee or free usage. You have to check with each one separately.
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
Does anyone know if exit(0) is deprecated in iOS application? I know it is not a good decision to manually terminate the app, but does Apple ban the application if we use it in the code?
I got an app which was rejected because of a way of exit (via UIAlertView), doing an exit(5) when user click on the correct button.
I received that:
We found that your app includes a UI control for quitting the app.
This is not in compliance with the iOS Human Interface Guidelines, as
required by the App Store Review Guidelines.
Please refer to the attached screenshot/s for reference.
The iOS Human Interface Guidelines specify,
"Always Be Prepared to Stop iOS applications stop when people press
the Home button to open a different application or use a device
feature, such as the phone. In particular, people don’t tap an
application close button or select Quit from a menu. To provide a good
stopping experience, an iOS application should:
Save user data as soon as possible and as often as reasonable because an exit or terminate notification can arrive at any time.
Save the current state when stopping, at the finest level of detail possible so that people don’t lose their context when they start the
application again. For example, if your app displays scrolling data,
save the current scroll position."
It would be appropriate to remove any mechanisms for quitting your
app.
A "hidden" exit could be understood as a crash for the user, no?
No, Apple will not reject your app for using exit(0).
You are correct, it is not a great design choice, but it can be useful sometimes.
As Larme mentioned, if used incorrectly, it can be perceived as a crash and a crash will result in your app being rejected.
However, it can be very useful in applicationDidEnterBackground when (on a conditional basis ) you might want to force the app to start a fresh.
No, you must not call exit as your app SHOULD be rejected. This has been repeatedly discouraged by Apple and is known to cause serious bugs with iOS multitask switching. You should simply leave the user to use the home button themselves.
http://developer.apple.com/library/ios/#qa/qa1561/_index.html
"Additionally, data may not be saved, because -applicationWillTerminate: and similar UIApplicationDelegate methods will not be invoked if you call exit. If DURING DEVELOPMENT or TESTING it is necessary to terminate your application, the abort function, or assert macro is recommended."
2012-04-09
Updated to more strongly discourage the exit function, and include best practices for debugging.
2008-08-27
New document that discusses best practices for terminating an iOS application in code.
Straight from the iOS Human Interface Guidelines
http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html#//apple_ref/doc/uid/TP40006556-CH20-SW27
"Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your app from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the app malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your app. It puts users in control, letting them decide whether they want to take corrective action and continue using your app or press the Home button and open a different app
If only some of your app's features are unavailable, display either a screen or an alert when people use the feature. Display the alert only when people try to access the feature that isn’t functioning.
If Necessary, Display a License Agreement or Disclaimer
If you provide an end-user license agreement (or EULA) with your iOS app, the App Store displays it so that people can read it before they get your app.
If possible, avoid requiring users to indicate their agreement to your EULA when they first start your app. Without an agreement displayed, users can enjoy your app without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your app, do so in a way that harmonizes with your user interface and causes the least inconvenience to users.
If possible, provide a disclaimer within your app description or EULA. Users can then view the disclaimer in the App Store, and you can balance business requirements with user experience needs."
I'm creating RSS reader application, and just wanted to know do I really need to include UIRequiresPersistentWiFi in my Info.plist file?
The only case I would find is the user read really long (loaded) article (or he read slowly) for more than 30 minutes, and boom the wi-fi get off, and he need to turn it back on.
This is super rare I know but I'm just concerned...
Thank you!
While it wouldn't be required for this type of app, for the user experience sake, I would present a dialog to the user upon the application first running to let them know that WiFi is not required, but is highly recommended. Maybe include a setting, letting the user choose if they want to put the app in "WiFi-only mode." This can be especially helpful as more and more carriers are switching to limited iPhone data plan models.
I am developing a game for iOS. I would like to implement a feature that allow the user rate my app and, if he does it, he will get points for my game.
I know how to display an screen, menu, whatever to ask the user rate my app, but I don't know how to know when the user does it, I mean, the user completes all the process and I get my valuation.
You will unfortunately not know this since apple won't give you the feedback on it. The best you can do is give them the "rate my app link" and attribute them with the points if they click on it. I've seen games that provided points to the user for rating and they give the points when the user clicks on the link.
The only thing you can do is to use something like Appirater
You could recommend to your clients to review and rate your app. But I think that you don't be able of know if they finally rate or not.
As a few people have mentioned not really possible to know if people who go to the store actually rate the App. But AskingPoint has an interesting solution that allows you to use your App Analytics (full disclosure Im a founder) to present your best users with a rating widget. We think this will increase the odds they actually DO rate it. And you will have the count of the number of people that were taken to rate on a given day, and could correlate that with number of ratings you got. It helps, but is not exactly what you want.
There is no way to know if a user actually rates the app. You can provide them with a callout to take them to the app store (with the intention of getting them to rate it). However you can't actually see if they rated it, only if they tapped the link in the first place.