Home
Blog
Authors
Dan Burcaw

Dan Burcaw is Co-Founder & CEO of Nami ML. He built a top mobile app development agency responsible for some of the most elite apps on the App Store and then found himself inside the mobile marketing industry after selling his last company to Oracle.

Latest articles by
Dan Burcaw
Written by
Dan Burcaw
15 Jun

iOS App Shared Secret: What is it, Types & How to Generate One

The iOS App Shared Secret is a crucial component in the development and management of applications within Apple's ecosystem. This secret key is used primarily to enhance security and streamline the validation of in-app purchases, ensuring that only authorized transactions are processed. In this article, we will delve into the concept of the iOS App Shared Secret, explore the different types available, and provide a comprehensive guide on how to generate one.

What is an iOS App Shared Secret?

The iOS App Shared Secret is a unique, 32-character hexadecimal string private key that developers use to secure in-app purchase transactions. This key ensures that communications between your app and Apple's servers are authenticated, preventing unauthorized access and fraudulent transactions.

It is especially vital for apps with subscription-based models, where the key is used to validate and renew subscriptions securely.  It works fantastic for server-side receipt validation and provides added security for receipts with auto-renewable subscriptions.

Receipt Verification and the Role of Shared Secret

Receipt verification is a process app developers use to verify purchases. Specifically, this process if for purchases made using Apple’s App Store payments mechanism (aka StoreKit). The receipt provides a complete list of all the purchases made by an app’s user. The receipt includes both in-app purchases and subscriptions.

Apple recommends that app developers validate a receipt for security and piracy reasons.  In fact, property security requires a secure backend.

The Shared Secret  allows you to receive the decoded form of a receipt.  In addition, its included in the payload of App Store Server Notifications. You can check that the password key’s value matches the known Shared Secret verify the authenticity of the notification.

Types of iOS App Shared Secrets

There are primarily two types of shared secrets you might encounter in the iOS development environment:

  1. App-Specific Shared Secret: This is used for a single app to manage its in-app purchases. It is particularly useful for apps with subscription services, as it allows the app to verify receipts and manage subscriptions effectively.
  2. Primary Shared Secret: This is used for multiple apps within a single developer account. It offers the convenience of managing subscriptions across several apps, streamlining the process for developers with a portfolio of applications.

How to Generate an iOS App Shared Secret

Generating an iOS App Shared Secret is a straightforward process. Here’s a step-by-step guide:

1. Log in to App Store Connect:

Visit App Store Connect and log in with your Apple Developer account credentials. To generate either type of Shared Secret requires an App Store Connect account with either Account Holder or Admin role.

2. Access My Apps:

Navigate to the "My Apps" section and select the app for which you need to create a shared secret.

4. In-App Purchases:

In the app's dashboard, go to the "Features" tab and select "In-App Purchases".

5. Generating App-Specific Shared Secret:

If you are generating an app-specific shared secret, find the section labeled "App-Specific Shared Secret" and click on "Generate" or "Reset" if a key already exists.

Generating an App-Specific Shared Secret in App Store Connect

6. Generating Primary Shared Secret:

For a primary shared secret, go to "Users and Access" and select "Shared Secret" from the sidebar. Click on "Generate" to create a new key.

Generating a Primary Shared Secret in App Store Connect

The App-Specific Shared Secret is a good idea if you want app-level security. Perhaps plan to transfer an app to another Apple Developer. For instance, if you sell an app to another party on a marketplace like Flippa.

7. Save Your Shared Secret:

Once generated, copy the shared secret and store it securely. It will be needed for integrating your app's in-app purchase functionality with your backend server.

Managing Your iOS App Shared Secret

Proper management of your shared secret is crucial for maintaining app security. Here are some best practices:

  • Regularly Rotate Keys: To enhance security, regularly regenerate your shared secret.
  • Secure Storage: Store the shared secret in a secure environment, such as a vault or secure server.
  • Access Control: Limit access to the shared secret to only those who absolutely need it.
  • Monitor Usage: Keep an eye on the usage of your shared secret to detect any unauthorized access or anomalies.

Conclusion

Understanding and effectively managing your iOS App Shared Secret is essential for maintaining the security and integrity of your app's in-app purchases. By following the steps outlined in this article, you can ensure that your app's transactions are secure, providing a better experience for your users and peace of mind for yourself.

For more detailed guidance on app development and in-app purchase security, visit our website at NamiML to explore our low-code solutions designed to simplify and enhance your app's functionality.


     
   
   

Written by
Dan Burcaw
13 Jun

Fitting Paywalls to User Context – A Guide to Driving Conversions

Discover how to personalize your app paywalls to user context, device, and journey stage. Unlock tactics of paywall A/B testing to craft frictionless experiences that drive conversions.

Paywalls offer a clear path to monetization for subscription businesses. However, neglecting user experience in the pursuit of conversions is short-sighted. Frustrated users won't convert, and worse, won't return. A well-designed paywall that showcases value and prioritizes user experience can drive sustainable growth.

Great design is a cornerstone of user experience, but it's only part of the picture. Effective UX is all about understanding how users' needs and expectations shift depending on the context.

Imagine a football fan on their morning commute – they're quickly checking scores on their phone. But later, relaxing at home, they're engrossed in the game on their smart TV. A one-size-fits-all paywall won't resonate with these different user journeys.

Similarly, a user’s journey within the app also influences their receptiveness to a paywall. A new user might be curious about the app's core features, while a returning user might be more interested in premium functionalities that fit into the workflow they have already established for themselves within the app.

This is where context-aware paywall optimization comes in. By understanding user intent, device usage, and the stage of their journey within the app, you can tailor paywall messaging and design to resonate with individual users.

How do you stand to gain from this?

Not only does a user-centric paywall lead to higher conversion rates but also makes a positive user experience possible. It keeps users engaged in the long run, so you can hope for them to bring in recurring business over an extended period.

In this article, we delve into the power of context-aware paywall optimization. We'll explore the limitations of generic paywalls, discuss the importance of understanding user context and journey, and dive into strategies for creating personalized experiences that drive conversions – all with the intention of serving users the right kind of paywall that doesn't block access, but rather takes them to the other side where the grass is greener, so to speak.

What does it take to create personalized, optimized paywalls?

Think of a supermarket where every product has a generic sign that screams "Buy this now!". That wouldn’t be very interesting or effective, would it?

Wouldn’t it make more sense to see targeted messages like "healthy yogurt for your morning routine" or "fresh vegetables for your family dinner"? Paywalls that cater to user context are like those targeted signs – more relevant and likely to resonate.

People have different needs and expectations. A busy professional on their mobile phone while traveling to their office seeks a quick and informative experience, while someone relaxing on the couch with a smart TV? Well, they don’t mind browsing a wider range of content with previews or trailers on offer. A one-size-fits-all paywall ignores these crucial differences, leading to user frustration and lost opportunities for conversions.

Understanding user context

The key to unlocking effective paywalls lies in understanding the context in which users encounter the paywall. This is where user data, gathered with the user’s consent, of course, becomes your best friend.

