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

[MaverickWar]

@folletto If thats the case then can't the restore link with magrocket to verify? rather than through apple? but then how would magrocket system know for certain that a transaction has taken place if it can't verify the receipt?

[folletto]

Baker can't do this alone, it's all on the sever. Baker can just provide the "openings" (API) to allow the server do what Apple asks.

We won't branch the proposals: the proposals are here for discussion and potentially to ask Apple before writing code (at least, us, if someone has spare time to do that...).

Regarding you latest comment: no idea. I'm not Apple. The comment above was to try to come up with a summary to shed light in the issue. However the server could do that if it knows who is the user: thus, likely, registration. :)

[folletto]

Please note this comment from the stack overflow thread I linked above:

The WWDC2012 session "Managing Subscriptions with In-App-Purchase" covers this topic in depth and actually prescribes using iCloud as the best mechanism for syncing non-renewing-subscription receipts across devices (around 30:00 into the video). The presenter says you can OPTIONALLY implement a registration mechanism involving your own server but suggests that this is more work than is necessary, and that iCloud-based syncing is entirely sufficient. – TomSwift Jun 24 at 23:02

Video: http://www.youtube.com/watch?list=PL5CD6A440489BB7C2&feature=player_detailpage&v=Qef6sssD6c8#t=1710

[MaverickWar]

Ok, just a quick one, i will attach images of this, dont know if it helps, This is how pixel mags does it. Im not saying its how you guys want to but it may give you ideas for the future or may help in the present, i dont know but im trying my best to help.

So this is the login area

The first thing it then does is ask for an email address of the user (login) which it checks with their database i presume.

After inputting email and clicking the button, it searches for account

Then once it finds the account from the email, it asks for a users password.

After logging in, it is linked to an account number name and email.

I hope this helps at some stage, like i said, im a bit limited to what i can do, i can try and send this info to apple that you wrote to see if they would accept any of it, they usually say submit and we will review then. Although maybe i will get a helpful one that wants to help...

[MaverickWar]

Sorry, anyone that just viewed my pics, they were a bit jumbled up, they should work now.

[callaght]

yeah thats what I'm trying to implement at the moment - worth a try!

[MaverickWar]

@callaght what are you trying to implement? What I just posted?

or did you mean davide's activation link solution

[callaght]

yep, here's how its looking so far: -

Hope you guys don't mind me hacking around with the code.

[MaverickWar]

Are you still working a bit on layout, its looking good mate, does it work alright on iphone aswell as iPad? as in how well does it resize, or maybe you have made a smaller iphone version?

What happens if a user doesnt input their details at that point, how will they then be able to access their purchases via login if they didnt register at the time of purchase?

[Simbul]

@folletto I just watched the WWDC video from 2012 (Session 308 - Managing Subscriptions with In-App Purchase). As the comment on Stackoverflow pointed out (and I had totally missed until I watched the video), the solution using iCloud applies to non-renewable subscriptions, which is something Baker doesn't even support. With non-renewable subscriptions an app can rely much less on iTunes Connect (e.g. there's no facility to Restore all purchases), which is why a custom solution for managing subscriptions is needed.

[Simbul]

I've also watched the latest session from WWDC 2013 (Session 305 - Using Store Kit for In-App Purchases). The presenter is mentioning an optional user registration, but again it is only for non-renewable subscriptions. For auto-renewable subscription there's no mention of any user registration. Indeed, the presenter is stressing the importance of offering a button to Restore purchases.

So, stupid question for @callaght, @DrByrnes and @MaverickWar: are you sure you only created auto-renewable subscriptions?

[MaverickWar]

I've tried a few combos with 2 mags, I tried just having subscription, and free issues, I've also tried have a free subscription with paid non renewables and I've tried paid subscription with paid subscriptions.

So I don't know what the right answer is...

[MaverickWar]

@Simbul @folletto Don't know whether that helps, hope you guys are able to get to the bottom of it.

[Simbul]

@MaverickWar just for clarity: you tried submitting 3 times, with:

• 1 paid auto-renewable subscription and some free issues
• 1 free subscription and 1 paid non-renewable subscription (what about issues?)
• 1 paid auto-renewable subscription and some paid issues (I guess that's what you meant as opposed to "paid subscriptions" again)

and they where all rejected by Apple with the same exact reason above?

[MaverickWar]

Yes that's correct, I thought by trying a few different combinations, I would have a better chance, I wanted to release free issues generally with the option of paid, wasn't sure which would give me the best option I success, I was told by one person a free subscription with mostly free and some paid editions was best and someone else said it should be a paid subscription with mostly paid and a few free. Hence the combinations, well that and each was rejected in succession.

[MaverickWar]

This is why I'm so confused. If this user login/reg is optional and only lined to certain iOS IAP's why have I been rejected with all these combos.

[callaght]

@Simbul

Slapshot Mag has got: -

2 x auto-renewable subscriptions 1 x single magazine IAP purchase

[callaght]

@MaverickWar

does it work alright on iphone aswell as iPad? I'm only publishing Slapshot Mag for iPad so haven't created an iPhone xib.

What happens if a user doesnt input their details at that point I think I'll look for some form validation code so that a user can't create an account if they haven't entered all the correct details.

how will they then be able to access their purchases via login if they didnt register at the time of purchase This is a difficult one which I haven't been able to come up with an answer to so far.

[DrByrnes]

@Simbul - In response to your question my app has only one in-app product and it is a non-renewing subscription. I tried with an auto-renewing subscription but since my app isn't a newstand or magazine app Apple kicked it to the curb. The subscription is simply an ad-removal sub.

I've since tried three times with varying random guesses at what Apple wants but no luck. My next step is to rip out the IAP altogether, get this approved, and then I take a bit more time at guessing at the solution that Apple wants.

[MaverickWar]

Hey guys, what's the latest, are we any clearer on what the issue is and how it may be resolved or are we officially stuck?

[Simbul]

I'm afraid we're stuck until Apple comes out with something clearer. In all the videos, posts and documents I've read there's nothing at all about user registration for renewable subscriptions. We need clearer requirements before we implement something of this magnitude.

[MaverickWar]

Is there nothing we can implement sooner (quick fix) or something, there must be quite a lot of people desperately trying to get their magazine on newsstand right now. I'm one of those people, I'm supposed to be releasing my magazine at start of September.

[MaverickWar]

I appreciate you don't want to do unnessessary coding but surely trying something is better than trying nothing.

[callaght]

Is a paid non-renewable subscription = 1 single issue a user can purchase?

[JamesMowatt]

Hi Everyone,

I have been reading this and panicking slightly as I am releasing 2 separate magazines this/next week to the approval process.

My thoughts however are:

To comply with the law and Apple; when I added countly to the app I added a settings bundle to allow users to turn the data collection on and off.

Surely using a settings bundle you could get a user to input their username and password for the app.

When the user adds their user details, run a function that checks that they are correct and if they are set a variable to 1.

Then if the variable is set to 1 send the Username to the database instead of the generated userID that the app creates.

This would then allow for a backup which didn't require users to register however easily implemented the Apple requirement for a registered option to restore instead of restoring direct from Apple's databases.

Any Thoughts

James

[MaverickWar]

Hey James, how does this username and password link to a purchase through the app or download that had been offered as free, also what stops file sharing with your username option? The issue so far is restoring to another device using iTunes seems secure, having a log in to do it means anyone with the login details has access to the files. Not sure how to meet apples demands whilst keeping product secure.

[JamesMowatt]

When something is purchased the USERID is send to MagRocket I believe. As far as the sharing the username, it is difficult, if not impossible. With Apple removing the UDID you are not able to uniquely identify a device. This would have solved the issue as you could limit the number of devices you could install upon. They seem to go back and forward, Apple made it so that StoreKit was all you needed for this as it encouraged people to use Itunes as the purchasing system, now I believe they are opening themselves up to allowing external purchasing (although against there guidelines).

[nicholasmartin]

As for the sharing logins issue, I wonder how/if larger publishers/developers can even combat this issue? It's just like many of the websites you buy access for (training sites, ebook sites, forums, etc) which are "just" secured with a username and password. These are extremely easy to share with friends, family and the rest of the interwebz.

I completely understand Bakers reasons to "wait" with implementing a quick fix until it's clear what apple requires. However, I think Andrew nailed the "quick fix" for the Baker guys. A simple post to the backend server with the UUID and an email address when readers register that can be associated with multiple UUID's on the server.

As far as limiting the sharing of logins, the backend server could set a limit to the number of devices (UUID's) associated with each account maybe?

Anyways, looking forward to see what this community can come up with :) It seems the Newsstand section of the apple developer forum is quite .... dead and nothing there about this afaik.

[MaverickWar]

That sounds like a bang on plan to me, Andrews idea plus administrator set UDID limits. Think that could work.

Then an admin could set a limit of say 5 per account to allow for a household. Sounds like the way forward to me.

[JamesMowatt]

@MaverickWar I believe UDID have been deprecated, every fresh install of Baker generates a different ID, even if you delete it and reinstall on the same device, the ID changes. You would have to then create a method of allowing users to de-authorise devices.

[MaverickWar]

Maybe there is something baker could introduce (maybe a secure code) which generated to one device only? This could maybe communicate with magrocket to tell it a device has been registered? Perhaps?

[folletto]

Apple forbids device identification, full stop. That's why they deprecated UDID and do things like returning a fake Mac Address if you try to get it. We are already generating what's "legal" (similar to the CFUUID), and that's re-created every app (re)install. Don't think of solutions that imply device identification more than what we have now, it's a dead end.

[MaverickWar]

So there is absolutely know way apple will let generate anything unique from a device to limit usage, they don't seem to bother about protecting people content... Basically we need to have open log in and hope they don't share logins around, that's good news'

[nin9creative]

Apple had been under increased pressure to change how the UDID works due to the privacy implications of a developer knowing which particular iOS device is being used to access their app. Apple and several app developers were sued over the use of the UDID to track users across different apps. While the UDID doesn't specifically identify a user, the sharing of UDIDs across ad networks and apps can help piece together a valuable picture of activity and interests of the user of a specific device. Apple seems to be requiring apps to generate their own unique identifiers for each installation to avoid this ability to share such information across apps.

---

From: MaverickWar notifications@github.com To: Simbul/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Thursday, August 29, 2013 8:34 AM Subject: Re: [baker] App Rejected - but I can't understand the reason (#1082)

So there is absolutely know way apple will let generate anything unique from a device to limit usage, they don't seem to bother about protecting people content... Basically we need to have open log in and hope they don't share logins around, that's good news' — Reply to this email directly or view it on GitHub.

[MaverickWar]

Well if what your saying is accurate Andrew, would it not be a solution for baker to come up with its own unique identified that links to magrocket backend and fill the final piece of the puzzle? Or am I missing something, the proposition you originally came up with that another member here highlighted seems to be a good fix, mixed with bakers own unique identifier and magrocket linked to control device limits sounds good.

[nin9creative]

That's what my initial suggestion was.

1)  Let Baker keep generating a UUID for each install/reinstall of the application 2)  Provide some manner to also (optionally) associate an Email address that would allow the backend to tie multiple UUIDs (devices/installs) together for that particular user

