App Rejected - Failed on Apple 11.6 guidelines

[callaght]

Slapshot Mag just got rejected again, but I can't understand the reason why. Has anyone been rejected for this reason? : -

11.6

We found that while your app offers a content subscription, there is no mechanism in place to support the App Store Review Guidelines requirement that the subscription content be available to the user on all of their iOS devices.

The detailed requirements for the Subscription Purchasability type are available in the Entering In App Purchase Information section of the iTunes Connect Developer Guide:

"...subscriptions must be provided on all devices associated with a user. In App Purchase expects subscriptions to be delivered through an external server that you will provide. You must provide infrastructure to deliver subscriptions to multiple devices."

It would be appropriate to modify your app to include an optional user registration feature, to deliver subscription content to all of a user's iOS devices. Such user registration must be made optional, not required. We also recommend indicating that registering is required to access the subscription content from their other iOS devices - and providing a way to register later, if users wish to have access to this content at a future time.

In layman terms, what does this mean?

Kind regards, Tom

[nin9creative]

That's weird. First time I've heard about that being used to reject a Baker app (but then again maybe I just haven't heard) :)

I think it means that basically if a user has two iPads or two devices they need to be able to access their subscription purchase on both devices. However I don't see why being able to click on "Restore Purchases" from the subscription dropdown doesn't fulfill this requirement. If I install and purchase something on an iPad, then install it on another iPad and then click the restore purchases - it should unlock the issues on the second iPad as well given the way that Baker resends the info to MagRocket...

Andrew

[callaght]

Thanks Andrew

I've replied with: -

Hi,

Many thanks for reviewing my app.

If the user taps the restore option then all of their purchases will be restored to which ever iPad they are using at the time.

Could you clarify why it was rejected as I think I have misunderstood the rejection reason.

Kind regards, Tom

---

lets see what they say! :-)

[nin9creative]

You could test it by using a test user id in the sandbox on the simulator. Delete the app after making the purchase, then reinstall it in the simulator and do a restore purchases with the same test user id.

[nin9creative]

Yeah, I guess see what they say... lol :)

[callaght]

Good suggestion - I'll test this on my iPad and simulator on Thursday

[callaght]

Apple came back with the response: -

Thank you for your message. It would be appropriate to modify your app to include an optional user 
registration feature, to deliver subscription content to all of a user's iOS devices. Such user 
registration must be made optional, not required.

So I tested by purchasing a subscription on an iPad2 and then restoring the purchase on an iPad Mini and all worked fine, so I replied to Apple: -

Hi,

I implement the user registration feature using open source MagRocket on PHP and MySQL.

I have tested by restoring Slapshot Magazine to a new iPad Mini (original magazine purchase, 
was on an iPad2)

On the iPad Mini, I tapped the 'Restore purchases' option(screenshot1.png attached) and, at 
the end of the process, I was able to download and read the magazine(screenshot2.png attached).

If you require, I can send all 9 screenshots I took in delivering subscription content to a 
user's additional iPad iOS 6.0 device.

Kind regards,
Tom

But Apple has replied: -

Thank you for your message. Aside from the Restore button, it would be appropriate to modify 
your app to include an optional user registration feature, to deliver the non-renewing 
subscription content to all of a user's iOS devices. 

In order for your application to be reconsidered for the App Store, please resolve this issue 
and upload your new binary to iTunes Connect.

I am soooo confused!!!! :-) what do they mean?

It seems restoring to a users addition device is fine. But apple want: -

an optional user registration feature, to deliver the non-renewing subscription content to all 
of a user's iOS devices

What is this feature? I just can't get my head around it.

I'm probably missing something obvious. Can anyone help?

[callaght]

I've been searching around for hours now trying to find something.

I noticed in my 3 Month Auto-renewing subscription that I had selected the option - 'Offer marketing opt-in incentive?'

Which I have said Yes to.

If I click the '?' next to it, it says: -

As an incentive, customers will get a free subscription extension when they opt in to receive 
marketing. This extension is in addition to any free trial that you may choose to offer with the 
subscription.

Could this be why?

[callaght]

PLEASE HELP! :-)

Apple simply aren't responding, I'm tearing out my hair and Slapshot Mag is gathering dust.

[callaght]

