I am developing an Android application to solve operational research problems. Right now it has a free mode and a paid pro mode using google play in-app purchases. Pro mode allows a user to solve problems of any dimension and using any method available in the app.
Now there is a following problem, which I don't know how to solve best:
I want to provide each user an ability to solve any kind of problem 3 times without paying when a user first installed the app. I'd like to somehow link it to a google account, so the state will be single across different devices with the same account. Good bonus would be if a user should not explicitly log in to the account in the app itself to identify.
What is the best way to do it? I'll need a backend server I suppose.
I'm thinking of two ways, the easy one and the right one:
The Easy one: you could use google play games services, which lets you store users game data without any backend. This is not the right way because what you are developing isn't really a game, thus when the user is prompted to sign in to google play games account will seem strange...
The right one: implement a google sign-in process and store your information on a database. I suggest you to use google's firebase which is free for limited usage and very easy to integrate. It offers an easy way to implement google sign-in procedure and a really cool database called firestore
Related
have the following scenario:
we have an app that users need to pay for. But we also want to sell the app bundled with a book meaning there is a code / voucher in the book that can be used to use the app for free. Unfortunately we haven't found any good way to address this scenario yet:
a) make the app a paid app and use Google / iOS Promo Codes for the books - not good, because the number of promo codes per app and quarter is limited
b) make the app itself free but require users to make an in-app purchase to access most of the content. Alternatively make it possible to enter a code to access that same content. The code comes with the book and is created and maintained by us.
negatives: a lot of effort to maintain the promo codes, handle the in-app purchases and Google / Android don't like it if content within the app is paid for outside - so we could end up being rejected.
I'm really wondering: are we the first one with this need? is there maybe already a solution to this problem we are not aware of? We do not want to rip Google / Apple of their 30% share of app sales. But there doesn't seem to be a supported solution for this.
any ideas? thanks
Thomas
Welcome to SO.
This could be done but i dont know if this is the optimal solution.
Make the app free and lock down at the sign-in, there give link to your play books.
In the app check if the user has purchased the book using
https://developers.google.com/books/docs/v1/using
So if user pays for the book and downloads it, On the next app launch give access to him to use the app.
You should be careful with Apple's in-app purchase guidelines, 3.1.1:
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. Apps and their metadata may not include buttons, external
links, or other calls to action that direct customers to purchasing
mechanisms other than in-app purchase.
I think for users that purchase the book, they would need to register outside of your app (e.g. on your website). If you had some authentication system you could store a flag on the users profile if they've unlocked the book or not and give them premium access to your app upon logging in.
You can make your app free and set non-consumeable book SKU in your app.
If you want to send the promo code, you can use Google Play Console.
https://android-developers.googleblog.com/2016/01/create-promo-codes-for-your-apps-and-in.html
Google only allow a small amount of promo codes per app, 500/quarter. This is because they don't want to encourage developers to sell this promo code offline. But this is still an official feature supported by Google Play. You will be totally fine as long as you're less than 500/quarter.
I'd like to be able to link users in one game to users in another game such that users that unlock certain achievements in game 1 are able to receive special items in game 2. This is very similar to how Blizzard does it where buying like X in Hearthstone gives you a special mount in WoW.
I know we could manage our own account system but we're hoping there's an easy way around that.
I've been researching Google Play Games and it seems like that could be the ticket but I can't seem to figure out a good way to identify that this new user linked in Google Play Games is the same user as in Game 1. Is this something I can accomplish with the SDK? Basically wondering if playerId is unique to the game or to the player themselves and across different devices.
(another option would be using the Google Play Advertising ID, but that isn't great for users that want to enabled limited ad tracking).
developer.android.com has a whole article on user identifiers. What you've got is a hard problem. I can give you a few tips:
playerId is the same for the same user across different devices, but is different between different games. This is deliberate to prevent Ad tracking that the user didn't intend. So playerId would probably be the wrong choice.
The Advertising id is "for user profiling or ads use-cases". So I definitely wouldn't use it for this use case.
In this case, my choice would be to use something like Firebase, especially Firebase Auth to manage a very simple account system. You won't need to create your own servers or write much sign-in code as Firebase handles this, and you get sign-in with Google or Facebook for free. And once you have it, it will give you a nice flexible way to do other things in future, eg experiments or configuration with Firebase Remote Config. And it is cross-platform if you ever write an iOS version, and from Google.
Background
I've written a game which I wish to run on multiple devices (tablets, phones, etc.). I've implemented an in-app currency, and have come to the stage where I need to store currency in the cloud so it can be accessed across devices and I can deal with conflicts etc.
I would like to go for the easiest option which, to me at least, means using some kind of available API provided, say, by Google, and not using my own server. I've come across the following possibilities:
Google AppState API (now deprecated)
Google Saved Games API
Google Drive API
Google Cloud Platform.
(1) is now deprecated and developers are directed to use the Saved Games API instead.
(2) actually seems to be a great solution because it deals with game Achievements, Leaderboards, and storage of custom data (such as in app currency). However, I see a problem with this in that in the Play Games App, there is an option to delete the player's profile, which would also delete in-game currency ! So, while (2) seems great, there is the possibility that currency data could be potentially deleted. Maybe this could be put in ther T&C's, something like "if you delete your profile you will lose any unspent currency and any purchased items"...
(3) Using the Drive API seems like an option, but then after reading online there seems to be many problems such as duplicate file names, potential for user to delete files, etc.
(4) I'm not sure about this option, but it looks like I may have to pay?
There also seems to be these deprecation schedules on some API's too.
My question
So faced with these (and possibly other not listed) options, what is a good solution to achieve cloud based in app currency? I am trying to avoid having my own server which records each user's currency/data, but maybe that's the only good solution? I want to try to reduce the ability to cheat the system.
Additional thoughts
I could use a Google Saved Games API and Saved Preferences (stored on the device) approach. I would update both Saved Preferences and Google Saved Games. I could keep both data storage methods synchronized, and if the Saved Games data did not match the Saved Preferences, then merge the Saved Prefs with the Saved Games data (e.g. set Saved Games and Saved Prefs to the maximum currency of either). This would enable me to keep a backup of currency on the device in case the user ever deleted their Saved Games profile. This would fail, however, if the user deleted their Saved Games profile, and removed the app from all devices... so many options...
Related/Interesting posts
Ricket's answer here is interesting.
Possible Compromise Solution
Due to the constraints imposed by the IAB systems and the API's available, I think I'm going to settle for this: use managed items for permanent purchases, e.g. different level themes, obtaining new characters, etc. That way these will always be available no matter what happens. Once they are purchased they are purchased forever, i.e. I will never consume these items. Have a separate virtual money (gem) system with a maximum of 100 gems say, which I keep track of through Saved Games. That way I get leaderboard/achievements too. If the player deletes their profile, that's their problem, but at least the core managed items will persist. Hopefully T&C's will cover the potential gem loss, and the maximum of 100 gems will hopefully help reduce any fall out.
You may want to checkout firebase one of its features is a real time database.
You may want to try Implementing In-app Billing. As mentioned in the documentation:
In-app Billing on Google Play provides a straightforward, simple interface for sending In-app Billing requests and managing In-app Billing transactions using Google Play.
Since, as you've also mentioned that you are trying to avoid having your own server to record your user's currency/data, it will be within your advantage. Here are a few advantages given in the documentation:
In-app billing relies on the Google Play application, which handles all communication between your application and the Google Play server. You just need to make your application request the proper permission to be able to use the Google Play application.
You can use the In-app Billing Version 3 API to track the ownership of purchased in-app products in Google Play.
You even have the option to secure your application because Google Play signs the JSON string that contains the response data for a purchase order to help ensure the integrity of the transaction information that is sent to your application.
Now, if you so decide to use in-app billing, may I suggest to please go through the given documentation and do take note of the important notes, cautions/warning and recommendations. I would also suggest that you read the In-app Billing Overview to familiarize yourself with concepts that will make it easier for you to implement In-app Billing.
Lastly, you may also add Security and Design as one of your references for more information about best practices for security and design. The suggestion in this SO post might also help.
I am building a website for a client that is promoting an App on Kickstarter. As one of the rewards this client wants to reward sponsors with in-app purchases. I have searched Apple and posted on other forums but I can't find out if this is possible and if it is possible, how it is done.
Thanks.
You need to implement a promo-code dialog inside your app to do that, then send promo-codes to your Kickstarter users.
I don't think It's possible.
Here's the only Google documentation I could find.
You could make the app free for a short period until all backers have their copy and then raise the price but non backers will be able to download it too.
It would be possible however to use the alpha/beta functionality in the Google Play store to release the app to backers who have joined specific circles setup by you. I don't know if Google would have a problem with you using it like this.
It might be possible to distribute the app outside of the Play Store but I suspect that will become a big support problem as users struggle to get the app installed and keep it up to date.
For iOS part we haven't this functionality with Store Kit. This framework was created to securely process payments from users. You don't need to work with payments. Just deliver some product or an extra functionality to user with promo code. Implement a dialogue in your app where user can enter his code, send this code to your server, check it and give an access for user, if code was right. That's all you need. After making the product available, your app needs to make a persistent record of the "purchase" like you do with normal in-app purchases.
If I have an iPhone app, Android app, and Blackberry app, is there any way to implement a monthly or yearly subscription-based billing scheme such that a user need only pay for one subscription in order to use my app on any device? The problem is that each app store seems to have the stipulation that any fees required to use the app must be paid through them so they can take their cut.
Dropbox does this, but I think they can get away with it because their apps will work for free, and the subcription only offers more storage space. Is their any way to do this type of billing for an app which requires a subscription in order to be used at all? If not, will simply adding some sort of free functionality get me around this?
Thanks.
[EDIT]
Let me be clear, my question is about how this can be done legally. I'm basically running up into the same issue that caused the Financial Times to stop offering its paper through a native iPhone app. The difference between them and me, though, is that I don't mind paying the app markets their cut. I just want to know if this is possible; a user can either order their subscription through Android Market or the App Store, and if a user isn't paying through both stores then I think I'm violating the terms of one of the stores.
You could try Bango.But you need to implement a possibility to transfer the Bango User IDs between your different apps on the different devices. They offer a service where they bill a recurring fee to the user. They offer a SOAP-Based API (amongst others) you can use from your app.
But beware: there are some legal restrictions concerning inapp payment in the Apple AppStore and the Android Market and maybe also in the Blackberry AppWorld.