DEV Community: Yulia Kondrashova

Apple Fiscal Calendar 2023

Yulia Kondrashova — Mon, 26 Sep 2022 20:11:52 +0000

So, it’s that time of the year again when Apple starts their fiscal year. It is essential for an owner of a mobile app that works on Apple devices to know how to track the revenue and when you’ll be paid your App Store earnings. In this article we explained the main logic behind Apple’s financial calendar and here is a quick recap of how do the fiscal year works:

In general, Apple’s fiscal year is 364 days and it’s divided into four fiscal quarters (Q1, Q2, Q3, and Q4)
Each fiscal year quarter starts with a 35-day fiscal month (5 fiscal weeks) and is then followed by two 28-day fiscal months (4 weeks each)
The first day of the fiscal year is the last Sunday of September
The first day of the week is Sunday (the same as the US calendar)
Apple will release the 2023 Apple payment calendar in September of 2022

We’ve prepared the preliminary Apple fiscal calendar 2023 for you below.

Qonversion offers you an ability to track the revenue that you expect from Apple as well as other subscription app metrics such as churn, retention, refunds, renewals of in-app subscriptions, and other crucial aspects for your business KPIs.

Click here to check Apple fiscal calendar 2023

5 ways to increase app valuation and score a beautiful EXIT webinar

Yulia Kondrashova — Wed, 15 Jun 2022 13:52:56 +0000

Hello team 😊

On June 21, 2:00 p.m CEST, we will hold a webinar together with Alon Waller from Bluethrone, an app acquisition company.

Join this webinar to learn more about:

How to measure and optimize the metrics that affect investors’ decisions
Why ASA is a must-have tool for those who want to sell an app
App Quoting Engine: how do investors determine what is the real value & growth potential of each app
Investors’ insights: what will make investors want to pay more?

Hurry up to save your spot! We’re waiting for you :

https://qonversion.io/webinar-five-ways-to-increase-app-valuation

The new App Transaction API, Enhancements to StoreKit 2 and other WWDC22 updates for in-app purchases

Yulia Kondrashova — Thu, 09 Jun 2022 11:44:12 +0000

During WWDC 2022, Apple released the latest updates for in-app purchases. In this article, we’ll briefly walk you through the most significant improvements that have already been covered: enhancements to StoreKit 2 and App Store Server API. For more details you can refer to our blog post, where you can find detailed description of these updates with advices for its implementation.

1. App transaction API is the new API to verify app purchases

The app transaction represents the signed information about the purchase of your app for the device it’s running on. It is signed using JWS and it replaces the app detail portion of the app receipt from the original StoreKit API. With App transaction you can change your business model from the paid app to a free app with in-app purchases, check who out of your customers pre-order the app, and check purchase dates.

2. New properties in the StoreKit models

The first one is price locale, which now is included in StoreKit products. It allows you to format numbers derived from decimal prices. For example, your customers may see how much a yearly subscription would cost them per month or how much they would save by purchasing your yearly service over your monthly service.
The Server Environment property allows you to tell which server environment a transaction or renewal occurred in, which could be Xcode, sandbox or production. It filters out unnecessary information to prevent it from being sent up to your server
Another one is Recent Subscription Start Date property. You can use this to make informed decisions about your customers based on their subscription patterns. It represent the most recent period of continuous subscription (no more than 60-days gap between any two subscribed periods). It can help you to determine a pattern of loyalty between you and your customer.
These properties return sentinel values — placeholder values that signal that these are not the real values you should work with — in older operating system. To overcome this limitation you need to update your test device to a new operating system. You can take advantage of these new properties on devices as far back as last year’s operating system and it’s available in Xcode 14 and above

3. SwiftUI API for redeeming subscription offer codes and asking your customers to review your app

With App Store connect, you can create uniquely named custom codes that can help you to acquire retain and win back subscribers by providing subscriptions at a discount or free for a limited time. When a customer redeems an offer code for your app, the resulting transaction is sent to the transaction listener. Be sure to set up a transaction listener as soon as your app launches to receive new and updated transactions while your app is running. This offer code view modifier is available starting on iOS 16.

Moreover, you can now ask for a review from your customer through the special sheet. You can decide the right time to request the review for your app, but you need to be aware that the prompt will only be displayed to customers a maximum of three times within a 365-day period and you shouldn’t ask customers to review the same version of your app multiple times.