Here are some key factors to consider –

  • Demographics: Age, location, and even income level can influence how users perceive a paywall. For example, a younger audience might be more receptive to freemium models with in-app purchases, while an older demographic might prefer a clear and concise value proposition before they decide to commit to a premium subscription. Knowing your target audience allows you to tailor the paywall's language, visuals, and offers to resonate with their preferences.
  • In-app behavior: This is a goldmine of information. How often do users engage with your app? What features do they use the most? Do they primarily access the app on their mobile phone or laptop? By analyzing this data, you can understand user needs and pain points. For instance, a user who frequently uses the social features of an investment app might be more receptive to a paywall highlighting exclusive subscriber-only discussion forums.

The user journey matters

A user's journey within the app is another critical piece of the puzzle. People don't just appear in your app fully ready to convert to paying subscribers. They go through distinct stages, each with unique needs and expectations.

Here's how you can tailor your paywall experience to each stage in the user journey –

  • New users: They're curious and want to understand the app's core value proposition. Focus the paywall on showcasing the app's essential features and benefits. Offer a free trial or freemium model to allow them to explore the app's functionalities before asking a user to commit to a paid subscription. Highlight user testimonials or positive reviews to build trust and establish the app's credibility.
Flo app paywall comes with a free trial plan toggle
  • Active users: They are already engaged and appreciate your app's functionality. Now is the time to showcase premium features that address their specific needs based on their in-app behavior. Let's consider a fitness app as an example. A paywall could highlight personalized training programs or exclusive workout challenges designed by certified professionals if a user consistently uses the free workout plans.
Fitbod’s paywall highlights personalized workouts

And let’s say you know from tracking analytics that the user prefers cardio-related workouts to strength-training ones, then, offering a paywall that highlights "cardio-related" activities can help seal the deal. Such an approach demonstrates a deep understanding of a user’s current usage patterns and offers a clear path to, not only monetization for your business but also for enhancing the user’s experience.

  • Lapsing users: These are users who have downloaded your app but haven’t been using it actively for a while. The goal here is to re-engage them and remind them of the value they experienced previously. Showcase new content, features, or exclusive benefits available with a subscription. You can even personalize the paywall to reflect their past usage. For instance, a user who last opened your meditation app a month ago could be shown a paywall highlighting new guided meditations or relaxation techniques focused on managing stress – a common reason users return to meditation apps.

Device usage and user mindset

In addition to the user journey stage, the kind of device the user is using also affects how they interact with paywalls.

Let’s take a look at the popular devices –

  • Mobile phone: Users on mobile phones are often on the go, seeking quick information or bursts of entertainment. Their attention spans are typically short, so paywalls should be concise and visually appealing. Focus on highlighting the app's core value proposition and immediate benefits. Consider offering free trials or tiered subscription options to cater to users who might be hesitant about making a full commitment.
  • Laptop and desktop: Laptops and desktops provide an environment that is conducive to deeper browsing and engagement. Users here are more receptive to detailed information. Paywalls, whether for the web or a desktop app can show the advantages of premium features in greater depth. Offering free content samples or in-depth comparison articles can entice users to explore the value proposition before committing to a subscription.
  • Smart TV: The primary focus for smart TV users is relaxation and entertainment. Paywalls should be visually captivating, leveraging high-quality images or videos to grab attention. Highlight exclusive content unavailable on the free plan, such as newly released movies or curated playlists. Bundling subscriptions with other streaming services can also increase perceived value for smart TV users.

A/B testing for personalized paywalls

Just like with any marketing strategy, the key to successful paywalls lies in continuous testing and refinement.  A/B testing allows you to tailor your paywall experience to different user segments, devices, and journey stages.

Here's how it works –

Imagine you have two different paywall versions - one focusing on exclusive video content and another highlighting in-depth articles. You can use A/B testing to present these variations to users on different devices.

By analyzing conversion rates, you can see which version resonates better on each of your devices. Chances are, the video paywall does best on smart TV while the one with in-depth articles is better suited for a desktop app. For a deeper dive into A/B testing paywalls on mobile apps, check out our article on A/B testing mobile app paywalls for maximizing revenue and user engagement.

A/B testing can also be used to personalize the paywall experience based on a user's journey stage. A new user who just downloaded the app might see a paywall with a free trial offer, while a user who has been actively engaged for a month might encounter a paywall highlighting premium features. This targeted approach feels less intrusive and increases the chance of a conversion.

Here are some A/B testing best practices to keep in mind –

  • Focus on a single variable at a time. Isolate the impact of a specific change, like pricing tier or messaging approach.
  • Run tests for a statistically significant timeframe. Don't jump to conclusions based on small data sets.
  • Continuously iterate and improve. A/B testing is an ongoing process, not a one-time event.

Fitting paywalls to the user’s context

Monetization is crucial for subscription businesses, and paywalls are a key tool to achieve that goal. However, a paywall that disrupts the user experience is more likely to drive users away than towards subscriptions. The key lies in a user-centric approach – i.e. delivering personalized paywalls that resonate with individual needs and context.

Unlocking this strategy starts with understanding your users. Analyze user data to see where they come from, what devices they use, and how they engage with your app. Knowing their journey stage – whether they are new users or long-time engaged users – is also essential. This data empowers you to craft the right message, design, and timing for your paywalls.

A/B testing is your next step. Test different paywall variations to see which ones convert best on specific devices and in different user contexts. By iteratively refining your approach, you can create frictionless paywalls that seamlessly guide users toward subscriptions.


Ready to build and iterate on your paywalls? Nami ML can help! Schedule a free consultation with our experts or sign up for a free trial of our paywall builder. Start creating and testing personalized paywalls in minutes.

Written by
Dan Burcaw
5 Jun

Nami ML’s Next-Gen Creator Dares Subscription Businesses to Deploy a Thousand Paywalls Without Code

With the power of a thousand paywalls, a company can now run countless A/B tests and granularly target users to give every customer a personalized purchasing experience. The result is accelerating revenue from a wave of loyal customers.

Subscription and Paywall Engagement Gets Personal with Hyper-Personalized Purchasing Experiences

DENVER, 5 June 2024 –Nami® ML today launched a groundbreaking new version of their Subscription Studio platform, empowering businesses to take their revenue from a trickle to a tidal wave.

While subscription services swelled over the past decade, the individualized experience that today’s consumers demand has been arduous to come by, primarily because producing any purchasing experience takes a lot of time and resources - it can take hundreds of hours to design, develop, deploy, test, and refine a single paywall, and those hours skyrocket when a subscription is offered at-scale across a variety of platforms and ecosystems.

A Thousand Paywalls

With Nami’s updated Paywall Creator, companies can adjust pricing, alter positioning or launch a new design in minutes– everywhere they sell. If a company can create one paywall in ten minutes, then they can create a thousand paywalls in about the amount of time it previously took to create a single paywall.

With the power of a thousand paywalls, a company can run countless A/B tests and granularly target users to give every customer a personalized purchasing experience.

“The best way to grow subscription revenue is to get personal. Nami customers rapidly discover what resonates, which translates to more revenue. Nami pays for itself after a few tests, ” explains Dan Burcaw, Co-Founder, CEO of Nami ML.

Take revenue from a trickle to a tidal wave

Harmonizing the Subscriber Journey