*The Restore Purchases function could still work the same

Not so sure on the device limits and all that - would need to think about those types of things.

Andrew

---

From: MaverickWar notifications@github.com To: Simbul/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Thursday, August 29, 2013 11:46 AM Subject: Re: [baker] App Rejected - but I can't understand the reason (#1082)

Well if what your saying is accurate Andrew, would it not be a solution for baker to come up with its own unique identified that links to magrocket backend and fill the final piece of the puzzle? Or am I missing something, the proposition you originally came up with that another member here highlighted seems to be a good fix, mixed with bakers own unique identifier and magrocket linked to control device limits sounds good. — Reply to this email directly or view it on GitHub.

[MaverickWar]

Well Davide was saying that apple don't allow udid anymore Andrew and that baker doesn't work in this way anymore or something, unless I misread. (Been known to happen)

[MaverickWar]

@nin9creative do you not think it would be a good idea to protect these user logins? Otherwise we might see login sharing on larger scale, where as a device limit set to say 5 would make people not want to hand out login. Also it gives enough for a user in a household to share between 5 devices.

I guess it's similar to movie subscription services like Netflix allowing only 5 devices being connected to a single account.

[nin9creative]

Well, I'm calling the ID that Baker currently generates a UUID (unique identifier).  However in the current implementation it does not identify a particular device.  It simply identifies a specific installation on a device.  Which means that it may change if the user deletes the app and reinstalls it.

I'm not suggesting that it changes or that anything different happens.  Just that we come up with a way for a specific user (email address based)

to associate multiple Baker UUID's...  Then the backend could act accordingly and return the same subscription information and purchase information for any install on any of the devices that they have associated with their ID - without having to do a "Restore Purchases"

Andrew

---

From: MaverickWar notifications@github.com To: Simbul/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Thursday, August 29, 2013 12:06 PM Subject: Re: [baker] App Rejected - but I can't understand the reason (#1082)