4. StoreKit Messages API used to display App Store messages to your customer

StoreKit Messages represents a sheet that appears over your app to display an important information to the user. Messages are vended by the App Store and each message has a reason which is included in the Message metadata. StoreKit messages are retrieved when your app goes to foreground. For example, if you’ve increased the price of the subscription and it requires user consent, the App Store will inform affected subscribers through e-mail, push notifications, and an in-app price consent sheet. This will appear when a user opens your app, if they haven’t already responded to your price increase.

How does it work?
You app goes to the foreground. StoreKit checks whether there are some changes with the App Store. The App Store returns the message info to StoreKit, and StoreKit asks the listener for permission to display the message or defer it (if you’d like to create your own scenarios for this messages to appear). But if StoreKit doesn’t include any listener, StoreKit will display the message over your app.

Once you’ve implemented in-app purchases, don’t forget to use the analytics tools to measure how much revenue each of your products brings. Qonversion provides a complete infrastructure for in-app purchases and allows you to create and restore purchases, validate receipts, and provide your app with an accurate subscription status without a need to build your own server. If you’d like to learn more on how to set up and analyze in-app purchases and subscriptions, please read our documentation or message us here.

Qonversion page is here!

Yulia Kondrashova — Thu, 26 May 2022 09:33:22 +0000

Hey everyone!
We created Qonversion blogpage here
Sign up to see more quality blogposts with subscription app insights from our superteam
Looking forward to see you there :)

The Ultimate Guide to Subscription Testing on Android

Yulia Kondrashova — Fri, 29 Apr 2022 09:29:54 +0000

You’ve already implemented access management logic for your subscription app, so now it’s time for testing. Before submitting your app for Google Play Console review make sure it responds to changes in subscription status and grants users access to your premium content. Actions related to subscription lifecycle events should lead to user access updates.

Today, we will follow detailed guidance from Google and explore the main subscription testing scenarios.

Prerequisites

Before we start, make sure that:

There are active subscriptions in the Google Play Console
The logic of purchasing subscriptions is implemented in your app

Sandbox environment setup

License testing

First, we need to configure the License testers list to access all the possibilities of testing subscriptions. After adding a tester’s Gmail address in the Google Play Console you have to log in to the device with the email. License test users can purchase subscriptions for free and use one of two payment methods:

Test card, always approves
Test card, always declines

Test devices

You can use both physical devices and emulators to test subscriptions. For emulators, make sure that it has the Play Store installed. You can check that by selecting Tools -> AVD Manager in Android Studio.

Test Subscription Periods

Subscriptions automatically renew until they are canceled. Test subscriptions renew up to six times and then will be cancelled automatically. Subscription Duration in the Sandbox environment differs from production and is shortened for testing purposes:

Duration of subscription states such as Grace period are also reduced in the Sandbox environment:

Test subscription-specific features

Purchase a subscription with successful payment

Purchase a weekly subscription with the following payment method: Test card, always approves.

Check that you have received an email from Google Play that confirms the subscription is purchased.

Make sure that your app unlocks the premium content after the purchase.
Wait for five minutes for the next renewal. Restart the app and check whether you still have access to the content.
Wait for 25 minutes for another five renewals. When the last renewal period ends, Google Play cancels the subscription. Check that you have received an email from Google confirming the cancellation of the purchase.

Make sure that the premium content is no longer available for you.

Cancel an active subscription

Make sure that you have an active subscription in your app.
Open Google Play and click on the account icon at the top right of the screen. Choose Payments & Subscriptions -> Subscriptions.

Tap on the active subscription.

The Manage Subscription tab will be opened. Click on the button Cancel Subscription and confirm the cancellation. The subscription will be active for the entire current billing period. But the next renewal will not be processed.
Make sure your app is still granting access during the current billing period.
After the end of the billing period, the subscription will be canceled. Make sure your app has ceased to provide access to the content.

Try to purchase a subscription with the fail method

In the purchase dialog, select the following payment method: Test card, always declines and click Subscribe.

Google Play will return an error.
Make sure that your app handles the error correctly and doesn’t provide access to the premium content.

Access recovery