Nami’s updated platform makes it easy to discover what each customer wants, then deliver a level of personalization never before achieved at scale. Paywalls can be contextualized at different moments - as your trial expires or when trying to access premium content, for example - or target CRM audience segments or even individual users.

Today’s release transforms how companies approach subscriptions. No longer is a paywall a mere product selection point - it is a marketing asset.

Burcaw continues, “The purchase experience is now in harmony with other marketing channels for a truly orchestrated subscriber journey. The result is accelerating revenue from a wave of loyal customers.”

About Nami ML

Nami ML helps brands deploy personalized purchasing experiences that foster long-lasting loyalty and drive revenue. Visit https://namiml.com and request a demo from a product expert today.

Nami is a registered trademark of Nami ML Inc.

Written by
Dan Burcaw
2 Jun

How to Verify Receipts for In-App Purchases on the App Store: A Definitive Guide

Verifying receipts for in-app purchases is crucial for maintaining the integrity of transactions within your iOS app. This process ensures that the purchases made by users are legitimate, protecting your app from potential fraud. In this article, we'll cover the essential steps for verifying App Store receipts. We'll explore the process of receipt validation, best practices for secure implementation, and troubleshooting common issues.

Update: Since this guide was published, Apple announced StoreKit 2 which adds new capabilities and APIs such as Signed Transactions. StoreKit 1-style receipts and APIs will continue to be available, so we hope this article will continue to be a useful reference. If you're interested in learning more about StoreKit 2, head over here. Also, the new APIs are a major change and another and a great time to build atop Nami which abstracts away these underlying implementation details.

What's an App Store Receipt?

An App Store receipt is a digital proof of purchase generated by Apple for any transaction made within the App Store, including app purchases, in-app purchases, and subscriptions. This receipt is a critical component in ensuring the integrity and authenticity of transactions, as it contains detailed information about the purchase, such as the product ID, transaction ID, purchase date, and subscription details if applicable.

The receipt is stored on the user's device and can be retrieved and verified to confirm that the user has made a legitimate purchase. This verification process typically involves sending the receipt data to Apple's servers, where it is checked for validity and authenticity. By verifying receipts, app developers can protect their apps from fraudulent transactions and unauthorized access to premium content or features.

The receipt data provided by StoreKit is a Base64-encoded. To receive a decoded version, described in detail in this article, you need to transmit the encoded receipt to Apple’s verifyReceipt endpoint. To fully understand verifyReceipt, see this article where we code a simple Python script step-by-step that demonstrates how to send an encoded receipt and receive the decoded receipt.

Why Does it Need to be Verified?

Why is all of this necessary? The two most important reasons:

  1. Receipt validation helps you ensure a user is getting access to what they purchased — which is especially important with subscriptions
  2. Validating receipts from a server-side provides an important safeguard against piracy

The mechanics of receipt validation are relatively straightforward as demonstrated in the Python script referenced early.

However, grokking the decoded receipt itself is painful. It’s not the most elegant data structure in the world, and there are all sorts of esoteric details and nuances. Our goal with this article is build upon and go beyond Apple’s documentation to help you better understand the decoded receipt and avoid common (and more exotic) pitfalls.

How To Validate Receipts in App Store

1. Obtain the Receipt Data

The first step is to obtain the receipt data from the app. This data can be retrieved using the SKReceiptRefreshRequest class or from the receipt URL located in the app’s bundle.

if let appStoreReceiptURL = Bundle.main.appStoreReceiptURL,
  FileManager.default.fileExists(atPath: appStoreReceiptURL.path) {
   do {
       let receiptData = try Data(contentsOf: appStoreReceiptURL, options: .alwaysMapped)
       let receiptString = receiptData.base64EncodedString(options: [])
       // Send receiptString to your server for verification
   } catch {
       print("Couldn't read receipt data with error: " + error.localizedDescription)
   }
}


2. Send Receipt Data to Your Server

Once you have the receipt data, you need to send it to your server. This step is crucial because the verification process should be performed on a secure server to prevent tampering. Your server will then forward the receipt data to Apple's verification server.

3. Verify Receipt with Apple

Your server should send a request to Apple’s verification server at the following URL:

  • For production: https://buy.itunes.apple.com/verifyReceipt
  • For sandbox: https://sandbox.itunes.apple.com/verifyReceipt

The request should include the receipt data and your app’s shared secret for subscriptions. Here's an example using Swift's URLSession to send the receipt data:

