There’s a general exemption for media, which why Kindle, Netflix, etc. are not required to use IAP:
3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as classroom management apps), […]
But these rules are all applied inconsistently. Sometimes you get lucky and they approve something that’s technically against their rules, and sometimes you don’t.
I think you could make the app look at the kanji etc that are available even without a subscription, and then enable the review etc once one puts the Api2 key that is not really a log in.
What Apple objects to is the unlocking of content from a service which accepts subscriptions, even if some of the content is available without a subscription. Whether you gain access to the service data through a login or an API key doesn’t seem to matter (they objected to both).
Your suggestion would result in a situation similar to how Benkyou interacted with the WK API, which had a version rejected by App Review a few months ago. That app originally used API key entry to link to a WK account when it was rejected, and changing this to a login still resulted in rejection.
You could always publish app builds externally not though the app store (s3 for example) and have people download/install from there… Then you are at least completely free from the app store restrictions, while still allowing people to somewhat easily install it.
Aw, damn, that sucks. When I was told by Apple that Benkyou was rejected, I assumed that it was because I offered some content for free (hiragana and katakana flashcards), and a WaniKani login without in-app purchases. My plan was to split the app to have one that just offered the WaniKani login, as it seemed like their objection was offering unlockable content.
I hope that Tofugu can offer some assistance with this, since it seems like Apple is intent in killing 3rd party ecosystems that don’t make money for them.
It’s the same thing, which tells me their just getting lucky the same way Allicrab has been up until now and will probably suffer the same fate eventually.
That’s not possible on iOS. Apps distributed outside of the App Store need to have a provisioning profile listing the specific IDs of the devices that it’s going to be installed in. Otherwise it won’t install.
@cplaverty are you using the v2 API? Benkyou is still using the v1 API, but I think I heard that with v2 all lessons are available to all types of accounts?
You can with an enterprise apple developer account. I don’t know how feasible it would be to get one since it requires a DUNS number (from what I understand anyone can apply for one for free…?) and it’s $299/year instead of $99/year, but it’s what a lot of companies use for internal management applications. I’d gladly donate some per year to help with that extra cost if that is a possible option.
I have everything set up in xcode so I can build locally onto my phone thankfully, but it’s definitely not easy for most people and requires a developer account.
This is really out of our hands. I honestly don’t know what to suggest. They made it pretty clear the want in-app purchases of WaniKani subscriptions implemented. But that is obviously a ridiculous request since the app is a third-party and not directly getting this income. I am assuming this was emphasized during the talk with the Apple rep? API V2 returns all information regardless of user’s subscription state. Is there any verbiage about subscriptions on the app? Is there any way the app user able to direct themselves to a page about subscriptions? Usually when Apple sees this it raises flags for them.
There are a bunch of apps out there made by first-parties that obviously have skirted this issue. Spotify, Netflix, Basecamp, Dropbox, et cetera. Should Gmail be banned even though they offer GSuite? Should apps using Google Maps API (paid) should be dinged as well?
We can try reaching out to Apple, but I honestly don’t know how much help it’ll be.
Spotify and Netflix are covered under 3.1.3(a) as reader apps, and dropbox offers the subscription through the app store which means it’s covered under 3.1.3(b).
Basecamp is a really interesting point though, because it (and the other team management apps like JIRA, Monday, Zendesk, etc) really doesn’t seem to fit under either exception… And I can’t think of a reason why google’s apps would fit as well…
I’m also looking at my Amazon cloud cam app, which requires an external subscription AND has a button labeled “cloud cam plans” that leads to a page that says “Unlock advanced features. You cannot manage your cloud cam plan from your app.” which sounds a bit like “directly or indirectly targetting iOS users to use a purchasing method other than in-app purchase”
There’s nothing in the app regarding subscriptions. I made the mistake of mentioning fixing a bug related to review counts after a subscription is lapsed in the update notes.
They weren’t asking me to add a subscription IAP. At the start of the call they made it clear that wasn’t an option since the app is third party. They just wanted me to remove the login and API key entry and instead contact you and “work something out” or “revise my app concept”. I have no idea what she thought we could work out. I made the point the API returns the same data regardless of whether the user is subscribed or not, but that didn’t seem to matter.
In any case, I appreciate the offer of contacting Apple but I don’t see any point. I can’t see it changing their mind. Just be prepared to have IAP in your official app before you release it, which I am sure you already know.