Users sometimes need to restore active purchases when they reinstall your app for any reason or when they use the app on several devices. If the user uses the same Google account, your app should provide the possibility of restoring subscriptions to maintain access to the purchased content. For more information, see the Handling the subscription lifecycle guide in the Google docs. The following test cases assume that you check active subscriptions at the start of your app.

Reinstall the app

Make sure that you have an active subscription and the app provides entitlements to the premium content.
Reinstall and open the app on the same device.
Make sure that your app correctly grants access to the user.

Multiple devices

Run your app on device №1 and purchase a subscription.
Make sure that you have access to the premium content.
Install and open the app on device №2.
Make sure that your app correctly grants access to the user.

Free trials

If you would like to give new subscribers the opportunity to use the subscription free of charge for a specified period of time, configure Free trial as Enabled and specify its duration in the subscription settings in the Google Play Console.

By default, users can only get one free trial or intro price for all subscriptions in the app. You can change that behavior. Go to Google Play Console -> All Apps -> Your App -> Monetize -> Products -> Subscriptions -> Manage subscription settings.

Purchase a subscription with a trial

Make sure that the subscription with a free trial hasn’t been purchased yet from the test Google account.
Start purchasing a subscription with a free trial (a weekly subscription in the example).
Make sure that the purchase dialog notifies that you’ll be charged only after the trial ends:

Purchase a subscription with the approved test card.
Check that you’ve been notified by Google via email that the subscription includes a free trial period.
Make sure the app grants access to the premium content.
Make sure that you have been charged for the full subscription amount only after three minutes (you will receive an email from Google).
The app should grant access to the premium content until the subscription expires and the subsequent automatic cancellation.

Cancel an active trial

Repeat steps 1–4 from the previous case.
Cancel the subscription via Google Play without waiting three minutes.
The subscription will remain active until the end of the trial. Make sure the app grants access to the premium content until the free trial period ends.
Make sure that you haven’t been charged when the free trial period ends.

Introductory price

If you would like to offer new subscribers a discounted price for a specified duration, you can configure an Introductory price in the subscription settings. In a test environment the Introductory price period lasts the same as the subscription test period. Google makes it possible to customize the intro price in different ways; choose the necessary one and test according to the corresponding scenario described below.

Single payment

New subscribers pay an introductory price only once for a specific period of time. After the end of the period, they pay the usual fixed subscription price.

Make sure that the subscription with an intro price hasn’t been purchased from the test Google account yet.
Start the process of purchasing a subscription (example shows a weekly subscription).
Check that Google offers to purchase a subscription at the introductory price.

Purchase a subscription with the approved test card.
Wait for the end of the billing period. The subscription should renew at the regular price (you will receive an email from Google with the details).

Recurring payment

New subscribers pay an introductory price for a fixed number of billing periods. Then they pay the usual subscription price.

Repeat steps 1–5 above.
Wait for the end of the billing period. Make sure that the subscription renews at introductory price again (you will receive an email from Google with the details).
Make sure that the third step was repeated for the number of billing periods specified in the intro price settings.

Grace period

Users may experience payment issues at the end of the billing period. While Google is trying to re-charge the money, you can still grant access to the subscription. Configure Grace period in the subscription settings in the Google Play Console for that purpose.

Grace period with payment resolution

Purchase a monthly subscription with the approved test card.
Open the Google Play app. Choose Account -> Subscriptions & Payments -> Subscriptions. Click your test subscription and change the payment method to “Test card, always declines.”
After five minutes, payment should be declined. The subscription enters the grace period.
Make sure that during the grace period the user still has access to the subscription.
Change the payment method in Google Play to an approved test card.
After another five minutes (duration of the grace period in the test environment), the subscription successfully renews, recovers, and exits grace period.
The app should grant access to the premium content until the subscription expires and the subsequent automatic cancellation.

Grace period without payment resolution

Please follow the Grace period and Account hold section below. ##Grace period and account hold The subscription goes into the Account hold state when the user is experiencing payment issues and grace period isn’t configured or has ended without payment resolution. The user no longer has access to the subscription while Google is retrying the payment method. Unlike the Grace period, Account hold does not need to be configured, and its support is mandatory for all developers.

With payment resolution

Note: Before we start, make sure that the grace period is configured for the subscription.