Well Davide was saying that apple don't allow udid anymore Andrew and that baker doesn't work in this way anymore or something, unless I misread. (Been known to happen) — Reply to this email directly or view it on GitHub.

[nin9creative]

I have no issue with device limits - however the question then is what should be the limit and then maintaining the list of "valid devices" etc.

Since the user can reinstall the application and generate a new ID the old one is basically now "dissapeared" but would still show up on the list etc...

It's just added complexity.

---

From: MaverickWar notifications@github.com To: Simbul/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Thursday, August 29, 2013 12:09 PM Subject: Re: [baker] App Rejected - but I can't understand the reason (#1082)

@nin9creative do you not think it would be a good idea to protect these user logins? Otherwise we might see login sharing on larger scale, where as a device limit set to say 5 would make people not want to hand out login. Also it gives enough for a user in a household to share between 5 devices. I guess it's similar to movie subscription services like Netflix allowing only 5 devices being connected to a single account. — Reply to this email directly or view it on GitHub.

[nicholasmartin]

Could always start with the email and password solution and just monitor if it "runs out of hand" with regards to sharing logins. I can't come up with another solution unless we could use the subscribers iTunes account information for the register feature (as people are less likely inclined to share that with others).

[MaverickWar]

I don't mind but we need to try something...

[nicholasmartin]

Any news or new thoughts from the Baker guys?

[folletto]

I'm sorry, no news. We work in the open, so if anything happens you'll see it commented on the issue tracker, here, or in the git repository – usually both. :)

[MaverickWar]

So basically, the project is paused at the moment. No one is able to submit this app and get it accepted so for now... We are all stuck it would seem.

[nin9creative]

@MaverickWar I think that basically it comes down to bandwidth. I for sure (and assume the Baker guys) don't have a ton of extra time to just keep stabbing in the dark blindly to implement changes that may or may not get approved by Apple.

There needs to be some definite minimal implementable solution that will be approved by Apple before we can all just start making changes. How do we get to that? Good question. I know that @callaght was working on something with both Baker and MagRocket for his own magazine that contained a log on form / email association etc. Personally I'm waiting and am interested in seeing what the feedback is from Apple on his solution.

I know that you are probably frustrated, as are a lot of folks right now. However Apple is constantly changing their requirements and guidelines which makes developing on the iOS platform a moving target. This time around we got stung with the Newsstand stuff...

I'm sure that we'll arrive at a solution at some point soon and everyone can continue on their merry way :)

[Barney2324]

Well I can't officially do anything else with newsstand until we get this issue resolved. I have had the same rejection by apple. I have people waiting for my magazine and no solution. I too am getting a bit flustered about it all.

[Barney2324]

I sure can understand the frustration of others here on this issue because it brings everything to a hault, without trying to sound like I'm talking out if turn here but without fixing this, is it worth bothering adding and fixing other things for iOS 7 etc, at the moment in wont even be accepted into the App Store, I would have thought that would be the priority? That's not me being funny, just making an observation.

[folletto]

As much as this is clearly a big issue and a source of frustration for many people and us as well, it's still just part of all the possible Baker use cases (free issues, free subscriptions, standalone, etc). Stopping iOS7 development to fix this means trading a few day of work for a certain deadline (Apple's announcement on the 10th, 8 days away from now) for weeks of work for an uncertain, untested solution that requires also a server (MagRocket, MagBoy or else) to work, a solution that still wouldn't be usable once iOS7 is released because Baker would still be missing these fixes above.

Plus, someone can still implement the fix in the meantime, validate it with Apple and report back, creating the certainty of a solution that we can finally implement.

[nin9creative]

For what it's worth - I agree with @folletto :)

iOS 7 is just around the corner and needs to be addressed...

Regards, Andrew

Sent from my iPhone

On Sep 2, 2013, at 5:58 PM, Davide Casali notifications@github.com wrote:

As much as this is clearly a big issue and a source of frustration for many people and us as well, it's still just part of all the possible Baker use cases (free issues, free subscriptions, standalone, etc). Stopping iOS7 development to fix this means trading a few day of work for a certain deadline (Apple's announcement on the 10th, 8 days away from now) for weeks of work for an uncertain, untested solution that requires also a server (MagRocket, MagBoy or else) to work, a solution that still wouldn't be usable once iOS7 is released because Baker would still be missing these fixes above.

Plus, someone can still implement the fix in the meantime, validate it with Apple and report back, creating the certainty of a solution that we can finally implement.

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