We'd like to display our own customers' ads in our iOS App. Do you think Apple tolerates it?
Like if we'd advertise a canadian mobile carrier ou something? I had one app rejected lately - Lost a lot of time and money so I don't want to end up with nothing again. I checked in the documentations but haven't found anything.
The concept would be popping up an ad when the user clicks on a list item, before the download of the associated file (mp3). I think they might find it "invasive" behavior or something. So if you have any informations, I'd be more than happy to read it.
Yes, it is allowed by Apple to use your own/customer advertisements and shouldn't endanger the approval of your application by Apple.
Related
I have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
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.
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!
Concept on howto maintain a trial and purchasable full version of an IOS-app today:
There are lots of dicussions on this topic, but I would like to look at this for my case and how it would be designed TODAY (2015), with actual Apple restrictions.
I have an app which initially loads data from the internet to be displayed. (Trial-Content -> 80MB, 20%, Full-Content -> 400MB, 100%)
I would like to offer the Users to try the app with limited content first.
With limited content: 20% works as like the fullversion. 80% are marked with a question mark. If the users clicks on the question mark I would like to guide the user to the fullversion.
I prefere to have 2 apps (2 builts), because of having 2 separate rankings. Users, which buy an app are rating better, because they are really interrested in the app and will only buy, when they are pleased with the trial app. So an app with inapp purchase has a lower ranking in avarage then a isolated full version (built). But I guess this concept would be rejected by apple, because you have to mention the fullversion in the trialversion and you have to name the trial version as "trial" ? (Sorry for the bad english)
How will this be designed with IOS apps ? Howto guide the User to the fullversion, without beeing rejected by Apple ? (I read popups like "Would you like to purchase the fullversion?" will be rejected. )
In Android I did the following:
I created one app with the full functionality, which is at the same time the trial-version.
I created one purchasable app, which is only an unlocker app.
The trialversion app checks if the unlocker is installed. That way I can differentiate between trial and full and will load the corresponding content.
When clicking on the question mark, I will show a popup saying "Would you like to purchase the full version?".
This is quite a common pattern, you just can't call your "trial" version "trial". Quite often such versions are called "light".
To send the user to the app store to buy the full version you can use the SKStoreProductViewController to display the app store page for your full version directly in your app. This should be OK with Apple.
Your Android solution with the paid "unlocker" app would be possible too. Your apps need to expose an URL scheme and using that you can check if the other app is available. They also could use an app group to communicate. But this will most likely not pass review as apps must do something useful by themselves. They will probably test your unlocker on a device that doesn't have your other app installed and immediately reject it.
I would strongly suggest to reconsider an IAP for this. That's basically the ideal use case for it. You must not be afraid of bad reviews for offering purchases. Trying to send the user to buy another app will probably give as many bad reviews if not more. The IAP flow is much more user-friendly.
As #Sven suggested IAP is recommended in your case.
If you want to maintain two different apps for trial and full version, you can give your trial app name as "APP NAME FREE", I think Apple will not reject the app with name "Free" in App name (I successfully uploaded free and paid versions of same app with this trick).
As of about May 2014 this year, searching Google for "ios in app purchase promotion code", yields lots of news sites reporting the same thing - Apple seem to be working on allowing promotion codes for testing in-app purchases as evidenced by a screenshot from EA games.
My question is; does anybody know how to do this yet? I logged into the new iTunesConnect interface but can't find any link and nothing appears in the Apple docs from what I can find.
Ideally I'm looking to create a code for a monthly subscription but they may only be allowed for consumables. With the lack of actual info on IAP promo codes my guess is that the feature hasn't been officially made available yet and that EA games were invited by Apple to test it out.
As #Christoph Wimberge notes this is old news. Apple is now supporting this.
You cannot officially get promo codes for IAP currently. See here https://developer.apple.com/library/prerelease/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html . If you're testing then you should be creating Sandbox Testers under Users and Roles. Depending on how you handled the IAP this could well serve as a promo code of sorts. So, for instance, if you're using the IAP to set a flag in NSUserDefaults or a plist file then this will work as a promo code. You will have to instruct the user to log in as the test user for the purposes of the purchase. Even if you delete the test user once the flag is set the user can use the IAP so long as they don't completely remove the app and assuming you don't change the way IAPs are handled like using App Store digital receipts to confirm purchases. Of course, if you're worried about crackers then you're probably not going to store successful IAP as a flag especially in User Defaults where anyone can just change the value willy nilly. But for apps that aren't games this probably isn't a huge worry. Hope that helps.
We were told by Apple today that they never allow users to type in codes, use Q-codes, or other gateway key to access anything. Instead, she said we should use a members-only webpage (i.e., login required) to accept redemption codes and associate the content through our backend. When the user returns to the app, the content would be available.
If Apple enabled codes for IAP, you could offer sales of the codes from another platform, which would then unlock the IAP. Apple would be doing all of the work, but reaping none of the rewards. In addition, all of a sudden, you've created a knock off market for promotional codes, like g2a.com does for Steam keys.
While Apple might have the functionality, it seems exclusive to EA for now.
Currently, you'll need to figure out how to support promotional items outside of the app store.