I have an app developed in NativeScript 7, designed for both Android and iOS. It is basically finished except that I have a problem with the in app purchase on iOS, since it works as expected on Android.
I can load the app correctly in App Store Connect and start the verification process, but the testers fail to test the IAP because the information from them is not downloaded and therefore the window to buy does not appear.
I am using the library https://github.com/choang10/nativescript-in-app-purchase following the configuration described in it, as I said above, on Android it works correctly.
At the same time, when the app is rejected, in the IAP it tells me that an action must be carried out by the developer, but I don't see anything explicit inside, only that a red ball appears in the description text, and when I modify any letter or space turns yellow and the error that an action is needed no longer appears.
In addition, everything that has to do with bank accounts, contracts, personal information, acceptance of terms of use and others has already been configured and accepted.
I do not know if the information I have provided is sufficient, let me know, thank you very much.
Related
Our Wear OS application, which is not a standalone application (it is a companion app of our smartphone app, it cannot be used without the smartphone app) keeps getting rejected by Google Play Policy team for the following reason : "Your application requires phone interaction for the watch version to function." even if we have clearly explained in our Play Store description that it is not a standalone application and cannot work when the smartphone app is not available.
Our application was previously accepted and published on the Play Store but we suspect a Google policy change even if we haven't found it clearly anywhere (we have only found recommendations which encourage standalone apps).
=> Are not-standalone Wear OS apps still allowed for Play Store submission or must our Wear OS app include at least a standalone feature ?
Thanks in advance for your help.
TLDR for those who don't want to read the whole message: I had to set the following flag in the watch app's manifest to get my watch app approved:
<meta-data
android:name="com.google.android.wearable.standalone"
android:value="false" />
The longer story
I don't believe that what they forced me to do makes any sense. My application is semi-independent according to Google's own documentation:
A watch app can be considered as one of the following:
Completely independent of a phone app Semi-independent (a phone app is
not required and would provide only optional features) Dependent on a
phone app If a watch app is completely independent or
semi-independent, it is in the standalone category. You must indicate
this categorization to the Google Play store by setting the value of
this meta-data element to true:
My app requires an initial initialization of 2FA accounts, which can be done from an Android phone or from an iPhone. In the second case the Android phone is not required. Google requested to write a "disclaimer", which I've added to the app's description, but that didn't have any effect, they continued rejecting the app. I've asked three times about what was wrong with the disclaimer, but the best answer I've got was:
As much as I'd like to help, I’m not able to provide any more detail
or a better answer to your question.
I've asked one more time about what's wrong with the disclaimer, didn't get any answer, set 'standalone' flag to false and got approved two days later.
The problem that Google created for me and my users was that going forward installing the watch app would be possible from an Android phone only and not from a watch directly. It means that iPhone users would either need to find an Android device to install the watch app or to use ADB, and I'm sure, the users will hate me for this change.
Once again, an impression is that Android is on its way to self destruction: new policies break the old apps, support doesn't exist and developers are forced to make changes that make customers unhappy.
It's not the first episode of this stupidly, just recently I had to disable GDrive functionality in my Android app because new policies broke the existing logic that worked for years, and all OAuth 2.0 processes that Google suggested to be compliant with the new policies were not feasible for a small company
Here is a fragment of my comms with Google that fell on their deaf ears
I built a small application that gives real time update on coronavirus cases in my country.
Just recently, the API which I used to get the number of cases, deaths etc changed their endpoints
e.g from
https://covid19.com/corona/country
to
https://covid19.com/v2/corona/country
Due to strict restictions by Google on apps relating to covid19, I couldnt upload to playstore but I built an APK and shared the link to many people to download.
Now, they cant access the number of cases in the app due to a change in the API endpoints.
Please, how do I change just that string URL from my end to have effect on everyone who has the app already without needing to build another apk and making people to download the app again.
I discovered Firebase Remote Config, I tried it on my android studio, run the app on my phone, and yes it was working on my device, but How do I get it to work on other people devices with the app already installed.??
The only option you have is:
If you have put any text field which takes string data dynamically (like from database/server), there you can inform user to download latest version with a short link. But again that depends upon the text view size/scope you have defined.
Since, without updating the app itself by anyway, it seems impossible to make the existing app working.
I built this app:
https://play.google.com/store/apps/details?id=com.FindNewMusic_Vakil
But ios keeps rejecting me for following reason:
Guideline 4.2.3 - Design - Minimum Functionality
We were required to install Spotify before we could use your app. Apps should be able to run on launch, without requiring additional apps to be installed.
Next Steps
To resolve this issue, please revise your app to ensure that users can use it upon launch. If your app requires authentication before use, please use methods that can authenticate users from within your app.
Even though I added another functionality which enables you to view artist in app (following pics).
Any ideas of what I should do to get app to be approved because I am lost at this point
The guideline clearly states that your app depends on other application for serving its purpose. What you're trying to do is novel but simply recommending won't suffice in my opinion. You could try providing a sample of the music and then if the user likes it, you could provide him/her with the option of redirecting to spotify. Your app should serve some purpose on its own. That's just my opinion however.
There is a test Google Play Store team does when they review Android Auto apps which forbids the visual information presented by the app on the phone while the app is active on Android Auto.
What is the best way to pass this test? Shall I just overlay a black screen which has a TextView on it saying "Android Auto Mode is ON"?
There isn’t any need to write in an additional overlay for this, It’s handled by Android Auto for you. This will be automatically applied when running while attached to a vehicles Head Unit.
Here’s the link to documentation on Testing apps for Android Auto for more info (just in case). While i’m connected to the DHU with a simple sample app, this is a screenshot of the what is visible from the mobile device.
Submitting your app to the Beta or Alpha channels will also kick off a review. If there’s anything that needs to be corrected or updated, you’ll receive an email with more information about what actions you’ll need to take.
I have seen so many threads on creating a time bound trial versions for an android apps but none of them seems to fulfill my purpose.
Few days back i Launched the paid version of my app and now I want to come up with trial version which i dont want to be crippled from any side. So i want to have a time bound limitation on the trial version. I have created a different Package name for the same. Earlier I was using LVL and now also I am using the same except that i created new license library and changed the
setValidityTimestamp(extras.get("VT"));
to
setValidityTimestamp(String.valueOf(System.currentTimeMillis() + (5* MILLIS_PER_MINUTE))); in ServerManagedPolicy.
so that i can test if trial version works for 5 mins and then give me the license error. I published it on the app store , downloaded it and then found that it was still working beyond 5 mins. Now i have unpublished it. Can someone help me in creating the better time bound application which a user can run for a week (say). Besides he should not be able to uninstall and re-install it and then again use it permanently. I know if i can write the info to some external file but again the file can be deleted from sd card and application can be made accesible to the user free for lifetime.
Regards
Pankaj
Within the current capabilities of LVL, and the degree of user control over your average handset, there is currently NO way to do this without a server-side component. Once your app is uninstalled all traces (except, as you pointed out, files you may write to the SD card, which are user-visible) are removed, so the only way to check for an uninstall/re-install is to generate a consistent, device-specific identifier and check with a server component that will either reject this as a re-install or accept it as a new time trial. Even this can possibly be spoofed by a dedicated customer (depending on the server-side component behavior), so you would need to engineer your software so that your server-side component is a necessary part of the process (i.e. it isn't just a license check, it is actually part of the application's functionality).
If you come up with something that works I'd love to hear about it, but I'd say you're out of luck.
#Femi is right, you need a server side component to make always work. What I tend to do is publish only a free version, and teh user buys the full version as in-app-purchase. The IAP server is your server side check if the use purchased the upgrade or not. You can store a pref on first use to know when the user started using the app. If users uninstall and install again your app, they get a new trail period, but this is annoying, and few will do it to save a few bucks. If you add a message in the app where you ask user nicely to upgrade, or have ads that are removed once you upgrade, it is a good enough solution.