Purchase a monthly subscription with the approved test card.
Change the payment method in Google Play to a declined test card.
After five minutes, payment should be declined and the subscription should enter the Grace period.
After another five minutes, payment should be declined again and the subscription should enter account hold. The app should stop giving access to the subscription content.
Change the payment method in Google Play to an approved test card.
In the next 10 minutes the subscription renews and exits Account hold.
Make sure the app grants access to the premium content until the subscription expiration and the subsequent automatic cancellation.

Without payment resolution

Repeat steps 1–4 from the previous case above.
After 10 minutes, the subscription should be canceled. Make sure that the user has lost access to the subscription.

Account hold and no grace period

Account hold with payment resolution

_Note: Before we start, make sure that the grace period isn’t available for the subscription. _

Purchase a monthly subscription with the approved test card.
Change the payment method in Google Play to a declined test card.
After five minutes, payment should be declined and subscription should enter Account hold. Make sure that the user has lost access to the subscription.
Change the payment method in Google Play to an approved test card.
After 10 minutes (duration of the account hold state in the test environment), the subscription should recover, renew, and exit the Account hold.
Make sure the app grants access to the premium content until the subscription expiration and the subsequent automatic cancellation.

Account hold without payment resolution

Repeat steps 1–3 from the previous case above.
After 10 minutes, the subscription will be canceled. Make sure that the user still doesn’t have access to the premium content.

Downgrade/Upgrade

You can provide your active users with the ability to upgrade and downgrade subscriptions. In these cases the previous subscription is invalidated, and the new subscription takes place. Let’s have a look how the ProrationMode value affects your subscribers while upgrading from a base to a premium subscription. The following test cases assume that the Upgrade button has already been added to your app.

Immediate upgrade

Purchase a base subscription.
Make sure your app grants access to the base content of your app.
Click on the Upgrade button and purchase a premium subscription with the suitable value of the following ProrationMode values: IMMEDIATE_WITH_TIME_PRORATION, IMMEDIATE_AND_CHARGE_PRORATED_PRICE, IMMEDIATE_WITHOUT_PRORATION, IMMEDIATE_AND_CHARGE_FULL_PRICE.
The subscription is upgraded immediately. Make sure your app unlocks the premium content of your app.

Upgrade after renew

Purchase a base subscription.
Make sure your app grants access to the base content of your app.
Click on the Upgrade button and purchase a premium subscription with the DEFERRED ProrationMode value.
The subscription is upgraded only when it renews. Your app should unlock premium content only after renewing the subscription.

Refunds

All of the previous scenarios were executed in a test environment. To test the refund, you need to buy a subscription for money in the production environment.

Please be familiar with Google’s Refund policy before making a purchase.
Purchase a subscription.
Request a refund on Google Play
Wait until Google processes your request (usually one day).
After the completed refund, your app should stop granting access to the user.

In Conclusion

In this article we’ve explored the main testing scenarios, but there are a few more, such as resignup or promo codes testing which are covered in the Google documentation.

We hope you successfully tested your subscriptions and didn’t find any bugs. But even if you did, it’s great news to find them before publishing your app. Implementation of subscriptions has never been easy and requires tremendous resources for developing access management logic — there are so many scenarios and use cases. Qonversion significantly simplifies this process by providing you with ready-to-go solutions so you can use purchase, restore and checkPermissions methods and manage your subscriptions without any issues. In any case, whether you use an in-house solution or Qonversion, please do your testing — it is a must. Remember: It is better to be safe than sorry; the trust of your users is everything.

Handling StoreKit Errors

Yulia Kondrashova — Fri, 22 Apr 2022 09:34:54 +0000

The error state is one of the five UI states. It is pretty important for users’ experience and satisfaction. If you don’t handle errors, it will be the main reason for users to lose control and as a consequence – a reduction in retention or even deletion of the app.

Error handling is more important when you work with dependencies, especially when working with a library like StoreKit. In general, StoreKit is a black-box in which anything can happen. In this short article, we will explore how to handle failed transactions and give appropriate error messages to the user as a feedback.

NSError Overview

I just want to remind you how NSError works. We will need it below. Any error that happens on iOS includes error domain, domain-specific error code, and additional information specific for the application. So, for us the most important fields are:

domain
code
userInfo

Variety of errors

