We are excited to announce that we have open sourced the Windows In-App Purchase Bridge, our in-app purchase bridge for Electron apps in the Microsoft Store.

In May of 2018, we rolled out subscription support for our apps across iOS, Mac, Android, web, and Windows. However, when it came time to switch our Windows app from UWP to Electron, we ran into quite a few problems, namely getting our app to talk nicely to the Microsoft Store to create a seamless experience for users. To solve this problem, we built the Windows In-App Purchase Bridge (Windows IAP Bridge).

We are really excited about our first open source project! In this interview, Tauseef, one of our engineers, who worked on and created the Windows IAP Bridge will provide some insight into what went into building it.

Hi Tauseef! So a few months before you joined we started offering a subscription for "Pro" tools in our app . Can you explain how subscription purchases worked on Windows at the time?
Tauseef: So we launched subscriptions in early May 2018. At the time, we used Microsoft's In-App purchase API for Windows 10 apps. The implementation was pretty straightforward at the time because Polarr Photo Editor was a UWP (Universal Windows Platform) app. It was easy because Microsoft's Visual Studio has a WinJS package which provides purchase APIs that you can invoke from any JavaScript code.

You mentioned that Polarr for Windows 10 was a UWP. It's no longer UWP?
Tauseef: Not anymore. It's now an Electron app!

Why did we move the app from UWP to Electron?
Tauseef: Our Windows app was working fine, but the experience was just not as snappy as the Mac or iOS app. There was a visible lag between when a user taps on a tool and when it would open up and become usable. This sluggishness was also present on our web app when used on Microsoft Edge, but not on any other browsers. Since UWP uses Edge internally, we wanted to move away from it eventually.

So in our case, moving from UWP to Electron was motivated by performance improvements?
Tauseef: The performance improvements were a big part of the decision to move away from UWP,  but moving to Electron also allowed us to provide a more stable app experience for our users.


The final nail in the coffin came sometime in October. We experienced a harrowing amount of crashes. There were around 5000 crashes every 72 hours. Our app’s rating was plummeting, and the reviews were flooded with complaints from users that the app was crashing at startup.

I remember those stressful messages in Slack. How did you figure out what was going on?
Tauseef: A little digging suggested that older display drivers caused this, we tried to get some users to update their display drivers and test Polarr Photo Editor again. It worked! But getting all our users to update their display drivers, for a plethora of different computers they had was not scalable.

Some debugging suggested that it was being caused by Microsoft Edge’s inconsistent behavior when using the gl_PointSize API it wasn’t just us, thank god for open source. Our brush tool was using gl_PointSize, and as the tool was getting initialized at startup, it would crash the whole app.

To temporarily reduce crashes, we moved the Brush Tool initialization to when a user starts using it. But this entire experience made us realize we needed to move on from UWP and so we started working on the Electron version of Polarr.

I remember it wasn't all roses and sunshine when we decided to start working on converting from UWP to Electron. What challenges did you encounter while converting from UWP to Electron?
Tauseef: Initially, moving from UWP to Electron seemed simple and straight forward, since we were already using it for the Linux app, however, we quickly discovered the conversion process would have its fair share of issues.

What issues?
Tauseef: Most of the problems we encountered involved getting the various native modules to work on a different OS (Win32). We rely on two major native libraries, DLib (for face recognition) and LibRaw (for decoding RAW images). After creating a build process for them for Windows, we moved on to supporting in-app purchases for our subscription.

There are a set of open source libraries under the @NodeRT namespace that allows the use of WinRT APIs inside of NodeJS applications. However, some of the APIs on Windows::Services::Store namespace requires that they be triggered from a UI thread, which meant that NodeRT was out of the equation. We would have to write our own solution to be able to use those APIs.

Is this our smooth segue into the work you did and the entire point of this article?
Tauseef: Yes. I ended up creating something we're calling the Windows In-App Purchase Bridge.

What does the Windows IAP Bridge do?
Tauseef: Windows IAP Bridge provides a limited number of Windows Store purchase APIs (including those that require the UI thread) that can be easily integrated with any Electron or NodeJS based application. It is extensible and going forward we can keep adding support for more APIs to it.

How does Windows IAP Bridge work?
Tauseef: It’s an N-API wrapper around Windows::Services::Store APIs. N-API is an abi stable way to develop native modules for NodeJS, and it allows developers to write native code and consume it inside of JavaScript applications. Windows::Services::Store namespace contains the in-app purchase APIs, and Windows IAP Bridge provides a JavaScript wrapper around those so that they can be used inside of Electron (or any NodeJS based) apps.

