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.
Related
Google APIs can have usage limits, both on a per-user and a per-application basis. For example, the GMail API free tier is limited to a billion daily quota units across all users of your application.
This works for well-designed server-side applications, which can centrally ensure they obey these usage limits. However, I’m not sure how this is supposed to work for client-side apps. As Google’s documentation says,
Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets.
These apps are still supposed to use a client_secret and credentials, but these are assumed to not be confidential despite the name. However, just saying they aren’t secret doesn’t prevent abuse; a user of the app can take the credentials file and use it for a different purpose, perhaps one that uses the APIs more. What can an application developer do to prevent people doing this from burning through all the available quota?
Edit for clarification:
The use case that prompted this is a purely desktop app that doesn’t connect to any service except GMail (see https://github.com/mbrt/gmailctl/issues/48). If it weren’t for a global quota for all users of the app, there would be no reason to worry about individual users at all; they don’t connect to any service except GMail itself.
You could write a server app (a Cloud Function would work) which holds the secrets. Clients call your endpoint with some form of identifier and you return an Access Token. If your users have a browser, they can auth each time; if not you would need to request a Refresh Token which you store and use that to generate an AT.
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
If I ask the app development company to host an app on their App store or their Google play store accounts, does this make them the legal owners of the app?
I want to stay the legal owner of the app. Does this affect my ownership rights by any means?
To ensure ownership of the App concept, IP and confidentiality:-
- Sign a IP rights document with the Dev Company.
- Sign a NDA with the Dev Company.
You might need more documents depending upon the laws of your country, so this step is not possible without consulting a lawyer.
Also, you need to ensure that:-
- You get all the source code with proper documentation.
- Also, make sure there are no encrypted files/libraries present in the source code.
Since, 2013 Apps can also be transferred between accounts if you happen to create one later.
================================
On the flip side
Why do you want to get into such a mess?
It is easy and cheap to create a Developer account. Just some straighforward paperwork and not more that 100$ for each platform (compared to the amount of resources you have already invested in creating the App)
Once you have the account, give the Dev company Developer access to your account. They can upload the App to your account with it. Once this is done and you have also ensured the you have all the source code, you have no dependencies on the Dev company.
I've used Visual Studio Online Team Services as a code repository and want to know if it is possible for Microsoft Employees to see the code you upload if they wanted to.
The privacy policy doesn't address this specifically that I can see but it does say that Microsoft can use your data for advertising purposes and they can share it with third parties. If "data" means my proprietary code that would be good to know.
Customer Data will be used only to provide customer the Online Services including purposes compatible with providing those services. For example, we may use Customer Data to provide a personalized experience, improve service reliability, combat spam or other malware, or improve features and functionality of the Online Services. Microsoft will not use Customer Data or derive information from it for any advertising or similar commercial purposes. “Customer Data” means all data, including all text, sound, video, or image files, and software, that are provided to Microsoft by, or on behalf of, you or your end users through use of the Online Service. Customer Data is not Administrator Data, Payment Data, or Support Data. For more information about the features and functionality that enable you to control Customer Data, please review documentation specific to the Online Service.
No, not merely if they "want to". Microsoft does provide a clause that allows them access if it's required for security or site operation:
From time to time, Microsoft employees need to obtain access to customer data stored within Team Services. As a precaution, all employees who have or may ever have access to customer data must pass a background check, which verifies previous employment and criminal convictions. In addition, we permit access to the production systems only when there’s a live site incident or other approved maintenance activity, which is logged and monitored.
(From the Visual Studio Team Services Data Protection Overview document.
That being said, this is the most liberal interpretation of this access. I worked as a senior software engineer on the VSO version control team and there's no possibility for me to get access to customer data. If you complain about a bug in our git repository handling, I'm going to ask you if you can give me a copy that I can use to reproduce - I can't just go get it. And if you decline, then I will not be able to get your data.
So while yes, we Microsoft engineers do have the theoretical ability to get to your files, there are significant policy and security safeguards against access and abuse.
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.