Errors associated with payments, store products, and cloud services occur with the domain model SKErrorDomain and error codes SKError.Code. The entire list of errors includes more than 15 options, you can find them in this documentation. In addition to SKErrorDomain errors, there may be network problems that occur in the NSURLErrorDomain model. Let’s handle all of them.

Handling StoreKit errors

For error handling, we need to implement two methods of the SKRequestDelegate delegate.

optional func request(_ request: SKRequest, didFailWithError error: Error)

This is an optional method that receives errors from SKRequest. It is important to keep in mind that when these errors occur, (void) requestDidFinish: (SKRequest *) request will not be called.

The second point of failure is transaction processing, here errors are quite varied and can be associated with both the fact that the user canceled the operation, and with the restriction of rights under parental control, for example. To receive errors when working with transactions, it is necessary to separately process the transaction status SKPaymentTransactionStateFailed.

- (void)paymentQueue:(nonnull SKPaymentQueue *)queue
 updatedTransactions:(nonnull NSArray<SKPaymentTransaction *> *)transactions {
  for (SKPaymentTransaction *transaction in transactions) {
      switch (transaction.transactionState) {
        case SKPaymentTransactionStatePurchasing:
          break;
        case SKPaymentTransactionStatePurchased:
          // implement handling purchased state
          // [self handlePurchasedTransaction:transaction];
          break;
        case SKPaymentTransactionStateFailed:
          [self handleFailedTransaction:transaction];
          break;
        case SKPaymentTransactionStateRestored:
          // implement handling restored state
          // [self handlePurchasedTransaction:transaction];
          break;
        default:
          break;
      }
  }
}

Method handleFailedTransaction:

- (void)handleFailedTransaction:(SKPaymentTransaction *)transaction {
  NSError *error = transaction.error;

  if (error && [[error domain] isEqualToString:SKErrorDomain]) {    
      switch (error.code) {
        case SKErrorUnknown:
          // Error code indicating that an unknown or unexpected error occurred.
          break;
        case SKErrorClientInvalid:
          // Error code indicating that the client is not allowed to perform the attempted action.
          break;
        case SKErrorPaymentCancelled:
          // Error code indicating that the user canceled a payment request.
          break;
        case SKErrorStoreProductNotAvailable:
          // Error code indicating that the requested product is not available in the store.
          break;
        case SKErrorPaymentNotAllowed:
          // Error code indicating that the user is not allowed to authorize payments.
          break;
        case SKErrorPaymentInvalid:
          // Error code indicating that one of the payment parameters was not recognized by the App Store.
          break;
        // Belowe codes available on different iOS
        case 6:
          // SKErrorCloudServicePermissionDenied
          // Error code indicating that the user has not allowed access to Cloud service information.
          break;
        case 7:
          // SKErrorCloudServiceNetworkConnectionFailed
          // Error code indicating that the device could not connect to the network.
          break;
        case 8:
          // SKErrorCloudServiceRevoked
          // Error code indicating that the user has revoked permission to use this cloud service.
          break;
        case 9:
          // SKErrorPrivacyAcknowledgementRequired
          // Error code indicating that the user has not yet acknowledged Apple’s privacy policy for Apple Music.
          break;
        case 10:
          // SKErrorUnauthorizedRequestData
          // Error code indicating that the app is attempting to use a property for which it does not have the required entitlement.
          break;
        case 11:
          // SKErrorInvalidOfferIdentifier
          // The specified subscription offer identifier is not valid
        case 12:
          // SKErrorInvalidSignature
          // The cryptographic signature provided is not valid
          break;
        case 13:
          // SKErrorMissingOfferParams
          // One or more parameters from SKPaymentDiscount is missing
          break;
        case 14:
          // SKErrorInvalidOfferPrice
          // The price of the selected offer is not valid (e.g. lower than the current base subscription price)
          break;
      }
  } else if (error && [[error domain] isEqualToString:NSURLErrorDomain]) {
    switch (error.code) {
      case NSURLErrorNotConnectedToInternet:
        // A network resource was requested, but an internet connection has not been established and can’t be established automatically.
        break;
      default:
       // Handle other network errors here
      break;
    }
  }

}

Types of errors

Let’s take a look at all the possible cases of StoreKit errors.

.unknownSKErrorUnknown code 0

