Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have an App which is rejected which behaves as the Twitter App on the ground that:
10.4 Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected
with as description:
We found your app includes a dashboard view which presents multiple
windows at once, and is therefore not in compliance with the App Store
Review Guidelines.
The iOS Human Interface Guidelines allow for multiple screens in an
app but access to these screens should always be sequential, never
simultaneous.
Please see the attached screenshot/s for more information.
It would be appropriate to modify your app by determining an alternate
way users can accomplish the same task in a single screen or a
sequence of screens.
The screenshot attached is seen below. Can anybody explain what exactly the reason is, looking at the Twitter App. Anybody with a similar experience and a possible solution apart from completely dashing the current interface and putting the ordinary split view controller in?
While I applaud your implementation, it wont make Apple approve you any faster or even at all.
The reason they are rejecting, as they say, is because you can interact with all of those views at once. Standard navigation would push one view over the top of the last using the navigationController and sliding effect. Because Apple views this as a widget type effect where everything is all still running at the same time, you are getting the boot.
One suggestion might be to take a look at how Path and Facebook are implementing the navigation controllers with the slide out effect. You could probably implement something similar where you can just slide the old and the new views on screen. You still need to completely obscure the other views I think to pacify Apple for this rejection. Sorry their ruling wasn't more favorable. Good luck with your appeal and/or corrections.
They also say going to the press upon rejection doesn't help your appeal. Just FYI. I went through one appeals process and said "My app is just like X" and they said (literally), "Thanks for your feedback, unfortunately...."
I'd keep your appeals to yourself (not trying to be mean).
Last piece of advice is to make sure there are no detectable errors or incomplete parts of your app. The more polished it is going in the better.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I was curious as to whether it's possible or not to "wrap" and app inside another. For example, insert the code of YOUR app (hereafter referred to as cookie cutter) into an existing app (hereafter referred to as wrapper) with the wrapper app designer's permission, of course. and have your app sit latent for x amount of time. After x amount of time, the cookie cutter app pulls up and initiates its code. From that point on, the cookie cutter app is accessible by pressing a button in the top left corner of the wrapper app, which will switch views to the cookie cutter. My question comes in two parts.
Part A: is this something that apple would allow? I know there's a certain level of red tape regarding what apple allows and doesn't allow
Part B: Would this be possible, even if Apple allowed it? Would the way that apps are designed allow for this functionality to be part of an app in the first place?
By asking this question, i'm more looking for articles on the subject. It's hard to fit this entire question into a couple words that can be searched for on google. Any ideas? Thanks for the help.
I think this is not possible (I don't know whether it is possible in Jailbroken devices). In iOS each app is sandboxed, so you can't run an app inside an app.
Also running app, terminating it these kind of things are managed by SpringBoard (Simply os). So you can't do this.
Suggestion:
Why can't you simply display the Second app's icon (in imageView or in button) inside the First app ? When useer tap on that icon open that app using URLScheme.
Like:
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:yourSecondAppURL]];
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm working on an iOS shopping app where users are shown a popup where they can choose to proceed to checkout as guest or login if they are registered. The design requires the popup to expand to show the password field if the user wants to login (otherwise only the email id field is shown so that he can proceed as guest). If users enter invalid email id or leave a field blank, the popup is required to expand further so that the users can be notified near the fields.
The only issue is, the design is such that this whole popup has the color, gradient and animation of UIAlertView, including the buttons. And as the normal UIAlertView can't be used to provide such extended functions, I designed it myself (as a view) and I'm presenting it modally with animations so that it looks like a UIAlertView has appeared
I just wanted to know whether this kind of imitation could lead to my app being rejected in the app store.
There are lots of components that mimic or extend the Apple components, for example: https://github.com/domesticcatsoftware/DCRoundSwitch
With regards to your UIAlertView approach - there are loads of customized UIAlertViews on github as well, and these have been used in many apps, such as this one: https://github.com/eaigner/CODialog . .nothing out of the ordinary here.
As long as you conform to the Human Interface Guidelines with regards to sizing etc, it will be OK.
I can see another problem with your App, however. Apple will reject an application from the App store that excludes users, or is only usable by a specific group of users. So if you provide a sign-on feature, it needs to be easy for the user to sign-up (freely) or provide guest access.
May be:
App Store Review Guidelines
10. User Interface
10.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iOS Human Interface Guidelines may be rejected
See these docs:
https://developer.apple.com/appstore/resources/approval/guidelines.html
https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html
The way I understand Apple's guidelines they don't want you to use familiar UI elements in suprising ways thereby confusing the users.
By correctly imitating UI elements, you are not confusing the user (as he/she probably can't tell the difference between the native and imitated implementation). So I don't expect them to reject your app.
However, you will have more work to adapt your app to the upcoming iOS 7 design and in particular to create an app that concurrently supports the iOS 6 and iOS 7 look (which will be the reality for some time).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I finish building my app and I don't see any error on xCode 4.2! Do I need to test it on the Instruments before send it to appStore?
You don't NEED to test your app although it would be nice for your users, instruments will let you see the performance of your app and also whether or not you have memory leakages.
Give it a go if you can Instruments.
I strongly recommend you to test your app on a real device before submitting it to the Apple Store because in various situations (depending on the size and complexity of your app) there are some errors or warnings that don't appear on the simulator but do appear on the real device. An example on this is the Media Player (this post is an example).
Another important reason is that the simulator does not support all real device situations. For example you can not receive Text Messages (SMS) or incoming calls on the simulator, and it is important that you test your app for such situations (handle states of appWillResignActive, appDidBecomeActive...).
And as our friends noted above, it would be nice for you to see your app in the way your customers will see it before you sell it to them.
It's not mandatory, but I'd recommend it - particularly if you were an indie developer looking to start making your mark on the Appstore.
Any warnings that Xcode presents are also acceptable - but anything serious that occurs during runtime and through the things Apple will do to it during the submission process will be flagged to you; you'll even get a crash log. (again, as a rule of thumb I'd recommend clearing warnings where possible - and given any time restraints on the project)
Just remember that no matter how much testing Apple will do - their systems can and DO miss things, like specific configs or situations on iDevices that just happen. (just because iDevices are very less fragmented in comparison to say Android, things always occur!)
Hope this helps - good luck!
Also, you might find this useful:
http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial
Instruments is for performance analysis and is not necessarily a "part" of your app building process. It would be nice for you to do some profiling for your app using this tool so that you, as the developer, give the best UX to the end user.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I make an app which is a clone of a well-known game. I had the name of that game as a keyword in the first two versions of my app. Many competing apps also use the keyword.
I just updated my app. Apple said I couldn't have that keyword and took it out.
Meanwhile, a search on the name of the game brings up over 40 apps, most of them third-party apps which are not licensed. Now that the keyword has been removed, my app does not come up in the search, even though it is highly popular.
Is my best bet to:
a) Point out the discrepancy to Apple.
b) Try again in the next update
c) Give up.
d) Something else?
Apple's official policy changed a while back to disallow the use of competitor's products in your keywords. Have any of the other apps that use this keyword been updated recently? It's entirely possible that their use of the keyword dates to before this policy change.
If I were you, I'd go with "a) Point out the discrepancy to Apple" and probably ask them why they took it out to begin with.
If I were me, I would just ditch Apple and move on (Android, maybe even Windows Phone 7).
(a) and (c).
Using unlicensed trademarks as keywords seems to be a violation of the App store guidelines (but IANAL). If you point out those other apps to the review board, it probably won't help you directly, but there is some small chance that sometime if the far future when these other developers try to update their apps, the keyword will be disallowed for them also. But don't count on it.
Your being allowed that keyword originally is part of the luck of the game. Don't assume that a some amount of luck won't be involved with Android and Windows Phone (et.al.) App store revenues as well.
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 5 years ago.
Improve this question
I have submitted my first iPhone app and am now waiting for approval. My only fear is having it rejected because of some subtle nuance in the HIG, this is from googling around.
How does Apple treat the HIG, as guidelines or as gospel?
It all depends.
If you use the wrong icons for certain functionality. They will reject it.
If it is confusing to the user. They will reject it.
If the standard UI components do not work as expected. They will reject it.
If an operations fails without appropriate feedback. They will reject it
But they will usually tell you one item in the GUI that they rejected it for.
Thus when you fix it and send it back they can tell you about the next one.
They are definitely guidelines, but if you don't have confidence or a good amount of experience with UX, you should treat them as gospel. When developing mobile apps, I kind of feel that providing a good UX should be the highest priority. A lot of developers are pretty bad at UIs, and the HIG provides a very good set of guidelines to follow, at least at the start. You should owe it to yourself to give a HIG a thorough read.
Guidelines. The bottom line is that it has to work, not use any private API or violate the terms of the agreement. If it does what it says it's going to do and doesn't crash right away, you'll probably be fine.
It really depends on how much your devition results in a better user experience.
The HIG is there to help you build an application that users will understand how to use more or less from the start, and make the application easy to use.
If you do some custom things that improve life for the user, Apple will probably let it go. But if you are deviating in ways that make the application harder to use, they will tend to come down on you.
A lot of the possible rejections are pretty reasonably things - for example I was rejected once for a rotated view where the UI elements didn't quite all replace correctly. Once fixed (and it really was a bug on my part) the app was accepted.
The HIG is more a way to change your odds in a lottery. You greatly improve your odds by not doing anything that clearly looks like a violation of the HIG. There are web sites that list things that appear to at least one reviewer to be violations.
But there are many apps with fairly crufty UIs (that don't look HIG compliant to other devs) but somehow got accepted into the App store. On the other hand, one hears about other apps that are rejected for something that looked to the reviewer very different than it looked to you (would you confuse icon X for the completely different icon Y? & etc.) Or mistake the word "or" for "and" in one of the SDK Agreement rules?