I have one application developed in both platform, where multiple users see each other online when they are using apps at same time.
User A using iPhone can see User B using android within same application.
Now I want to add one more feature of gifting each other based on certain occasions.
So, is it possible to purchase digital content (eg- smiley icons, cards, etc) via in app purchase process of iPhone application and then gift it to User B who is actually using Android version of application?
Inverse should also be case, where User B (android) purchase digital content and send it to User A(iPhone).
Note: I Know that in-app purchase with in same platform is not a problem, it means if all users are using iPhone or Android then it is not a problem. But in my case I have two different platform.
Any idea ?
Basically, no, you cannot cross-buy items between iOS and Android. However another approach is that you implement the possibillity to buy "credits" in both Android/iOS stores. Then implement and host your own DRM-service, where your users could use/give away credits.
Speaking about the iOS In App purchase and following the App Store Guideline:
Apps utilizing a system other than the In-App Purchase API (IAP) to
purchase content, functionality, or services in an App will be
rejected
This means that you can't purchase somethings on android and than unlock something on iOS
Apps using IAP to purchase physical goods or goods and services used
outside of the application will be rejected
And this means that you can't purchase something in iOS and use it on Android.
One simple solution is to keep the trace of what is bought on your server that is queried by both Android & iOS.
Teovald is right, I had to do a test with a dating app that is available on iOS and Android, I bought a one month suscription via iTunes and then my one month suscription was also available on Android app too.
Thanks for all your input with this.
Regards
Antonio
Related
The mobile application I am building has got payment features (both for buying some coins and subscription of (1 month, 3 months and 12 months) for premium accounts. Here, I should not directly ask card details to pay for the users, instead I need to the user's device stored payment to pay for the mobile application (it may depend on ios and android) I am building. Also, how do the subscription works and keeps making charges to the mobile application timely?
Actually, I need help with the implementation mechanism. I am new to this kind of scenario.
For iOS payment you should go with in-app purchase. It is apple's payment gateway. It has facility to create different subscription plan with duration. So, all things which you want that managed by apple. Same way for android , google have also same mechanism for payment(in-app feature).
I have to create an application for iOS and Android, from which I can buy some "items".
I don't understand how the in-app purchase work; can I buy and download the content I already paid for? Or can I buy just the unlocking of internal content without downloading it? If its just for unlocking internal content, is there any way to buy and download the content?
Thanks
The only thing you can't do with in-app purchase is selling actual goods - that's also allowed in case you have a website doing the same thing (eg ebay app). And there are some more rules for iOS in-app purchase.
As for the step by step idea about in-app purchase, here is a gist:
iOS app requests for SKProducts from app store (already setup via itunes connect portal by developer)
The retrieved products are displayed in the app along with localised pricing
User selects a product to buy
Purchase goes through via various steps - in-progress / success / failure. Depending upon the status, the app UI should be updated to keep the user informed.
Upon successful purchase, you can download content inside the app using your own server, or the content that's uploaded on Apple servers. You can unlock the content from within the app as well.
In a nutshell, you have a long way to go. The best way to start theoretically is to refer to In-app purchase programming guide. In addition, this book by Apple is also helpful. And for your needs, here is a sample code from Apple to begin with.
If you rather want a step by step tutorial, here is one authored by me. A rather easier one is the video lecture series with SWIFT and Objective C - prepared by me - which also accompanies code sample for SWIFT and Objective C to save time.
Is it allowed to keep in sync auto-renewing subscription in Android and iOS via an online account?
That is to say : in Babbel, if I buy an auto-renewing subscription in Android (with the Android system of purchasing), it will be available on my iOS device.
In the same way, if I buy an auto-renewing subscription on iOS (via IAP), the courses will be available on Android too.
Everything is synced into my Babbel account.
Is it allowed (according to Apple guideline about IAP) so that I can reproduce this system in an app of mine? (The content sold being videos)
Thank you very much,
Jery
Yes. Both app stores have provisions to allow for this. (It's how Kindle, for instance, avoids being kicked out of the App Store even though you purchase content for it from Amazon directly).
There are drop-in libraries like Frac.as that handle the syncing part for you.
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.
I developed a remote app where the user has to provide an ethernet ID for the target device.
For users who have two of these devices I would like to give the possibility to install the app twice, one for each device.
But they should not have to pay for the second one (eg just selling the same app with different package-names might not even be accepted by Apple, while on Android it is possible)
Designing the app in such a way that it works with two devices would make it quite complex to use.
Is there a good workable solution for this for iPhone and/or Android?
Many thanks
From an iPhone perspective, this wouldn't be possible. Selling the app with different package names is a very poor solution for a number of reasons:
As you say, it wouldn't be accepted by the App Store (and would probably be eventually removed from the Android Market if it is just a duplicate app).
You have no control over which version of the app people download, and then need to keep track of this, which is overly complex.
2 versions of the app would be acceptable if the user has 2 devices, but what if they have 3? What if they had 10?
To me, this would seem like an issue that would be solved by some sort of severside registration server which links up to some logic within the app in order to determine whether the user has made the necessary payment in order to use the app.
In other words -- and if I am understanding the concept of your app correctly (more explanation would be needed for a more complete answer) -- the user goes onto your site (or within the app) and creates an account, registering their Ethernet ID(s) and arranging any payment (or does this via in-app purchase). You could even charge on a per-device basis and have this built in to the app via in-app purchasing.
So the app itself would be free, but in order to use the app they would need an account which has been registered with you in order to ensure it is only being used by paid users.
Not sure exactly what you trying to build but there are other apps (games & tools) have a client and a server app.
Usually people give the client app away for free, but charge for the server app.
Another way, you could do in-app billing so give the app away for free, but charge for the features in the app to unlock it.
Implement your own registration server that keeps track of registered/licensed devices a user has.
That would you would know that a user has bought the required upgrade that can be used with his/her registration on x number of devices.
Each device the user downloads the app onto and logs into their account.
The app could check check if they have purchased the licence on at least one of their devices, thus unlocking the features.
Not definitive, but those are the two ways I would look into if I were developing such an application
Any iOS app from the App store can already be installed on multiple devices, as many as are logged into to the same iTunes customer account. The customer only pays once for one to as many installs as they have devices on that same account.