This error SKErrordomain=0 return usually happens when an unknown or unexpected error has occurred. Usually, there is no need to take any action on the developers side, but here are a few recommendations to check:

Check the LocalizedDescription property of the error object.
If the error appeared during the testing, try logging out or try it with a new test user.
The problem might be on the user’s account side, so it is worth asking the users to check and see if anyone gets back to you with more information.

.SKErrorClientInvalid code 1

This error is displayed when someone without the required permissions tries to perform the action. No action is needed to be done on your side. However, it is possible to try and show an automated notification with a message related to the action such as: “due to …. you are not allowed to perform the action. Please, change your account or device”.

.SKErrorPaymentCancelled code 2

This error code indicates that the user canceled a payment request. No action is needed from your side, however, you could try to look at the user’s behavior to find the right trigger to encourage the user to complete the payment in the future – such as an offer or triggered email that talks about the value of your app. The best reaction to this error would be to catch the event and send the user an automated notification with a discount offer or something else of value to try and encourage them to continue using your app.

.SKErrorPaymentInvalid code 3

This error shows that the payment was not processed correctly due to an issue with the billing – Error code indicating that one of the payment parameters wasn’t recognized by the App Store, card expiration or not enough funds. Try to check whether the billing issue is related to card expiration and if so, the best idea is to catch this error, and send an automated notification or email with a reminder to your user.

.SKErrorPaymentNotAllowed code 4

An error code that indicates that the user is not allowed to authorize payments.

.SKErrorStoreProductNotAvailable code 5

This error might happen when your user tries to purchase a product that is unavailable in their region. Check SKStorefront.

.SKErrorCloudServicePermissionDenied code 6

Error code that indicates that the user has not allowed access to Cloud service information.

.SKErrorCloudServiceNetworkConnectionFailed code 7

This error occurs when the user tries to complete an action without a proper internet connection. Your best bet is to show them a notification highlighting that their connection is unstable, such as “please make sure that you have a proper internet connection, and try again later”.

.SKErrorCloudServiceRevoked code 8

Error code indicating that the user has revoked permission to use this cloud service.

.SKErrorPrivacyAcknowledgementRequired code 9

Error code indicating that the user has not yet accepted Apple’s privacy policy for Apple Music.

.SKErrorUnauthorizedRequestData code 10

Error code indicating that the app is attempting to access a property for which it does not have the required permissions.

.SKErrorInvalidOfferIdentifier code 11

This error indicates that the specified subscription offer identifier is not valid. For instance, you have not set up an offer with that identifier in the App Store, or you have revoked the offer. The best way to do this is to show the user a screen with your support team’s contact details.

.SKErrorInvalidSignature code 12

The cryptographic signature provided is not valid. This error indicates that the promo offer purchase has been created incorrectly. There is no reason to show this error to the user – it’s best to handle this error and fix this within your infrastructure.

.SKErrorMissingOfferParams code 13

One or more parameters from SKPaymentDiscount are missing. Same as above.

.SKErrorInvalidOfferPrice code 14

This error indicates that the price of the selected offer is not valid, for instance, the price with a discount applied is lower than the current base subscription price.

NSURLErrorNotConnectedToInternet

A network resource was requested, but an internet connection has not been established and can’t be established automatically.

How to handle StoreKit errors?

There are a lot of types of errors, so I‘d recommend dividing them into several groups:

external, which cannot be influenced in any way, for example, network problems
request errors such as incorrect product ID
user side errors such as canceling an operation or an unverified account

External errors

For such errors, an alert about the error itself is enough, as well as a repeat button for starting purchasing again. For example, if there is no Internet or an error occurs when connecting to the App Store.

Request errors

This is a group of errors that can cause the greatest damage to the product conversions, as they are system problems, for example, SKErrorStoreProductNotAvailable or SKErrorInvalidOfferPrice. Errors of this group must be covered with additional logging, with the ability to remotely catch them on the server and fix them.

User side errors
This group of errors is directly related to the user’s state, for example, SKErrorPrivacyAcknowledgmentRequired.

Correct error handling within the application is a very important part of the user experience. First of all, I would recommend implementing the error and (not too sure, would you say “implementing the error AT the loading state”, since both have to occur simultaneously) the loading state and then start implementing the main (content) state.