I've spoke to a very helpful lady in the Apple review team today.

She called me about this opt-in issue that I've that a brick wall with.

She explained to me that there needs to be an option for a user when they subscribe to optionally enter their email address.

This email address would be stored on a server so that if that user got another iPad they could simply enter their email address on this new iPad and their subscription would be available on that new iPad and all of the content they have paid for would be downloaded.

I tried to explain that the restore button did this, but she said this is not the same.

My problem is I'm not exactly articulate and able to get my point across on the fly! So was unable to explain this to her.

When I tried to talk about MagRocket (sorry I know this is the Baker board) One of the questions she did ask was - What information was MagRocket storing so that it could implement this required functionality.

Argh! That put me on the spot there! :-) Busted! I couldn't answer her question. I think I said something like - er, the UDID and receipts and stuff - oooops.

Maybe this is the key - if I can explain what is stored and how it was determined the user had already subscribed and could download content based on this.

Anyways, she's said I can email her back when I've got my thoughts together. Could someone help me on this - to explain succinctly what is stored and how this determines a user can get their content on multiple devices?

[nin9creative]

Odd since others have been approved already with Baker and MagRocket - not sure why you are having these issues...

Andrew

---

From: Tom Callaghan notifications@github.com To: Simbul/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Wednesday, August 21, 2013 2:49 PM Subject: Re: [baker] App Rejected - but I can't understand the reason (#1082)

I've spoke to a very helpful lady in the Apple review team today. She called me about this opt-in issue that I've that a brick wall with. She explained to me that there needs to be an option for a user when they subscribe to optionally enter their email address. This email address would be stored on a server so that if that user got another iPad they could simply enter their email address on this new iPad and their subscription would be available on that new iPad and all of the content they have paid for would be downloaded. I tried to explain that the restore button did this, but she said this is not the same. My problem is I'm not exactly articulate and able to get my point across on the fly! So was unable to explain this to her. When I tried to talk about MagRocket (sorry I know this is the Baker board) One of the questions she did ask was - What information was MagRocket storing so that it could implement this required functionality. Argh! That put me on the spot there! :-) Busted! I couldn't answer her question. I think I said something like - er, the UDID and receipts and stuff - oooops. Maybe this is the key - if I can explain what is stored and how it was determined the user had already subscribed and could download content based on this. Anyways, she's said I can email her back when I've got my thoughts together. Could someone help me on this - to explain succinctly what is stored and how this determines a user can get their content on multiple devices? — Reply to this email directly or view it on GitHub.

[callaght]

Yeah, I'm really being made to run the gauntlet with this!

Hopefully my experience will come in useful for others that may face this similar situation in future.

I think one of my problems is in me being able to convincingly put across how functionality 11.6 is indeed implemented in MagRocket/Baker. Although, saying that, I shouldn't need to explain - they just need to tap the restore button!!! lol!

[DrByrnes]

I'm being dragged through the exact same coals that you are, callaght. If/when you discover the definitive reason why your app isn't approved and what needs to be changed or implemented for approval, please follow up and post the result here!

[MaverickWar]

If this is the case, could baker link up with mag rocket and create an account feature, which has a login that connect to mag rocket and collects purchased or downloaded content?

I think the issue now is that alot of the commercial apps for newsstand now contain an account feature or login and with the popularity of people having multiple devices and apple wanting their app stores to contain top quality apps, it seems they are making big changes.

This could be something we now all start to face.

[MaverickWar]

I know this might be a little time consuming but if people continue to get rejected as these have and I have. Perhaps we could look to get things in line with their new terms,

[callaght]

I think the solution is: -

1. Store username and password in new table in MagRocket
2. On new device enter username and password
3. If they match, execute the restore button code

No idea if that will work, but thats what I'm going to try.

[MaverickWar]

How will that combat the registration and login they ask for, I was under the impression they equally wanted to see login and registration facility aswell as pulling records for restore?

If this works, would definitely appreciate you helping us out with it, it would be nice if baker worked closer with magrocket to fix this moving forward though.

A temporary fix is good for now but apple appears to be moving in the direction or closer linking server backend with front end app and user transactions being better recorded, managed and recalled in multiple devices.

