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 9 years ago.
Improve this question
I am selling apps on monthly payment plans to external companies. If they decide to stop paying the subscription fee is there any way I can remove or disable the app on the customers device?
Can I for example use Google App Engine, read in a value and check to see if 'Valid' or not. Would this pass the app store review process?
Don
This is how I interpret your situation:
You have several customers, lets say company A and company B and you are making an app to both of them.
To make and host these apps they both pay you a monthly fee.
Suddenly company B stops paying the fee and you wish to remove app B from the app store and render it unusable for all devices having the app installed.
You could do something like this:
Remove app B from appstore by removing it from sale in iTunesConnect
Whenever anyone opens any of your apps (app A or B) you let the app connect to a web server that you are hosting, to see if it should still be available.
You could make sure that you don't make the check unless some time
has passed since the last check.
If the network is not available when you are making the check, do the check at a later time and let the user use the app as normal.
If the check is successful and you find out that the app is no longer valid, give the user an error message and stop showing the app's contents.
As for the review process, I don't see any problem rendering the app unusable, as long as you remove the app from sale on the App Store as well.
About the subscription thing, what Apple regulates is the subscriptions made by the app users, not by the company to who you are selling the app to. You can charge them in any way you like.
Apple will probably not reject your application for having a "self destruct" mechanism, but once they find out you've been utilizing this, they will most definitely pull you out of the App Store for 2 reasons:
Your application is now useless to some people which is not acceptable.
You've been selling subscriptions indirectly and not through Apple.
If your app is for your targeted users, why not use logins? If you've already have logins, then you can disable their account at any time. If you wanna go more complicated, you can also create web services and whenever they log in, check their UUID. In this way, you can ban them either on their accounts or their UUIDs. Ban on their UUID could be useful to protect their information if they lose their devices.
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 9 years ago.
Improve this question
I have done a lot of researches regarding accessing device SIM card data such as SIM serial number and user phone number, and below are my findings :
By using private API for iOS SDK we can extract the needed information from SIM card (If already stored on the SIM card).
The issue related to the rules and regulation for submission apps. On Apple store, since Apple rejects any application accessing SIM card because hey supposed that such behaviors break the user privacy and security.
This functionality used for application not attended for APPStore submission.
References :
How could I read information from SIM card in iPhone?
Programatically get own Phone Number in iPhone OS 4.0
How can I get the phone number of my iPhone device?
Read/write certificates on a SIM card - iOS
all the posts and tutorials that i found said that i can't extract data from the device SIM card without facing apple rejection !!!
My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? and i appreciated any reference to the part in apple submission rules and regulations document that says "NO SIM CARD DATA ACCESS" !!
My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? - No there's no way. There's no direct reference of "No Sim Card Data" in documentation.
As you have already read SIM card data access is not possible using the Apple SDK. Following is the part of Apple Developer Document :
The following guidelines can help you ask for user data in ways that
help people feel comfortable.
Make sure users understand why they’re being asked to share their
personal data. It’s natural for people to be suspicious of a request
for their personal information if they don’t see an obvious need for
it. To avoid making users uncomfortable, make sure the alert appears
only when they attempt to use a feature that clearly needs to know
their information. For example, people can use Maps when Location
Services is off, but they see an alert when they access the feature
that finds and tracks their current location.
Describe why your app needs the information, if it’s not obvious. You
can provide text that appears in the alert, below a system-provided
title such as ““App Name” Would Like to Access Your Contacts”. You
want this text to be specific and polite so that people understand why
you’re asking for access to their information and don’t feel
pressured. Your reason text should:
Not include your app name. The system-provided alert title already
includes your app name. Clearly describe why your app needs the data.
If appropriate, you might also explain ways in which your app will not
use the data. Use user-centric terminology and be localizable. Be as
short as possible, while still being easy to understand. As much as
possible, avoid supplying more than one sentence. Use sentence-style
capitalization. (Sentence-style capitalization means that the first
word is capitalized, and the rest of the words are lowercase unless
they are proper nouns or proper adjectives.) Ask permission at app
startup only if your app can’t perform its primary function without
the user’s data. People will not be bothered by this if it’s obvious
that the main function of your app depends on knowing their personal
information.
Avoid making programmatic calls that trigger the alert before the user
actually selects the feature that needs the data. This way, you avoid
causing people to wonder why your app wants their personal information
when they’re doing something that doesn’t appear to need it. (Note
that getting the user’s Location Services preference does not trigger
the alert.)
For location data, check the Location Services preference to avoid
triggering the alert unnecessarily. You can use Core Location
programming interfaces to get this setting (to learn how to do this,
see Core Location Framework Reference). With this knowledge, you can
trigger the alert as closely as possible to the feature that requires
location information, or perhaps avoid an alert altogether.
You can refer this
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 9 years ago.
Improve this question
At the bottom of the second page Apple's In-App Purchase Guidelines it says that virtual currency is not allowed to be sold through In-App purchases. However, many games on the app store today sell "coins" or something similar that the user then spends on various upgrades or powers. I am designing an app that should do something similar, but I obviously do not want it to get rejected. Can anyone shed some light on this situation? Also, if the items that are bought through the credit are non-consumable, will Apple host them? And can I track which ones have been bought and how many times if they are bought through the credit?
This is a great question. I think the virtual currency apps are like fart machines and flashlight apps: They were accepted into the store at first, but Apple eventually realized they didn't want that type of app on their store. So those apps that got accepted, they are still on the store, but from now on, no more.
As for your second and third questions, Apple isn't going to host any of the content of your game or app beyond what you can get into iCloud; they only record which things which people bought. So if someone bought 1000 coins 12 times, Apple will know that, but you have to keep track of how many coins the customer has left via iCloud or your own server.
Update: It looks like Apple will accept In-App purchase of virtual currency per the Apple Store Review Guidelines. Section 11.4 states:
Apps that use IAP to purchase credits or other currencies must consume
those credits within the application
So as long as the currency is redeemable within your application, it's fine. However, right in the introduction, it does say:
We don't need any more Fart apps.
So fart apps are out, but virtual currency is OK!
I think woz is right about how existing apps got there with virtual "coins", that they were submitted before Apple tightened the guidelines. Subsequent updates might get rejected. The main issue is that a virtual currency means you're able to alter the exchange rate, so a purchase of $5 worth of virtual coins could subsequently be devalued to $2 worth of virtual coins if the user doesn't redeem them in time. That's consistent with Apple's guideline that "it is important that users know the specific good or service they are buying."
As for tracking purchases of items, a non-consumable product is something that can only be purchased once: If the user tries to purchase it again, the store will tell you that the purchase succeeded, but it won't result in a second transaction. If you want something that can be purchased multiple times, then you need to track that yourself, and make it a consumable product.
I am building an app for a client that will have 30 days of content for free, thereafter you are required to buy a subscription via in app store purchases.
However, I have read that you will get rejected if you have trials.
Don’t set time limits on any of the functionality of your app, either
for run times or life times. Applications that only run for a set
number of minutes per session, or that expire altogether after some
period of time, don’t recruit customers so much as leave a bad taste
in their mouths.
Finally, they also say "your app will be returned to you by the App Review Team for modification if it is found to have time limits".
This seems odd because I know the Guardian and all major newspaper apps have limited functionality.
The Guardian app is free but you get limited functionality?
The Daily app is free, but you have to pay for daily subscriptions
and has limited functionality for the period of your subscription.
The Times app is free, but is a free trial (of sorts) (plenty of
complaints about it)
There are other examples which seem to differ from Apple's policies.
Lets say you have an app that is free, but then you have to pay for subscriptions to gain access; however according to the rules this is considered limited functionality -- yet there are lots of newspaper apps that do exactly that.
I'm confused.
Can someone clarify the situation? Can apps have trials?
Thanks
It is difficult to clarify the situation because unfortunately the guidelines are not necessarily set in stone. They can and do vary on an app and publisher basis.
In the case of The Times and The Daily, both apps are produced by News Corp. It is perhaps safe to say that News Corp has a good deal more influence with Apple than a one-man development shop producing an iPhone game. Apple would be loath to admit it, but there are clear cases of popular apps on the store that don't conform to the guidelines, where they have tacitly made an exception.
So what I would say to you is this: be sensible. Don't have an app that quits automatically when your trial runs out. Think about what would be acceptable to users. It's very much a case of nothing ventured, nothing gained. Take a risk, submit your app with your limited trial, and see what happens.
With the Guardian app, we had to deliver an app where you always got at least some fresh content if you were using the free version. Subscribing opens up more content to the user.
I think, you are mixing up "content" and "functionality".
You can deliver content items (i.e. an magazine issue) for free or user has to pay for it — so the first n issues, or all issues in a certain timeframe, can be free, while the others need to be paid. But if an user purchased an content item before, you have to re-deliver it for free.
You can sell functionalities (i.e a search in the magazine's archive) as-well. But you cannot give it to the user for free for a certain time and them make him pay.
So the general rule is: What ever the user got from you — you cannot take it back from them and make them purchase it again.
There are plenty of free apps which provide limited functionality. They don't provide time limits though (or at least they shouldn't). I'm guessing it won't be as clear cut as accept or reject for Apple, because I did encounter an app which closes itself after 10 minutes, opening a web page to purchase it (closing an app is also against the Apple Human Interface Guidelines, as an app should never terminate itself).
The guidelines mention this is only allowed for specific types of content:
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
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 needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have an app that I want users to be able to pay a small fee to remove ads from. I figure the best way to do this (the app needs to remain free) is via an in-app purchase. I'm wondering however the best way to go about removing the ads and how to do it once the user has bought the upgrade. Any help or advice would be great thanks.
A boolean in NSUserDefaults seems like the right bet. You can check it on launch to see if ads should display, have the app hide or show ads accordingly, and set it to the appropriate value when the user pays to disable it.
Edited to add:
Just saw this on the dev forums. If you're especially concerned about users on jailbroken devices fiddling with your NSUserDefaults boolean, you could alternatively store the data using keychain. Keychain can't be meddled with in the same way NSUserDefaults can. More details at that link.
I don't generally believe in expending much effort at all on anti-piracy stuff but this is an easy way to cover yourself that doesn't cost terribly much more than using NSUserDefaults.
Another approach would be to record the receipt from the SKPaymentTransaction received on purchase or restore. On subsequent launches you could verify that receipt with the app store in the background, re-enable the ads for next launch if necessary.
Verifying Store Receipts documentation
Whilst I don't think this protects you from pasting in a valid user's receipt from elsewhere, it's more difficult to circumvent than toggling a boolean in the NSUserDefaults. Anyone going to this length is unlikely to pay for your app anyway.
Well, this problem is not iphone limited. You should apply one of the many security algorithm.
(I don't know how the purchase is done but i'll make a suggestion)
You can for example after purchase make the app send the IMEI to the purchase server that will generate a code that the app will save. Then all the app will check for it to enable/disable the ads. (try to make the code with some hashing algorithm or such)
Please remember that all systems can be cracked so don't try something too complex that will give your real user headache.