I'm in the process of making an iOS app. This will be my first iOS app. It is based on making phone calls using calling cards. The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
I went through the submission guidelines. Usually when a app requires the user to buy something from with-in the app, then IAP is used but here the purchase is being made in the real world, without using the app. Do I need to integrate IAP into the app? Will Apple accept the app into the app store?
Any help is appreciated.
Thanks
As your requirement suggest
The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
It means you are dealing with somewhat physical stuff like customer will buy the calling cards in the real world so at that time he/she must have to pay something for that. so there is no need to integrate IAP in this scenario.
IAP is only for the stuff/service that will provide within the app by service provider. for physical service you can exclude the IAP. if you give proper description and explanation to apple when you submit your app for the review apple will definitely approve it
hope above answer will help you
I think you're in a grey area because it all depends if Apple thinks the credit is consumed in the app. If considered consumed in the app, you may have a problem. Try to find another iOS telephony app that uses cards, one that's well know enough to be sure that Apple may have had a good look.
If you'd give users game credit with physical cards, it's clear that Apple would not allow this.
What makes this a grey area is the telephony side: If it's a VoIP app you could argue that the the credit is (partly) consumed while using the app. But you could also argue it's outside the app on the VoIP/telephony network.
If it's not a massive investment, I'd try the calling card route first.
You could try ask Apple, but you'll probably won't get a clear answer as they want to see the app first. I've tried this a few times in the past. Makes sense because they don't want to make promised based on what you write in an email.
Related
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
I have been extensively searching through Internet but I could not able to come across so far then I have decided to ask the following question in SOF.
My idea is to implement a selling and buying product in my application. There will be no charge from both sides(seller or buyer). However, I only want to receive user feedback to increase my app reputation in the AppStore.
I would like to know how to check whether or not that an app user rate or leave comment for my application in the App Store. I need to know because I want to give him more advertising opportunities within the app.
Sorry again, I wish to provide a sample code but I could not able to come anything to start with.
As far as I'm aware, there isn't a way to do this. Most apps just direct people to the app store and then assume they rated the app. You can have the user copy and past their review into your app and store it so you can double check that they actually did it. That will ensure more people don't try to cheat the system. Essentially, the more work you make it to unlock the feature, the less likely people are to cheat.
From Apple via #Paulw11's comment:
Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the iOS Developer Program
link: https://developer.apple.com/app-store/review/guidelines/#metadata
All,I am making app for reminders & its kind of social reminders. I can share my reminders with my contacts. I want to make it like whatsapp. Can we use user's mobile number for this purpose? Or will apple reject it? Please tell me more, if anyone has done such app before?
Thanx.
You can ask user for any information, no matter how personal. In terms of Apple guidelines, here's a few things to bear in mind:
asking is fine, but taking (via a hack or whatever) will get you bounced.
the ask has to be essential to the service the app delivers. in other words, it's perfectly okay for a retirement calculator to ask about how much money user has in the bank, but not so okay for a tic-tac-toe app.
editorially, be very clear and honest about how you'll use the information (Apple might not catch you here, but you should do this anyway to motivate the user's answer).
the app must remain functional even if the user opts not to provide the information. for example, the retirement calculator should supply a default bank balance and carry on.
I'm building an app that registers people for an event and charges them a registration fee. I've got most of it built but I'm having trouble actually charging them. I've read the guidelines and don't want to use apple's in-app purchase method because they charge a big fee and the goods being purchased aren't digital or for in-app use.
I've looked at doing paypal and I think that should work fine for me, I've already started playing around with their sdk and sandbox. However, I would also like the ability to charge a credit card. I found card.io that looks like it works really well but that just gets me the card information, it doesn't give me a way to actually process a transaction. Also, I know there are card readers like Square out there but I'd like to do everything in my app, not need the user to switch out to a processing service. Any ideas on how I can make this work? Thanks!
If you use a service like Balanced or Stripe you can tokenize your card info straight from the phone, this will save you having to process it via your server which keeps the PCI hassle low. These services are only for tokenizing and charging cards, if you're looking for a way to capture card info e.g. scanning or swiping the card, then a service like card.io or Square is what you want.
If you don't want to get the assle of the PCI-DSS certification you could use Braintree in combination with card.io.
Braintree offer an ios sdk so it won't even hit your server. (See https://www.braintreepayments.com/mobile-payment-processing.)
Card.io just let youscan the card, but when youget the card info back youcould push it to the braintree api.
Since what you are selling is a "service" you don't need to use the Apple in-app service.
You might look at the newly released PayPal iOS SDK.
Looks like you're looking for a Square solution but in your own app. You might want to check out CardFlight (https://getcardflight.com), as they provide the hardware and an SDK so that you can process payments within your own app. They work with your processor so you can still use Braintree to process the payments.
Full disclosure: I am currently working on this. We realized that there was a huge opportunity to provide the software and hardware so that people can accept physical card payments within their own app.
I'd like to ship a paid application where the user has access to one of the in app purchases for free.
Assume I have a collection of city maps. I'd like the user to pay $0.99 for the app and get one of the maps free, but have to pay $0.99 for successive apps. However, I want to let the user choose which map they get for free rather than it being baked into the application.
Is there a way for IAP to support this? Or do I have to build it outside of the framework?
Sanjay
Well, once you want to give them a list of the maps and the one they choose they get. Make a NSUserDefault for every map and have the application check for that on startup.
If your application supports iCloud use an NSUbiquitousKey or even better, if you have a server, just have it store that their "account" has that map.
Hope it helps. (Comment if I missed the question completely, I feel that I might have misunderstood it). :)