Setting Up Consumable and Non-consumable In-App Purchases

Yulia Kondrashova — Fri, 22 Apr 2022 08:18:32 +0000

When developing mobile applications, you may want to generate revenue with your app. According to the latest Sensor Tower report, consumable and non-consumable in-app purchases are some of the most commonly used monetization mechanics — especially in games with Ad Removal. Games with this monetization method account for 90% of all games. In this article, we’ll take a closer look at features of in-app purchases, what’s the difference between consumable and non-consumable IAPs, and how to set it up with Qonversion.

Types of In-app Purchases

IAPs can be used in a number of ways. For example, to add features, remove ads, or purchase in-game currency. But which type of purchase should you use for each purpose?

There are two types of in-app purchases that can be used for iOS and Android mobile apps:

Non-consumable items. The idea is that they could be purchased only once. It is permanently associated with the user’s store account. Examples are purchasing game levels, race tracks, and extra app features, and yes – ad removal.
Consumable items can be purchased multiple times. It could be used up during the life of the application. Examples are in-game currency and extras.

Differences Between Google and Apple In-app Purchases

Google makes no difference between non-consumable and consumable in-app purchases when creating a product. However, Apple requires developers to specify the type of in-app purchase in App Store Connect:

How to Setup Consumable and Non-consumable In-app Purchases

Let’s assume we develop a racing game for iOS and Android. Our app allows users to unlock premium race tracks (non-consumable item, once a track is purchased, a user gets access to it forever) and purchase extra health for a car (consumable item, the user should be able to buy health every time he needs it). Qonversion allows handling all types of in-app purchases including non-subscription products.

The following example describes the process of integrating in-app purchases into mobile apps with Qonversion.

Before we get started with the creation of consumable and non-consumable purchases, make sure that you already have a Qonversion account and have created your project and register the app.

Preparation

Suppose we have already created in-app purchases in Google Play Console and App Store Connect with the following IDs: android_premium_track, android_extra_health and ios_premium_track, ios_extra_health accordingly. Let’s create Products in the Qonversion dashboard:
Then we should create a Permission and link it to the premium_track product. Premium permission will unlock access to the track after its purchase.
For the extra_health product, we don’t need to create a permission. Let’s also create an Offering to be able to change the products set remotely without releasing app updates. Attach created products to the offering:

How to Provide a Lifetime Access With Non-consumable In-App Purchases

Displaying products

Display products for sale to the user:

iOS:

Qonversion.offerings { (offerings, error) in
  if (error != nil) {
    // Handle the error here
  }
  let offering = offerings?.offering(forIdentifier: "standard_offering")
  if let product = offering?.product(forIdentifier: "premium_track") {
    // Display the product for sale
  }
}

Android:

