Teaching a techie- Sample apps for SDKs

Back in 1990 when I was at high school, my father’s business was going through a tough time, so we downsized and moved from the most wonderful city of Mumbai (India) to our infrequent vacation town, Nasik. The thought of being distanced from all my dear friends in Mumbai was devastating, but there was nothing I could do about it! Little did I know then that our move to this obscure town was the foundation that would shape my career! It was at my new high school in Nasik that I was first introduced to computers in grade 9. We started with “logo”, moving the faithful turtle around the screen, and gradually started coding in “Basic”. Some day that year, the director of the computer section was on rounds during a programming competition prep session, and pointed out a potential flaw in my code… and I explained to him why he was wrong. He said he was sorry and I said “you should be!”.  I think that event established my “geek” status and I proceeded to win my first ever inter school programming competition.

Till then, unlike my very academically successful sister who was in med school at the time, I had never achieved anything to brag about in sports or academics, or for that matter anything a ninth grader could brag about. Daddy was impressed to see that his son found something to excel in and some how managed to fund additional coaching in computers for me. During one of those coaching classes, we were assigned a Fortran coding exercise and I completed it with some clever use of for and while loops, and enthusiastically announced that I was done. The advantage I had over others was my school programming experience in Basic, while the rest of the class was just being introduced to programming. The instructor awarded me with an opportunity to explain my solution to the class. I went to the board (can’t remember if White boards were a thing then or was it chalkboard) and wrote my code there. My “explanation” of the solution was reading out the code. I felt like I was the smartest of the lot, but the impression I left on others, including the instructor, was that this guy must have copied the solution from somewhere and has no idea how it works! That is when I learned that tech and teach are completely different worlds.

Fast-forward to 2015, when, thanks to my Computer Science foundation, I found myself armed with a US citizenship, a good resume, and a new job with PayPal Here’s SDK team in the Silicon Valley. The SDK team had a “Sample App” that partners could refer to for coding their integrations. Our partner developers could download the single page app, enter their credentials and demo it to their management easily. To my genuinely awesome peers, this app was as self evident and self explanatory as my lines of Fortran code.

My first project was to build and publish our new PayPal Here Windows App and SDK… all completely new code. Our team has one very important value that we encourage- we encourage any fresh set of eyes to share their perspective. When it came time for creating the sample app for the Windows SDK, I discussed my concerns about the existing sample apps with the team and convinced our PM, the new hire with a cool mustache, to assign cycles for coding a sample app that splits each step in the use of our SDK and dedicates a separate screen for each step. The objective of this new sample app was not to showcase the technical and coding expertise and efficiency of our team, but rather to highlight each nuance of using the SDK and walk the “reader” of the app through the steps.

So, for a change, the target of our code became a “reader” rather than a “user” of the app! The app became an extended part of our “documentation”…. a live document that developers could read and also immediately interact with if they chose to execute the code. Our PM went on to showcase the new sample app and had it recorded on Microsoft Channel 9.

In 2018, with the launch of our next generation SDKs, we had the opportunity to revisit our iOS and Android Sample Apps. Over the years, our PM has grown the product team and we now have a new hire go-getter PM for the SDK. With the new SDK, we also took the opportunity to simplify the APIs so that there would be fewer steps to get things done, while still maintaining the power of the old APIs for any partner wanting to code advanced use cases.

Our goal was to have minimum friction for getting started and then have advanced capabilities available to use.The design of the new sample apps is one group of API features per screen (authentication, initialization, connection, payment selection, refund etc.).

This is obviously not how any self respecting developer would design and publish a real-world app, but then, this is not a real world app! It is an extension of our SDK documentation. The purpose of this app is API-first: to show how each API can be used, so each API feature-group gets its own screen.

The new sample apps can be found on PayPal Here’s public github repos:

I would love to hear your experiences with SDKs, sample apps, and documentation- PayPal Here or any other: what do you like about the sample app, what you wish should have been done differently, what could be added, what are the friction points, or any other observations. A fresh set of eyes and a fresh perspective is a highly valued asset, thank you so much for reading!

PayPal is hiring now! Check out these jobs.

Disable Apple Pay

Mobile Point of Sale and Apple Pay

Your mobile Point Of Sale app is gaining popularity and you have started receiving lots of user feedback. Your users appreciate the convenience and rates offered by you. You have offered shiny new contactless credit card readers to your users so that they can accept contactless payments using your app. Well, congratulations! And now, it’s time to make your user experience better by disabling Apple Pay when your app is active.

