4 ms·

Unfortunately this model can't be implemented on iOS Your app updates go to everyone, even if they've stopped paying their subscription. So it becomes really

Unfortunately this model can't be implemented on iOS Your app updates go to everyone, even if they've stopped paying their subscription. So it becomes really tricky to sell a subscription on iOS where, once lapsed, the user can continue to use the latest version available at the end of their subscription. One way to do this is to have feature unlocks based on a timeline (Working Copy, an iOS git client, does this). Where users continue to receive a subset of features but some new features are locked behind a yearly upgrade payment. This requires littering your codebase with checks that certain features are unlocked based on the user's latest yearly purchase. I'd love official support for the JetBrains / Sketch subscription model on iOS. As a developer, I would feel bad locking my paying users out of features they paid for just because they stopped subscribing. But I also really can't be bothered spending months developing a robust in-app-purchase feature locking mechanism to work around Apple's limited set of purchase options

joshstrange 5y ago
I completely agree with everything you've said. The big problem (as I see it) is even if there was a way for Apple to provide the infrastructure for "hasPaidForSubscriptionInPast" or "lastSubscriptionActiveDate" or similar, the limiting fact is that Apple only allows 1 version of your app to exist in the app store (under the same identifier, obviously you could release seperate apps). The whole thing breaks down if you need to ship a nasty bug fix for a previous version. Sure, Apple could stop letting users get updates if they stop subscribing but then you have no way to ship ANY updates to that user on an older version. I'm honestly not sure if JetBrains ever ships bug/compatibility fixes for older versions but for apps that are half-free/half-subscription this would be a huge problem. How can I convince people to restart their subscriptions if from their perspective the app has been stagnant since they stopped subscribing? And/or do they even have the option to go to the latest version and just use the free features? Now we are back into the "littering your codebase with checks"-hell that I agree would be terrible to maintain. I'm not giving Apple a pass in the slightest, but I'm having a hard time coming up with what the "gold standard" would be where you could support something like this.

joshstrange 5y ago

I completely agree with everything you've said. The big problem (as I see it) is even if there was a way for Apple to provide the infrastructure for "hasPaidForSubscriptionInPast" or "lastSubscriptionActiveDate" or similar, the limiting fact is that Apple only allows 1 version of your app to exist in the app store (under the same identifier, obviously you could release seperate apps). The whole thing breaks down if you need to ship a nasty bug fix for a previous version. Sure, Apple could stop letting users get updates if they stop subscribing but then you have no way to ship ANY updates to that user on an older version. I'm honestly not sure if JetBrains ever ships bug/compatibility fixes for older versions but for apps that are half-free/half-subscription this would be a huge problem. How can I convince people to restart their subscriptions if from their perspective the app has been stagnant since they stopped subscribing? And/or do they even have the option to go to the latest version and just use the free features? Now we are back into the "littering your codebase with checks"-hell that I agree would be terrible to maintain. I'm not giving Apple a pass in the slightest, but I'm having a hard time coming up with what the "gold standard" would be where you could support something like this.