It seems almost like they have looked at some of the top commercial apps that have teams of devs and said, 'this is what we want all newsstand apps to look like and function like'

[nin9creative]

The part I don't get is what are they actually expecting. The restore purchases process does all this at a subscription, purchases and availability standpoint.

I really don't get the comment about implementing an "optional" registration system... But then rejecting apps?

Apparently they are changing requirements as to what will get approved or not.

Sent from my iPhone

On Aug 24, 2013, at 8:03 AM, MaverickWar notifications@github.com wrote:

How will that combat the registration and login they ask for, I was under the impression they equally wanted to see login and registration facility aswell as pulling records for restore?

If this works, would definitely appreciate you helping us out with it, it would be nice if baker worked closer with magrocket to fix this moving forward though.

A temporary fix is good for now but apple appears to be moving in the direction or closer linking server backend with front end app and user transactions being better recorded, managed and recalled in multiple devices.

It seems almost like they have looked at some of the top commercial apps that have teams of devs and said, 'this is what we want all newsstand apps to look like and function like'

— Reply to this email directly or view it on GitHub.

[MaverickWar]

It's seems like they have a look and feel for what they want to see in a magazine newsstand app, I think this is their way of pushing the quality of apps up, they are looking for all apps to look like the commercial newsstand apps, I know that pixelmags have had the subscribe/register, account area which shows you what you've bought for a while now and it now seems that apple wants all solutions to do this... So for the time being, it looks like baker mags are on hold

[callaght]

From what I understand when speaking to Apple is that its optional to the user if they register or not but it is a mandatory requirement to implement this functionality for us.

[MaverickWar]

So you don't think they are specifically looking for something pretty? Just a specific function, gosh they are so picky.

[MaverickWar]

Someone posted this online as a response to this new apple rule and his app has been accepted for a while now, may be worth a read...also a slight I change to the below, he said aswell as adding a token, he also added a username.

"I have a suggestion given to me from Gavin McKenzie, which sounds like the best bet I've heard:

Upon purchase of the subscription, make a "short code" available to the user. The code would be stored on the server as well, tied to that user's account. When they hit Restore on another device, request the short code from the original device and account, thereby tying those devices together.

Gavin further suggested the use of this in a "pairing" method similar to Bluetooth: when restoring, initiate the pairing on Device A, which generates the short code and pushes it to the server. Device B can then use that code. Five minutes later, or when the pairing screen is dismissed, the code is deleted.

I'm not sure how this would stand up if you want to restore to the same device, say, after deleting the phone and restoring. But this feels like a good start."

[Simbul]

This email address would be stored on a server so that if that user got another iPad they could simply enter their email address on this new iPad and their subscription would be available on that new iPad and all of the content they have paid for would be downloaded.

This is exactly what restoring purchases does. The explanation you got from the Apple rep does not make any sense to me.

If you want to try and get in touch with them again with a bit more information, here's how purchases work in Baker+MagRocket:

1. Baker generates a unique identifier to track the specific instance of the app (i.e. this does not map 1:1 to a user). This uuid is used by MagRocket to know what the app is allowed to download.
2. When a user buys anything (a single issue or a subscription), the App Store saves the purchase against the user Apple ID and sends a receipt to Baker.
3. Baker sends the receipt for the purchase and the uuid to MagRocket, where the receipt is checked against the Apple verification server and the issue (or group of issues) is unlocked.

Now, here's how restoring purchases works:

1. When a user opens the app on a new device, Baker will generate a new uuid. There is yet no way to get to previously purchased content at this point
2. However, when the user Restores purchases, the App Store will send to Baker the receipts for all of the user's purchases (issues and subscriptions).
3. Baker sends the receipts for the purchases and the uuid to MagRocket, where the receipts are checked against the Apple verification server and the issues are unlocked.

You can see that the steps are essentially the same in both scenarios, with the only difference that step 2. is applied to multiple receipts when restoring and to a single one when buying.

In short, Baker generates a uuid for each installation of the app. When restoring purchases, MagRocket will associate all purchases with the new uuid, effectively "cloning" the purchase history of the user, so that they will be able to access all the content they purchased on a newly installed app.

[callaght]

Thanks Simbul!

[MaverickWar]

