Since its announcement on April 30th, 2014, Facebook has been rapidly changing app permissioning rules and Software Development Kit ( SDK ) requirements. By rapid, I really mean instantaneous as they began enforcing the new rules the very day they were announced. This meant that Facebook apps created on or after April 30th were required to play by the new rules and use the new SDK and app creation process.

Changes in a Nutshell

Permission Grants and Requirements

Prior to the SDK 2 announcement, a Facebook application developer was able to simply create an app and indicate which permission grants it would require from the user or the Facebook page. As an example, if your app pushed notifications to a Facebook page wall you would simply check the box for “manage_page” permissions. A user or page manager would then see that permission request during the application approval process.

The new Facebook app development process is much more restrictive by throwing in a new double permission grant process. A developer will have to petition Facebook for the ability to ask the user for any permission beyond authentication and basic user information. That’s right, you have to be granted permission by Facebook to be granted permission from a user to do anything more than logging in.

It is kind of like raising your hand in class, being recognized by the professor and asking “Is it okay if I ask the students a question?”.

The process goes something like this…

STUDENT
“Is it okay if I ask my fellow students a question?”

PROFESSOR
“That depends, what would you like to ask?”

STUDENT
“I want to know if they would allow me to let them know when and where the study group meets each week.”

PROFESSOR
“In what way would you ask the students this question?”
“And what is the benefit of them allowing you to contact them?”

STUDENT
“I would ask them to volunteer their email address by writing it down on a signup sheet.”
“People who sign up will be able to know the date and location of the study group each week or if it got cancelled. People who attend these meetings would likely post higher scores on exams and finals.”

PROFESSOR
“Can you provide a visual sample of the signup sheet and a notification that you might send?”

STUDENT
“Sure, I have it all right here in a file folder for you to review.”

PROFESSOR
“Thank you for this information…”
“I will get back to you in no more than 7 business days with my decision.”

Now, if the student is granted permission by the professor she/he will then be able to present his notification request to the students. Each student receiving the question will be able to accept or decline this request.

If, on the other hand, the professor finds an error in the signup sheet or insufficient description of the process and reported benefits the students may receive they will say “NOPE” and provide specific reasoning for the rejection. All is not lost for the student, however, as he/she will be able to resubmit their request with refactored reasoning, benefits and supporting samples.

While this can be an annoying, heartburn inducing, timeline and budget influencing process it does not mean that it is all bad. In reality this process does provide a good service to the “student body” as a whole, by attempting to validate what permissions you are asking for and providing proof that you are going to use them in a useful and responsible way.

SDK 1 vs SDK 2

The differences here are much less entertaining and much more technical. Sorry, no screenplay for this description. One of the biggest fundamental changes is that there will now be versioning for the API with a non-guaranteed 2 year guarantee up time for each minor release. This will provide some long term SDK stability for app developers, but hopefully allow for a smoother transition between releases.

The SDK is available for several different languages and platforms, Android, iOS, Javascript and PHP. The biggest impact would appear to be on the PHP SDK as that was completely rewritten and has a higher PHP version requirement to run. The latter is not a big deal as most modern sites and apps should be well in line with the PHP version requirements, but the rewritten part can be a big expense for application owners.

Beyond the integration and calling of the new SDK there are a number of changes and enhancements that will impact your app. These changes affect permission grants, permission denials, information access, and unique facebook user ids per application.

As noted earlier in this article, the permission granting process has changed a great deal and how the SDK works with those grants has also changed. Permissions are granular and can be asked for, granted or denied individually. How you ask for these permissions and how you handle the acceptance or denial of each request can have a big impact on your application workflow, user experience and even user interface.

The result of the granular approach to permission grants is a higher degree of information and access security for the user. The unique facebook user ids per application ( App-Scoped User Ids as facebook calls it ) also increases the security of facebook and user data. The concept of this App-Scoped User Ids is that when a user grants access to a facebook app it will provide that app a user id that is unique to that application and that user. So if the facebook users id was 12345, the facebook user id given to the app would be listed as 13456. Previously an application would given the facebook users actual id of 12345.

Documentation Improvement?

This is less of a stated change and more of a hope of change. Historically if you had an issue or weird bug, you would have better luck finding a solution within the developer community or the question / answer sites than in the documentation itself.

While this is true of many API’s out there we hope that facebook will vastly improve their documentation as SDK 2 and subsequent variants are released. Not only would this improve the adaptation time needed for migrating your SDK 1 app to SDK 2 and above but it would make it a much friendly environment to work with.

The Verdict

While it is never fun to rework applications that worked perfectly fine before the changes, we feel the changes enforced are generally positive. Even if a little superficial, the permission requests and grants should improve the quality of the apps and user information security and control.