Apps, Facebook and the Trust Problem

I knew there might be an issue before my app was released when I had my wife try it out. She initially clicked on the Facebook login button, but when a confirmation dialog popped up that asked her if she was sure she wanted to grant access to her profile info and friends list, she flinched and then clicked “No”. Then when the login failed, she called me over to see what was wrong. I asked her if she said “No” to granting the app access to her Facebook account and she replied, “Yes I did, I don’t want this app having access to that information.” To which I then inquired, “You understand that I wrote this app, right? So by not trusting the app to have access to your Facebook information, you are saying you don’t trust me, your own husband, with that information?” I don’t remember her exact reply, but it was clear that she wasn’t even sure why she clicked “No”, but some alarm went off when she saw the confirmation dialog and she reacted impulsively in the negative.

One of my biggest worries when working on my first multiplayer iPhone/iPad game was how many people would download, install and run the app and then be turned away by an initial registration screen. I wondered if I should delay the release of the app just so that I would rework the front and backend to allow for some initial, limited game play without registering first. I had fears of more than half of people running the app balking at registration and immediately deleting the app.

I totally understand. I’m just some guy who started a company you’ve never heard of who wrote an app. Why should you trust me? I have a very clear privacy policy which states what I will and will not do with this information, including the fact that I will not share it with anyone, but who reads those really?

Ultimately, I decided to just release the app with required registration and see how it went. If the drop rate was too high, I could always release a new version which didn’t require registration. To my pleasant surprise, so far it seems that around 75% of the people who run the app end up registering. I don’t like the idea that I’m losing 25% of potential users and I may add limited, registration-free game play eventually, but I think that a 75% registration rate is pretty decent and is much better than I had feared.

Like many other multiplayer smartphone games out there, my app’s registration process has two options: Facebook login and email/password registration. As an end user, I generally prefer Facebook login so that I don’t have to remember yet another login and password and I figured that my users would be similarly inclined. But I was wrong.

So far after a few thousand registrations, 75% of my registered users have opted for email/password registration over using Facebook login. I had figured it would have been the other way around. And considering that this is a multiplayer game in which I was expecting most people to choose their Facebook friends as partners (the game is collaborative, not competitive, thus partners instead of opponents), this lack of Facebook usage is a bit concerning.

Then after the app was released, I announced it to all of my friends on Facebook and several of them logged in with Facebook, but some of them did not. I asked a couple of them why and their answers were mostly some form of “I don’t want the app spamming all of my Facebook friends.” Some of these were friends I have known for over 20 years and I wondered what sort of horrible things I have done in the past that my friends don’t trust me not to be some low class spammer mail bombing everyone they know to play my app.

After probing more, it turned out that my friends didn’t really understand who was responsible for the spam they have received in the past from their friends playing various Facebook games. It could have been Facebook themselves, the app developers, or some nefarious third party. So it wasn’t so much that they didn’t trust me, but they didn’t understand the inner workings of the exchange that took place when they granted someone permission to their Facebook information. They just knew that there was some possibility that if someone was granted access to that information, it could be used for bad deeds.

Farmville_9767b9_508385Which, of course, is true. This information has been abused by unscrupulous opportunists in the past, which, unfortunately, makes life more difficult for those of us with ethics who aren’t going to sell out their users just to get a few more installs. It also doesn’t help that Facebook itself doesn’t have a great reputation as a company in respect to its own users’ privacy.

Facebook is obviously aware of the tendency of their users to now be more shy about sharing their information than ever before. They recently announced some features to Facebook Login aimed at helping in this regard:

1) They now allow a user to choose what parts of their Facebook information they allow an app to have access to. So if a user wants to allow an app to have access to their profile information, but not their friend list, they can uncheck the friend list permission when logging in.

2) They added something called “Anonymous Login” which allows a user to log in via Facebook without giving the app any access to any personal information.

Until these new features are out in the wild, it is hard to say how much effect they will have in increasing Facebook Login usage. Since the dialog to allow/disallow different permissions occurs after a user has clicked on the Facebook Login button, it likely won’t have much effect on users who avoid clicking the button entirely.

The Anonymous Login feature might help since it is intended to be a completely different button with a different look. However, a question still remains whether or not users will understand what the Anonymous Login button is for and will therefore be more likely to use it. The button also has a disadvantage in that if you don’t have access to the user’s information such as their friends list, you can’t provide easy ways to have users start new multiplayer games with their friends.

1301053-grandpa_simpson_shakes_fist_at_cloudI wish I had some solution to this problem, but I’m not sure there really is one until the day someone invents a time machine and goes back to warn Facebook of the dangers of the Farmvilles of the world before they take over everyone’s news feed with their “growth hacking”. As has happened many other times in history, those who came first didn’t play nice and they screwed it up for everyone else. Now we’re left with users who are afraid to share any information and they’re not even sure why. And then we developers spend weeks creating elegant and simple interfaces for users to easily choose friends to play with and it turns out that our users are too afraid to use them.

In a recent update to my app I added more verbiage in an attempt to explain to my end users that I don’t store or make any use of their Facebook friends list or phone contact list in any way other than to help them find friends to play with. Once I have enough data from the new version I plan on reporting how much of an effect that had, if any. Stay tuned.


Handy load testing code for Google Cloud Endpoints

Now that my app has been submitted and I am awaiting its review, I have time to work on non-critical things like open-sourcing code that I’ve been working on.

I’ve always been a big user and proponent of open source software and have released open source code in the past, but this will be the first code I’ve released for Cromulent Labs. I hope to provide more useful code to the public in the future.

The first project I am releasing is a custom JMeter log parser which can be used to replay Google Cloud Endpoints requests in order to load test an API.

If you’re not familiar with Google Cloud Endpoints, it is a handy extension to Google AppEngine which allows you to define an API on the server-side and it auto-generates the client code for IOS, Android and Javascript. This makes it very easy to create a Service Oriented Architecture, which is all the rage with the kids these days, without having to write your own custom client code to hit the API on the server.

My custom log parser allows you to easily replay logs from an app session in order to stress/load test your API and see if anything breaks. This can be especially useful before you release your client software because while testing by yourself, you probably always hit the same App Engine frontend instance. By loading up enough concurrent JMeter thread groups, you can simulate many more users and test how well your back-end works with a number of different instances running under load at once.

To use the custom log parser, all you need to do is turn on Cloud Endpoints logging on your client. Then create an Access Log Sampler in JMeter and point it at your Endpoints logs for a session. It goes through each API log in order and automatically sets the same URL endpoint, query string, headers and post body for each API call and replays it to your frontend instance. If you want to try it out, there are more detailed steps in the README file for the project which is hosted here on GitHub:



It’s 2013, I live in San Francisco, and I’m starting a new company to make iPhone apps. That is quite the cliche.

However, like most startups you hear about these days, I am not trying to get rich and I don’t plan on creating a billion dollar company. I’m not a 24 year old with a once in a lifetime idea convinced he is going to change the world. Instead, I am a grizzled 38 year old software developer and if all goes to plan I will be the only employee my company ever has. I don’t plan on taking any VC money, selling the company to the highest bidder, or going public ever. Hey, you never know, though, things change.

My plan is to create a company which creates useful and fun smartphone apps and if all goes well, perhaps someday those apps will produce enough income that it will pay my bills and be my only job. I am currently still doing some consulting on the side until that day comes, if it ever does.

There has never been another time where it was easier and cheaper to start your own company and so I have taken the plunge. Along the way, I plan on blogging about the experience in case there is anyone out there who will find the journey interesting and/or informative.

Feel free to leave comments, critiques, or insult me along the way.