Ok, i have just got off the phone with them, it was weird having them call me from america, The reason they rang is because i appealed about a few days ago, anyway, i told them all of this and they basically said the software you are using in its current state doesnt comply with their terms, reference 11.6, she said that heres what im saying but there is not user/registration option on the account, there is no where through the app where you can see the user is logged and what the user is able to use, they no longer accept this restore button as an option to fix this issue, its not clear enough for end users, i said what i said on here basically, that they seem to be expecting these apps to be able to access account like features and be like the commercial apps and she basically gave the impression that this is the way its going.

She said if there was a tab that had a login/register facility within the app, not just relying on itunes, but to connect to backend, this would be acceptable.

She also indicated that there could be more changes on the horizon regarding newsstand terms and what they are looking for in their ecosystem.

I cant tell you anymore because i was unable to bounce back from a points, it was a dead end and they seem pretty stuck in their ways about it.

Any thoughts guys?

[callaght]

Just working on it at the moment.

So, from your conversation, does the user have to 'opt-in' with just an email address, or, do they have to create a password as well?

Basically, can the user enter their email and if it matches what they registered with then we just execute the restore button code?

Just out of interest - is the reviewer you spoke to called Sky?

[Simbul]

Here's what section 11.6 of the App Store Review Guidelines says:

11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices

In the review, they quoted the iTunes Connect Developer Guide (even though I couldn't find that specific quote in there):

...subscriptions must be provided on all devices associated with a user. In App Purchase expects subscriptions to be delivered through an external server that you will provide. You must provide infrastructure to deliver subscriptions to multiple devices.

As far as I can see, Baker completely meets these requirements by the Restore Purchases button. The only thing I can think of now is that Apple wants all devices belonging to a user to be in sync. It's not simply a matter of making the content available: supposing a user had an iPad and an iPhone and they bought a subscription on their iPad, all issues covered by that subscription should be pushed to both devices simultaneously.

If that is the case, entering just the email won't work: you would be able to access all purchases for a user just by knowing their email (which is fairly trivial).

@MaverickWar have you asked them about the "short code" approach?

[callaght]

How would we implement such a thing - to push out and sync to all devices? That sounds like a complex thing to do.

Are there any good examples of this in action at the moment on the AppStore?

[MaverickWar]

As far as i could tell they are looking for a cleaner more unified approach and login/account management seems to be the way its going, i asked about short code approach and she said every submission is taken on its merits but she couldnt tell me whether it would be accepted for certain until it was with their submission team.

She said that for now the requirements are that a user have the 'option to log in', she didnt say how the log in would need be implemented, i questioned her and she mentioned username and password for login and registration that link up with a users purchase history, she said ideally apps will have an option to see purchase history also in the future but this isn't a requirement at this moment.

I got the impression that was coming soon though so it may be a good idea to consider this otherwise we could be looking at more down time when they make those changes.

I found it hard to narrow down exactly what they wanted from the conversion, she spoke alot but none of it seem to give 100% clarity on what they want.

You guys had any luck deciphering what they are looking for. I find it all a bit confusing and it seems its sprung out of nowhere.

[MaverickWar]

Well at the moment, like i mentioned before, when you log into custompc magazine, there is a settings area and account section where you log in via username(email) and password.

so you set up a registration to tie in email or username with password, then when user makes a purchase or subscription, this then links to the user/password. and as such whichever device they log onto it would appear.

as pixelmags do this already and have (a lot) of high profile magazine in AppStore, i would assume that this would be sufficient with their current guidelines. Obviously restore buttons no longer work for them.

[nin9creative]

Sounds pretty complex to me! lol

Regards, Andrew

Sent from my iPhone

On Aug 24, 2013, at 4:47 PM, Tom Callaghan notifications@github.com wrote:

How would we implement such a thing - to push out and sync to all devices? That sounds like a complex thing to do.

Are there any good examples of this in action at the moment on the AppStore?

— Reply to this email directly or view it on GitHub.

[MaverickWar]

honestly Andrew, lol i spoke with them on the phone and im more confused and frustrated than ever, they have always made changes and added new requirements but they seem to be going overboard with this.

The real question is, what are we going to do now..... seems like were stuck now.

[Simbul]

The first step should be to understand how serious Apple is with this policy. We all know how capricious the approval process can be sometimes, and 1 case is sadly not enough to extrapolate that this is a new policy they'll enforce from now on.

If they're serious, we need some clear requirements on what they want. This is a pretty big feature and it's definitely not something I'd like to implement in the dark.

[MaverickWar]

its not just one person, youve already had 2 people with this issue, if you check the web, there a few more that have been coming out of the woodwork slowly over the last few months.

but your right, we do need to try and narrow down whats going on definitively.

[DrByrnes]

Good comments here, thanks for the follow up. Unfortunately if I'm understanding the present state of things we still are all just guessing as to what our apps are missing. We don't have a clear, concise, definitive answer as to what Apple wants before our apps are approved which is absolutely maddening!

nin9creative is spot on - Apple wants to make something optional, then reject it when it isn't there - even though the expected functionality is indeed there with the 'Restore Purchases' button!

[nin9creative]

I think ultimately the gap here is that Baker associates each install of a magazine as a "USER". Each time someone installs your application - Baker generates a UUID which is then thought of as the USER_ID.

On the Backend, Baker then links that USER_ID with the receipts that Baker also passes (for single in app purchases and/or subscription purchases).

When a "restore purchases" is done, Baker sends the USER_ID and recommits the purchases for all of the receipts it gets back from Apple. Right now, MagRocket basically treats that as a new USER_ID that has no relationship with the first. While the end user will experience a restoration of purchases on their new device - they are still "separate" in MagRocket's eyes because it doesn't know of a linkage.

I think what we need to do is come up with an optional method of notifying the Backend and storing an email address (along with password) to use that as a "linkage" for the possible multiple USER_ID's... Each instance of Baker installed could still have it's own UUID - however if a user registers with their email address, when they "LINK" a new device to their subscription, instead of regenerating/duplicating all of the receipts and purchases etc on the backend, MagRocket could simply tie the new UUID to the prior UUID so that the multiple devices would be pointed to the same single instance of receipt and subscription data.

However, this is not a trivial change and would require backend work for sure. Along with the headaches of dealing with lost passwords, reset passwords etc from some sort of interface.

I think we need to somehow find out what minimal functionality is needed to get approved and then work towards implementing that - the problem is I don't know how we get at that since the approval process is not at all consistent from app to app.

[MaverickWar]

So a baker login screen that links to magrocket api to check for a user account or create a user account that links to a purchase id is alot of work i assume, i wish i knew what they were looking for exactly Andrew but they spout these terms and are very vague in their follow up. except to say user registration/login (optional for users to use) but must be there.

[nin9creative]

It's not a trivial task. The issue also seems to be that Baker is somewhat disconnected from a specific backend implementation - so it makes it more difficult to come up with something that can be easy to implement/integrate/extend etc...

Once we come up with an approach I would expect that Baker would drive the design of the feature and then spec out a service interface which MagRocket would then comply with.

[MaverickWar]

Are baker working with you on this at present or is it just you, just its been really quiet on this topic last week or so besides this thread so its hard to know whats actually going on.

[folletto]

As you said @nin9creative, I'm just waiting to have more info regarding what the "minimal" setup should be. On our side, well, we could make it incredibly flexible: might even be just adding the ID in a javascript in the INFO box and rename it from "Info" to "Registration". In that way the backend might provide the HTML/JS for that box and that would be it.

But: again, what is the minimal implementation there?

[folletto]

@MaverickWar when we work we work in open, thus, here on GitHub. As said above 1/ it's not a trivial task and 2/ we need to find out the minimal functionality required. We cannot afford to code blindly hoping that Apple likes it.

[MaverickWar]

@folletto Absolutely understand that, just a bit frustrated, took me ages to product the mag and then by the time i get to release there are new restrictions, also i went through all that process to find out specifics and came out with vague unhelpful responses, all i know is my magazine is fine but the app it is delivered in is not up to their requirements.

I wish i could help more but i have said all i know from my discussion with them...

[MaverickWar]

also quick note, not sure how this works but going on apples logic, if a username and password is attached to a purchase, what stops people sharing login details and downloading the magazines for free? This may be slightly off point but that seems a little flawed also from a security of product point of view.

[folletto]

I understand it, clearly. Same frustration here finding out that Apple is changing the guidelines right now, days before iOS7 is out (probably), with such changes that are likely to require a lot of work while we are still fixing the changes happened in iOS7 in time for the release. Not fun. We've been all pretty much scr... ahem. :D

For the solution, I mean, it could even be a solution password-less, where "activating" means "send me an email with the activation code", thus removing a lot of work... but even this, we don't know if Apple would accept it.

[MaverickWar]

I have immense respect for what you guys do and appreciate your hard work, im really annoyed with apple at the moment, they seem determined to make life as difficult for as many people as possible but they seem to spare big business. Its the smaller business' and projects that they have running round like headless chickens dancing to their ever changing and complicated tune.

For now it seems the magazine is on ice, i will have to release my first issue web and hard copy only which is bummer.

[MaverickWar]

the other problem is apples turn around at the moment is close to 7-10 days, meaning 2 attempts is over half a month gone.

[folletto]

Ok, one thing would be to come up with a basic thing to ask Apple first if it satisfies their terms. Quick brainstorming:

Proposal A

• When the user touches to register a subscription we first ask for the email (skippable). Then proceed with the current flow, adding the email pushed to the server.
• When the user restores on a different device, we ask the email, send an email with a code, and then the user will type in the code to restore

Proposal B

• The login is in the button/window info. The user can open the info box and register, or just ignore it.
• The login is separate from both the subscription and restore flows.
• The user instead of restoring through the button restore, can restore by logging in.

Please comment these two, both on complexity of implementation and annoying-factor for the user. If we polish these two (or others) we can then try later to ping back Apple and ask if such solutions will get the approval.

[folletto]

As a reference, quick summary of the findings so far given the comments above (three users with the issue: @callaght, @DrByrnes, @MaverickWar):

1. "include an optional user registration feature" (Apple)
2. "to deliver subscription content to all of a user's iOS devices" (Apple)
3. "optional" (Apple)
4. "when they subscribe" (callaght)
5. "if that user got another iPad they could simply enter their email address on this new iPad and their subscription would be available" (callaght)
6. "must comply on their terms, reference 11.6" (MaverickWar)
7. "there is no where through the app where you can see the user is logged and what the user is able to use" (MaverickWar)
8. "no longer accept this restore button as an option to fix this issue" (MaverickWar)
9. "not just relying on iTunes" (MaverickWar)
10. "there could me more changes on the horizon regarding Newsstand terms" (MaverickWar)

[folletto]

Also, if you have links of other people with the same issue, please add them here (even if they are not accessible to everyone inside Apple Dev Forums).

Because... I discovered people with the same rejection in these threads... from 2011 and 2011!

1. http://stackoverflow.com/questions/4712049/inapp-subscriptions-transferability
2. http://stackoverflow.com/questions/13494692/inapp-purchase-allow-subscription-to-multiple-devices-for-same-user

[updated] with a link from April 2013 and the before mentioned (I think) link from 2012 with the code solution:

3. http://www.snowcrash.eu/binary-rejected-11-6/
4. http://stackoverflow.com/questions/9492898/how-to-support-multiple-devices-with-non-renewing-in-app-purchase

[folletto]

Uhm. Re-reading through everything it seems to me that the mentioned transferability is referred to the subscriptions, not to the IAP content. So, the subscription must be transferrable... with something that isn't a "Restore" but...

From that link from 2011:

It would be appropriate to modify your app in a manner that will enable you to deliver subscriptions to all devices owned by a single user, such as with an optional user registration. If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.

It specifically say "in a manner that will enable" adn "such as with an optional user registration". Yes, the message above is from 2011, but sounds the same as above...

So: it must be a Restore that doesn't use Apple servers to work.

Do you agree?

[MaverickWar]

Proposal A sounds good to me but i dont know what they will say, i will see if i can still post in the resolution centre, if i can, then i will ask their suggestion on this.

How will the download link know that the person is verified to download, i.e. has subscribed or purchased? does this require magrocket integration or is this just a baker solution?

If we try both, i have my app which im publishing an app for another student magazine in my area, so if you decide to branch the proposals, i can submit both (one for each app) and see which (if any) gets accepted, if both go through then you know enough has been done. just need to pick the best one.

Or if its too much work, pick whichever you think is more likely to go through.