Yesterday, we released of the . To mark this release, we thought we’d share some details about how we approach development of the SDK including our key design goals. version 1.1.0 Nami SDK for iOS Creating great customer experiences is a core part of Nami’s company values. As part of , the Nami SDK was built around five key concepts that we believe to be vitally important: our mission of BCE 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. 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! Minimal code to get started. 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. No third-party dependencies. Make Subscriptions Simple . 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. Receipt validation 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. Easy purchase testing. . 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. Cached purchase details . 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. Avoiding "Restore Purchases” . 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. Cloud-enable your existing sales sheet . Ready to turn over control of the sales sheet to your product or marketing team? The 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. Adopt a Nami Paywall Nami Paywall Protecting the End User Experience 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. Maintain main app performance. 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. No UI impact. . 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. Protect and conserve battery life 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: , so expect read more in future posts detailing our technical approaches. BCE 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. No PII. 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. Data minimization. Built For Developers . 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. Simplify but do not hide complex StoreKit workflows 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. Built for Swift 5. 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. Detailed release notes. 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. Example apps included. Take a look at our and let us know how we’re doing. developer documentation