This is a fairly common scenario with mobile POS applications. When your users use personal devices to run POS apps, it is very likely that they have also enabled Apple Pay on their devices. So, if these users have contactless credit card readers near their devices while accepting payments, then they could be prompted to use Apple Pay on their own device to pay themselves. Here’s some good news for you: Apple has a solution for this annoyance so that you can continue receiving those 5 star reviews from your users!

How to get started

The code for disabling Apple Pay is relatively simple. The longer and less documented part is the process to from start to publishing the app for review. Disabling Apple Pay requires an entitlement from Apple. In this post, we will look at our journey of obtaining an “entitlement” from Apple to disable Apple Pay in our app.

Step 1- Request Entitlement for suppressing Apple Pay

At the time of this writing, an entitlement to disable Apple Pay can be requested by contacting apple-pay-provisioning@apple.com

I wrote to them explaining that we need to disable Apple Pay while our app is in foreground because our app accepts contactless payments using an external reader, and we do not want our merchants to accidentally pay for their customers if the merchants’ phone is close to the reader during payments.

I (almost) patiently waited for about a month for Apple to respond. Finally, after a month of sending my initial email, I reached out to my friend who worked at Apple and copied him on a reminder email asking about the status. A few days later, I got a response to my reminder with the good news that our request was approved and asking me to provide our team and app details.

Step 2- Send details about your team and app

The approval is for the specific use case described in the initial email. As a next step, I was asked to provide the Team ID (found in https://developer.apple.com/account/#/membership)

Step 3- Set entitlements on your profiles

A few days after sending our team IDs, I got the following reply:

The entitlement was granted. Please head to the developer website, login, edit your provisioning profile, select the entitlement from the drop down menu. Then go to Xcode, head to build settings, then ensure you select a provisioning profile for which you added the entitlement on the developer website. Then, within Xcode, ensure you add the entitlement “com…” to the entitlement plist.

Developer.apple.com -> Account -> Provisioning Profiles -> Your profile
Entitlements section on your profile


Step 4- Add entitlements

After adding the entitlement as explained in the email, I needed to figure out how to add an entitlements file to my project (We do not use any other entitlement)

  • A quick option to add an empty entitlements file is to go to the capabilities tab and enable some capability, then remove that capability
  • Go to build settings, search for Code Signing Entitlements and set the name of the entitlements file added (removing the capability will reset the Code Signing Entitlements value). The value to be set is the entitlements file name without the .entitlements extension.
  • Add row com.apple.developer.passkit.pass-presentation-suppression to the entitlements file and set its value to Boolean, YES
Project -> Build Settings -> Code Signing Entitlements
Entitlements File in Build Settings

Step 5- Add the Passkit framework to your project

Remember to set it to optional if you expect your code to work on devices that do not have Passkit.

Project -> General -> Linked Frameworks and Libraries -> PassKit.framework -> (Status = Optional)
Set Passkit as optional


Step 6- Download updated profiles

Ensure that you download the updated profile that has the entitlement so Xcode knows about it.

Step 7- Use the PassKitHelper (or your custom code)

Call requestAutomaticPassPresentationSuppression to suppress Apple Pay. I have published a basic PassKitHelper class on my github repo for reference. The “requestAutomaticPassPresentationSuppression” line will fail till you obtain the entitlement and use the updated profile to run your app.

Good to know

  • A Swift Code sample is available on github.
  • Once you call requestAutomaticPassPresentationSuppression, iOS ensures that Apple Pay is enabled when your app goes to background and disabled again when the app comes back to foreground.
  • Although the PassKitHelper in the code sample has an option to enable Apple Pay, in practical scenarios, you may not need it because of the way iOS handles foreground-background.
  • Apple is generous with the use of this entitlement. Once you are approved, you can disable Apple Pay immediately on launching your app, you do not need to code special conditions under which to disable Apple Pay.
  • This cannot be implemented in an SDK/framework alone. The entitlement is granted to your Apple Developer profile. So, this needs to be coded at the App level. You could bundle the code in a framework, but the app that uses the framework needs to request the entitlement.
  • When the entitlement works, you will be greeted with this message confirming that Apple Pay was indeed disabled. This message is only displayed once per install, the first time when the app disables Apple Pay. Subsequent disables are silent.
  • As of Feb 2018, the message displayed when Apple Pay is disabled is not customizable. The message could be a bit confusing to users who use the app to accept Apple Pay payments using contactless card readers, so I have submitted a bug report to Apple to provide a way to change this message. I will update this post when this becomes available.
  • Apple Pay Not Available message

I hope you were able to find some useful information in this post. I would love to hear about the scenarios in which your apps disable Apple Pay. Any feedback on the code or the process described will also be appreciated!

PayPal is hiring now! Check out these jobs.