My app got metadata rejection(Auto-renewable subscription). They said to give the privacy policy and terms of use URL in the information. so i find the place of privacy policy url and gave it. May i know, where i have to place the terms of use url in iTunes connect for sent it to app store review?
I got the following line in the Appstore metadata rejection list.
Links to Your Privacy Policy and Terms of Use
#ishwarya, you have to give these url and links in your App description in App Metadata in itunes.
Write all detail about your app's Auto-renewable in-app purchase.
eg.
1) Duration
2) Price
3) What are you offering to your customers. etc.
These are means a lot to a end user.
You can check my app's description. please check it out miles-automatic-mileage-log
Related
The Instagram new API policy have become super strict. They are not allowing fetching public content at all. We are literally following all Instagram policies and still cant get approval of public_content.
Is there any workaround or any possibility of fetching the data.
This is the response that I have recieved from instagram
General issues:
Policy Violation (Ad network, Influencer network, Other related): Your
app should not attempt to build an ad network on Instagram, nor
transfer any data that you receive from us (including anonymous,
aggregate, or derived data) to any ad network, data broker, influencer
network, or other advertising or monetization-related service. In
working to build a high quality platform, we ask that you comply with
our Platform Policy
(http://wwww.instagram.com/about/legal/terms/api/).
Yeah, they now grant permissions only to applications with some specific usage cases.
According to Instagram official website, these are:
To help individuals share their own content with 3rd party apps
To help brands and advertisers understand and manage their audience and digital media rights
To help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution
Note that in order to get public_content permission, you need to fall under the 2nd or the 3rd use case. Otherwise, consider changing your application / service in such way that is now uses basic permission and acquires only your users' media.
There is no valid and legal possibility to fetch public data except for successful passing the Instagram permission review.
This official developer documentation page may be useful to you.
You need to enable scopes invividually for your client https://api.instagram.com/oauth/authorize?client_id=CLIENT_ID&redirect_uri=APPCALLBACK&access_token=ACCESSTOKEN&response_type=code&scope=public_content in your browser, using your values for the uppercase words? This should enable your registered client to work with the public_content scope.
https://api.instagram.com/oauth/authorize?client_id=xxxxx&redirect_uri=xxxxx&access_token=xxxxx&response_type=code&scope=public_content
your comment
Read the error message, did you supply a valid client-id from your instagram developer account. Did you setup a redirect_uri for that client? Do you authenticate to instagram to get an access token?
This worked for me this weekend. Double check the values you set in the url and call it directly in your browser.
We have an app and have built in IG integration but keep getting denied on our submission. We want to allow our users who have IG accounts to sign in on our app and then link their IG account. We show the IG icon and their IG name with a follow button so a user can gain followers on IG through our app. We need the follower list permission so that we can know if they are already following them or not and the relationship permission so that we can follow from our app. We have detailed the use case demo'd on a video but this is the only reply we continue to get. Any assistance would be great.
follower_list:
This permission (follower_list) does not support the use case you described in your submission notes, screencast and website. Please review Login Permissions (http://instagram.com/developer/authorization/) for a comprehensive list of permissions and valid use cases.
relationships:
This permission (relationships) does not support the use case you described in your submission notes, screencast and website. Please review Login Permissions (http://instagram.com/developer/authorization/) for a comprehensive list of permissions and valid use cases.
I'm running into the same issue with them declining my application for a valid use case.
I think it's because there wasn't enough information for them to validate the app, or the website isn't following their Platform Policy. I would read through it and make sure you're doing everything they want you to do. I would triple check what use case you picked and how you justified that your app falls into it.
It's also good to cover these, taken from Instagram.com:
Your submission should explain what does your app or company do, which
of the approved use cases your integration falls into, who will be
using your app, how do your user authenticate with your app, how you
use the API to power your integration, how does your product use the
data acquired from Instagram, etc.
I am trying to install an app from Google Play store and I see Device & app history permission.
does anyone know what android permission in manifest causes "Device & app history" permission?
Device & app history
Allows the app to view one or more of: information about activity on the device, which apps are running, browsing history and bookmarks
OK, after researching about this mysteries Android permissions, I got my answer from Adam P. in Android Communities. Thanks Adam.
If you look at the picture below, you will see a description for Device & app history permission for an Android app. At first, this permission description sounds really bad. If you don't know the reasoning behind why all those 3 permissions listed under one group, you would think that this app is really accessing your list of apps, your browsing history and bookmarks. WOW! what a scary thing!
We all know that Google's Android permission system is really broken. From the non tech-savvy people's point of view, this message will scare them and they may not even install your app. Simply, this message on the permission dialog is misleading. Why? actually this sample app needs "retrieve running apps" permission only.
Now, if you pay attention to the message, it reads "one or more of:". What do you mean by "one or more of:"?
Why can't you just display it in a simple format instead of confusing users?
Lesson learned: apparently, one permission from that group is enough to trigger to show that message shown in #1.
Here are the permissions under Device & app history group permission:
Read sensitive log data (android.permission.READ_LOGS)
Retrieve system internal state (android.permission.DUMP)
Read your web bookmarks and history (com.android.browser.permission.READ_HISTORY_BOOKMARKS)
Retrieve running apps (android.permission.GET_TASKS)
Now, if you close the dialog shown on #1 screenshot and then scroll down on the Google Play Store app, you will see a text link reads "View details" shown on #2 screenshot. Click that to see a little bit different version of these permissions. By the way, this link is hidden down in the page and I wonder how many users find that link.
This is what I like. It's clear and concise. Whereas in #1 screenshot, you need to be a linguistic teacher to understand what Google's copyeditors' message mean. Obviously, the first permission dialog in #1 confused me.
OK, this is an extra bonus for you to get confused even more. This sample app apparently requires your phone number to create an account. Nowadays, a lot of social apps started doing that.
Now, if you hold down your app's launcher icon and drag onto App Info button, you will go to your app's details section. Suddenly, you will see this yellow scary message reads "this may cost you money". Well, I know this app does not make a call at all. It just used your phone number to register an account. Google, is it fair to scare people off with that message when the app doesn't really do that?
Conclusion:
Lesson learned; the group permission can be triggered by one permission within and that can cause to show those scary messages.
I am still waiting for the day that Google changes these permissions system. Instead of asking me Yes or No question before installing, I would like to customize the app permissions while I am installing.
Wouldn't it be nice if you check/uncheck each permission and install the app? And, you can turn on more permissions in the app's settings view if necessary. By the way, App Ops won't help with that much.
some more info at: https://support.google.com/googleplay/answer/6014972?hl=en
You're leaving out an essential point concerning these permissions groups. According to Google's Review app permissions (your source) it states the following:
Permissions groups
Permissions groups are designed to show what an app will be able to
access on your device. With permissions groups, you can quickly see
what capabilities or information an app may use before downloading it.
Also, you can review individual permissions at any time using the
Google Play Store Play Store app.
It's a good idea to review permissions groups before downloading an
app. Once you've allowed an app to access a permissions group, the app
may use any of the individual permissions that are part of that group.
You won't need to manually approve individual permissions updates that
belong to a permissions group you've already accepted.
I got an app on my phone that I wanted to update today and noticed that it now asks for access to the Device & app history permission group. As you suggested, the drill down via the Permissions details shows that in reality, it is only requiring the 'retrieve running apps' permission. Great! .. you might think ... but NOT!
If I proceed and accept this now in good faith that I'm OK for this app to see what apps I got running, a subsequent update of this app is NOT going to ask again for access to the Device & app history permission group if they ADD another permission from this same permission group. In other words, today I approve this, granting access to Retrieve running apps (android.permission.GET_TASKS), but as a consequence of that I will not get a new approval request if a next app update adds any of these permissions:
Read sensitive log data (android.permission.READ_LOGS)
Retrieve system internal state (android.permission.DUMP)
Read your web bookmarks and history (com.android.browser.permission.READ_HISTORY_BOOKMARKS)
My conclusion is that if the developers of this app decides they want to obtain eg. my browser history for whatever reason (ads?), they can just add the com.android.browser.permission.READ_HISTORY_BOOKMARKS to their app and I will not be notified when it automatically updates since I have already granted the Device & app history permission group.
Device & app history
Allows the app to view one or more of: information about activity on the device, which apps are running, browsing history and bookmarks
I am developing an app for iOS. I am planning to publish this app in app-store as free app. I would like to authorize app users via outside RESTful webservice. Is this practice against any Apple official guidelines and can be not approved by Apple app review?
The Apple Review Guidelines 11.1 states:
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected.
It sounds clear, but I believe it is open to interpretation on behalf of their reviewers. My company has produced an app exactly as you describe and it not only passed but has been versioned up very recently. Like yours, this app consumes a web service and while the launch screen is public facing, the user must immediately authenticate on the screen after that to go any further.
Our app was not a good candidate for the enterprise store model, since the intention is to distribute to customers, not employees.
Also, and perhaps most telling, when you prepare to upload your binary the iTunes Connect portal has a place for you to enter demo account credentials for the testers to access protected content in your app. So I think you're OK. Screencap below taken from iTunes Connect.
UPDATE
Apparently, when submitting your app you can provide demo account information (#erikr98), implying that an app like yours could be tested by Apple and be approved in the store. I've seen apps like this and worked on them before, but was under the impression that you also had to provide some sort of functionality in the app outside of your "pay wall."
....
I think the answer is maybe. It sounds like you're hovering the line between a public app and an enterprise app. I'm going to assume your question could be rephrased like this:
"I make money from my customers through an existing process (probably on the web) and I want to allow them to use that functionality on iOS without giving 1/3 of that money to Apple via a paid-app or through In-App Purchase. If I build a free app and provide my current customers access to its content via their existing accounts (and through a login process) will Apple reject it?"
Apple's App Store Review Guidelines, Section 11, clearly states that if you allow users to upgrade the content, unlock features or abilities, or purchase content through your application, that purchase must be done through In-App Purchase.
However, in my experience I have found that Apple will not reject an application if it provides value to everyone, not just those with an account. If you provide some sort of benefit for someone without an account you stand a much better chance. In my case we had, 5 features available to the people without an account, and 10 features available for those that could login. Our app was approved and released to the App Store. This was last year.
Also, think about this from a reviewer's perspective at Apple: When you sit down to review an app, its probably not a good sign that you can't access any part of the app without a user name and password.
Look at the model that the newspapers use. Washington Post, for example, has a free app with a $15 In-App purchase that provides you access to their content. You get a limited number of free articles, first, though. See, they provide content for everyone even if on a limited basis. You can also sign into the application, which unlocks all content, if you already have a paying account.
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).