Password Protect an App for Select Audience

We are working to develop an app for attendees at a large conference. These people will not be a part of our organization so we can’t distribute under the Enterprise program and we will have too many users to try any ad hoc methods, so we will look to submit to the Apple Store. Our concern is that we wouldn’t want people who do not attend the conference to be able to access the content within the app, so we would want to password protect the app.


From reading various threads it seems like this approach would be rejected. We would instead need to offer a certain level of functionality to all and then use IAP to unlock the other content. Can someone confirm this is correct?


If so, then a few questions:

  1. What constitutes an acceptable level of free functionality to get it approved?
  2. If the only way to unlock additional content is via IAP, how does this differ from apps that use full authentication with back-end systems, like Bank of America?
  3. And similar to both question 1 & 2, how do apps like Lincoln Financial or Janney Montgomery Scott have fully gated apps with only privacy and legal notices offered as additional functionality get approved?

I’m just trying to understand the distinction and why we couldn’t build something similar.


Thanks

Replies

In your example, I'd suggest you'd be better served w/a modern HTML5 website, rather than attempting to run the app store gauntlet. This approach has the added benefit of getting you both iOS & android out of the box. Add a designer logon and live large.

The thing you can't do is charge to unlock functionality within the app. It is unclear whether '...included in your registration fee is the use of the conferennce app....' is, in fact, charging to unlock functionality. The financial apps you referenced are not charging to use the app.


Under:

3.11.(v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a log-in.

there is an implicit allowance of log-in to use 'account-based features'. You might be able to operate under that (if the first paragraph issue doesn't get you).


You can certainly create an app with multiple conferences offered to the user. The user picks one conference and is hit with an IAP requirement in order to access that conference's content. The cost of that IAP should reflect the 'value' of the unlocked code. That means, if the app is really loaded with stuff you can't charge $1000 for the conference and $0.99 for the IAP. But who decides whether that app for the conference with the $1000 conference fee should be $0.99 or $4.99 or $99.99??? I think you do.


And here is an idea......create a consumable IAP that costs real money - say $9.99 per consumable. Let the conference organizer purchase 100 of them and distribute the consumable - from device to device - to attendees. That way the app developer makes money, the conference organizer includes the modest $10 cost in the conference fee and the user is not shocked that it will cost them $9.99.