I have an application for various platforms. Let them be iOS, Android and Windows. In order to use a app, a monthly fee needs to be paid, but it just needs to be paid once in order to use all platforms. It is the same as with Spotify, so by paying once, every platform can be used.
According to the guidelines of Google and Apple, I need to offer In-App Purchases for the monthly fee. The system is connected to user accounts, which are managed by a server, which is in my control. I am storing the subscription data of users, so if a user uses the In-App Purchases on iOS, the information is transmitted to the central server in order to unlock the Android-App as well (in case it has been paid on another platform already)
The problem is the following scenario:
A user has a valid subscription which has been payed via Google Play. The iOS and Windows apps are unlocked as well. Now the user uninstalls the Android app, goes to the Google Play website and cancels the subscription. In the current scenario, I am not able to detect this and the subscription will be valid for all other platforms.
The question is:
Is there any pattern to circumvent this problem? Spotify and co are solving this issue as well, so there must be a solution for this
Well, the server that handles the authorization of the user (that is, your server) should query the Google Subscription API, to check if the current subscription is still valid. Each SubscriptionPurchase Resource contains information about when the subscription expires.
(see https://developers.google.com/android-publisher/api-ref/purchases/subscriptions)
For Apple, the same stuff applies: You will get a receipt, and with that receipt, you can query the server at any time to check if that subscription is still valid.
There is a slide which summarizes these points and the pitfalls very well: https://speakerdeck.com/rosapolis/the-recurring-nightmare-cross-platform-in-app-subscription-purchases
Bottom line: You won't be able to make that happen without a server that does the communication between the two stores. It comes with issues, though, as the slide shows.
Bonus: The talk from which the slides are taken is also on Youtube
Related
When a user buys a subscription on CH Play, can I use the server to verify and then update the subscription on the iOS App side and vice versa?
However, Apple has a policy stating that: Guideline 3.1.1 - Business - Payments - In-App Purchase - Your app unlocks or enables additional functionality with mechanisms other than the App Store, which is not appropriate for the App Store.
That means the user has to buy again.
So How should I do mobile app cross platform payment?
Should I create a lot of offer codes?
Or refunding the user after buying twice is still a solution?
That means the user has to buy again.
No, you can buy subscription from Android or web and when you login into your account on iOS device you will find your subscription active. this is do not violate Apple's Guidelines (e.g. Spotify is doing this)
You should handle the subscription from server side to verify if the subscription paid on the original platform.
UPDATE:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app.
After Submission to Windows Store I am Getting the Following Issues :-
App Policies: 10.1 Inaccurate Functionality
Your app and its associated metadata must accurately and clearly reflect the source, functionality, and features of your app.
All aspects of your app should accurately describe the functions, features and any important limitations of your app, including required or supported input devices. Your app may not use a name or icon similar to that of other apps, and may not claim to be from a company, government body, or other entity if you do not have permission to make that representation.
Your app must be fully functional and must provide appropriate functionality for each targeted device family.
Keywords may not exceed seven unique terms and should be relevant to your app.
Your app must have distinct and informative metadata and must provide a valuable and quality user experience.
Tested OSes: Windows 10 Mobile
Tested Devices: Acer Iconia W700, Lumia 650
Notes To Developer
The app contains placeholder content that impairs access to core functions of the app.
App Policies: 10.5.1 Privacy Policy
The following requirements apply to apps that access personal information. Personal information includes all information or data that identifies or could be used to identify a person, or that is associated with such information or data. Examples of personal information include: name and address, phone number, biometric identifiers, location, contacts, photos, audio & video recordings, documents, SMS, email, or other text communication, screen shots, and in some cases, combined browsing history.
If your app accesses, collects or transmits personal information, or if otherwise required by law, you must maintain a privacy policy. You must provide users with access to your privacy policy by entering the privacy policy URL in Dev Center when you submit your app. In addition, you may also include or link to your privacy policy in the app. The privacy policy can be hosted within or directly linked from the app. Your privacy policy must inform users of the personal information accessed, collected or transmitted by your app, how that information is used, stored and secured, and indicate the types of parties to whom it is disclosed. It must describe the controls that users have over the use and sharing of their information and how they may access their information, and it must comply with applicable laws and regulations. Your privacy policy must be kept up-to-date as you add new features and functionality to your app.
Additionally, apps that receive device location must provide settings that allow the user to enable and disable the app's access to and use of location from the Location Service API. For Windows Phone 8 and Windows Phone 8.1 apps, these settings must be provided in-app. For Windows Mobile 10 apps, these settings are provided automatically by Windows within the Settings App (on the Settings->Privacy->Location page).
You may publish the personal information of customers of your app to an outside service or third party through your app or its metadata only after obtaining opt-in consent from those customers. Opt-in consent means the customer gives their express permission in the app user interface for the requested activity, after you have:
described to the customer how the information will be accessed, used or shared, indicating the types of parties to whom it is disclosed, and
provided the customer a mechanism in the app user interface through which they can later rescind this permission and opt-out.
If you publish a person’s personal information to an outside service or third party through your app or its metadata, but the person whose information is being shared is not a customer of your app, you must obtain express written consent to publish that personal information, and you must permit the person whose information is shared to withdraw that consent at any time. If your app provides a customer with access to another person’s personal information, this requirement would also apply.
If your app collects, stores or transmits personal information, it must do so securely, by using modern cryptography methods.
Your app must not collect, store or transmit highly sensitive personal information, such as health or financial data, unless that information is related to the primary purpose of the app.
Your app must not collect, store or transmit personal information unrelated to its primary purpose, without first obtaining express user consent.
Tested OSes: Windows 10 Mobile
Tested Devices: Acer Iconia W700, Lumia 650
Notes To Developer
The privacy policy provided for this app fails to inform users of the personal information transmitted by your app and how that information is used, stored, secured, and disclosed. See policy 10.5.1 for details about the requirements for a privacy policy.
I have already stated the privacy policy indicating the use of names ,private data etc. What needs to be done for this type of issue? Any help. Thank you.
What needs to be done for this type of issue?
Without seeing your app, it's really hard to make detailed advice at forum. Regarding this type of question, it will be more appropriate to create a support ticket through your developer account so that support can give you specific suggestion after reviewing your submission.
You may rewrite your privacy policy following How To Add a Privacy Policy to Windows Phone Apps, which is old but you can still find some useful info within it.
I am trying to recruit some beta testers for an app of mine using Test Flight. None of the testers will be in house employees or anything like that- just some folks I know who would like to help test my app (I'm a hobbyist and don't have any employees anyways).
When I went to add somme users in ITC for test flight it made me assign them a role. The only role that made sense to me was "Technical". However, I am worried that assigning somebody I don't know well the technical role will allow them to make changes to my app descriptions, reject or submit binaries, and things like that.
Is that something I need to worry about? Is there a way to assign a user the role of JUST tester without giving them access to my apps via ITC?
Apple's documentation does not seem to explicitly state what users with various roles can do.
No, this isn't really safe, and it's not a good idea to give the 'Technical' role in iTunesConnect to someone you don't fully trust.
The iOS 8 TestFlight system has a way to setup external testers, see the "External testers" section on https://developer.apple.com/app-store/Testflight/
The downside is that your app has to go through the review team each time you make any major changes before it goes to external testers (hence if the tester is really a close part of your team it is still advantageous to add them as an internal tester by giving them the technical role). The reviews don't take as long as a normal App Store review.
Alternatives (that don't involve a review) are Crashlytics Beta Distribution (owned by Twitter) or HockeyApp (owned by Microsoft). There are other services too, or you can host IPAs on your own website (using the mechanism designed for enterprise apps) but generally doing this means you miss out on other features you get when using the more integrated solutions.
Short answer: no. It is not safe to add testers with technical role.
Long answer:
According to iTunes Connect, the user must have Admin or Tech.
After reading the comments, I will complete my answer with this.
There are Internal Testers and External Testers.
External Testers are not available as of yet (see https://developer.apple.com/app-store/Testflight/).
Only Internal Testers are allowed by now (which means, your testers WILL be able to change your apps).
Since you need the user to have minimum rights, you should add the user as Technical (the less risky, but still dangerous).
I see that there is a checkbox in iTC that lets you enable the Internal Tester role:
What permissions will the users have? Theoretically, they will only have access to the beta versions (but that is a guess, since I have not tried it yet). You could create an account for a fake internal tester and check that you can't modify apps with that role.
A technical users will have access to the 'My Apps' section of iTunes Connect. This means that they can change the description of an app in the app store, update prices and even remove an app from sale.
There is no way to have a user with just an 'internal tester' role. That's what external testers are for.
It is possible to grant someone access to test as an internal tester, but not have them be able to log into iTunes Connect.
Create an iTunes Connect User with the "Technical" role with an email address that they can receive. Then have them accept it with a different Apple ID.
As long as they cannot log into iTunes Connect with the email address you added as the "Technical" user, they cannot misbehave.
I have a quick question...may sound a little straightforward but still want to throw it out there.
I am aware that typically a session is limited to a single browser and client instance.
With that said though say a user signs up on your mobile device and starts to do some shopping...maybe adds something to their cart and then decides that they want to complete the purchase on their desktop.
I have some people that want to call this a single session while technically its a new session.
Does this make any sense?
In theory this should work with Universal Analytics, at least for logged in users ( I assume that your users are logged in if they want to buy).
You can pass a client id as a parameter when you create the tracker. The client id is supposed to be formatted as UUID, so you'd have to store that along with your real client id in you backend system and pass it in to the tracker as a part of the confuguration json object (optional third parameter in ga create). Apparently this get retroactively applied to the running session (no written source for that but I recently attented a conference where a google employee said as much, so I assume this is legit).
So as far as it concerns data collection UA is ready for multidevice. I frankly do not know to what extent this already works in the Analytics Interface.
I recently had a glimpse at a Analytics Premium Account which already had some new multdevice reports. I don't know if the fact that those reports are, at least for the moment, absent from the free version means that multidevice tracking does not work yet on the free version (those reports are along the line of Venn diagramms for "How many users used more than one device" and the like).
Does anyone have any idea of the average Adaptive Payments application approval time at the moment? It appears there may be a backlog as we've heard nothing from the moderators and it has been over 15 days (their usual timescale apparently). Our case is a crowdfunding website built on CodeIgniter with the Adaptive Payment gateway installed and ready to go live when we are given application approval. Our site has been active for 6months using other methods via PayPal, but it's time to move up a notch.
It depends on the permissions your application is requesting; less restricted permissions usually goes through quicker.
Even so, check with PayPal Developer Technical Services at https://www.paypal.com/dts/ if you're looking for an update.