My boss asked me an interesting question about if the developer gets a cut of the ads ran on their app page. I was unable to give him an answer. I tried to search for an answer and could not find one.
Nope. You get no money whatsoever from just running your app.
The only way to make money, is to sell token to buy in-app stuff.
See this documentation for more information about in-app payments:
https://developers.facebook.com/docs/payments/
More than 1000 apps are made on facebook on each day.The facebook apps are primarily made by different service level companies as a medium of promotion .They are in no mood or temptation to sell them .But if some people really want to sell the token id of the apps .
Related
we are developing an iPhone app as an extension of a classifieds system (web site). On that web site users can buy (prepaid) credits and use them to boost and promote their ads. Will Apple reject our app if we implement consumption of credits? We are not gonna allow buying the credits, just using them (users will still have to buy credits on the web site).
Only worrying thing I found is item 11.2 in App Store review guidelines:
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be
rejected.
Is there a way to contact Apple directly regarding this question?
And a add-on question. I suppose we can implement a payment gateway system like Amazon and Ebay and get a way with buying credits? I don't see any restrictions in guidelines regarding non in-app purchase system.
"In-app purchase" is only required to purchase content or extra-functionality or extra feature or to remove any type of limitations inside the application. To achieve these things you shouldn't use any other external purchase mechanism (per App Store review guidelines ยง11.2).
In your application, the user will only use the available credits which are already bought on your website, so there is not an issue, although you shouldn't provide any type of link to your website inside your application.
Genererally "will Apple reject this if..."-questions can only be answered as such:
Apple does as they like. If they feel this in some way breaks the review guidelines, they will reject it and tell you, but you have no way of knowing for sure until you have submitted the actual app. In your case, I can't see why they would ban it, as you are not able to use real money within the actual app, but as I said, you don't know.
If you want to try to get an answer from Apple, you can try to contact them from this page.
I finally got an answer from Apple. It took a while and it wasn't worth a wait. I think Siba was right, but I'll get back to you after we submit our app just to verify everything.
Apple replied:
Thank you for taking the time to contact us about your app design and concept questions. I understand that you would like to know if you
implement consumption credits into your app would be acceptable for
your app.
While we cannot pre-approve apps, we can address compliance questions
about specific App Store Review Guidelines or sections of the iOS
Developer Program License Agreement (PLA). I understand that this may
be a little frustrating and I apologize for any inconvenience this may
cause, however, we may only answer specific questions concerning the
following resources, unless the app is submitted for review so that we
may test the functionality.
I have an application that my client wants to give away to customers for free.
To get the full functionality, the customers would have to fill in a code.
Other customers will need to do an In App Purchase to get the full functionality.
Is this allowed by Apple or will I bump into app store restrictions.
Tried to find it, but haven't found a decent answer.
Anyone tried it before ?
Thanks !
Please see this other SO answer:
Redeem codes for inapp purchase items
I dont think it is possible to do what you want. Either everyone has to enter a code, or everyone has to do an in-app purchase.
You could also have both of these options available inside the app, but that may seem messy and informal for customers
I would say you could ask the user for a login (email + password). You could then connect to a server of yours and check the credentials. If the server knows this user because you host a list of all the users allowed to use the premium options for free, you could unlock your premium features. Otherwise, you ask Apple for the In App Purchase precedure.
I would like to know my options for letting users make payments in my iPhone application for goods in an e-Commerce store. This will be an app rather than a mobile website.
Ideally, I would just like to use Authorize.net or SagePay - is this possible? I found some posts from a year ago saying that Apple only allow their In App purchase, is this still true?
Thanks for any guidance.
Assuming you have access to Apple's developer member center, have a look at the App Store Review Guidelines, section 11.
To my understanding it is allowed (or required even) to have your own payment-system, as long as you're not selling (digital) items that are supposed to be used in the App.
I have an app that has an about page. I would really like to include a photo of myself, mostly to boast to my friends. I am under 18 however my parents are the ones that have the developer account, so it would basically be them putting my picture up with my consent. I was wondering if Apple will reject my app because of the person photo or not.
Thanks, Michael Amici
The official App Store Review Guidelines state nothing that will reject your app because you didn't buy the developer account yourself. Company's that have multiple employees won't get their apps rejected either because the person who bought the developer account actually programmed the app. If you have the consent it should be no problem.
The bottomline is: If you coded the app yourself and you have the consent from the owners of the Developer Account to release that app under their account they cant reject it for that reason.
We intend to launch a free iPhone/iPad app on the AppStore.
The content will actually be accessible thanks to a subscription model (login/pwd authentication in iPhone app).
The subscription (about 100$ a month) is handled via a dedicated web server.
If used without subscription, this app will provide minimum value.
Does anyone know if this kind of subscription model can be rejected by Apple ?
I know some apps follow this model, but I'd like to have your thought on this before starting in this direction.
Thanks for your answer.
This is fine AFAIK - As long your app is free and you put in the description that it requires a subscription to whichever service. When you submit the app, you'll need to hand over details to a test account to Apple so that they can test it, but other than that it's no hassle at all.
I know of an app which works just like that on the app store right now - Spotify for iPhone. It's a music playing app which streams music from the web - but you need a Spotify premium account. When you first open the app, you have to sign in, and if you don't have a premium account it just tells you that you're not allowed in!
Javawag
There are plenty of apps which only work if I have an account somewhere, and some for which I have to pay for that account so, without knowing the specifics, there is nothing which immediately rules out your subscription model. There are even Apple apps, iDisk for example, which are useless if you don't have a $100 mobile me subscription.
If there are issues you can look at selling your subscription as an in app purchase (apple will take their 30% which should make them happy) or look at making the app more functional without the subscription.
Either way, when submitting for approval make sure to set up a sample account with a full subscription that the apple testers can use (there is space in the submission for including logins for this kind of thing).
Our app, previously approved, update was just rejected because we sell subscriptions through our website. (We have been doing this for 15 years, without giving Apple 30% of our money.) They are requiring that all subscriptions for iphone/ipad content go through in-app purchasing. I guess we will be looking at building a browser based app instead.
Cheers,
Gerry