Qonversion.offerings(object : QonversionOfferingsCallback {
    override fun onSuccess(offerings: QOfferings) {
        val offering = offerings.offeringForID("standard_offering")
        offering?.productForID("premium_track")?.let { product ->
            // Display the product for sale
        }

    }

    override fun onError(error: QonversionError) {
        // Handle the error here
    }
}

Making Purchases

When the user is ready to purchase the product, start a purchase flow with the following method:

iOS:

Qonversion.purchaseProduct(product) { (permissions, error, isCancelled) in
  if let premium: Qonversion.Permission = permissions["premium"], premium.isActive {
    // Successful purchase
    // Unlock premium content
  }
}

Android:

Qonversion.purchase(context, product, callback = object: QonversionPermissionsCallback {
    override fun onSuccess(permissions: Map<String, QPermission>) {
        val premiumPermission = permissions["premium"]
        if (premiumPermission != null && premiumPermission.isActive()) {
            // Successful purchase
            // Unlock premium content
        }
    }

    override fun onError(error: QonversionError) {
        // Handle the error here
    }
})

Every time you want to know whether the user has access to the premium content, you should call the checkPermissions() method. Once the product has been successfully purchased and the permission has become active, you should not allow the user to purchase the product again: The user has a lifetime access since now.

Provide an Access With Consumable In-app Purchases

Displaying products

Display products for sale to the user:

iOS:

Qonversion.offerings { (offerings, error) in
  if (error != nil) {
    // Handle the error here
  }
  let offering = offerings?.offering(forIdentifier: "standard_offering")
  if let product = offering?.product(forIdentifier: "extra_health") {
    // Display the product for sale
  }
}

Android:

Qonversion.offerings(object: QonversionOfferingsCallback {
   override fun onSuccess(offerings: QOfferings) {
       val offering = offerings.offeringForID("standard_offering")
       offering?.productForID("extra_health")?.let { product-&gt;
           // Display the product for sale
       }

   }
   override fun onError(error: QonversionError) {
       // Handle the error here
   }
})

Making purchases

When the user is ready to purchase the product, start a purchase flow with the following method:

iOS:

Qonversion.purchaseProduct(product) { (permissions, error, isCancelled) in
      if(!error){
         // Successful purchase
         // Unlock premium content
      }
}

Android:

Qonversion.purchase(context, product, callback = object : QonversionPermissionsCallback {
    override fun onSuccess(permissions: Map<String, QPermission>) {
        // Successful purchase
        // Unlock content
    }

    override fun onError(error: QonversionError) {
        // Handle the error here
    }
})

To unlock content, you don’t have to check permissions. Instead, you should rely on a successful result i.e., when there is no error. Note: The app has to remember the state of the purchased product: how many units were purchased and give access accordingly. For instance, if the user purchased 50 units of extra_health,and then used 20, you should consider it and demonstrate the actual balance of 30 pieces of health within your app. So, just 30 remaining pieces will be available for your user to purchase.

Conclusion

In this blogpost, we took a closer look on how to set up consumable and non-consumable purchases. As you can see, the process is pretty simple. Once you’ve implemented in-app purchases, don’t forget to use the analytics tools to measure how much revenue each of your products brings.

DEV Community: Yulia Kondrashova

Apple Fiscal Calendar 2023

5 ways to increase app valuation and score a beautiful EXIT webinar

The new App Transaction API, Enhancements to StoreKit 2 and other WWDC22 updates for in-app purchases

1. App transaction API is the new API to verify app purchases

2. New properties in the StoreKit models

3. SwiftUI API for redeeming subscription offer codes and asking your customers to review your app

4. StoreKit Messages API used to display App Store messages to your customer

Qonversion page is here!

The Ultimate Guide to Subscription Testing on Android

Prerequisites

Sandbox environment setup

License testing

Test devices

Test Subscription Periods

Test subscription-specific features

Purchase a subscription with successful payment

Cancel an active subscription

Try to purchase a subscription with the fail method

Access recovery

Reinstall the app

Multiple devices

Free trials

Purchase a subscription with a trial

Cancel an active trial

Introductory price

Single payment

Recurring payment

Grace period

Grace period with payment resolution

Grace period without payment resolution

With payment resolution

Without payment resolution

Account hold and no grace period

Account hold with payment resolution

Account hold without payment resolution

Downgrade/Upgrade

Immediate upgrade

Upgrade after renew

Refunds

In Conclusion

Handling StoreKit Errors

NSError Overview

Variety of errors

Handling StoreKit errors

Types of errors

.unknownSKErrorUnknown code 0

.SKErrorClientInvalid code 1

.SKErrorPaymentCancelled code 2

.SKErrorPaymentInvalid code 3

.SKErrorPaymentNotAllowed code 4

.SKErrorStoreProductNotAvailable code 5

.SKErrorCloudServicePermissionDenied code 6

.SKErrorCloudServiceNetworkConnectionFailed code 7

.SKErrorCloudServiceRevoked code 8

.SKErrorPrivacyAcknowledgementRequired code 9

.SKErrorUnauthorizedRequestData code 10

.SKErrorInvalidOfferIdentifier code 11

.SKErrorInvalidSignature code 12

.SKErrorMissingOfferParams code 13

.SKErrorInvalidOfferPrice code 14

NSURLErrorNotConnectedToInternet

How to handle StoreKit errors?

External errors

Request errors

Setting Up Consumable and Non-consumable In-App Purchases

Types of In-app Purchases

Differences Between Google and Apple In-app Purchases

How to Setup Consumable and Non-consumable In-app Purchases

Preparation

How to Provide a Lifetime Access With Non-consumable In-App Purchases

Displaying products

Making Purchases

Provide an Access With Consumable In-app Purchases

Displaying products

Making purchases

Conclusion