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.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Does apple view the actual source code when approving apps?
So I'm gearing up for my first submission to the App Store, but before I submit I have a quick question or two.
1) First off - when submitting, will Apple be looking through code and verifying its correctness or just testing the App itself?
2) If Apple is indeed looking closely at the code, does whether or not you follow Apple's suggested paradigms influence whether or not the App is accepted? For example; In my program I frequently use [self dismissViewControllerAnimated::] rather than the Apple specified way of using delegation to have the presenting VC dismiss its presented VC's.
Just like to get feedback from people who maybe have already gone through the process and could give feedback on the experience. Thanks for your time!
Apple will not look at your code. All you submit is your binary application.
You are not going to submit the source code so be patient, none will stole your cool patterns :)
However, there's usually a good reason to recommend one or another approach, you'd better to think about following Apple recommendation not to appear among a lot of deprecated, slow or even disabled functionality.
Another point is that while they are not looking through your code directly, they are still kinda able to catch the used methods symbols which allows them to detect the private API usage and sometimes the app gets rejected just for your method being the match to the private API method from a signature, that's not happen often, but you better be accurate.
Another free recommendation for you - store the .dsym file somewhere, it will help you to symbolicate the crashes which could appear later right from the report file (you'll also need the app binary for that).
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!
I have a question for the iPhone Development community. I am currently building my first app, and on two of my views I have some buttons. Sales and Marketing have requested that these buttons do nothing and have the title of “Feature Available in Pro Version” or have a title of an application but when touched, an UIAlertView is displayed stating “Feature Available in Pro Version”.
First off, I think this is wrong from a user interface and experience. Secondly and more importantly, I think this will cause a denial when I finish the application and send the app in to the App Store for approval. I have look into the iOS Human Interface Guidelines and really can not find whether this will be an issue or not. I would like to tell Sale and Marketing that their request is stupid and will not get the application approved and they need to stick to their jobs and quit trying to play programmer.
Any comments would be greatly appreciate.
Quoting http://developer.apple.com/news/ios/appstoretips/
Only display the UI for what your "Lite" version will do. Grayed out menu commands, "more track/car choices" you can see but not select, etc. makes your "Lite" version feel more like a commercial than a product, and an annoying and ineffective one at that.
...
It's important to follow these simple rules not only to create a better user experience, but also because your app will be returned to you by the App Review Team for modification if it is found to have time limits, incomplete functionality, or disabled functionality.
Come up with some better options for your clients. They are not trying to "play programmer", they are trying to market their product. Also, try to mitigate the risk of the app being rejected by getting it in a submittable state as soon as possible, or at least make sure that you have a plan B for the things that you suspect might fail to get approved.
It sounds like you're just looking for a stick to beat your sales and marketing team with - there are quite a few apps out there in the wild that exhibit precisely this behaviour, painful though this might be to you. (The buttons do something after all - they show a dialog.)
That said, it's hard to recommend a more pleasant alternative without knowing more about your app. (Does it have the concept of "levels" for example? If so, you could replace the buttons with a nicer "purchase the full app to unlock additional levels" style message.)
I am pretty sure this never used to be allowed. If you show user interface elements they have to be fully functional. I don't know in which document or agreement this is stated, though.
It also may not cause your app to be rejected, at least not initially. The app may be removed from the store at a later date, though.
Apple has been known to quickly reject apps for non-functional or grayed-out buttons, especially if these non-functional UI elements are just to advertise Full or Pro versions in Lite apps.
Apple has also been known to approve apps with a non-functional button or two (happened to one of my apps, got a bug report several weeks after the app had become available in the App store), but this is probably due to oversight, and not a policy that anyone should count on.
If you want an advertisement for your Pro version, make it look and act like a standard in-app advertisement, and not a misleading UI element. Serving house ads, or mostly (99%) house ads is a widely done practice.
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