While transferring the app first time to one account to other its simply done by accepting the review by other receiving account.But when I tried to retransferred app its showing the
As part of Family Sharing, this app is available to all users who’ve purchased it. To complete the app transfer, you must authorise Apple to enable all previously purchased iOS apps to be shared as part of Family Sharing on a permanent basis
in the recipient account. Here New Meta Data and Accept button is not enabled. I did't find any suitable link for this. Can some one tell me that how to fix this issue?
We were into the same scenario and we solved the issue by requesting a paid application agreement from the recipient account page.
Disclaimer: this might not be a solution for all instances but in our case it was the only way to proceed with the transfer process.
Goto itunes connect using the destination account
Goto agreement, tax, banking
Don't open the transfer agreement. Instead, click on the "request" button on the "iOS Paid Applications" agreement on top of the page.
Review the information and accept the agreement. You don't have to provide the entire information but just request it.
Go back to the previous page and open the transfer agreement. You should now be able to accept it.
The recipient should enable Family Sharing on his side.
Family Sharing can be enabled for your apps by accepting the latest
Paid Applications agreement in Agreements, Tax, and Banking. To enable
Family Sharing for customers who have already purchased your apps,
ensure that you’ve selected the appropriate checkbox on the agreements
page.
Related
I have created a app in flutter with in app subscription.
I have used in_app purcharse package for payment.
Whenever I click on pay it opens pop up with primary email which will be used to make payment.
Is there a way to detect all the accounts associated with the android device and ask payment from one specific account from the list of accounts as per our need?
I tried looking into documentation of in app purchasing to check if I can ask for a specific google account, but I didn't get anything related to that.
I'm building an app that uses Apple Pay and as you can see below, when I display the PKPaymentAuthorizationViewController, it's not getting the current user's billing address and email. If the user has used Apple Pay before, they are likely have this data somewhere. I see in the docs there is a PKContact variable on PKPaymentRequest.
Is there a way to get this data and pre-fill it for the first time user of my app?
Users have to enter that information themselves in the iOS Settings app. Then it should be automatically filled out for all websites, apps, ec. that support Apple Pay.
To do this, simply:
Open the Settings app.
Tap "Wallet & Apple Pay"
From there, simply add a credit or debit card, then fill out the default information. Now it should appear automatically in any transactions.
The billing address and email are linked to an Apple ID.
The user can add these details themselves by going to Settings -> Wallet and Apple Pay -> add details and they will be saved for all purchases
I'm writing an iPhone app. The question is regarding the new rules restricting purchases inside the app.
So: the user charges their account up with 'credits' on the associated website using real money via a payment provider. The user installs the app and logs in using the same account as is used on the website: they cannot use the app without first logging in [edit: although they can register an account without adding any credits.].
The purpose of the app is to build up a report about a property, which can then be emailed out, or exported to their account to appear on the website. The report can be built up without using any credits. However, to export the report to the website or email it out, these credits must be expended by contacting the server and debiting X amount from the user's credits.
Here's the question:
The user's account is debited whenever they do this export. Only if/when the user's account is out of credit does the app complain that credits are low (otherwise it doesn't mention them), and it tells the user to go to the website to top-up their account to proceed. Remember that they can't login without an account, which can only be created on the website, and the website explains this.
From the guidelines:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes
to a web site to purchase a digital book, will be rejected
So, my app does not provide a link to the website when explaining that their account is low on credits, it just says that this is what is needed to proceed. The export function, however, does require that the user has topped up their account, so in a sense this does fall foul of the next rule:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
I'm somewhat worried that this credit currency will fall foul of these recently-tightened rules, does anyone want to please reassure me (or, break the bad news)?
P.s. Spotify requires that users pay a subscription (on their website) to use the iPhone app. The difference between them and the above is that their subscription is unlimited-use whereas the above has a per-use charge.
Thanks in advance,
Ian
When you submit your app, include a tester username / password to the App Store. Fuel this account with a few million credits so they don't see the reference to Credits Low. There are many apps that get rejected just for having a login - if you make the reviewer's job easier by having a user/pw they can use, it'll increase your chance of acception.
If you app does get rejected, it means you have to change your model anyway. Actually - you might just be able to add 'Buy Credits' as an in-app purchase to appease Apple. Just make sure the credits in-app cost the same or less than externally - as far as I can tell, Apple will let you keep external purchases around as long as they cost the same or more than in-app purchasing.
Additionally, make sure your "low credits" alert doesn't link to an external page to buy more credits-- this may be frowned upon.
I'm sorry to break it to you but it definitely is a grey area and could potentially get your App rejected because you are asking the user to go to an external source to purchase credits which means Apple is cut out from any potential revenue.
I've had first had experience with this sort of rejection, all that was the issue was the description pointed to a web page where you could buy the product but Apple still had a hissy fit about it and added 2 months to the approval time and it ended up with me removing the link.
You could warn the User that their credits are running low, however pointing to the page to purchase them could potentially be the tipping scale.
On the other hand, there are some apps which make it through but there is no certainty. You are at the mercy of the reviewer in the end... You could potentially ask Apple Developer Support for any further information after describing your scenario.
I work for a start up company and have just developed a paid iPhone app for a client who is not in anyway tech-savvy. She knows very little about the appstore process and does not have a developer account or even a mac.
What we basically need to know is what is the standard way of distributing an app from the clients side?
Does a separate developer account need to be created by the client and the app signed with their certificates? Or...
Can we release it under our own developer license using their bank details in the paid app contract? If so are multiple paid app contracts allowed so that we can release more paid apps for other clients or ourselves?
I have looked around SO and haven't been able to find an answer applicable to our case. Most scenarios inolved the client already owning a developer license.
Only one paid app contract per developer enrollment is allowed. If you want to work with multiple clients (or have your own apps in the App store), each client will need their own ADC account and iOS developer enrollment.
If they can't enroll by themselves, you might have them loan you an email account in their domain to use for their ADC account, use of their company credit card for the $99, legally authorize you (in writing) to apply, click agree, and enter their banking and tax info. Or sit down with them with your Mac and tell them which boxes to click, and which private info to fill in, line by line. If they are a corporation, have them ready to fax incorporation (etc.) papers to Apple. If they have a legal department, you may need to give them a copy of all Apple's agreements ahead of time to review.
Then, after they are enrolled, you can use their ADC account login, from a separate User account on your Mac so as not to contaminate your keychain, to get certificates, build, sign and submit their app for them.
If they want to keep their financial information private, they can always change the password on their ADC team leader account after letting you submit their app.
In order for the profits from app purchases to be given to your client directly, they must have their own account. Otherwise, you can set them up as a user on your account so that they are able to monitor sales and then you send them the procedes afterwards. However in your case it sounds like they would like the money directly.
Buy a new account, set up the distribution certificates and keypairs on a separate computer than the one with all your dev keys for your current account, or even a seperate account on the same computer; keychains do not overlap between users. Sign the package, upload (wait a week) and viola. Give them the credentials to the new developer account and watch the money roll in.
We have developed an application that allows a user to download audio content. The use of application itself is free, but we charge for the content. In our current business model, we accept payments using premium-rated SMS (which increases the in-app user's balance), however, Apple rejects the app since they do not allow this model for their applications.
Is there any other way (except In App Purchase API) we can accept the payments with?
Apple will only accept in-app purchases for this type of business model. Even then, you still have to submit each and every "in-app update" for approval at least a week prior.
Like Liam said, they want their piece of the pie too and they also don't want people slipping something past them (for instance, highly offensive content, pornography, etc.)
Per Apple:
You can create In App Purchases on both Free and Paid applications. Every product you want to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.
There's no other way with this type of business model. More info here around page 116
Another option would be offering the same service via an ordinary website and then offer the app to allow users accessing their existing accounts. Take dropbox as an example - they offer paid memberships which you purchase on their website. The dropbox app itself is free but lets you access your dropbox account, for which you paid elsewhere.
In your case maybe you could offer "credits" for purchase (payable by premium-rated SMS) on your services website which the user could then spend by accessing his account from within the app.
This is less "direct" (requires the user to visit your website to pay for the content he will download later) and I wouldn't even bet on apple's approval (if the website appears to be merely a place for buying credits without further functionality, they'll propably reject the app too for circumventing in-app purchase), but then again, there are (propably) no alternatives. However, I'd talk with apple about this option before implementing it, to avoid wasting time and money. After all, in-app purchase is the way apple wants people to go if they want to spontaneously purchase content using only their device, so they'll defend it.
The easiest was to look at this is to work out why they refused the application, which is because it is not in their interest. You are selling a product to their customer and they are not getting any commission. In order for them to accept the app I would imagine that you will need to provide an in app purchase mechanism, but you could do this in addition to the Premium SMS as long as the app doesn't send the message