let requestDictionary: [String: Any] = ["receipt-data": receiptString, "password": "your_shared_secret"] guard JSONSerialization.isValidJSONObject(requestDictionary) else { return } do { let requestData = try JSONSerialization.data(withJSONObject: requestDictionary, options: []) let storeURL = URL(string: "https://buy.itunes.apple.com/verifyReceipt")! var request = URLRequest(url: storeURL) request.httpMethod = "POST" request.httpBody = requestData request.setValue("application/json", forHTTPHeaderField: "Content-Type") let task = URLSession.shared.dataTask(with: request) { data, response, error in guard error == nil, let data = data else { print("Error verifying receipt: \(error?.localizedDescription ?? "No data")") return } // Process the verification response } task.resume() } catch { print("JSON serialization failed: \(error.localizedDescription)") }

4. Handle the Response

Apple’s response will include the status of the receipt and, if valid, the receipt’s details. Your server should parse this response and take appropriate action, such as granting the purchased content or renewing a subscription.

let requestDictionary: [String: Any] = ["receipt-data": receiptString, "password": "your_shared_secret"]
guard JSONSerialization.isValidJSONObject(requestDictionary) else { return }
do {
   let requestData = try JSONSerialization.data(withJSONObject: requestDictionary, options: [])
   let storeURL = URL(string: "https://buy.itunes.apple.com/verifyReceipt")!
   var request = URLRequest(url: storeURL)
   request.httpMethod = "POST"
   request.httpBody = requestData
   request.setValue("application/json", forHTTPHeaderField: "Content-Type")
   let task = URLSession.shared.dataTask(with: request) { data, response, error in
       guard error == nil, let data = data else {
           print("Error verifying receipt: \(error?.localizedDescription ?? "No data")")
           return
       }
       // Process the verification response
   }
   task.resume()
} catch {
   print("JSON serialization failed: \(error.localizedDescription)")
}

The Receipt Decoded: Element-by Element

The responseBody JSON payload can be daunting (example), especially if the receipt belongs to an end-user with a lengthy past purchase history.

It turns out, that there are somewhere between 3 and 7 top-level keys in the verifyReceipt responseBody JSON data structure. Here are the keys:

responseBody

Some of the top-level keys are present only in certain circumstances. Here’s a summary of each top-level key, what it is, and when you should expect to see it in the responseBody:

Key
Type
Is Returned?
Integer
Integer
Receipts with status code from 21100-21199
String
JSON Object
Byte
Receipts with auto-renewable subscriptions
Array of JSON objects
Receipts with auto-renewable subscriptions
Array of JSON objects
Receipts with auto-renewable subscriptions

Let’s dig into each of these top-level elements in detail, starting with response metadata keys: status, is-retryable, environment.

status

Upon received a response from verifyReceipt, the first thing you should do is check that status key. If the value is 0, the receipt is valid. Otherwise, an error occurred and you will need to interpret the status code to know what to do next.

HTTP Status Code
Apple Response Status Code
Description
Resolution
200
0
The receipt is valid
-
200
21000
The request was not made using HTTP Post
Change HTTP request method to POST
200
21001
Deprecated status code no longer sent
-
200
21002
Malformed receipt-data property sent in the request
Check that the receipt-data property of the request (sample code)
200
21002
The receipt server experienced a temporary issue
Try to validate this receipt again later
200
21003
The receipt could not be authenticated
Do not grant the user access to the purchased content
200
21004
The shared secret sent in the request is incorrect
Send the correct app-specific shared secret per App Store Connect
200
21005
The receipt server was temporarily unable to provide the receipt
Try to validate this receipt again later
200
21006
This receipt is valid but the subscription has expired. (Only returned for iOS 6-style receipts for auto-renewable subscriptions)
Upgrade to iOS 7+ style receipts in your app code from Bundle.main.appStoreReceiptURL
200
21007
This is a sandbox receipt sent to the production environment
Send this receipt to the sandbox endpoint: https://sandbox.itunes.apple.com/verifyReceipt
200
21008
This is a production receipt sent to the sandbox environment
Send this receipt to the production endpoint: https://buy.itunes.apple.com/verifyReceipt
200
21009
Internal data access error
Try to validate this receipt again later
200
21010
The Apple ID cannot be found or has been deleted
-
200
21100-21199
Various Apple internal data access errors
Check is-retryable to determine if you should try again
500
-
Internal Service Error
Implement retry logic or add request to a job queue for future processing
502
-
Bad Gateway
Implement retry logic or add request to a job queue for future processing
503
-
Service Unavailable
Implement retry logic or add request to a job queue for future processing

ProTip: Notice that the resolution to a number of the status codes is to retry later. It’s important that your receipt validation service is robust enough to handle a wide variety of scenarios including: network timeouts, HTTP status codes such as 503, and also status codes embedded in the return payload of a  HTTP 200 response. In some of these cases, you may want to to support retry logic to try again immediately. If you still failed to validate the receipt, you may want to add them to job queue for a future processing attempt.

is-retryable

If the Apple status value is within the range of 21100-21199, the is-retryable key should be present in the response payload. Apple’s documentation says the type is boolean, but the provided values are 0 and 1, not the proper JSON boolean values of true and false.

Value
Description
1
Temporary issue - try to validate this receipt again later
0
Unresolvable issue - do not retry validating this receipt

environment

The environment value tells you which Apple environment the receipt was generated from.

Value
Description
Sandbox
This receipt was generated from the sandbox environment (Development builds)
Production
This receipt was generated from the production environment (Ad-Hoc, TestFlight, App Store builds)

Now let’s look beyond the metadata into the primary keys containing the responseBody’s substance: receipt, latest_receipt_info, pending_renewal_info.

receipt

The value of receipt, a key within the decoded receipt response, is a JSON object containing the decoded receipt data.

This key always exists, whether a user has made an in-app purchase or not.

In fact, if you follow the best practice and send receipt data from your app to a server you will end up storing and decoding (via receipt validation) many receipts, containing this receipt key with certain metadata even if there have be no in-app purchases.

Consider the history of the App Store. It was built atop the foundations of the iTunes Music Store. On iTunes, an email receipt was sent to the user whether the song or album cost money or was free. This lineage carried on to the App Store, where in the early days there were just two types of apps: paid and free.  

Once in-app purchases were added, additional context was introduced to this data structure. In fact, it contains the full context you need to understand the purchase.

Now, with the advent of subscriptions things have gotten a bit more complicated. Some context about the subscription in-app purchase exists in this data structure, but some does not. For auto-renewable subscriptions, you will find additional context inside the latest_receipt_info and pending_renewal_info top level keys which we go into more detail later in this article.

Jump to an element-by-element breakdown of the receipt data structure.

latest_receipt

The latest Base64 encoded app receipt. This field is only returned if the app receipts contains an auto-renewable subscriptions.

latest_receipt_info

An array of JSON objects representing in-app purchase transactions for auto-renewable subscriptions. This field is only returned if the app receipts contains an auto-renewable subscriptions.

ProTip: If your verifyReceipt request includes the field exclude-old-transactions set to true, only the latest auto-renewable subscription transaction will be included in this field in the response.

Jump to an element-by-element breakdown of the latest_receipt_info data structure.

pending_renewal_info

An array of JSON objects representing open (pending) or failed auto-renewable subscription renewals as identified by the product_id. This field is only returned for app receipts that contain auto-renewable subscriptions.

Jump to an element-by-element breakdown of the pending_renewal_info data structure.

responseBody.receipt

Let’s take a look at all of the possible elements you may encounter in the receipt JSON object.

Key
Type
Is Returned?
Integer
Integer
String
String
Integer
String
Returned for apps purchased via VPP
String
Returned for apps purchased via VPP
String
Returned for apps purchased via VPP
Array
String
Returned if user pre-ordered app
String
Returned if user pre-ordered app
String
Returned if user pre-ordered app
String
String
String
String

adam_id / app_item_id

A unique 64-bit long integer generated by App Store Connect. This is used by the App Store to unique identify the app associated with the receipt.

In production, expect a unique identifier. In sandbox, this field will be populated with a 0.

application_version

The current version of the app installed on the user’s device at the time of the receipt’s receipt_creation_date_ms. The version number is based upon the CFBundleVersion (iOS) or CFBundleShortVersionString (macOS) from the Info.plist.

In the sandbox, the value is always “1.0”.

bundle_id

The bundle identifier for the app to which the receipt belongs. You provide this string on App Store Connect and it corresponds to the value of CFBundleIdentifier in the Info.plist file of the app.

download_id

A unique identifier for the app download transaction.

While not well documented by Apple, this unique value appears to be tied to the download transaction represented by original_application_version and original_purchase_date.

In production, expect a unique identifier. In sandbox, this field has been observed to be populated with a 0.

expiration_date

The time the receipt expires for apps purchased through the Volume Purchase Program (VPP).

Key
Format
expiration_date
expiration_date_pst

expiration_date_pst

See expiration_date

expiration_date_ms

See expiration_date

in_app

An array containing in-app purchase receipt fields for all in-app purchase transactions.

original_application_version

The original version of the app installed on the user’s device. For example, if the current app version is 2.0 but the user originally had version 1.8 installed, this value would be “1.8”. For the current version installed, see application_version.

The version number is based upon the CFBundleVersion (iOS) or CFBundleShortVersionString (macOS) from the Info.plist.

In the sandbox, the value is always “1.0”.

original_purchase_date

The time of the original app purchase.

Key
Format
original_purchase_date
original_purchase_date_pst
original_purchase_date_ms

original_purchase_date_pst

See original_purchase_date

original_purchase_date_ms

See original_purchase_date

preorder_date

The time the user ordered the app available for pre-order. This field is only present if the user pre-orders the app.

Key
Format
preorder_date
preorder_date_pst

preorder_date_pst

See preorder_date

preorder_date_ms

See preorder_date

receipt_creation_date

The time the App Store generated the receipt.

Key
Format
receipt_creation_date
receipt_creation_date_pst
receipt_creation_date_ms

receipt_creation_date_pst

See receipt_creation_date

receipt_creation_date_ms

See receipt_creation_date

receipt_type

The type of receipt generated. The value corresponds to the environment in which the App Store or VPP purchase was made.

Value
Description
Production
This receipt was generated in App Store production environment.
ProductionVPP
This receipt was generated in VPP production environment.
Sandbox
This receipt was generated in App Store sandbox environment.
ProductionVPPSandbox
This receipt was generated in VPP sandbox environment.

request_date

The time the request to the verifyReceipt endpoint was processed and the response was generated.

Key
Format
request_date
request_date_pst

request_date_pst

See request_date

request_date_ms

See request_date

version_external_identifier

An arbitrary number that identifies a revision of your app. In the sandbox, this key's value is “0”.

responseBody.latest_receipt_info

An array of JSON object(s) found at latest_receipt_info contains in-app purchase transactions for auto-renewable subscriptions. This field is only returned if the app receipts contains an auto-renewable subscriptions.

ProTip: If your verifyReceipt request includes the field exclude-old-transactions set to true, only the latest auto-renewable subscription transaction will be included in this field in the response.

Key
Type
Is Returned?
String
Only present for transactions refunded by the App Store, for Family Sharing access revocations, or upgrades to a different product.
String
Only present for transactions refunded by the App Store, for Family Sharing access revocations, or upgrades to a different product.
String
Only present for transactions refunded by the App Store, for Family Sharing access revocations, or upgrades to a different product.
String
Only present for transactions refunded by the App Store, for Family Sharing access revocations, or upgrades to a different product.
String
String
String
String
Only present if Family Sharing is enabled.
String
String
Only present for upgrade transactions.
String
Only present when a customer redeemed a subscription offer code.
String
String
Only present when a customer redeemed a promotional offer.
String
String
String
String
String

cancellation_date

The time of the subscription was canceled. This can happen for one of the following reasons:

  1. The App Store or Apple customer support refunds the subscription transaction
  2. A Family Sharing change causes the user to lose access to the subscription
  3. The user upgrades to different product.
Key
Format
cancellation_date
cancellation_date_pst
cancellation_date_ms

cancellation_date_pst

See cancellation_date

cancellation_date_ms

See cancellation_date

cancellation_reason

The reason for a refunded transaction. When a customer cancels a transaction, the App Store gives them a refund and provides a value for this key.

Value
Description
"1"
The customer canceled due to an actual or perceived issue within your app.
"0"
The transaction was canceled for another reason; for example, if the customer made the purchase accidentally.

expires_date

The time a subscription expires or when it will renew.

Key
Format
expires_date
expires_date_pst

expires_date_pst

See expires_date

expires_date_ms

See expires_date

in_app_ownership_type

Indicates whether the user is the purchaser of the product, or is a family member with access to the product through Family Sharing.

Value
Description
FAMILY_SHARED
The transaction belongs to a family member who benefits from service.
PURCHASED
The transaction belongs to the purchaser.

is_in_intro_offer_period

Indicates whether or not an auto-renewable subscription is in the introductory price period.

Value
Description
"true"
The customer’s subscription is in an introductory price period.
"false"
The subscription is not in an introductory price period.

is_trial_period

An indicator of whether a subscription is in the free trial period.

Value
Description
"true"
The customer’s subscription is in a free trial period.
"false"
The customer’s subscription is not in a free trial period.

is_upgraded

Indicates a subscription has been canceled due to an upgrade. Only present for upgrade transactions.

Check cancellation_date to determine when the cancellation occurred.

Value
Description
"true"
The customer’s subscription has been canceled due to an upgrade

offer_code_ref_name

The reference name of a subscription offer that you configured in App Store Connect. Present when a customer redeemed a subscription offer code.

original_purchase_date

The time of the original auto-renewable subscription purchase.

Key
Format
original_purchase_date
original_purchase_date_pst
original_purchase_date_ms

original_purchase_date_pst

See original_purchase_date

original_purchase_date_ms

See original_purchase_date

original_transaction_id

The transaction identifier of the original purchase.

product_id

The unique identifier for the product purchased as configured for that product in App Store Connect.

promotional_offer_id

The identifier of the subscription offer redeemed by the user.

purchase_date

The time the App Store charged the user’s account for a subscription purchase or renewal.

Key
Format
purchase_date
purchase_date_pst

purchase_date_pst

See purchase_date

purchase_date_ms

See purchase_date

quantity

The number of consumable products purchased. Included but meaningless in the latest_receipt_info data structure, which is for auto-renewable subscriptions only. Likely an artifact from Apple internally sharing data structures between responseBody.receipt.in_app and responseBody.latest_receipt_info.

subscription_group_identifier

The identifier of the subscription group to which the subscription belongs.

web_order_line_item_id

A unique identifier for purchase events across devices, including subscription-renewal events. This value is the primary key for identifying subscription purchases.

transaction_id

A unique identifier for a transaction such as a purchase, restore, or renewal.

If transaction_id and original_transaction_id match, the transaction is a purchase. Otherwise, the transaction is a restore or renewal.

responseBody.pending_renewal_info

The array of JSON object(s) found at pending_renewal_info for open (pending) or failed auto-renewable subscription renewals includes a number of possible fields. Let’s take a look.

Key
Type
Is Returned?
String
Only present if the user downgrades or crossgrades to a subscription of a different duration for the subsequent subscription period.
String
String
Only present for a receipt containing an expired auto-renewable subscription.
String
Only present if user experiences a billing error at the time of renewal.
String
Only present if user experiences a billing error at the time of renewal.
String
Only present if user experiences a billing error at the time of renewal.
String
Only present if an auto-renewable subscription is in the billing retry state.
String
Only present when a customer redeemed a subscription offer code.
String
Only present if the customer was notified of the price increase.
String

auto_renew_product_id

The product identifier for the customer’s pending subscription renewal, if the user has downgraded or crossgraded to a subscription of a different duration for the subsequent subscription period.

auto_renew_status

The renewal status for the auto-renewable subscription.

If this value is “0”, the customer is showing a likelihood to churn out of the subscription at the end of the current renewal period. A best practice is to present the user with an attractive upgrade or downgrade offer in the same subscription group.

Value
Description
"1"
The subscription will renew at the end of the current subscription period.
"0"
The customer has turned off automatic renewal for the subscription.

expiration_intent

The reason a subscription expired.

Value
Description
"1"
The customer voluntarily canceled their subscription.
"2"
Billing error; for example, the customer's payment information was no longer valid.
"3"
The customer did not agree to a recent price increase.
"4"
The product was not available for purchase at the time of renewal.
"5"
Unknown error.

If this value is “1”, you may want to offer the user an alternative subscription or a “winback” offer.

If the value is “2”, you may want to prompt them to subscribe to the same product again since they churned involuntarily.

grace_period_expires_date

The time at which the grace period for subscription renewals expires.

Key
Format
grace_period_expires_date
grace_period_expires_date_pst
grace_period_expires_date_ms

grace_period_expires_date_pst

See grace_period_expires_date

grace_period_expires_date_ms

See grace_period_expires_date

is_in_billing_retry_period

Indicates whether the user’s auto-renewable subscription is in the billing retry period.

Value
Description
"1"
The App Store is attempting to renew the subscription.
"0"
The App Store has stopped attempting to renew the subscription.

If the value is “1”, consider prompting the user to update their billing information.

offer_code_ref_name

The reference name of a subscription offer that you configured in App Store Connect. Present when a customer redeemed a subscription offer code.

original_transaction_id

The transaction identifier of the original purchase.

price_consent_status

The price consent status for a subscription price increase.

Value
Description
"1"
The customer has consented to the price increase.
"0"
The customer has been notified of the pending price increase

product_id

The unique identifier for the product purchased as configured for that product in App Store Connect.

Receipt Date Formats

Throughout the Apple decoded receipt payload, you will find three different date formats expressed whenever a date is provided:

  • ISO 8601-like GMT
  • ISO 8601-like PST
  • UNIX Epoch Time in milliseconds.

What is a date-time format similar to the ISO 8601?

What is ISO 8601-like? Apple documentation refers to “a date-time format similar to the ISO 8601” and “an RFC 3339 date”. In reality it’s not strictly either. The timezone part of the string make it difficult to convert these string-based date formats into date time object using common libraries which except ISO 8601 or other common standards.

Why Apple uses this specific non-standard format is probably an esoteric story related to the origins of NeXT or WebObjects.

Key Example
Date Format
Date Example
receipt_creation_date
ISO 8601-like GMT
2021-01-14 17:11:10 Etc/GMT
receipt_creation_date_pst
ISO 8601-like PST
2021-01-14 17:11:10 America/Los_Angeles
receipt_creation_date_ms
Milliseconds since UNIX epoch time
16106442700000

To dive deeper into these three formats, let’s take a look at the date found at responseBody.receipt.receipt_creation_date. This is date the receipt was created expressed in the ISO 8601-like format relative to Greenwich Meantime (GMT).

Each base date key has two modifiers: _pst and _ms with the ISO 8601-like PST and Milliseconds since Unix epoch representations.

responseBody.receipt.receipt_creation_date_pst is an ISO 8601-like date relative to Pacific Standard Time (PST). Please note, even though the timezone modifier is provided in the format America/Los_Angeles instead of a UTC offset, the date provided is indeed Pacific Standard Time. Your code needs to be careful during Pacific Daylight Time (PDT), since this value will still be a Pacific Standard Time date.

responseBody.receipt.receipt_creation_date_ms is when the receipt was created in the number of milliseconds since the Unix epoch time.  The _ms modifier for all date fields in an Apple decoded receipt is the far easiest to work with. Most modern languages can convert this to a native date time object out of the box or with commonly used libraries.

What's VPP?

VPP stands for Volume Purchase Program. It's essentially how Apple provides an App Store-like experience for educational institutions or businesses to acquire and deploy apps at scale. As it relates to this article, some receipt fields only show up or contain values for transactions that occur on the VPP store.

There is a Better Way to Manage Receipts: Don't

As this guide illustrates, understanding the decoded receipt is complicated. So is the code necessary to store, validate, and make meaning out of the decoded receipt so you can properly manage your paid customer base.

The esoteric and sometimes arcane receipt response is the result of years of change and new features bolted on to the App Store year after year. It’s incredibly complex to write rock solid code to manage receipts and leverage all the App Store ecosystem has to offer related to in-app purchase and subscription monetization.

That’s where Nami can help. We’ve built a complete service to help you sell in-app purchases or subscriptions. In addition to a variety of features, we handle all client and server side details involving the receipt. In fact, you also don't have to write a single line of StoreKit 1 or StoreKit 2 code.

Our code has encountered many of the hard to test edge cases you’ll see encounter over time if you do-it-yourself. Our service has extensive test coverage and operates at scale.

This means you can stay focused on building your app experience. If you’re interested in learning more, we’d love to chat.

{ "@context": "https://schema.org", "@type": "HowTo", "name": "Verify App Store Receipt Data", "step": [ { "@type": "HowToStep", "name": "Obtain the Receipt Data", "text": "Obtain the receipt data from the app using SKReceiptRefreshRequest or from the receipt URL in the app’s bundle.", "itemListElement": { "@type": "HowToDirection", "text": "Fetch receipt data using Swift code snippet.", "url": "https://www.namiml.com/blog/app-store-verify-receipt-definitive-guide" } }, { "@type": "HowToStep", "name": "Send Receipt Data to Your Server", "text": "Send the obtained receipt data securely to your server.", "itemListElement": { "@type": "HowToDirection", "text": "Send receipt data using Swift code snippet.", "url": "https://www.namiml.com/blog/app-store-verify-receipt-definitive-guide" } }, { "@type": "HowToStep", "name": "Verify Receipt with Apple", "text": "Send a request to Apple’s verification server with the receipt data and your app’s shared secret.", "itemListElement": { "@type": "HowToDirection", "text": "Verify receipt using Swift code snippet.", "url": "https://www.namiml.com/blog/app-store-verify-receipt-definitive-guide" } }, { "@type": "HowToStep", "name": "Handle the Response", "text": "Process the verification response from Apple and take appropriate actions based on the receipt status and details.", "itemListElement": { "@type": "HowToDirection", "text": "Handle response using Swift code snippet.", "url": "https://www.namiml.com/blog/app-store-verify-receipt-definitive-guide" } } ] }
Written by
Dan Burcaw
23 Apr

50 Mobile App Growth Hacking Tactics You Can Try Today

Discover how you can increase mobile app subscriptions with 50 growth hacks – experiment across different stages of the user journey with paywall AB testing, best practices for user acquisition and using in-app features to drive subscription growth.

With great opportunity comes fierce competition. The world is increasingly being run on apps – which makes it both a boon and a bane for businesses hoping to attract customers. To establish a strong foothold, you need to cut through the noise.

Sure, strategic planning is crucial for long-term subscription growth. But sometimes, a quicker win can be achieved through rapid testing of various mobile app growth hacking tactics. This is how you can identify what resonates with your users, and then double down on those high-performing strategies.

We have compiled a list of 50 growth hacks (yes, we said 50!) that are used by some of the world’s most successful apps that you can experiment with to drive the growth of your app subscriptions.

We’ve broken down these hacks into five key areas, so you can unlock subscriber growth across every stage of the user journey.

  • Know your ideal subscriber so you can create relevant subscription offerings.
  • Conduct targeted acquisition to attract the right users with the right message at the right time.
  • Make the free-to-paid user journey frictionless so that upgrading becomes really easy.
  • Find ways to optimize your app using data and run A/B tests so you can refine it for continuous growth.
  • Engage with your users in-app to keep them hooked and nudge them towards a subscription.

Know your ideal subscriber – craft relevant subscription offerings

  • Craft user personas: Identify your ideal subscriber's demographics, desires, and frustrations. What keeps them up at night? How can your app solve their problems? When you understand this you can tailor the app experience, and subscription offerings, to the actual needs of your users.
  • Conduct user research: Surveys, polls, and interviews provide invaluable insights directly from your target audience. You won’t have to rely on guessing which features will attract a premium – you can use actual user feedback to define your subscription plans.
  • Analyze app usage data: Not everyone uses your app the same way. See how users interact with the features in your free tier. Analyze usage patterns to optimize your free tier, then segment users (potential, engaged, churned) and target them with tailored incentives throughout the subscription lifecycle to skyrocket conversions.
  • Leverage user reviews: App reviews are gold! Positive ones highlight winning features, while negative ones reveal pain points. Listen, learn, and adapt your subscription offering. Turn frustrated reviewers into loyal subscribers by addressing their concerns.
  • Social listening & competitor analysis: Monitor relevant app communities on social media and online forums. Identify user pain points and desired features. Analyze your competitors' subscription offerings and user reviews to understand what features resonate with your target audience who use apps similar or complementary to yours. Use all this data to tailor your subscription plans to address specific needs.
  • User onboarding quiz: Integrate a short quiz when onboarding new users to understand their goals and needs. Based on their responses, recommend the most suitable subscription plan, maximizing the chances of conversion.

Targeted acquisition – attract the right users with the right message at the right time

  • Highlight value proposition: Don't just tell users about the premium side of your app, tell them why they need it. Craft compelling copy that speaks directly to your target audience's needs and desires. Clearly communicate the exclusive features and enhanced functionalities offered by a subscription, showcasing the additional value they'll unlock.
  • Utilize appealing creatives: Use high-quality, eye-catching visuals in your app paywalls to grab attention and make a strong impression. This will pique the user’s interest and nudge them towards that "buy" button.
  • Frictionless onboarding: First impressions matter! Guide new users seamlessly through core functionalities during onboarding. Showcase the app's strengths like its user-friendly design to make them feel confident using the app – only then will they feel comfortable spending money on a subscription.
  • Focus on immediate value: Don't overwhelm users with complex features right away. Highlight the benefits they can unlock with the free tier, showcasing the app's core value proposition and encouraging them to explore further – it takes proof of value to be convinced of the utility of an app before someone decides to spend money
  • Strategically place CTAs: Calls to action (CTAs) are your conversion levers. Don't just place them anywhere. CTAs should appear strategically at opportune moments when users experience limitations of the free tier. This nudges them towards upgrading for a more complete and valuable experience.
  • App store screenshot carousel: Design screenshots for the app store showcasing the value proposition of your subscription plans. Highlight exclusive features and benefits to entice users to download your app and upgrade!
Image shows Headspace using the image carousel in the app store to share screenshots to showcase its value proposition
  • Content marketing magnet: Publish valuable content (blog posts, infographics, videos) that addresses your ideal subscriber's pain points. Subtly integrate your subscriptions as the ultimate solution.
  • Influencer sponsorship: Partner with relevant influencers like Instagrammers or podcasters to reach your target audience. Offer exclusive discounts on subscriptions during the collaboration content like reels or podcasts and leverage the host's credibility to promote your value proposition.
  • Themed subscription bundles: Partner with complementary subscription services to offer themed bundles.  For example, if you’re a streaming app a “movie night-in” bundle could be combined with a meal delivery app at a discounted rate. This incentivizes users to explore multiple subscriptions while offering a unique value proposition.
  • Subscription gifting: Introduce a feature that allows users to gift subscriptions to friends and family.  This fosters social sharing and encourages existing users to promote subscriptions – one of the best ways to drive adoption and engagement because the subscription comes from a trusted, loved source.
  • Leverage influencer reviews: Secure app reviews on popular blogs relevant to your niche. Positive reviews with mentions of premium features build trust, showcase app value, and drive new users to invest in upgrades.

Frictionless free-to-paid user journey – make upgrading really easy

  • Freemium with strategic limitations: Use this approach to hook users with a free app experience, but cleverly limit key features. It's a way to showcase the true value of your subscription and drive conversions by highlighting the full app potential.
Canva's paywall showing a 14-day free trial plan
  • Introduce a special price: Sometimes, users might be hesitant to commit to a premium subscription without fully understanding the app's value. An introductory price acts as a "test drive," allowing them to explore features and experience the benefits firsthand before committing to a long-term plan.
  • Strategic hints of premium: Don't force an upgrade, but subtly showcase its value. At key points in the free tier, introduce users to "premium-only" features with a gentle nudge towards subscribing to unlock the full experience.
  • Personalized recommendations: It's important to cater to individual needs. Leverage user data to suggest premium content or features that align with individual interests, making a premium subscription even more tempting for users.
  • Reward active users: Build loyalty and encourage upgrades. Implement a loyalty program where users earn points or badges for their activity, that can be redeemed for exclusive content or subscription discounts.
  • Freemium to premium flip: Intrigue users with a trial twist. Offer a limited "reverse trial" period where users automatically have access to premium features. After the trial, these features become locked, incentivizing users to subscribe to regain access.
Asana displaying a message at the end of the trial period
  • Friction point analysis: Analyze user behavior data to identify points in the free tier where users encounter friction. You can use such points to strategically introduce your premium plans – providing immediate context and value for the paid features, making upgrades more appealing.
  • Free tier expiry countdown: Implement a visible countdown timer within the free tier showcasing the remaining storage space or time left (or any other core feature that will run out) before limitations kick in. This creates a sense of urgency and subtly encourages users to upgrade before they lose a beloved feature.
  • Subscription waitlist with exclusive content & early access:  Implement a waitlist system for upcoming content releases or highly anticipated features.  Subscription users automatically gain priority access, while users on the free tier can join a waitlist. This incentivizes users to subscribe to avoid missing out on new releases and creates a sense of exclusivity for existing subscribers.
  • Subscription “buddy system” incentives: Introduce a "buddy system" where existing subscribers can invite friends to join the app and receive a discount on their subscription when their friend upgrades. This incentivizes existing users to promote the app.

Data-driven optimization – A/B test and refine for continuous growth

  • A/B test paywall placements: Don't settle for a single location to place your paywalls! Experiment with A/B testing paywalls by displaying them at strategic points in the user journey - onboarding, feature limitations within the free tier, or after completing tasks.
  • A/B test CTA placement: Experiment with different locations for your calls to action. Test CTAs after completion of key tasks, within limited freemium features, or even embedded in progress dashboards.
  • A/B test value propositions: Craft multiple compelling value propositions highlighting the different benefits of your subscriptions. Utilize A/B testing to compare these messages and see which ones resonate best with your target audience.
  • A/B test visual design: Utilize A/B testing to optimize your app’s paywall design. This goes beyond simply changing colors. Experiment with different visual hierarchies, color psychology, and overall design styles, like minimalist versus playful design approaches.
  • A/B test headlines & copywriting: Make use of different tones and styles like using strong verbs to encourage action (e.g., "Upgrade Now" vs. "Explore Premium”). You can also test the length of headlines and copy by comparing concise headlines that clearly communicate the value proposition versus longer, more descriptive headlines and copy.
  • A/B test social proof and trust signals: Utilize A/B testing to optimize the placement and format of social proof on your subscription paywall. This could be customer testimonials, logos of well-known companies using your app, or prominent security badges. For example, highlight industry-specific certifications for B2B users, or showcase testimonials from users with similar demographics for a more relatable approach with your B2C consumers. You can also test the format of social proof elements and trust signals like text-based testimonials, video testimonials, or showcasing user ratings and reviews.
Canva sharing logos of customers that use the business plan
  • A/B test different pricing layouts: Test different ways to present your pricing – it should be clear, concise, and easy for users to understand exactly what they're getting for their money. Avoid hidden fees or confusing terminology.
  • A/B test free trial durations: Test different trial lengths to discover the sweet spot for user habit formation within your app. A shorter trial might be enough to spark interest, while a slightly longer one could nudge users towards forming a regular habit and ultimately converting them into paying subscribers.
  • A/B test different pricing options by locations: Conduct price experiments in different countries. User behavior and price sensitivity vary greatly by location. By A/B testing different price points in different regions, you can reveal the unique price elasticity of each market, optimizing your pricing strategy so you can win over a global audience without sacrificing conversions.
  • User churn prediction & pre-emptive incentives: Implement churn prediction models based on user data and behavior patterns. For users identified at risk of canceling their subscription, launch targeted in-app campaigns with personalized offers or incentives to encourage them to stay with free or discounted upgrades.

In-app engagement strategies – keep users hooked and nudge them toward a subscription

  • Offer multiple paywall subscription models: Cater to different budgets and needs with various paywall subscription models offering different feature sets. Distribute features strategically across tiers. Higher tiers should offer significant value increases compared to lower tiers.
  • Offer annual subscription discounts: Implement a tiered pricing structure that incentivizes users to commit to a year-long subscription. Clearly showcase the cost savings associated with the annual plan compared to the monthly option. Annual subscriptions secure predictable recurring revenue for a year, boosting your overall customer lifetime value.
  • Subscription anniversary or birthday rewards: Celebrate user subscription anniversaries or their birthdays with exclusive rewards or bonus features in the form of higher-tier subscriptions or discounts. This fosters customer loyalty and appreciation, potentially encouraging users to maintain their subscriptions for the long term.
  • Run seasonal promotions: People are more receptive to special offers during holidays and seasonal events. Capitalize on this by running limited-time subscription deals that tap into the excitement of the season. The holiday season (Thanksgiving through New Year's) is a goldmine for subscription campaigns, but don't stop there! Think creatively and explore other holidays relevant to your target audience and the countries or cities they live in.
  • Utilize in-app promotion: Carefully integrate non-intrusive ads or banners within the free tier to promote in-app purchases and potentially convert users to paying subscribers.
Asana showing an in-app message on the user's account page at the end of the free trial
  • Offer early access to new features: Entice users to subscribe by providing them with exclusive access to upcoming app features or content. Early access to new features creates a sense of exclusivity and significantly increases the perceived value of your premium subscriptions.
  • Host webinars or online courses: Offer valuable educational content related to your app's functionality, with a premium tier providing in-depth access or exclusive resources. Such content could take the form of pre-recorded webinars, live online courses, or downloadable resources
  • Run contests and giveaways: Organize contests and giveaways with subscriptions as prizes to generate excitement and attract new users.
  • Push notifications: Utilize strategic push notifications to remind users about valuable subscription features or limited-time offers. However, avoid being spammy – tailor notifications to be relevant and add value.
  • Offer offline functionality or syncing features (if applicable): Provide the ability to use certain app features even without an internet connection or the ability to sync across multiple devices, increasing the value proposition of a subscription.
  • Use the FOMO effect: Create a sense of urgency with a limited-time deal. But be mindful and ethical about how you use this. The fear of missing out (FOMO) incentivizes users to act fast and subscribe before the deal expires but you need to make sure you don’t end up overwhelming users with constant promotions.
  • "Others are upgrading" notification: Display a notification (with privacy considerations) that a certain number of users within the app (or a specific region) have recently upgraded to the premium tier. This social proof, combined with a touch of FOMO, can nudge users towards subscribing as well.
  • Offer the benefits of a community: Nothing creates a sense of belonging like a strong community does. Include community elements like exclusive forums, expert interactions, or the ability to "connect" with other users as premium features – all of which create a rich social experience within the app.

Unlock mobile app subscription growth by testing multiple hacks

The mobile app landscape is teeming with subscription opportunities, but standing out requires a strategic approach. Before you decide to invest in specific tactics, try testing out different hacks that can help you make an immediate impact and score some quick wins in the form of new paying subscribers.

These hacks are your springboard for crafting comprehensive app growth strategies. Experiment, analyze, and refine your approach to build a thriving and loyal subscriber base.

Want to ace mobile app growth hacking? Build high-converting app paywalls and test these strategies in minutes! Sign up for a free trial of Nami's no-code paywall builder platform and unlock the full potential of your mobile app subscriptions.

Written by
Dan Burcaw
6 Apr

How to Change the App Name in App Store Connect: A Step-by-Step Guide

Changing the app name in App Store Connect is an essential task for developers and marketers aiming to keep their app’s branding consistent and up-to-date. Whether you're rebranding, making minor adjustments, or aligning with a marketing campaign, App Store Connect provides a straightforward process to update your app's name.

Step 1: Log into App Store Connect

First, visit the  App Store Connect  website and log in with your Apple ID and password. Ensure you have the necessary permissions to manage the app whose name you want to change.

App Store Connect name and subtitle locked

Step 2: Select Your App

Navigate to the "My Apps" section, where you will see all the apps associated with your account. Select the app for which you want to change the name.

Step 3: Create a New Version

Click on the "+" button or the "Create New Version" option to start a new version of your app.


App Store Connect new version

Step 4: Edit App Information

Go to the "App Information" section in the left-hand menu. This section contains all the details about your app, including its name and subtitle.

Step 5: Change the App Name

In the "App Information" section, click on the name field and enter the new app name. Ensure the new name adheres to Apple’s App Store Review Guidelines and fits your branding strategy.

Step 6: Save Your Changes

Scroll down and click the "Save" button to save the changes to your app’s metadata.

Step 7: Submit for Review

Navigate to the “App Store” tab and click “Submit for Review.” Apple will review the changes before they go live on the App Store.


If Your App is Not Yet Live

To change the name and subtitle of an app that is not yet live on the App Store, you need to open App Store Connect and navigate to your app's page. Once there, you can directly modify the app name and subtitle fields. After making the necessary changes, ensure that you save your updates.

App Store Connect change name and subtitle

Additional Considerations

  • App Store Optimization (ASO): When changing your app name, consider how it impacts your ASO. Use keywords that enhance discoverability and align with user search behavior. Tools like Sensor Tower or App Annie can provide insights into effective keyword strategies.
  • Brand Consistency: Ensure the new name aligns with your overall branding strategy. Consistency across all branding elements, including app icons, screenshots, and promotional materials, reinforces brand recognition.
  • User Communication: Inform your existing users about the name change to avoid confusion. Use push notifications, in-app messages, and email newsletters to communicate this change effectively.
  • Legal and Trademark Considerations: Verify that your new app name is not infringing on existing trademarks. Legal conflicts can lead to your app being removed from the store.

Summary

Updating your app name in App Store Connect is a crucial step in maintaining your app’s relevance and brand identity. By following the steps outlined above and considering additional factors like ASO, branding consistency, and user communication, you can easily change your app name, ensuring it reflects your latest updates and marketing efforts.

If you’re interested in learning more about how your App Store Optimization efforts relate to monetization, we’d be happy to help. In the meantime, happy app making and best of luck with App Store discovery.