I have created a new app that is not in both stores yet. It is supposed to charge users subscriptions every 1 / 3 / or 6 months. The app helps users find nearby users based on some criteria. Some parts of the app are for paid members and other parts of the app for all users. There are 0 users in the app right now. So there are no users to show to each user. Which makes it difficult to charge people subscription.
I have the following questions that would appreciate if someone can answer:
Should I show the paywall to the users at this point?
What is the best way to make all users paid so that they can use the app even though they did not pay anything.
What would be the best way to show the paywall to the users at this early stage.
Please keep in mind that users are the assets in this app. So if there are no users in the app, there would be nothing to show to other users and charging people subscription would not make sense.
What would be the best strategy here.
I appreciate any help I can get.
Should I show the paywall to the users at this point?
Sure, why not, as earlier you implement the feature, easier will be the changes in the future screens if you have a reusable logic.
What is the best way to make all users paid so that they can use the app even though they did not pay anything.
You need to handle the access control of each feature or screen in the App that you want to be allowed only for premium access, something like:
if(isPremium) {
return UnauthorizedScreen() or SubscribeNowScreen();
}
return PremiumFeatureScreen();
EDIT: It seems i missunderstood the question, I would focus on acquiring users in the beggining and monetizing the App with premium features instead unless you will be able to market and you company have a big name that can attract users even without have they using the app yet. You can put limitations in the app, or you can offer longer free trial period such as 1 year?
This article is quite interesting on how to monetize Applications.
What would be the best way to show the paywall to the users at this early stage.
I Recommend you to add the option to subscribe in the Options of your App, so the users can go there and subscribe if they want. Apollo is one the Apps i like the Subscription model so you can get some ideas from this App.
Related
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
This is the first time i am trying to create an application in which money in involved . I will give premium some features to user once he pays on the apple store.
I heard something about In App Purchase , that by implementing it we can take money form the users.
My major query is: What should be the best procedure to upgrade the application loaded with new features (like we get all powers in games.)?
Should we involve some kind of file download after money transaction or we she unhide it from existing application.
My concern is the best approach that should be applied ? If i am thinking in a wrong direction then please assist me with the correct path for this kind of scenario.
Thanks in advance.
In case of an 'upgrade' or 'unlock' based on an in-app purchase, it would be best to provide the complete application to the user and block the features while the app is in demo mode. So, you will have to check each time whether the app is 'upgraded' when the user attempts to use a premium feature.
Involving some download after the user makes the purchase will be tedious to implement, but this is also based on what you are trying to provide with the purchase.
Read up on in-app purchases here.
In iOS, is there a way to figure out the version of app the user originally bought from?
For example, what if i want to implement some special behavior only for user who purchased v1.0. one obvious "feature" is disable in-app purchase so they can enjoy the rest without paying? I thought up some ways to do it but unfortunately, it wont survive the test if the user deleted the app and also i didnt user icloud early enough to persist this metadata.
Unfortunately this can't be done. At least not in any perfect manner. There is no API to get any details about the user and their purchase. If your 1.0 version of the app doesn't already persist some meaningful clue, your only solutions would be partial at best.
Your issue is made worse if you already have newer versions of the app out (such as 1.1) and you want to add this new feature to a newer version (1.2 or 2.0). There is no way to know if anyone ever had 1.0.
You basically have two options:
Leave it alone. You can't convert a paid app to a free-with-IAP app without hurting at least some portion of your existing customers. If anything, leave the app paid but add IAP for any new functionality. This way, everyone pays the same for the base app and everyone has the option to pay more, through IAP, for additional features.
Depending on your ethics and the number of existing customers, you could just make the switch and make existing customers pay again for functionality they already paid for. Obviously, this is a bad idea but it is an option.
I'm building an app that will provide users with an evolving directory of companies in their local area (location-based) that manufacture green/sustainable products. I want companies to be able to add themselves to the app by purchasing a subscription using in-app purchase. This would be a 1 year subscription.
Just read this in the iOS Standard Agreement: 2.3 Content and services may be offered through the In-App Purchase API on a subscription basis (e.g., subscriptions to newspapers and magazines). Rentals of content, services or functionality through the In-App Purchase API are not allowed (e.g., use of particular content may not be restricted to a pre-determined, limited period of time).
If the service is only for a year, does this preclude me from doing the above? Anybody have any insight on any of this? I'd appreciate your input - I can't get any info from Apple. Thanks.
My guess is that you are not allowed to do that. As you really cannot restrict who subscribes for a year – it might be any user – you probably cannot offer this. The IAP doesn't provide any content or service to the user other that a listing. As you probably need an external data source (e.g. a web application) I would suggest moving the subscription there. This is just my opinion and I am no lawyer so I might be completely wrong here.
You can do it. See the image below. You just have to choose the right option.
You can find it itunesConnect in the app detail section.
For your case I suggest Consumable is appropriate and have to maintain a check that wether its been a year or not since the last magazine purchase or what so ever your scenario is.
Consider following example. Let's say we have an app in which professional writers write stories from a web based UI. And then these stories become available for user of the iOS app as in app purchase items.
As you may know we need to create in app purchase products in advance. But in our situations it means that for each of the story created by the writers we will have to create a new IAP product and wait for Apple to approve it.
To circumvent this, I am planning to create generic "consumable" products in IAP like story worth $1.99, story worth $2.99, so on, so forth. Then in the Application UI I will show the list of stories of created by the writers and show corresponding prices for the stories as specified by the authors when they created the story. Once the user taps on the buy button, I will show the purchase for the generic consumable product of the same price and complete the in app purchase process.
Now the question is will Apple approve of such implementation? Does it fit with their IAP policy? I am asking as I couldn't find a guideline for a workflow such as this.
Another approach to implement this is by implementing an in app credit/currency system, like games use. Where people buy credits/coins and then they purchase items with coins. This is a tried and tested approach but it doesn't fit in my analogy of the app, hence the question.
What you want to achieve is perfectly feasible, the only thing is your purchasable content has to be dynamic. You will have to download the product IDs from a server rather than having them hardcoded in your app.
To refer to your example, I can imagine a table view being fed with a list of objects that would have the SKProduct ID stored on them. You would have to do this because, at the time of writing, you can't retrieve all the available product IDs for your app from Apple servers. I know it's a pain in the ass they didn't implement this feature but to be honest, if they haven't already I don't think they will ever do.
This is the method I'm referring to: initWithProductIdentifiers
You provide it with a NSSet with all the identifiers you want to retrieve, but if you provide an empty set or a nil, it doesn't reply with all the existing. You can file a bug with a Apple if you feel this doesn't work as it should. Please check this SO answer if you still have any doubts: link
Another important thing to note is, you will have to upload your products manually. Apple doesn't expose any API in order to have the process automated. This means, every time a writer uploaded something to your server, you would have to log in into iTunes connect and create a product. Plus, you would be limited to 10,000 products because that's the maximum amount of different products you can register with Apple. I'd also recommend you to have a quick read to the iTunes Connect guide, which has some important information like the one I just mentioned: iTunes Connect
Regarding 3rd party frameworks, like the aforementioned UrbanAirship, they will just save you from having to implement receipt validation on your servers. Apart from that, I don't see any major advantages.
Said this, I'd recommend you to reconsider your business model. Is it really worth it all the hassle of uploading the products one per one? Or is it better to go the subscription way, in which your users pay a fixed amount of money for downloading a number of articles per month. You could have different tiers, like, basic, premium (unlimited downloads) an so on and control the delivery of the articles from your servers. That's up to you, but for me the answer is pretty clear.
Pritam
For delivery dynamic content you should be using a Subscription, not a consumable. Using a subscription solves your problem by allowing you to charge for each update AND distribute new content at the same time.
You can looking into 3rd party services like UrbanAirship that will significantly reduce the amount of time you spend trying to dynamically deliver your content, track subscriptions and expirations, etc.