This question already has an answer here:
Closed 12 years ago.
i'm writing a tweak for iPhone that at certainly point needs to set the ringtone, but i'm not able to find how to do that.
Can someone tell me how to do that, put me in the right direction where to look or just tell me a website where to search or maybe in some wiki?
All i've found are useless answers.
More Info:
I need to know how to set ringtone for a tweak so the solution can be only for jaibroken devices.
Thanks!
You cannot set the user's ringtone using the iOS SDK. If you need this ability, consider filing an enhancement request at https://feedbackassistant.apple.com/. However, as this feature would annoy the unholy poop out of almost every user on the platform, don't hold your breath.
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).
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.
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 7 years ago.
Improve this question
I hope this is the right place to post this. If not, please redirect and I will be happy to move.
I am a little confused about the App Icon that represents our app in iTunes and on the devices. I am having some questions, specifically, about licensing for the icons I choose to use.
Technically, I was wondering of the app icon is officially defined as a 'logo'. It seems like if it is called a logo, on many sites you have to buy the exclusive rights to an image before using it as an app icon.
Otherwise, it seems like you can simply purchase an extended license. Obviously this differs from site to site, but they seem to all say I need a simple extended license when I describe the use, then they turn around and say that a logo needs exclusive rights. It's too bad that mant of these sites haven't addressed iOS applications as a category specifically.
Additionally, we specify several icon images within our apps in the plist file. I think I read somewhere that we might need a separate license for each of these icons, even if the same image is used repeatedly.
I could really use some feedback on this issue. I want to be compliant with the law and respect the needed licenses, without spending way more than I need to, and I already have app icons out there (and can't get a consistent answer from the site where I bought the icons) so I don't want to go the paid designer route. Thanks.
First off, we are not lawyers. We cannot give you legal advice.
That said, you should not use art you do not own in your app, regardless of how you use it. As an app icon, it may well count as a logo depending on the legal/applicable definition of that term. It certainly counts as copyright infringement if you don't have the rights to the art in question.
Ideally, the company you're working with should be supplying the app icon and other art. If they're unable to do that, they don't sound terribly professional. Art is not (usually) the coder's responsibility. Check with the company and get a consistent answer.
As Jonathan said so well above, I am not a lawyer, so take this with a grain of salt... it is not legal advice.
Whether or not an image can be used with an extended license, without full-on purchasing the rights, seems to depend on it is technically a logo or not. Also, whether you are trademarking the image. The logo part is where things get grey... and I haven't been able to find any clear answer on it. There may not BE a clear answer.
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?