What Should I Do When My App Is Rejected Due to the Reported Error "serviceCatalog:X6" for Payments? - appgallery-connect

My app submitted for review was rejected by Huawei because the “serviceCatalog:X6” error was discovered for payments. I have checked my test environment by referring to the guide(hyperlink:https://developer.huawei.com/consumer/en/doc/development/quickApp-References/quickapp-api-pay): connected to Wi-Fi, used Android and EMUI versions complying with the specifications, and used the environment in English.

Change the value of serviceCatalog so it is the same as the app category, and do not use the X6 value for your app.
Check whether you have called the GetBuyIntentWithPrice API. If so, check the value of serviceCatalog based on this material.
 Note: The GetBuyIntentWithPrice API has been brought offline, so this may not be the cause.
Check your enabled service APIs.
If you have not called the API, see this material to check your enabled services.
If your app is not a game, do not enable Game Service.
Note: It takes about 15 minutes for your enabling or disabling operations to take effect.

Related

Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service _after_ implementing AdMob

I just integrated AdMob into my project and I get a whole bunch of these error messages in the Xcode output.
The app does not communicate w/ the internet and does not open up WKView (all I found n SO was references to WKWebView like this https://stackoverflow.com/a/44623268/14414215 but doesn't seem to be related to me since I don't use WKWebView). All I did was integrate Google-Mobile-Ads using cocoa pods and followed the Admob support pages.
Some SO Pages talk about ATS, but google support pages don't have the same error message (https://developers.google.com/admob/ios/app-transport-security)
App Transport Security has blocked a cleartext HTTP (http://) resource
load since it is insecure. Temporary exceptions can be configured via
your app's Info.plist file.
Its happening both on simulator and real device. Is this a real issue or something I can ignore?
Also, there's a ton of messages coming out from the Admob SDK, it's frankly a bit annoying to filter through.
The Messages in the console remains and does not seem to affect the app performance (AFAICT) and while it is excessive, I have silenced them some-what using environment variable ( https://stackoverflow.com/a/64471106/14414215) in my scheme. (per below pictures)
Take note however, if you do have issues w/ Google-Mobile-Ads, please be reminded to remove this such that you will be able to see the console messages.

avoiding app store subscription (and implementing your own)

We're building a cloud service that will enable users using misc mobile devices (iPhones, Androids, new Nokias...) to sync their data to the cloud. We plan to charge for the device cloud sync capability through a monthly subscription on our website. Our users will pay a single monthly subscription and then use the service across all their devices, regardless of the platform. Users without subscription will be able to use parts of the app without the cloud sync.
Will the kind folks at the AppStore accept this kind of behavior since we're in a way avoiding the in app purchases - the app will be free, and the user will be paying for the service on our website.
I am aware that the Kindle app for iOS uses the same behavior, so I am guessing this should be possible. From what I saw here:
Will Appstore accept this kind of application?
it should be applicable in my case. Does anyone else have any additional info regarding this?
As far as I know yes as spotify, mog and other music streaming services all behave this way

Acceptance of Location tracking app with nsTimer in background in apple market

I have created this location tracking app, that uses nstimer in background to fetch location every 4 mins.
I am wondering if there will be any problem in submitting the app in the market place..
If you know something regarding it, can you please let me know.
Thanx.
If it's relevant to what your app is doing I don't think it will be a problem.
This is from Apple's App Store Review Guidelines:
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
4.2 Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
4.4 Location data can only be used when directly relevant to the features and services provided by the app to the user or to support
approved advertising uses
But pay attention that if you want your app to keep getting location updates even in background, you need to declare this in your plist file, otherwise when the app goes to background you won't be able to get location updates.
Declaring Your App’s Supported Background Tasks
Support for some types of background execution must be declared in
advance by the app that uses them. An app declares support for a
service using its Info.plist file. Add the UIBackgroundModes key to
your Info.plist file and set its value to an array containing one or
location—The app keeps users informed of their location, even while it
is running in the background.
I've gotten one app through. You have to make sure that the user is informed exactly as to what is going on. So dialogs have to be very specific and have a privacy policy in place.
4 minutes is a little bit extreme if that's a permanent state of your app.. I don't think Apple would allow that if they found it during app review. Would it not suffice to just have it updated based on movement? ie. the significant location change api?
The app I did this for used significant location change api for background location tracking and then stepped it up to higher frequency tracking if the app was actually open.

using ios 5 newsstand limitations

I have an app that needs to fetch background media from the server even when the app is closed.
I know that ios 5 newsstand does this for once a day.
but i also know that this feature is intended for magazines and not any app.
so what is the limitation of integrating it in my app? will it simply get rejected ? is there a format for the app to be a newsstand?
They're very strict on the requirement that the app's content be a newspaper or magazine.
That is, issue-based, mainly written content. Don't waste your time if your app is none of these.
Newsstand applications can receive Push Notifications with a special payload ("content-available":1) that causes the app to launch in the background so that it can check for content to download. This notification can only be sent once a day (the rest of the time it is ignored).
In order to receive this notification, your app must have a UIBackgroundModes that includes newsstand-content. Apple has suggested that non-newsstand apps with this background mode will be rejected, but I have not seen any evidence one way or another.
According to the App Store Review Guidelines,
Apps that are offered in Newsstand must comply with schedules 1, 2 and
3 of the Developer Program License Agreement or they will be rejected.
The License Agreement requires that
[You] confirm that the content of the Licensed Application is a
periodical (e.g., newspaper or magazine)
You acknowledge and agree
that Apple reserves the right to recategorize or reject your Licensed
Application if it is not appropriate for Newsstand.
(I'm in the same boat - would love to use the NK features to manage downloads, spent half a day reading about it, then found out about this limitation.)

What is the iPhone SDK Missing?

I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....