ok in that case, i'm seeing these options:

1. Argue precedence to app review. e.g. that other apps like Hey and are.na are not subject to this rule. But I don't think apple will care
2. Make a blog post go public etc. but I'm not sure enough people will care bc they'll just say why don't you 'just' add the IAP?
3. Add the IAP: There are abstractions like revenuecat that may make this less painful but I don't have any first hand experience with storekit. From my research and looking at other apps it doesn't seem like you have to provide 'sign in with apple' to have IAP. I emailed revenuecat to ask if that's the case, so I'll let you know if they reply.

If we add IAP, can we resubmit the app so we don't have to answer those other stupid questions?

If we add IAP, I'm okay with setting the $rate higher to incentivize using the web. I regret answering the previous questions honestly, so at this point I'm okay with lying to them by omission

Implementing IAP

Technically speaking here's the bare minimum we would need I think:

• Upgrade dialog: in navigator.secureAppContext I'll show an button in the after the user chooses to pay either monthly or yearly. Clicking that button would send out a post message to the app which would trigger the iap payment flow.
• Upgrade dialog: in navigator.secureAppContext I'll also show a button for restoring an existing apple purchase in the case where a user changed phones?
• Somehow the app needs to be able to know if a user has upgraded (with revenuecat you can tie upgrade status to user id and retrieve that status, there might be some equivalent with storekit). But we'd want to check for apple user upgrade status on app launch, and after the checkout flow. We would also need to be able to check apple user upgrade status from the regular website too in the case where they upgrade on the phone but use it elsewhere
• Billing info dialog: if the user is apple upgraded i'll provide instructions on cancelling a subscription through apple