As most of you know, our iOS app hasn’t been available in the App Store since February 19th, 2022. Apple removed it on the grounds that we should implement in-app purchases. After a three-month-long dispute with Apple, we managed to get our iOS app back online and available for download at the beginning of May.
Despite the successful resolution of the problem, the whole situation took a lot of energy and resources on our side and caused frustration for our hosts. Since we’ve always been transparent, in this article, we want to explain in detail the whole story and give a better overview of the issue we’ve been facing for the past three months. We hope that this may help other developers of mobile applications to understand how they may navigate an issue like this one, and come to a resolution in the interest of their customers.
What happened?
On February 19th, 2022, Apple removed our app from the App Store. According to Apple, we should implement in-app purchases for subscriptions to our users.
The main purpose of our iOS app is simple: facilitating push notifications for messages received from guests. All other functionalities are available through a web browser, optimized for a mobile screen. The push notification is the one thing that cannot be emulated on the browser for iOS devices. For that only added value, we were asked to implement in-app purchases.
Why wouldn’t IAP work for us?
Implementing in-app purchases (IAP) would mean that we’d be paying 30% of payment processing fees to Apple, which is not to our greatest advantage. At the same time, IAP is not a good fit for a business like ours for several other reasons.
If we were to implement IAP, the user experience would be seriously degraded. IAP does not support a merchant-initiated upgrade or downgrade of quantities, which is at the core of our pricing. Depending on seasonality, our hosts may have more billable listings in one month than the other. We would have to manually force the user to review all changes beforehand and interrupt their business services.
We’re suspended. Wait, what?
Our app suspension came as a surprise, considering it has been approved several times in the past as a companion app to the existing web application.
All other iOS apps in our space have been approved on the same basis, did not have IAP implemented, and were live. There was no reason why our mobile application would be treated differently.
What did we do?
As soon as our app was suspended, we decided to cooperate and make the case that we should not have to implement IAP based on one of Apple’s exemptions.
So far, we’ve been relying on the Free Stand-alone Apps exemption, which is typically used by software companies operating a web application. The only value of our iOS app is to use iOS app notifications, and the mobile app is not necessary to achieve anything that our software product is doing, except showing guest messages and conversations, similar to that of an email reader. We do not allow the creation of accounts from iOS, and our application prevents taking subscriptions from iOS.
The other exemption we have a strong case for is the Enterprise Services exemption. It is applicable if the end-user is not the buyer – in our case, we had to prove to Apple that our hosts who use the iOS app are working with their team members (cleaning people, assistants, and maintenance people). This exemption is especially valuable because it allows for a full-featured application.
We submitted the information to make that case, but we didn’t hear from Apple for several weeks. As our hosts grew more frustrated with the situation, we decided to appeal to the App Review Board since there was no movement on Apple’s side. Unfortunately, our appeal was declined within the same day, stating the same arguments.
How did we resolve the dispute?
At that point, we decided to look at what others in the industry were doing, and we noticed most had lightweight apps with limited functionality, taking advantage of what we perceived was the Free Stand-alone Apps exemption, to avoid implementing IAP. We wanted to test an assumption that Apple would approve an application that was native, a little bit easier to control, with more limited features, essentially read-only, and therefore falling within that exemption.
We developed a lightweight app that allows hosts to receive push notifications, with limited features (we would have included more features if we had the time to implement them). We developed the app in three days to ensure we had a solution and submitted it for review on Thursday, April 28. That application was again declined on Friday, but this time, we were actually able to get on a call with someone with the Apple Review team.
During that call, we finally managed to get some clarification from Apple. As it turned out, it’s not about the app or its features – it’s really about who our customers are. That hinted towards the Enterprise exemption.
Instead of restricting the features, we were asked to demonstrate that the buyers of Hospitable.com’s services are not the users of the mobile application. Our data confirms that our customers are quick to add teammates (such as cleaners) and users (such as clients) to their Hospitable account. That helped us justify using the Enterprise exemption because our customers were not purchasing an application for themselves but also for their teams who are overwhelmingly the end users of the iOS application.
On Friday night and shortly after this phone call, the lightweight application was finally approved under the Enterprise exemption. The lightweight application was immediately released and over the weekend we received a lot of feedback (spoiler alert: it was rarely positive). Now, upon discovering that we were falling under the Enterprise exemption, we could suddenly have a full-featured application approved.
As of today, nothing has changed. Hosts now have the same app that was available before it was suspended in February. We have not made any changes to it, and Apple didn’t win anything out of the whole situation. On our side, there was a lot of energy and resources burned for nothing and to come back to the original situation of February 18th.
But that was not completely all for nothing; We learned from this situation that we could develop a native application, that is properly integrated with iOS in a fast and elegant manner. We believe a native application, for iOS and Android, would allow us to deliver an upgraded user experience and better push notifications across devices. It is something we now want to allocate more resources to.
