I've seen a lot of answers out on SO detailing how to accept user input on an UIAlertView, but I was wondering if doing so violates Apple's iOS Human Interface Guidelines.
According to the section on Alerts,
Avoid creating unnecessary alerts... [alerts] are usually unnecessary if they... [a]sk for confirmation of user-initiated actions. To get confirmation for an action the user initiated, even a potentially risky action such as deleting a contact, you should use an action sheet.
However, I wish to use a Alert view to prompt the user to input a password, much like Apple does when a user purchases an app from App Store.
I'd appreciate any input!
As Apple does this in many locations, I don't think it violates the HIG. I can also say this with confidence because of something I learned at WWDC. I would advise you to look on the Apple Developer site under the prerelease documentation for iOS 5 on UIAlertView (unfortunately I can't say more on here since it is under NDA).
I can see how they would reject it for something their own app does such as login using an undocumented API (as said by Karithikeyan). However I think the odd alert view here and there can't harm your chances of getting in the store.(Used for input)
(To give an example of how I have used the Alert View differently without problems).
I sometimes use the alert view for my loading indicators. I get the alerview and put the indicator inside while it spins, and I have had no problems doing this either.
My advice: use it with restraint but do not fear rejection. If it seems right to use, it probably is.
As far as i know ,
i dont think so that apple will reject bcoz my one of my app released in the appstore for using a UIAlertView to prompt user to enter login Credentials ,
my vote is you can go with it!
be sure you are using addTextFieldWithValue this method to create your alertview bz this is undocumented API , you will get rejected.
so better use normal methods to design your alert!
Related
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 have been reading around trying to find a definitive answer on if subclassing UIAlertView to change the background color is ok with Apple.
I know the apple documentation states:
Subclassing Notes The UIAlertView class is intended to be used as-is
and does not support subclassing. The view hierarchy for this class
is private and must not be modified.
Yet I have seen many people attempting it and some stating that they have done it with no problem.
Can someone give a solid Yes or No answer as to if I should do this or not in my app.
I know I will have to take it with a grain since it is the app store and the last time one of my apps was rejected and I appealed the Apple representative only stated, "The app store is an ever changing marketplace where acceptance is at the discretion of the team." click
Nobody can give you a solid yes or no. Just because an app on the store does something doesn't mean you will be accepted for doing the same thing. My gut says as long as your alert behaves like the standard one and isn't horribly ugly, you probably will be fine.
How can I suspend my application or send a suspend message to my application?
I want to simulate pressing the home button.
There is a private instance method for UIApplication:
The following code would work, (tested in an iPhone 3GS):
UIApplication *app = [UIApplication sharedApplication];
[app performSelector:#selector(suspend)];
In swift:
UIControl().sendAction(#selector(NSURLSessionTask.suspend), to: UIApplication.sharedApplication(), forEvent: nil)
Edit Swift3:
UIControl().sendAction(#selector(URLSessionTask.suspend), to: UIApplication.shared, for: nil)
Quitting your application or sending it to the background programmatically is a violation of the iOS Human Interface Guidelines, which usually doesn't bode well for getting through the review process:
Don’t Quit Programmatically
Never quit an iOS application
programmatically because people tend
to interpret this as a crash. However,
if external circumstances prevent your
application 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 application 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
application. It puts users in control,
letting them decide whether they want
to take corrective action and continue
using your application or press the
Home button and open a different
application
If only some of your application's features are not working, display
either a screen or an alert when
people activate the feature. Display
the alert only when people try to
access the feature that isn’t
functioning.
The philosophical reason for this is explained earlier in that document:
People, not applications, should
initiate and control actions. Although
an application can suggest a course of
action or warn about dangerous
consequences, it’s usually a mistake
for the app to take decision-making
away from the user. The best apps find
the correct balance between giving
people the capabilities they need
while helping them avoid dangerous
outcomes.
Users feel more in control of an app
when behaviors and controls are
familiar and predictable. And, when
actions are simple and
straightforward, users can easily
understand and remember them.
People expect to have ample
opportunity to cancel an operation
before it begins, and they expect to
get a chance to confirm their
intention to perform a potentially
destructive action. Finally, people
expect to be able to gracefully stop
an operation that’s underway.
There should be no reason that you need to force your application into the background during its operation. It should remain fully functional when displayed onscreen and it should be up to the user when they want to switch away from your application.
You can't do this.
If you want to exit your app, don't fear rejection and love false positive crash report emails from users you could call exit(0);
Use :
sleep(15)
it will suspend your app for specific time
When the application is suspended, a UIApplicationWillResignActiveNotification notification is posted.
I would guess you could try to post this notification manually. Didn't try this myself though.
Someone wants me to make an App, where the NavigationButton (usually top left) shall be put into the Tabbar (in this case leftmost Button of the Tabbar). I wonder if that might yield a possible rejection.
It reads in the Appstore Review Guidelines:
a) Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected
-> Could that also include NavButtons?
Furthermore:
b) Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines may be rejected
I do not know whether we crossed the line there.
What's your opinion on this?
I'd say it's a bit of a crap shoot and you need to weigh whether the feature is important enough to possibly delay your release by 2 weeks or more. If you submit it with the feature I would spend some time working on a different solution so that if it is rejected you can submit with the changes right away.
From personal experience, I had an app rejected because they didn't like the image I used on a button since that image was meant to convey "picking a contact for use in the app" not picking a contact to add information too. It was my opinion that this was a petty almost silly thing, but I corrected it and resubmitted. Both reviews took over 2 weeks. So it took me over 4 weeks to get approved.
Apple has gotten better about telling you what won't be accepted, etc. But different reviewers seem to have different opinions. I'd say the description of your feature is likely to be rejected, but you'll never know until you submit it.
Instapaper has a back button in a tab bar at the bottom. I think that if you decide to do this, you shouldn't use the system back button but create your own. Using the system button feels like a HIG violation.
I just added a done button on my number keyboard and read that using the keyboard class directly is illegal but some people said that their app was successfully submitted to the app store? Does anyone know if it is legal or not?I have been googling around for 1hr and I keep getting yes and nos.. anyone knows for certain if this will cause the app to get rejected?
Thanks
It is not absolutely sure that doing something like adding a DONE button to a numeric keyboard is legal or not. It all depends on Apple, some app is rejected but many apps is already approved by Apple. It is hard to say.
It also depends on your technique as well. Usually, I see that people will work into the UIKeboard view hierarchy to add the DONE button and for this case, the usual approval problems is like I described above, some fail, some succeed