When it comes to designing mobile apps, one of the most important decisions developers need to make is whether to use native user interface elements or web views. While web views can be more versatile, they often fall short in terms of user experience and functionality. In particular, paywall screens are an area where native UI elements shine.

Here are some of the benefits of using native UI elements for paywall screens in mobile apps:

Consistent Look and Feel

Native UI elements ensure that the app looks and feels consistent across different devices and operating systems. This helps to establish a sense of familiarity and trust with the user, which can be crucial in convincing them to pay for content or services.

Faster Loading Times

Web views can be slower to load, which can frustrate users and discourage them from making a purchase. With native UI elements, paywall screens load quickly and seamlessly, which can help to improve conversion rates.

Native UI Elements for Paywall allow Better User Experience

Native UI elements are designed specifically for mobile devices. This means they are optimized for touch screens, smaller screens, and other mobile-specific features. These native elements can help to create a more intuitive and enjoyable user experience. A more enjoyable user experience will encourage users to engage with the app and make purchases.

Looking for ideas on how to design your native paywall? Read our guide to Paywalls with Better Conversion Rates.

Improved Security

Native UI elements are more secure than web views, as they are less vulnerable to attacks such as cross-site scripting and injection attacks. This can help to protect sensitive user information and improve user trust in the app.

Increased Customization

With native UI elements, developers have more control over the design and functionality of paywall screens. This means they can create a unique and engaging user experience that reflects the brand and appeals to the target audience.

In addition to these benefits, native UI elements also allow paywalls to leverage system features like localization, accessibility, dark mode, and more. Let's take a closer look at each of these features:

Localization

By using native UI elements, developers can take advantage of the built-in localization support provided by mobile operating systems. This makes it easier to create paywall screens that are localized for different languages and regions, which can improve the user experience and increase the app's reach.

Accessibility

Native UI elements also provide better accessibility support than web views. This means paywall screens can be designed to be more accessible to users with disabilities, such as those with visual impairments. This can help to improve user satisfaction and ensure compliance with accessibility guidelines.

Dark Mode

With the increasing popularity of dark mode, native UI elements allow paywall screens to automatically adapt to the user's system-wide preference. This can create a more seamless and immersive experience, which can help to increase user engagement and satisfaction.

Haptic Feedback: Native UI Elements for Paywall

Native UI elements also allow paywall screens to leverage system features like haptic feedback, which can improve the user experience by providing tactile feedback for user interactions. This can make the app feel more responsive and engaging, which can encourage users to make purchases.

If you're looking to create paywall screens for your mobile app, consider using Nami's no code paywall solution. With Nami, you can have the best of both worlds by creating paywalls that are rendered using native UI elements. This means you can take advantage of all the benefits of native UI elements, such as faster loading times, better user experience, improved security, and system feature integration, without the need for coding skills. By using Nami, you can create paywalls that are customized to your brand, easy to use, and optimized for revenue generation. So why wait? Get started with Nami today and take your mobile app to the next level.

When performing simulator in-app purchase testing from Xcode, the purchase flow is canceled before the purchase sheet pops up in the simulator. Then, the macOS crash reporter pops up and indicates a crash in a service called PassbookServiceUI!

Here’s what it looks like:

In addition, if you inspect the error responses from StoreKit you’ll see messages like this:

SKPaymentQueue: Payment completed with error: Error Domain=ASDErrorDomain Code=907 "Unhandled exception" UserInfo={NSUnderlyingError=0x60000009e5b0 {Error Domain=AMSErrorDomain Code=6 "Payment Sheet Failed" UserInfo={NSLocalizedDescription=Payment Sheet Failed,

The crash is in a service called PassbookServiceUI, which sounds like it has nothing to do with in-app purchases. Unfortunately, it makes it impossible to perform Xcode StoreKit purchase testing.

This occurs when triggering purchases with either StoreKit 1 or StoreKit 2 APIs. It happens even if a valid StoreKit Configuration file (.storekit) file is assigned to the build target.

The Crash Environment

The PassbookServiceUI crash occurs with the following environment as of this writing:

• macOS 13.0 Ventura
• Xcode 14.0.1
• Simulators iPhone 14 Pro running iOS 16
• App code utilizing either StoreKit 1 or StoreKit 2 APIs
• A valid StoreKit Configuration file

Solutions to the PassbookServiceUI crash

This error can be resolved by altering the simulator device, as many are known to function correctly.

1. For iOS 16 testing - Use iPhone 14, iPhone 14 Plus, or iPhone 14 Pro Max.
2. For iPhone 14 Pro form factor testing - Use iPhone 13 Pro (with either iOS 15 or iOS 16)

That’s it! While this is an annoying bug that hopefully Apple fixes in a future version of Xcode, the workaround is quite simple.

Level Up Your App Revenue

Nami is a complete solution for growing your app revenue. Here’s what we have to offer:

• A proven StoreKit implementation, covering all tricky edge cases
• An easy to adopt SDK, no server-side code is required
• Built-in no-code paywall templates, A/B testing, and analytics
• Our generous free tier provides reasonable limits and lots of features not found in homegrown implementations.

Now you can focus on building a great app experience that is built for generating revenue. Get started for free here.

If you have a development team, you might be considering building a paywall in-house. Why should you use a paywall solution instead? Here are our top reasons why you should use a no-code paywall solution for your subscription app business.

See a Live Preview in a No-Code Paywall Builder

When coding a paywall, you spend a lot of time staring at lines of code and not a lot of time focusing on the layout and design. With a no-code paywall builder, you get to skip right to designing and editing colors and copy live.

Experiment with Different Designs

Industry best practices for paywalls are constantly changing. Rather than spending days of development on 1 paywall design and being hesitant to change it, use a solution that is continually evolving and adding new components and layouts.

Nami’s no-code paywall builder has dozens of paywall designs available out of the box. And we are always adding more designs that require no development time to add to your app.

Update No-Code Paywall without App Review

The Apple App Store requires your mobile app to go through review each time you submit an update. While review often goes smoothly, your app update can get delayed for everything from long review times to new guidelines that require big product changes. According to Apple, “...forty percent of apps or updates submitted to Apple are rejected...” - CNBC, Inside Apple’s team that greenlights iPhone apps for the App Store

40% percent of apps or updates submitted to Apple are rejected

With a no-code paywall builder you can make big and small changes that go live immediately without the hassle.

Test Faster

When you want to grow your app revenue, you need to optimize paywall conversion rate. To do this, you need to make frequent updates and enhancements to your paywall and purchase funnel. If you are always relying on development to make change, testing grinds to a halt.

With Nami’s no-code paywall builder, you can create 2 variants of the same paywall in minutes. Then use our campaign view to set up a one-click A/B test with customizable split and audience filtering. When your campaign goes live, your app audience immediately starts getting the test paywalls.

Learn more about A/B Testing best practices.

Take Advantage of Built-in Analytics

When you are coding your own paywall, analytics are often the last thing on your mind. But without data telling you if users are viewing or purchasing from a paywall, you are in the dark about paywall performance. Choose instead a no-code paywall solution that has a full package of analytics. Nami analytics are specifically designed to give you the fullest picture of how your app is performing.

Final Thoughts

Use a no-code paywall builder to build paywalls live, experiment with new paywall designs, avoid App Store review delays, test faster, and get built-in analytics.

Get started with Nami’s no-code paywall builder solution today.

Google Play Billing provides various Proration Modes via the BillingFlowParams.ProrationMode API to help developers implement an upgrade and downgrade experience.

One of the most frustrating Proration Modes to work with is DEFERRED. Here’s how Google defines this mode:

Replacement takes effect when the old plan expires, and the new price will be charged at the same time.

Typically, app developers use DEFERRED for the downgrade use case.

Practically speaking, this mode will wait before making the product the user is downgrading take effect until after the current (the future old plan) plan expires.

For example, if your current plan has a monthly bill term, the new plan will take effect when the current plan is set to renew within the next up to 31 days.

Similarly, if the current plan is an annual bill term, it may be quite a while until the DEFERRED plan takes effect. If the user downgrades, the same day they bought an annual plan, the new plan won’t take effect for 365 days!

Testing the DEFERRED Proration Mode can be a bit tricky. Let’s dig into this a bit further.

Testing DEFERRED Proration Mode

Here’s what you need to know to successful test and have confidence in your DEFERRED implementation:

Testing via a Device Development Build has limits

Development builds will trigger the downgrade flow, and you will get the confirmation email from Google.

However, the deferred product will not replace the current plan at the end of the current plan’s bill term. In fact, it will be “stuck” in limbo where the current plan will be active, despite not renewing and an expiration time in the past, and the new plan will not be active.

You can get out of this state by cancelling the current plan manually via Play Store > Payment & subscriptions > Subscriptions. Doing so will throw an error in the Play Store app, but the cancel will expire the current plan and the deferral.

Conduct End-to-End Testing via a Test Track build

Fortunately, a signed build distributed via a Test Track, including Internal, will allow you to conduct end-to-end testing of DEFERRED plan changes.

If you have any problems testing this scenario via a Test Track build, be sure you are setup for successful IAP & subscription testing:

1. Only active products can be bought - Make sure the in-app purchase or subscription product is active in Play Console.
2. Add Google accounts to the Test Track - Add approved testers to the internal, alpha, or beta test tracks. Testers added to the list, must also join the test via the link surfaced in the test section in your Play Console.
3. Add Google accounts to Setup > License Testing - This allows testers to make purchases using test credit cards to avoid actual charges.
4. Check the Google Play Account on Device - the Play app allows you to sign in to multiple accounts. Make sure the one added in step 3 and 4 above is the active account signed in before attempting the test purchase.

Practical Considerations

Testing the DEFERRED Proration Mode is tricky and so can be providing customer support to users who have triggered this duration mode (likely via a downgrade).

Here are some real world considerations you need to know about Google Play DEFERRED plan changes:

1. Play Billing doesn’t surface DEFERRED transactions - You will not have a Purchase Token or Order number until the plan takes effect.
2. End Users don’t have visibility into DEFERRED transactions via the Play Store app - End users will only know about the plan change via the Google Play plan change sheet at the time of the change and the confirmation email from Google Play. The plan change is not surfaced in the Play Store > Payments & subscriptions > Subscriptions.
3. Trying to upgrade back to the original plan, while a DEFERRED is pending will result in an error - The Play Store sheet will raise an error that says: “We are unable to change your subscription plan.”
4. Trying to initiate a DEFERRED sku change to the plan that is already DEFERRED will result in an error - The Play Store sheet will raise an error that says: “We are unable to change your subscription plan.”
5. Play Billing can get confused - If you see the Play Store sheet with DF-DFERH-01, you’re in a funky state. You can try again, cancel your subscription and try again, or delete your test app build and try again.

Google Play Billing Made Easy

Make your life easier by simplifying your Play Billing implementation with Nami.
Here’s what we have to offer:

• A proven Play Billing implementation covering all tricky edge cases -- including upgrade/downgrade logic plus DEFERRED Proration Mode handling
• An easy to adopt SDK, no server-side code is required
• Built-in native paywall templates, A/B testing, and analytics
• Our generous free tier provides reasonable limits and lots of features not found in homegrown implementations.

Now you can focus on building a great app experience, not hassling with Play Billing infrastructure. Get started for free here.

Alternative payments are finally here for the App Store. At least in South Korea, with a number of important caveats.

On March 15, 2022, detailed rules from the Korea Communications Commission went into effect preventing Apple and Google from mandating that app developers have to use their payment systems. These rules resulted from an amendment to the Telecommunications Business Act in South Korea which was signed into law in August 2021.

Now, Apple has finally provided app developers with detailed guidance for how to use a third-party payments provider in South Korea.

7 Takeaways from Apple’s South Korea Guidelines

Here are 7 takeways you need to know before considering whether to offer alternative payments in South Korea:

1. Apple still takes a 26% commission

The commission assessed is the normal App Store revenue split of 30% to Apple, less the fees associated with payment processing and related features.

2. Responsible for user support related to payments shifts from to the developer

App developers offering alternative payments in South Korea will need to provide all end user support functions related to payment processing issues, refund requests, subscription management, and more. Apple will not field any support requests related to third-party payments and will direct users to your support URL(s).

3. To offer alternative payments in South Korea, your app needs a special entitlement from Apple

Developers interested in offering alternate payments in South Korea must request a special entitlement called the StoreKit External Purchase Entitlement for use within a build of your app specific to the South Korea App Store storefront.

4. Your alternative payments app for South Korea must be a new, separate app binary

App developers who want to offer alternative payments in South Korea must create a new app binary. This app will need to use a new bundle ID that has not been previously published on the App Store.

5. You must select an Apple pre-approved payment service provider

Apple has pre-approved four payment services providers (PSP) in South Korea for payment processing:

• KCP
• Inicis
• Toss
• NICE

Each of these providers all meet Apple’s criteria which includes having broad payment support, industry standard privacy and security, fraud prevention, subscription billing, and split payments support. The special entitlement permits usage of only one PSP. You may request a PSP not on the pre-approved list, but Apple will consider additional PSPs at their discretion.

6. You must surface an External Purchase Modal Sheet
to users as part of your alternative payments flow

Before collecting payment information, you must inform users that the app is using alternative payments via a modal sheet conforming to a design provided by Apple.

7. No web views allow for third-party in-app payments

Apple is requiring that the in-app payment experience for apps in South Korea taking advantage of alternative payments is fully native. No web views are permitted.

Final Thoughts on Alternative Payments in South Korea

It remains to be seen whether app developers will widely adopt alternative payments in South Korea or anywhere else in the world should they become available in other juristidations.

Arguably, Apple’s requirements allow compliance with South Korea law while trying to minimize as much end user confusion as possible.

For app developers and publishers, owning the customer transaction can sound enticing. As we’ve shown in this article, there are important considerations that make it a less straightforward decision.

At Nami, we’re tracking the global regulatory pressure that has been building for some time that may force Apple and Google to more widely permit a solution such as what’s now available in South Korea.

We’ll have more to say in the future about the approach we’re taking with our product. In the meantime, we are 100% committed to providing a great experience for developers who depend on native Apple and Google billing.

WWDC22 wrapped up this week and we've got you covered on the key announcements relating to payments, monetization, and in-app purchases from Apple WWDC22:

• Major New Apple Pay Merchant Features
• Benchmarks in App Analytics
• SKAdNetwork 4.0
• In-App Purchase Testing Improvements
• Refinements to StoreKit 2

💳 Apple Pay

Apple Pay received major new capabilities to will help merchants remove purchase friction and do more. Let’s take a look:

Tap to Pay on iPhone

Apps that accept payments via an approved payments partner such as Stripe or Square can now accept contactless payments. This way, no extra hardware is required to accept payments from customers using Apple Pay, Apple Watch, contactless credit or debit cards, or other digital wallets.

Apple Pay Later

BNPL - buy now, pay layer - is coming to Apple Pay. Customers can now split a purchase across four equal payments over six weeks. No additional interest or fees are applied, and merchants don’t have to do anything.

Order Tracking

Once an Apple Pay payment is complete, merchants can how add additional order details that will show up seamlessly in the Wallet. For example, surface order tracking details, order changes, or provide easy access to customer service options.

Merchant Tokens

Automatic or recurring payments can now happen independent of a device using merchant tokens. This means if a user upgrades to a new iPhone, their payment information will remain active even if they remove a card from their old device.

Merchants can also support new transaction types to fine-tune the payment experience with the Payment Request API.

📊 App Analytics Benchmarks

App Store App Analytics will soon have new App Benchmarks so you can see how your app’s performance compares to your peers. Peers are determined by Apple based upon your category (e.g. Travel) and business model (e.g. subscription). This is done in a way to protect end user privacy and to protect your app’s specific performance. Benchmark results are shown via a percentile distribution.

Here are the metrics available for comparing your app to others:

App Store Conversion Rate

Conversion rate is the rate at which users download or re-download your app after seeing it on the App Store. This metric will let you compare your user acquisition to your competitors.

Retention

Benchmark your app’s retention on Day 1, Day 7, and Day 28 post-download compared to your competitors. Strong retention over time is a good measurement for how well your app is doing in keeping users engaged.

Crash Rates

See how well your app avoids crashes versus your peers. Crashes are a negative user experience that can cause users to find alternatives.

📏 SKAdNetwork 4.0

Apple’s privacy-focused click measurement solution is taking another leap forward. SKAdNetwork 4.0 will support new capabilities and is coming later this year. Advancements include:

SKAdNetwork for the web

Advertises will be able to attribute web-based ad interactions that lead to an app download from Apple’s App Store. This will give app publishers are more holistic view of their app campaigns.

Multiple Conversions

Postbacks from multiple conversion windows will help advertisers and ad networks better understand user app engagement over time.

Hierarchical Source Identifiers and Conversion Values

Advertising becomes more flexible and gets more attribution information while still maintaining end user privacy.

🧪 IAP Testing Improvements

Similar to the App Store's in-app events, LiveOps will include an Events feature. Events will be surfaced throughout the Play Store to give you more exposure.

Sync IAP Products to Xcode

Bring App Store Connect IAP products to Xcode for testing without manually re-entering data.

More Xcode Testing Scenarios

Test new scenarios such as code redemptions, refund requests, price increases, or grace periods. This makes it much easier to validate certain previously hard to test scenarios.

Sandbox

The IAP sandbox is getting better. At last, Apple is making it easier to add sandbox testers and to test certain complex scenarios in the sandbox environment. This is a welcome addition as you advance your IAP implementation from development to App Store release.

👩‍💻 StoreKit 2 & Server API Refinements

Introduced last year at WWDC21, StoreKit 2 was a major step forward for app monetization via in-app purchases or subscriptions. This year, Apple is further refining StoreKit 2 to make it even easier for developers to work with.

AppTransaction API

App developers now have the ability to get more transaction detail via the AppTransaction API in StoreKit 2. Developers can more easily access the transaction history in-app. Additionally, transitioning an app from a paid to freemium business model is now easier than ever.

App Store Server API Notification History

Now app developers can have a history of notifications and in-app purchase transactions sent to their backend via the App Store Server API. This is useful when your backend server has an outage or if you need to replay events for scenario testing. The new API also allows you to look up IAP purchase history.

SwiftUI APIs

Lastly, Apple is extending more StoreKit 2 APIs such as presenting an offer sheet to SwiftUI apps. This is a welcome addition as SwiftUI matures and more and more developers adopt SwiftUI as their first choice for building apps for Apple platforms.

Final Thoughts

WWDC22 made a lot significant announcements for app publishers related to payments, monetization, and in-app purchases. From Apple Pay merchant improvements, to App Store Benchmarks, to IAP improvements, developers can look forward to having access to the most robust commerce capabilities yet.

Combine Apple’s commerce advancements with Nami’s entitlement engine, native paywall manager, and paywall A/B testing , and it’s easier than ever to grow and optimize your app revenue. If you’re interested in giving Nami a spin for your own app, you can create a free account here.