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 8 years ago.
Improve this question
I understand that in the App Store rules :
-3.9: Developers are responsible for assigning appropriate keywords for their apps. Inappropriate keywords may be changed/deleted by Apple
-8.5: Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
I want to use the name of a competitor app as a keyword for my app, but the competitor is complaining that I am doing so (though many other people are also using it too).
For instance(not the real case here), my app is a photo app, I have put "instagram" as keyword.
I believe it's fair to use competitor's name as keyword as long as I don't outrank it. Apple also seems to suggest people to use trademarked name as "descriptors".
What would you suggest?
You are bound to US rules and those of your own country. Assuming rules of the USA and of the UK (I am from the UK which is why I include it here) you can use their trademark as long as you are only using it to draw a comparison or to describe your product, which you are doing here. You cannot use it in such a way that it causes confusion between your product and theirs. By the sound of things here you should be okay.
The only thing to be worried about is that if the other company complains there will be a period where the complaint is reviewed, during that time your app may be blocked from the app store so be prepared to wait while that is resolved.
After writting this I did a quick google and found the link below, it does a better job of explaining this than I have done. Be aware that the information below and in my own answer may not apply in your country. I am not a lawyer, I am only an app developer myself.
http://www.insidecounsel.com/2011/11/08/ip-using-a-competitors-trademark-in-marketing
I don't think it's fair to use competitor's name especially trademarks, copyrights and etc. Apple is doing so to protect your competitor's interest. And many other people succeeding in using it don't implies that you can use it.
Related
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 am developing an iOS app and I would like to receive payments within the app. I am selling a "real" good/service, so my profit margin on each sale is only around 20%. I can't afford to pay Apple 30% on each purchase made within the app.
What are my options for accepting payment without giving Apple a 30% cut?
Disclaimer: I have created and offer a standalone solution payment acceptance solution for small businesses.
The actual answer to the question you asked is, "select and integrate any of the various payment processors", but that's not very helpful.
I would second the other answer about looking for canned solutions unless you absolutely need to control the whole experience.
If you do still want to go down the roll-your-own route, you will need an enhanced vocabulary and some time to research on your own. First suggestion: look for relevant questions/answers on the net for "iOS app payment processing". The search engine of your choice should lead you to many possible answers from which you can refine your question or even, perhaps, find an outright answer that works for you.
You'll need to understand how you expect to capture payment information, process that payment into "money", and how you will manage your back-end. For example, you could use Apple Pay, but that by itself doesn't actually solve any of your actual payment processing issues (not to mention very likely unfavorably restricts your customer base if that's all you do).
Do alternatives like Stripe, Braintree, and more have their own APIs? Yes. Can they be used with Apple Pay? Yes. You could try implementing them then coming back here with specific questions.
Separate out questions like "How do implement Stripe payment processing?" from questions of the type "What are some of the options for knowing when an item needs to be shipped, where to, and when it has been accepted?" (Which won't be appreciated here -- you'll also need to research/write at least an attempt at this before asking.) Each type of question will need to have a "show your work so far" component as well as a clear (as much as possible) problem description in order to get responses that are pertinent.
Real world goods don't need to be set up through in-app purchases. You can use other services such as Stripe or Authorize.net to set up payment flows in your app that way.
Note that you'll most likely also need a web service and server backend aspect as you'll need a centralized location to keep track of your real goods inventory and perform the actual transactions of charging your customers, updating the inventory and starting the process of fulfillment. Of course, this isn't true if you're creating an app to manage payments of your flea market sales, but in that case, you really should be looking to use an existing app solution like Square since you'll still be subject to charges when using Stripe and Authorize 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 7 years ago.
Improve this question
What's the license of OS X Lion's /System/Library/Fonts/Apple Color Emoji.ttf?
In this posting Apple's Peter Edberg says:
As previously stated, Apple would like to make the Apple Emoji font -
and the glyphs therefrom - widely available using a license that makes
it possible for anyone to change it as they see fit or to combine its
glyphs with those from another font, without Apple acquiring any
rights to such changes. The only conditions we want to impose are: a)
The name "Apple Emoji" can only be used for the original unmodified
font; if the font is modified or combined with another font, the
result must have a different name (without "Apple" in it). b) The
original font, or one derived from it or incorporating parts of it,
can not be sold as a stand-alone package. (However, it it could be
included as part of a system which is sold as a package). Otherwise a
third party should be free to use the font, or to adapt it, modify
it, extend it, distribute it, etc.
However, at the time of that posting (2009), Apple had not decided about the actual license. I tried to find out now, but I could not find a more official license statement.
[Update 2014-03-12: I have now mailed Mr. Edberg and asked for clarification.]
Mr. Edberg has answered me (my emphasis):
The font being considered for licensing as per the emoji4unicode posting [...] was not “Apple Color Emoji”, which was never considered for licensing. Rather, it was a separate black & white “Apple Emoji” font mainly developed as part of the proposal to Unicode and ISO 10646 for the addition of emoji characters, in order to provide glyphs for use in the code charts etc. As far as I know it is not a font that ever been included in shipping Apple products.
So the answer is that there is no license for 'Apple Color Emoji.ttf' available.
IANAL, by the way.
Update 2018-02-06: According to Twitter posts, Apple has started enforcing that now in the App Store. Sam Eckert reports there:
I’ve just been on the phone with the App Review team regarding the Emoji issue. Apps are NO LONGER ALLOWED TO USE EMOJI in non-keyboard based situations. Means if your app displays emoji anywhere without a user having it typed in, it’s illegal and will be rejected.
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 wish to track a set of data my educational app generates based on user challenges. Every nth challenge I want the app to send these metrics to my server so I can observe various things about the app.
Further, and most important, I need to uniquely identify each instance of my app so that I can watch the trends of a single user. I wish to persist this number through the life of the user's interaction with my program in an anonymous kind of way, and persist over multiple removal / installations on the same device.
Bonus points for what your opinion of the standard method of reporting these metrics to a web server are. XML? JSON? Simple NSURL's?
Bonus points for links to relevant Apple Documentation.
DISCLAIMER: (due to past experiences...)
I am relatively new to stack overflow. If this post doesn't conform to the standards of this site, please explain why before voting me off of the island.
You can't tie a device to a user unless you set up a username password combination. Nothing else will work if you expect to handle app removal, installation, or device upgrades.
As for preferred data-type. My preference is JSON. But that's just a preference and you'll get lots of other differing replies. Hence it's a sort of pointless question.
Take a look at this link. It explains what identifiers are constant when and in what situations they are not. He talks about the identifierforvendor and advertisingidentifier that are now the only supported unique identifiers you can access. They took away the UUID tracking as well as the MAC address method. You can still get the device serial number, but that method uses code that will get your app rejected by apple's app store review process.
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 6 years ago.
Improve this question
The guidelines for iOS and the Mac App Store state that demo versions of apps are not allowed.
As far as I can tell, a lite version is (most of the time) just a demo with an IAP for the full version (so as to retain progress)
A "demo" app is traditionally a fully functional app that only runs for a limited time or doesn't let you save anything, or is crippled in some way to make it useless beyond being a demo.
A "lite" app is fully functional in its own right. If a user never upgrades to the full version, the lite app must still do something useful, even if it is fairly limited. One critical thing Apple will look at is no part of the UI must be disabled in a lite app. If a bit of functionality doesn't work in the lite version, then it must not be part of the UI at all.
In a lite app you may have a button or other UI element that lets the user upgrade. If the user reaches some limit imposed by the lite version, you may inform the user that they can upgrade if they wish. But never prompt the user out of the blue to upgrade.
A lite app does not require IAP. You can create a pair of apps (lite/paid) instead if you wish.
If you decide to use a single app with IAP to upgrade, don't call the app "Lite". Don't put "lite" in the icon. Because if you do, your customers will hate you once they upgrade the app and it still says "lite" anywhere.
Provided you're not putting any sort of time limit on your application, or removing functionality from the game - it'll pass as a lite version.
The "removing functionality" limitation is one of those ambiguous statements. You wouldn't get away with removing the "Save" function from a text editor, though you would get away with not having a different model of car in a racing game, or by having it as an IAP.
It's all rather subjective
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
When submitting an app to the iOS App Store, one is required to declare whether the app "contains encryption" (and, as I understand, go through additional administrative hurdles).
Does anyone know of any guidance on what precisely is covered by the term "encryption" in this context?
Are they referring to:
specifically cryptographically secure encryption schemes (AES, RSA etc);
OR, any scheme or method that might in everyday parlance be referred to as 'encryption', or a variant of a standard scheme that is cryptographically weak?
Specifically, I was intending to use some weak scheme to protect some of the app's assets against a casual hacker, e.g. by XORing the data from the file with a string of bytes generated from a (non-cryptographic) random number generator. If you like, it would be a "one time pad", but where the key isn't actually cryptographically random: just random enough so that somebody looking to steal the data would need to go to a small amount of effort beyond 'just copying the data out of the file'.
So, for the purposes of the declaration, would this count as using "encryption" even though it's not actually a cryptographically secure form of encryption? What I'm doing is common enough practice that I'm guessing other developers have submitted apps using such a procedure: did you have to declare the app as using encryption?
(The iTunes Connect Guide, for example, doesn't give any further specification on this matter.)
This flow chart will probably help you get on the right track. It indicates that if the encryption is limited to copyright protection / intellectual property then it is exempt from the review. I got to this flow chart from the BIS homepage. That page is referenced by the FAQ entitled World Wide Trade Compliance for the App Store in iTunes connect which states you can claim exemption:
(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS
Hope this helps clear things up a bit.
EDIT Another interesting section is this, you can claim exemption if:
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve