A question for the devs

[Deleted User]

Hi all,
I have a question to ask the devs who attend this forum: there are so many apps in the AppStore that offer a free trial period, more or less extended, which allows you to evaluate the pro version and then decide whether to buy it or not.
In the world of music apps I have seen this option used very few times, and since I think it would be very useful for both buyers and sellers, I wondered what is so difficult to implement to make this type of app.
I apologize for the stupid question, but I don't understand anything about software programming.
Thanks to those who want to answer.

AlanC3

I haven't used this sort of scheme for two reasons:

1. Implementing in-app purchase means I have to write receipt validation code to make sure that the purchase is genuine. This is NOT easy: the code has to be 'hardened' against security exploits and Apple (deliberately) don't give any sample code because everyone would use it, so if it contained a flaw the vulnerability would be huge.

2. Past experience: I used in-app purchase in one of my previous apps and would regularly get bad reviews accusing me of being a thief (and worse in support emails) when someone loaded the app on a new device and didn't realise they needed to reclaim their purchases.

Plus Apple's refund policy is very lenient. While I don't make a habit of it, I've asked for refunds on apps (iOS and macOS) that have had serious bugs that made them useless, or that just weren't suitable for purpose, and I've never been refused.

[Deleted User]

The user and all related content has been deleted.

SevenSystems

@AlanC3 said:
I haven't used this sort of scheme for two reasons:

1. Implementing in-app purchase means I have to write receipt validation code to make sure that the purchase is genuine. This is NOT easy: the code has to be 'hardened' against security exploits and Apple (deliberately) don't give any sample code because everyone would use it, so if it contained a flaw the vulnerability would be huge.

2. Past experience: I used in-app purchase in one of my previous apps and would regularly get bad reviews accusing me of being a thief (and worse in support emails) when someone loaded the app on a new device and didn't realise they needed to reclaim their purchases.

Plus Apple's refund policy is very lenient. While I don't make a habit of it, I've asked for refunds on apps (iOS and macOS) that have had serious bugs that made them useless, or that just weren't suitable for purpose, and I've never been refused.

1. I have read about that stuff, but never used it precisely because it seemed too complicated for the benefit it would possibly offer. is the iOS ecosystem really rife with hackers who fake IAPs?

2. Yep, however I often got bad reviews because the app is "crippleware" (doesn't have all listed features included, even though every single IAP is clearly marked with a separate parenthesis "(In-App Purchase)").

I may add that in general, adding IAPs is complicated because you have to add a million often convoluted exceptions everywhere in the code, and watch project file / other file compatibility between IAP and non-IAP installations, etc.

Also, IAP can be quite unreliable. When you add a new IAP, it often won't be "recognized" by the App Store until about 24 hours after the update has been released.

[Deleted User]

@tja said:
As a non-developer, I need to add that IAA are a pain in the a..
I try to avoid them when ever possible.

Best scheme for me: Lite App (free) and Full App (

This could be a good alternative, but I think it implies double work for maintenance on the devs side

[Deleted User]

@AlanC3 said:
I haven't used this sort of scheme for two reasons:

1. Implementing in-app purchase means I have to write receipt validation code to make sure that the purchase is genuine. This is NOT easy: the code has to be 'hardened' against security exploits and Apple (deliberately) don't give any sample code because everyone would use it, so if it contained a flaw the vulnerability would be huge.

2. Past experience: I used in-app purchase in one of my previous apps and would regularly get bad reviews accusing me of being a thief (and worse in support emails) when someone loaded the app on a new device and didn't realise they needed to reclaim their purchases.

Plus Apple's refund policy is very lenient. While I don't make a habit of it, I've asked for refunds on apps (iOS and macOS) that have had serious bugs that made them useless, or that just weren't suitable for purpose, and I've never been refused.

Thanks for the reply. What apps you developed, if I may ask?

mungbeans

@AlanC3 said:
I haven't used this sort of scheme for two reasons:

1. Implementing in-app purchase means I have to write receipt validation code to make sure that the purchase is genuine. This is NOT easy: the code has to be 'hardened' against security exploits and Apple (deliberately) don't give any sample code because everyone would use it, so if it contained a flaw the vulnerability would be huge.

2. Past experience: I used in-app purchase in one of my previous apps and would regularly get bad reviews accusing me of being a thief (and worse in support emails) when someone loaded the app on a new device and didn't realise they needed to reclaim their purchases.

Plus Apple's refund policy is very lenient. While I don't make a habit of it, I've asked for refunds on apps (iOS and macOS) that have had serious bugs that made them useless, or that just weren't suitable for purpose, and I've never been refused.

Can you explain what is an example of an un-genuine purchase please.
If the user has to be signed into their Apple account on their device before they can make a purchase, and Apple take care of the validation of that aspect of things, and then they click the purchase button, where is the opportunity for fraud or security exploit? Fruad of whom? the developer of the app, or impersonating a fake Apple account?

[Deleted User]

I think Sugar Bytes have got this right for Aparillo and Factory. The app is free to try but full access to all the features is a one-off IAP.

AlanC3

@SevenSystems said:
1. I have read about that stuff, but never used it precisely because it seemed too complicated for the benefit it would possibly offer. is the iOS ecosystem really rife with hackers who fake IAPs?

@mungbeans said:
Can you explain what is an example of an un-genuine purchase please.

Years back (around 2012 IIRC) there was a significant vulnerability that allowed "man in the middle" attacks to provide a substitute receipt when an app checked for previous in-app purchases, and there was a lot of stuff all over the place about how to exploit it. So you really needed to do receipt validation because it was far easier than you might expect to fake a purchase.

@Faland My previous apps weren't music related. There was a cartoon strip generator (that became quite popular in education and sold around 10,000 copies) and a cartoon character generator that effectively got killed by memoji.

TonalityApp

As others have said, Apple makes it more difficult than it should be to deal with trials and IAPs. I implemented a trial version with receipt validation once, and the tediousness (and unreliability) stopped me from releasing it. It gets even more painful if you've got AUv3 extensions to deal with. Additionally, if you're trying to switch over to such a model from a previously paid app, you're pretty much screwed if you want to allow old users to keep access without paying again (I actually managed to make this work, but I didn't trust the method to work 100% of the time and didn't want to introduce anything that could potentially fail or become an annoyance).

@tja @Faland This (a separate trial app) would be a decent alternative, and generally wouldn't require double the work as you can create separate targets from the same code base (one for a free version and one for a trial version). It may make your code a bit messier though, and Apple tends frown upon (i.e. reject in some cases) making separate trial apps.

@mungbeans Apple doesn't really take care of the validation for you in the case of IAPs... it's complicated. They give you a really basic "validation" for free, but it's prone to hacking and if you want anything better you're pretty much on your own. The fraud isn't the dev or anyone faking an Apple account; instead it comes from users creating false "receipts" for IAPs, which fool Apple's validation process (and potentially your own, depending on the implementation) into thinking that they've paid for the IAP.

[Deleted User]

Thanks for your answers, the situation is beginning to clear up. I imagined that there were technical problems that made impractical to implement this type of method.

The funny thing is that I believed that the use of the in-app system would guarantee greater security to devs because in many countries, including Italy, Apple does not refund this type of purchase and only shows a notice that clarifies that it will not be possible to have a refund.

This prevents untrustworthy people from buying apps to try them out and then get reimbursed for no real reason, except that they don't like them, even if the app works great.
As far as I understand, this behavior involves considerable damage, especially for small devs.

espiegel123

If one maes use of Family Sharing, using IAPs essentially makes family sharing useless as IAPs are exempt from family sharing.

[Deleted User]

The user and all related content has been deleted.

AlanC3

@Faland said:
This prevents untrustworthy people from buying apps to try them out and then get reimbursed for no real reason, except that they don't like them, even if the app works great.
As far as I understand, this behavior involves considerable damage, especially for small devs.

I've been stung by that.

Somebody bought 60 copies of my cartoon strip app in one go (with an educational discount), used them for a year, then asked Apple for a refund. Which was granted.

[Deleted User]

The user and all related content has been deleted.