What purchase APIs are in there right now?
Tauseef: Currently, these APIs are exposed to the JavaScript context:







The returned objects are a little different from the objects described on the Windows docs, that's because we were only using a subset of the information, and these were critical to Polarr Photo Editor. I've added type information, so IntelliSense provides autocomplete hints.

Why did you decide to open source this?
Tauseef: Most of the problems we faced during the development could not have been solved without the open source community. And when I say help, it doesn’t necessarily mean that the support came directly. Sometimes even thorough documentation or a blog post written by a developer goes a long way in helping others out.


I’ve personally bugged a lot of people on Twitter to bounce ideas off them while writing the module. Some people off the top of my head that have been a tremendous help include Felix Riseberg with NodeRT, Brian Hughes at Microsoft, and Vincent Mühler who created dlib-build.

Another less sexy reason is that we need more eyes to take a look at the code. I have limited experience, but the open source community has a lot of expertise, and I'm looking forward to people (telling me how bad the code is) making it better.

How do you see other developers in the Windows community using this?
Tauseef: One of the most significant incentives for developing applications for any Appstore is how easy they are to monetize. Microsoft recently announced that they are increasing the developer's share of the revenue that comes from store purchases. Windows IAP Bridge would help devs take advantage of all the in-app purchases that weren't readily available on platforms other than UWP.

Any particular developers or use cases that you see being excited for your work here?
Tauseef: Any Electron developers who want integration between their in-app purchases and their apps. It could be JavaScript game developers who use Electron, and consumable add-ons are a part of their gameplay or developers of subscription-based apps. For me, JavaScript is the language of choice when it comes to teaching kids how to code, and I'm always excited to see what individuals are building, this would hopefully help them monetize on their hard work without getting tied down by the limitations of Edge or UWP.


This is the first open source project here at Polarr. How does it feel to be leading the charge internally?
Tauseef: As far as I know, this is indeed the first open source project. I’m super stoked that we're doing this. I think it's important to share knowledge, however small, with the broader developer community. And Polarr is still an early stage startup, so we don't have any corporate inertia that might slow down our involvement with the open source community.

What happens next?
Tauseef: Next, the sun becomes a white dwarf… there will be nothing to show that we were ever here, except for maybe stardust.

But for now, I'll be working on other Polarr Photo Editor features, and hoping that people who use Windows IAP Bridge will start adding more APIs as they need. There are so many APIs under the Windows::Services::Store namespace that need to be added, ideally we’d have wrappers around all return types too.

I’m definitely going to be maintaining this for the foreseeable future, and maybe somebody smarter will come along and take over.

How can people get in touch with you if they have questions?
Tauseef: I think the "best" way to reach me is through Twitter (@Tauseefk). Not the most active, but I usually check it every two days or so. I'm also going to be maintaining the repository, so GitHub issues is a great way to request a feature or report a bug. I'm going to add an issues template at some point.

Can you link our readers to the repository where they can find Windows IAP Bridge?
Tauseef: Github is the place you want to go to.

Before we leave, can you tell us a bit about yourself?
Tauseef: My name is Tauseef, and I’m an engineer here at Polarr. As a street photographer, I've used Polarr Photo Editor to edit photos right on the phone. It cuts out the hassle of using a laptop and I like the freedom to edit wherever I am.

You joined Polarr last June 2018. What made you want to work here?
Tauseef: So I was already familiar with Polarr since I was using the photo editor. That familiarity led me to discover that the team was looking for a Frontend engineer with WebGL experience at the time. This role was the perfect opportunity to combine both my passion for photography and my skills as an engineer into one position. Applied, interviewed and joined Polarr in June 2018.


What did you start working on when you joined Polarr?
Tauseef: When I first joined I was trying to get the hang of the codebase. So my first project was to implement a keystroke ticker for editing shortcuts. The keystroke ticker is similar to Mortal Kombat’s tutorial mode where they teach you the various combos needed to perform fight moves. You're probably curious why a photo editor would need to show keystrokes on screen. When experienced photographers do a screencast or record a tutorial, it helps the viewers follow along with the shortcuts when they conveniently pop-up on the screen.

I honestly did not know we had this feature. How do you activate it?
Tauseef: When you're using Polarr Photo Editor on a desktop platform, like Windows, you go to settings and enable "display touches on screen" to see your keystrokes. Again, this is a useful tool for anyone creating tutorials or trying to teach others how to edit.

Thanks again, Tauseef! That repo link one last time for our friends?
Tauseef: Visit our GitHub :)