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.
Related
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 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
Pretty self explanatory...Which day of the week does the App Store get the most traffic?
I run into this dilemma every time I release an app. Anybody have raw statistics and not just anecdotes?
Edit I'm referring to actual App Store visitor traffic. I'm trying to maximize views as a new release. Don't have a lot of marketing budget so those early days count.
I can't imagine why this is really much of a dilemma that you run into every time you release an app.I really don't feel this is the kind of thing you should be worried about if your goal is to actually increase the appeal of your app. There are so many more important and more consistent variables, especially compared to the small handful of potential browsers that this kind of "optimization" might bring you.
Here are some more important things to concern yourself with:
The quality of your app.
See number one.
...oh yeah, and also see The Guide to App Store Marketing for more pro tips.
Only Apple have the real numbers. Developers might be able to tell you which days they get the most sales on, but this isn't quite the same as where the traffic comes from.
Anecdotally, it seems that the days you get most of your sales depends on the type of app. Games do better on weekends and holidays. My apps (social networking) are pretty consistent across the whole week.
There is no universal best day of the week for apps. The target audience for one type of app will have a different schedule with respect to people interested into different kind of apps.
For a particular app analyze the audience and their typical behavior and work out the best schedule for that given app. Expect to redo the work if you bring out a different app.
You are actually better off by monitoring the daily and weekly download/sales figures and use that numbers as a basis for timing an update. Users like updates to their apps and unless you have available an industrial size advertising budget then word of mouth tends to be the best bet.
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 was wondering if It is possible to "register" an iPhone App Name before the app goes on the app store?
Example:
A developer comes up with a really clever name for a iphone game.
He wants to register the name before he programs the game so that no one else comes up with the same name.
Yes, you can, but only for a limited amount of time. When I tried it, the time period was 120 days, but this may have been changed to 90 days. EDIT: It seems that this is now 180 days, based on the comments below.
A developer can choose enter information about the application before uploading it, but Apple will remove the app and it's meta information if the name is not used within the grace period. You cannot use the name ever again after that.
I have, however, some apps that were rejected on the first review and were never re-submitted. It seems that those names are still available to me. Just don't submit a really lame first submission or Apple will know that you are "parking" the name.
Here's a screenshot of my email from Apple:
You can squat a name for something like 90 days per recent Apple iTunesConnect changes. If you do not upload a binary in that time, it will be deleted and you will be unable to use it again.
There exists a loophole I have found though I don't know how long it will stay open. It seems that uploading a binary, any binary, then immediately rejecting it will prevent you from deletion. I don't condone squatting, but sometimes, apps take longer than 90 days to develop.
If you have the money, not only submit the name in iTunes Connect, but register a trademark on the name. If you don't, than someone who does, and gets to market first with any other mobile platform game, might try to take the name from you, or involve you in legal wrangling in an attempt to do so.
You might also want to quietly snap up all the relevant domain names, if you can.
A developer can upload basic information about an app including the name before the binary is ready to be submitted. The developer needs to be set up in iTunes Connect and have an active Developer Agreement.
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?