Yesterday, we released of the Nami SDK for iOS. To mark this release, we thought we’d share some details about how we approach development of the SDK including our key design goals.
Creating great customer experiences is a core part of Nami’s company values. As part of our mission of BCE, the Nami SDK was built around five key concepts that we believe to be vitally important:
- Ease of Adoption
- Make Subscriptions Simple
- Protecting the End User Experience
- Emphasis on End User Privacy
- Built for Developers
Below we’ll touch on each of these concepts in more detail.
Ease of Adoption
We’ve experienced SDKs that take way too much time to integrate or create additional unforeseen work. Adding a new SDK to your app should be as painless as possible. That’s why we’ve focused on making the Nami SDK incredibly straightforward to adopt.
Minimal code to get started. We strive to get you up and running with just a few lines of code. The basic integration steps are straight forward so you can stay focused on what really matters: building a great app!
No third-party dependencies. The Nami SDK does not require any third-party code or dependencies. This helps us keep the size small and the integration points to a minimum. The Nami SDK will never generate a dependency conflict.
👉Read more: Announcing Our New Documentation Portal
Make Subscriptions Simple
Receipt validation. We take care of the complexity in the Apple APIs for details around app purchase receipts, including monitoring updates to purchases including users canceling a subscription or getting a refund for a purchase, thus re-disabling a feature in an application.
Easy purchase testing. We know that testing in-app purchases is a hassle. That’s why we wanted to make it much easier to test a variety of purchase flows, so that you do not have to spend as much time managing StoreKit test users or going through tedious system prompts just to test your apps reaction to purchase changes.
Cached purchase details. StoreKit doesn’t offer a way to ask for purchased products, so developers typically have to cache purchases. The Nami SDK stores away information about purchases so they can be easily checked at launch if the user is already subscribed without relying on the network.
Avoiding "Restore Purchases”. The restore purchase flow is clumsy for a user of any application so we use receipt validation and other techniques to determine if a user on a new device or with a reloaded app has previously purchased products.
Cloud-enable your existing sales sheet. Attach your existing subscription sales sheet or offer screen to the Nami SDK to make it more dynamic. This means you can make changes from the cloud and require fewer app updates.
Adopt a Nami Paywall. Ready to turn over control of the sales sheet to your product or marketing team? The Nami Paywall is a native (no WebViews!), feature rich sales sheet experience that can be fully managed in the cloud by non-developers. Meanwhile, in your app code the Nami Paywall handles much of the complexity of offering subscriptions with StoreKit.
Protecting the End User Experience
Maintain main app performance. Nami uses background, low priority queues for work whenever possible. Sometimes providing a great user experience means processing or information must be fetched quickly. When this is necessary, we strive to do as little work on the main thread as we can, or at times when app performance is not impacted.
No UI impact. We strive to ensure whenever possible that none of the work that Nami does will impact UI performance. As described above, whenever possible Nami works on the background thread, but we also take extra care to avoid doing work during certain kinds of animations such as controller transitions.
Protect and conserve battery life. We avoid unneeded work on the device. This means taking care to exercise power consuming features like network requests in a way that allows the system to batch with other requests as much as possible.
Emphasis on End User Privacy
Customers are expecting more privacy in apps every day and the regulatory landscape is constantly changing, making it more risky to be producing software and not have your user’s privacy as a top priority. Are your vendors and partners helping you reach your privacy goals? The Nami SDK strives to be a strong partner in your goal to protect your users data.
Privacy is core tenant of our company mission: BCE, so expect read more in future posts detailing our technical approaches.
No PII. While we do have to collect a unique identifier to be able to offer personalized experiences, the Nami SDK does not collect email addresses, geolocation information (except at a country level), or device identifiers.
Data minimization. We employ data minimization to limit what we collect to only what is absolutely necessary. This is in stark contrast to the many SDKs that collect voluminous and invasive data with little regard for the user.
👉Read more: Cross-Platform App Development
Built For Developers
Simplify but do not hide complex StoreKit workflows. We want our SDK to help provide you with the simplest possible means of receiving important information about the purchase flow within an application, while still providing access to the underlying StoreKit metadata you may need for more complex workflows.
Built for Swift 5. We built the Nami SDK using Swift 5 to ensure we get all the benefits of Apple’s modern programming language. This helps us iterate more quickly and keep quality high.
Detailed release notes. With each update to our SDK, we’re adding detailed release notes to our GitHub repository. While it’s generally a good idea to keep the SDKs you ship in your app current, our detailed release notes will help you prioritize updates.
Example apps included. Code fragments are great, but we appreciate SDKs that include fully functional example apps (that compile!). With our latest release, we shipped our first example app with more to come. We’ll be sure to keep examples updated with new operating system, developer IDE, and toolchain releases.
Take a look at our developer documentation and let us know how we’re doing.
* * *
We want the Nami SDK to be as delightful as possible to use, so if there is anything you find confusing or would find helpful, please let us know or open a GitHub issue!
