I am seeing the same behavior as well (Card Unavailable - Try again in a few moments). Have tried the following things but none did not resolve the issue:Restart Watch and iPhoneRemove credit cards and re-addReset the watchSign out of iCloud on iPhone and restart iPhone and Watch and sign-in again (with adding credit cards back to wallet)I have now filed a bug report with apple (#37449485), let's hope it will be fixed in the next Beta. Payments working fine in iPhone X with latest Beta, just not in WatchOS 4.3 Beta 2 with Series 0 watch.
4.3
404 results found
Post
Replies
Boosts
Views
Activity
Is Apple reversing course on guidelines 4.3 and 4.2.6? What exactly is the standard now?Before, the 4.2.6 App Store guideline read as follows:4.2.6 Apps created from a commercialized template or app generation service will be rejected.The company’s revised wording now states:4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences.Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.https://techcrunch.com/2017/12/20/apple-revises-its-controversial-guideli
The ASRGS have recently been updated to say this:4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.And for reference:4.3 Spam Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is alr
I develop apps for radio stations and WebTVs.Recently I had to update some apps at the same day, because I had to change the streaming url, and all were rejected. Now, even the new apps are rejected.I submitted an appeal explaining that my apps are individually branded, so branding on the home screen, app store searching and the app name matter for my clients. I believe my apps are not creating clutter, each one has unique brand, name, color scheme, background and specific content. That will not confusing users.They replied:We understand that your radio and TV apps are individually branded. However, they share the same concept and feature set. It is no longer appropriate to submit multiple apps that provide the same or similar feature set.To resolve this issue, please consolidate similar apps into a single directory app (for example, all radio apps into one container, and all TV apps into one container) that allows users to select from different channels within the app.These type of one container app with mul
The discussion is under guideline 4.3. See, for example, https://forums.developer.apple.com/thread/85411
Hello,We’re struggling ourselves with the 4.3 Rule Spam restriction, and we need your guide to know how to proceed without breaking the Apple Rules.Well, our company develop homecare softwares, monitoring health by an app, where user can save and view its historic of health recordings, such as glucose, blood pressure, oximetry and others. Actually we have one app at store, Glico, which registers glucose, meals, medicines and physical activity.The problem is, that we have some contracts to develop new apps, for different companies. They’ll have similar purpose, and also similar design, but their icons, colors, and also some parts of the design will be different between them. As well, they will have some same features, and some others different.Our doubt lies in if and how we can do this without breaking the Apple Rules (in this case, 4.3 Rule Spam restriction, about similar apps), because as a great part of features will be shared between the apps, we will reuse great (or at least some) of th
Guidelines 4.3 is in place for very good reasons - Take a look at the Google play store. Be creative and be unique instead of trying to game the system with copy cat apps.
Did you try to submit the app under your own developer account? Or did you enroll the client, and submit their customized app through that client’s own developer account? (Note that you could contract to manage each client’s enrollment, which might potentially allow creating some nice ongoing revenue streams for you. Thus, if Apple approves each client’s apps when submitted under their own account, then rule 4.3 could create additional business opportunities for you.)
I had a similar issue, and it took a lot of email, phone calls and appeals to finally have Apple understand the apps I'm developing. The reviewers are over zealous in their quest to enforce rule 4.3 and are doing more harm than good. I felt it was a huge waste of time and energy.
>and also similar design >because as a great part of features will be shared between the apps, we will reuse great (or at least some) of the codeIf app review sniffs out seemingly templated apps in your case, I think your primary concern should be with 4.2.6, instead. 4.3 kicks in when you have more than a few apps...have you a number, yet?Perhaps the best approach is for each client to have their own dev account, and their own unique app. Only app review knows how they will react otherwise.
I have apps that are travel guides and maps for various cities. I just updated them and some got approved but others got rejected with this message:We noticed that your app provides the same feature set as other apps submitted to the App Store; it simply varies in content or language, which is considered a form of spam.In 4.3 Spam in https://developer.apple.com/app-store/review/guidelines/#spam it saysIf your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase.It says consider not that it's absolutely required. I did consider it and thought it better to have multiple apps because 1) discovery, I can't put the keywords for all the cities in one app and 2) better user experience to have all the data in the initial app download than require seperate downloads from a server.What is the exact policy on this? It seems that many developers are able to have multiple apps with the same functional
One of the developer that you listed - eTips - has hundreds of similar apps in the app store and one of their app update was approved 1 week ago.Same thing with the other one. Ulmon had an app updated a month ago.Wow apple, great job in being consistent with 4.3 spam guideline. Talk about complete selective punishment.
Re: 4.3. They let you launch a few similar apps before shutting you down. Do you know that promo codes work for IAPs? There were a lot of complaints when they were first 'released'.
Wouldn't that run afoul of the 4.3 guideline everyone (who makes cookie cutter apps) is complaining about, regarding spamming the store with almost-identical apps?IAP promo codes do exist and do work. I'm not sure that would help the situation much though. Apple really doesn't seem to encourage arbitrarily charging different people different prices for the same product.
Read the very long posts on 'spamming the app store' and rejections under 'guideline 4.3' on these forums. I think what you are proposing is mentioned as a solution to the 4.3 rejections.