Connect with us

FACEBOOK

Build a Discord Bot with Rust and Serenity

Published

on

By Joe Previte

Discord is on the rise in developer communities. And, as we all know, developers love building on top of platforms they use. It’s fun!

Today, I’m going to show you how to build your own Discord bot using Rust and serenity.

Building the App

Before building the app, I’ll cover how it will work and the prerequisites for following along. After that, I’ll jump in and go through each step before setting it up to run locally on your machine. Finally, I’ll show how to test it out in your own Discord server.

How will it work?

Imagine I’m creating a bot for a developer community Discord server. I’m going to build a Discord bot which supports a single command !help, which will return a message explaining:

  • What channel to post in for technical help
  • Where to find the code of conduct
  • How to get in touch with admins of the server

This could be helpful for new people who need help for various scenarios. Think of it being analogous to the –help flag commonly used by CLIs.

Prerequisites

In order to start writing this Rust application, there are a few requirements:

  • Rust installed locally
  • IDE setup for Rust development
  • Discord account

Install Rust

I already have Rust installed locally. If you don’t, you can install it locally using:

 shell curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh 

Afterwards, run rustup –version to verify that it worked. If it did, you should see something printed to your terminal.

IDE for Rust Development

I’m going to be using VS Code and the rust-analyzer extension. You can find support for other IDEs under the Tools on the rust-lang website.

Discord Account

I already have an account, but if you don’t, you can sign up for free.

Set up Code

Since this is a new project, I’m going to create a new project with cargo. For simplicity, I’ll name the project discord-help-bot.

 shell cargo new discord-help-bot 

Add Dependencies

This project requires two external dependencies:

  • tokio – “A runtime for writing reliable, asynchronous and slim applications with the Rust programming language”
  • serenity – “a Rust library for the Discord API”

I’ll add both to the Cargo.toml file:

 toml [dependencies] tokio = { version = "0.2", features = ["macros"] } serenity = { default-features = false, features = ["client", "gateway", "model", "rustls_backend"], version = "0.9.0-rc.1"} 

Note: you’ll notice this is a release candidate (rc). When you go through this, check to make sure you’re using the latest version of serenity.

tokio allows the program to run asynchronously and serenity allows you to interact with the Discord API. With both of these dependencies, I can start adding logic to the program.

Add Logic to main.rs

Since this is a small program, I will only need to add code to the main.rs file. I’ll add the code and then afterwards I’ll walk through how it works.

 rust use std::env; use serenity::{ async_trait, model::{channel::Message, gateway::Ready}, prelude::*, }; const HELP_MESSAGE: &str = " Hello there, Human! You have summoned me. Let's see about getting you what you need. ? Need technical help? => Post in the <#CHANNEL_ID> channel and other humans will assist you. ? Looking for the Code of Conduct? => Here it is: <https://opensource.facebook.com/code-of-conduct> ? Something wrong? => You can flag an admin with @admin I hope that resolves your issue! -- Helpbot "; const HELP_COMMAND: &str = "!help"; struct Handler; #[async_trait] impl EventHandler for Handler { async fn message(&self, ctx: Context, msg: Message) { if msg.content == HELP_COMMAND { if let Err(why) = msg.channel_id.say(&ctx.http, HELP_MESSAGE).await { println!("Error sending message: {:?}", why); } } } async fn ready(&self, _: Context, ready: Ready) { println!("{} is connected!", ready.user.name); } } #[tokio::main] async fn main() { let token = env::var("DISCORD_TOKEN") .expect("Expected a token in the environment"); let mut client = Client::new(&token) .event_handler(Handler) .await .expect("Err creating client"); if let Err(why) = client.start().await { println!("Client error: {:?}", why); } } 

Code Walkthrough

I’m going to walk through the code in four chunks. In the first chunk, I’ll look at the following:

 rust use std::env; use serenity::{ async_trait, model::{channel::Message, gateway::Ready}, prelude::*, }; 

These are the use declarations. They make it easier for developers because they “shorten the path required to refer to a module item.” Here, there are two blocks. The first refers to the env module from the standard library, which we later use to access the DISCORD_TOKEN environment variable.

The next block refers to the modules I use provided by serenity. The first is async_trait which I use on the Handler to tell the compiler the type and methods Handler should support. After that are two structs, Message and Ready. The first is used inside the function signature of message to indicate the type for the third parameter msg. As you can guess, this is for the shape of the message when we receive it from the Discord server. The other struct is Ready and is used in the function signature of the ready function for our Handler. The last line here is the prelude which says, “include the basic things out of the box for the user.”

In the second chunk, I’ll discuss the following piece of code:

 rust const HELP_MESSAGE: &str = " Hello there, Human! You have summoned me. Let's see about getting you what you need. ? Need technical help? => Post in the <#CHANNEL_ID> channel and other humans will assist you. ? Looking for the Code of Conduct? => Here it is: <https://opensource.facebook.com/code-of-conduct> ? Something wrong? => You can flag an admin with @admin I hope that resolves your issue! -- Helpbot "; const HELP_COMMAND: &str = "!help"; 

I declare both HELP_MESSAGE and HELP_COMMAND using the const keyword because they stay constant throughout the lifetime of the program and don’t change. With const, you must explicitly annotate the type. We use the &str because these are string slices.

In the third chunk, I’ll look at the following:

 rust struct Handler; #[async_trait] impl EventHandler for Handler { async fn message(&self, ctx: Context, msg: Message) { if msg.content == HELP_COMMAND { if let Err(why) = msg.channel_id.say(&ctx.http, HELP_MESSAGE).await { println!("Error sending message: {:?}", why); } } } async fn ready(&self, _: Context, ready: Ready) { println!("{} is connected!", ready.user.name); } } 

In this part of the program, I declare struct Handler. This doesn’t do much because all it does is declare the struct without any fields. In the next block, we use the #[async_trait] macro to tell the compiler that the struct below implements that trait like allowing us to use the async keyword with our functions and the .await method.

After that, the impl EventHandler for Handler tells the compiler, “My struct called Handler is going to look like an EventHandler.” Inside the struct are two functions: message and ready. The message function is where the main logic of our program happens. It takes in a message, checks the content to see if it matches the HELP_COMMAND and it does, it sends the HELP_MESSAGE to that channel using the same channel id. If there’s an error, it prints it.

The ready function logs a statement letting us know the handler for our Discord bot is ready using the bot’s name.

Last, the final chunk I have to walk through is:

 rust #[tokio::main] async fn main() { let token = env::var("DISCORD_TOKEN") .expect("Expected a token in the environment"); let mut client = Client::new(&token) .event_handler(Handler) .await .expect("Err creating client"); if let Err(why) = client.start().await { println!("Client error: {:?}", why); } } 

The first thing I see is the #[tokio::main] macro which is used because this is an asynchronous application. The next is the main function which is called when the program runs. The first thing it does is get the DISCORD_TOKEN environment variable. Then, it creates a new Serenity Client using the token for us to talk to the Discord API. Last, the program starts the client and handles the error if it has issues starting up.

And that’s all the logic for the program! Onto the next step.

Create a Discord Server

In order to test this out, I’ll need my own Discord Server. To create one, follow these steps:

  • Open the Discord application
  • On the left side, click the plus icon “Add a Server”
  • Click “Create a server”
  • Once you’ve filled everything out, click “Create”

Create Channel and Get Channel ID

Since I’m starting from scratch, I’ll need to create a new channel. I can do this by clicking the plus icon on the left next to “TEXT CHANNELS”. I’ll call mine “help”.

I need to get the channel ID. Discord makes it easy to expose this in the UI if you toggle on Developer Mode. To get here, go to Preferences > Appearance > Developer Mode.

To see the channel ID, right click on the channel and select “copy ID”.

Returning to the application, replace the “CHANNEL_ID” placeholder text with yours. After words, it should look something like `<#750828544917110936>`. Make sure you have the angled brackets and the “#” symbol.

Add a Role

I’ll also need to add a role. To do this, follow these steps:

  • In the top left, click on the server dropdown menu
  • Select “Server Settings”
  • Go to Roles on the left
  • Click the plus next to Roles in the middle
  • Type in the role name – I’m using the name “admin”
  • Click “Save changes”

To make yourself that role, right click on your Discord handle either in a message on the right sidebar, select Roles > admin.

Now that I have the role set up, someone can actually use the @admin to get my attention.

Create Discord Application

In order to create a Discord bot, I first need to create a Discord application. Follow these steps to do this:

After this is done, I can move on to the next step to create a bot.

Create Discord Bot and Install on Discord Server

The next step is to create a Discord Bot. Think of this as the profile for the bot. To create one, do the following:

  • On the left sidebar, click “Bot”
  • Click “Add Bot”
  • Feel free to change the name and the icon here
  • After you’re done, click “OAuth2” on the left sidebar
  • Under scopes, select “bot”
  • Scroll down to permissions and select “Send Messages” and “Read Message History”
  • Scroll up and click “copy” to copy the generated OAuth url
  • Paste it in a new tab in your browser
  • It will ask you which server you want to add it to. Note: you can only add bots to servers where you have the “Manage Server” permissions. Since we created our own, we do. Add it to the server you created earlier.
  • Click “Continue”
  • Confirm that you want to allow the bot to send messages and click “Authorize”

Great! Now the Discord bot is created.

Before I leave the Discord Developer Portal, I need one last thing: the Discord Bot auth token. To see it, follow these steps:

  • Click “Bot” on the left sidebar again
  • Next to the bot icon, look for the token
  • Click “copy”

I’m going to save this now because I’ll need it later when I run the application locally. Also, a friendly reminder to not commit this to git. You don’t want your auth token to get in the wrong hands!

Build Code

I am ready to build my project for testing locally. To this, I can run:

 shell cargo build 

If the compiler is happy with my code, it will output my code under /target/debug/ and contain an executable using the name key in the Cargo.toml. In my case, this is discord-help-bot.

Run Locally

It’s time to run the executable locally and see if my bot starts up as expected. I will run the command:

 shell DISCORD_TOKEN=<use your token here> ./target/debug/discord-help-bot 

I’ll replace “<use your token here>” with my token from earlier. This makes the token available as an environment variable to the application.

If it worked, you should see a message printed to the terminal saying “BotName is connected!” where “BotName” shows the name of your bot according to what you named it.

Test Bot on Discord Server

The moment I’ve been waiting for – testing my bot on my Discord server. With the bot still running from the previous step, I will open my Discord server where the bot is installed and send the message “!help” in the #general channel. And it works! I see the help message I wrote earlier posted to the channel almost immediately by my bot.

Woohoo! Mission accomplished.

Summary

Congratulations on making it through this project with me! I had a lot of fun and hope you did as well. I built a basic Discord bot with Rust and tested it on my Discord server by running it locally.

If you’d like to see a full-working version of this, you can check it out here on GitHub. If you want to make this better, I encourage you to open a pull request! You can ask questions there in an issue or open an issue if you find a bug. All contributions are welcome!

Next Steps

If you’d like to continue hacking on this project further, here are a few ideas:

  • Print a message to the console along with the username of the person who interacted with the bot
  • Add an avatar/icon to the bot
  • Add a second command to the bot
  • Deploy the bot

Let me know if you do this or something similar. We’d love to see what you build.

Resources for Learning More Rust

Looking for more ways to develop your Rust skills? Here are a few recommendations for continuing your learning:

Thanks for reading. Happy coding!

Special thanks to the maintainers of Serenity for the project examples and Will Harris’ article “How to Add a Bot to Discord” both of which made writing this tutorial possible.

To learn more about Facebook Open Source, visit our open source site, subscribe on Youtube, or follow us on Twitter and Facebook.

Facebook Developers

Continue Reading

FACEBOOK

Preparing our Partners for iOS 14: Actions for Partners and Mobile Web Advertisers

Published

on

Today, January 19, we are providing an update to our earlier guidance to prepare you for the changes created by Apple’s iOS 14 requirements. We’re launching new experiences in our advertising tools that will guide you through some of these changes, including some of the actions you will soon be able to take. While Apple has still not made it clear to the industry when they will enforce their AppTransparencyTracking prompt, we are taking advance steps to help prepare you and reduce disruption to your advertising and integrations across Facebook apps.

Please note if you use the Ads Insights API, there will be an immediate change to measurement beginning today. Please see details below.

RESOURCE CENTER

We will launch Resource Center, a dedicated tab in Ads Manager with a customized checklist of tasks to guide advertisers through specific actions to ensure your advertising is set up optimally and prepare for the upcoming impact of iOS 14 requirements.

The Resource Center will provide a list of relevant updates summarizing how iOS 14 requirements may impact your specific ad account. Most tasks and updates will link to Help Center articles to further support you through these changes.

EVENT MANAGEMENT

Beginning today, advertisers will be able to view all their events through new tabs in Events Manager, “Pixel/Conversions API” and “Aggregated Event Measurement.” The Aggregated Event Measurement tab will provide information on web events processed using Aggregated Event Measurement. Pixel/Conversions API tab Full data events includes all other web events that are not limited by Aggregated Event Measurement. Initially, the Aggregated Event Measurement tab will include events autoconfigured for the accounts domains based on an accounts ad activity.

Advertisers will be able to edit and prioritize the automatically configured events for a given domain in a new event configuration tool in Events Manager.

Below you will find previous guidance and additional details provided for Aggregated Event Measurement and Event Limits.

Aggregated Event Measurement: Facebook will introduce Aggregated Event Measurement to support measurement of web events from iOS 14 users once Apple requires the ATT prompt. It is designed to help you measure campaign performance in a way that is consistent with consumers’ decisions about their data.

Event Limits: You will be limited to the use of 8 conversion events per domain (i.e., 8 <pixel, event> or <custom conversion> per domain) for campaign optimization. You will not need to make changes to the pixel or your Conversions API implementation as event selection will be done in Events Manager.

  • Ahead of the prompt enforcement, advertisers will be able to view, edit and prioritize the 8 conversion events for a given domain.
  • Prior to enforcement, configuring the 8 conversion events for a domain will not impact optimization or reporting
  • At the time of enforcement, ad sets optimizing for a conversion event that is no longer available will be paused.
  • The 8 conversion events per domain will be ranked based on priority. If multiple events are completed by a user (i.e. “add to cart” and “purchase”) only the higher prioritized event will be reported.

Actions to take now:

Domain verification in Business Manager: We recommend that all advertisers verify their domain using the steps outlined in the Facebook Help Center. However, if a domain has pixel events owned by multiple Business Managers or ad accounts, one Business Manager is required to verify the domain in order to edit the event configuration.

Note: Domain Verification must be done at the effective top level domain plus one (eTLD+1 ). For example, for www.books.jasper.com, books.jasper.com and jasper.com the eTLD+1 domain is jasper.com.

Plan for 8 conversion events per domain: If you use more than 8 conversion events per domain for optimization prepare an action plan for how to operate with 8 conversion events per domain based on your business priorities. You will not need to make changes to the pixel or Conversions API implementation as event configuration will be done in Events Manager.

DELIVERY

VALUE OPTIMIZATION (VO)

  • VO will transition from Ads Manager to Events Manager and value set will need to be enabled.
  • If you have previously used VO, value sets will be automatically assigned based on historical data and turned on in Events Manager.
  • If you are eligible and use VO infrequently or have never used it, value sets must be configured manually.
  • You will be able to have a maximum of 8 value sets. Note: turning on value sets will automatically utilize 4 out of the 8 events allowed for campaign optimization and reporting for a given domain.
  • For optimal performance, events with value sets turned on should be placed in higher priority slots within the Events Manager.

Actions to take now:

DYNAMIC ADS

There are no specific changes for Dynamic Ads for Retargeting, but you may see performance and audience sizes decrease. We expect minimal impact to you using Dynamic Ads to reach Broad Audiences.

Actions to take now:

  • Verify product URL domains in the catalog feed and avoid the use of URLs redirecting users to a different domain.
  • Prepare to use only 1 pixel per catalog to optimize for prioritized conversion events across all catalog items.

MEASUREMENT

Ads Reporting (Ads Manager, Ads Reporting, Ads Insights API):

The changes outlined below will be going into effect January 19, 2021. Visit our business help center for more information.

  • We will be replacing the account level attribution window with a new attribution setting at the ad set level accessed during campaign creation and ensures that the conversions we measure are the same ones that inform campaign optimization, allowing for increased clarity when analyzing ad performance. This setting will also be available to query via the Ads Insights API. Please reference the recent Ads Insights API blog post for more information on two new fields related to attribution settings that can be used: use_unified_attribution_setting and attribution_setting.
  • To prepare our advertisers for upcoming changes resulting from Apple’s enforcement of their AppTrackingTransparency (ATT) prompt, beginning January 19, 2021, we will initially default to a 7-day click and 1-day view attribution setting. Due to limitations around view-through signal, the attribution setting for newly created campaigns after prompt enforcement will default to 7-day click instead of 7-day click and 1-day view.
  • Any active campaigns along with future campaigns will report and optimize on the new attribution setting. While these changes don’t impact ad delivery and we will not change the optimization window for any active campaigns, the new default attribution setting may result in a decrease in the number of reported conversions, especially for advertisers who have currently opted for reporting based on longer attribution windows like 28-day click and 1-day view.
  • Until Apple begins to enforce their App Tracking Transparency (ATT) prompt, you can continue to access data for all existing attribution windows (such as 28-day click, 28-day view, 7-day view) with the comparing windows feature. Once Apple enforces their ATT prompt, we will no longer support 28-day click, 28-day view and 7-day view windows and historical data for deprecated attribution windows will only be accessible via the Ads Insights API.
  • Statistical modeling will be used for certain attribution windows and/or metrics to account for less data availability from iOS 14 users. In-product annotation will communicate when a metric is modeled.
  • Certain attribution windows will have partial reporting and metrics will not include all events from iOS 14 users. In-product annotation will communicate when a metric is partial. This will launch in early 2021 upon Apple’s enforcement of their ATT prompt.
  • Delivery and action breakdowns will not be supported for offsite conversion events.
  • Offsite conversion events will be reported based on the time the conversions occur and not the time of ad impressions. As a result, you may notice small fluctuations in cost metrics, as cost per conversion will reflect spend over a given period divided by conversions that took place over the same period, whereas today, cost per conversion reflects spend over a given period divided by conversions driven by ad impressions that took place over the same period.

For automated rules: In early 2021, attribution window settings for existing and newly created automated rules will no longer be supported, and a default window of 7-day click-through for non-iOS conversions and the SKAdNetwork window for iOS conversions will be implemented.

Actions to take now Specify attribution window changes (deprecation of 28-day click-through, 28-day view-through, and 7-day view-through windows):

  • Leverage the Comparing Windows feature to see how conversions attributed to ads compare across different attribution windows. This allows you to better anticipate the impact to reported conversions as a result of upcoming attribution window changes.
  • Update any automated rules currently using a 28-day attribution window to prevent any unexpected adjustments in spend once the new 7-day click-through window default goes into effect.

DEVELOPER APIs (Marketing API, Ads Insights API, Targeting API)

Please review the most recent guidance published here.

For information on iOS 14 impact to App based developers please see our separate Developer blog post here.

For information on how to plan for changes to our Marketing & Ads Insights API, please see our blog post here.

Facebook Developers

Continue Reading

FACEBOOK

Preparing our Partners for iOS 14: Actions for App Advertisers and Developers

Published

on

Today, January 19, we are providing an update to our earlier guidance to prepare you for the changes created by Apple’s iOS 14 requirements. We’re launching new experiences in our advertising tools that will guide you through some of these changes, including actions you will soon be able to take. While Apple has still not made it clear to the industry when they will enforce their AppTransparencyTracking prompt, we are taking advance steps to help prepare you and reduce disruption to your advertising and integrations across Facebook apps. Below you will find the following updates:

  • New experiences in Events Manager, including a dedicated resource center
  • Updates to Ads Measurement
  • New Limited Login Mode for Facebook Login

Please note if you use the Marketing API or Ads Insights API please review this blog in detail for changes that will impact your campaigns. If you use the Ads Insights API there will be an immediate change to measurement beginning today.

As a review, advertisers using our Facebook SDK, Audience Network SDK, or and/or a Mobile Measurement Partner SDK need to be aware of the following version requirements:

FACEBOOK SDK

  • Advertisers who have already upgraded to Facebook SDK v8.1 or above will be able to configure their SKAdNetwork for App install ads via standard or customizable methods.
  • Advertisers who have not already upgraded should upgrade to Facebook SDK v9.0 which was released today.

AUDIENCE NETWORK SDK

  • All publishers will need to use Audience Network SDK v6.2.1 in order to monetize with iOS 14 users when Apple introduces their new requirements. Audience Network SDK v6.2.1 was released on January 11, 2021.

FOR ADVERTISERS WHO WORK WITH MOBILE MEASUREMENT PARTNERS (MMPs)

  • If you work with an MMP and do not use the Facebook SDK, check with your MMP for more information regarding their completion of integrating with Facebook to support SKAdNetwork. If completed, the MMP will be able to provide you with a unique URL to paste into Events Manager to be able to run AEO and VO campaigns.
  • If you work with an MMP and use the Facebook SDK:
    • When optimizing for Installs (MAI): App should have the latest version of the Facebook SDK (v8.1 or above) or equivalent version of MMP SDK. This requires MMPs to have completed integration with Facebook to support interoperability of SKAdNetwork. Please check with your respective MMP for more information on where they stand on completion of integration with Facebook to support MAI using SKAdNetwork.
    • For optimizing app events, value, or mobile app installs + events, you will need to select one method to set measurement goals/conversion bits:
      • If events are sent from Facebook SDK, use Events Manager to set configure conversion schema.
      • If events are sent from MMP, the MMP interface needs to be used to configure the conversion schema.

EVENTS MANAGER:

  • Starting January 19, 2021, ahead of Apple’s prompt enforcement, advertisers will be able to configure the SKAdNetwork conversion schema in Events Manager to measure and optimize for App Events (AEO), Value (VO), or App Installs + App Events (MAI+events).

APP INSTALL ADS:

  • Starting January 19, 2021, ahead of Apple’s prompt enforcement, we will begin rolling out the ability for advertisers to set up and test SKAdNetwork-based app install campaigns in Ads Manager and via API.
  • Starting January 19, 2021, advertisers will see a toggle at the campaign level to indicate that they want to run an app install campaign targeting iOS 14 users.

ADS MEASUREMENT

  • We will be replacing the account level attribution window with a new attribution setting accessible during campaign creation at the ad set level. For active and new ad sets, the setting will default to 7-day click and 1-day view, which may result in a decrease in the number of reported conversions. Due to limitations around view-through signal, the attribution setting for newly created campaigns after prompt enforcement will default to 7-day click instead of 7-day click and 1-day view. Today, you can prepare for attribution window changes by using the Comparing Windows feature in Ads Manager to see performance across all existing windows.

APP EVENTS API

  • If you use App Events API and do not use Facebook SDK to support SKAdNetwork API, confirm that you have properly implemented SKAdNetwork through Events Manager to access the SKAdNetwork configuration experience.
  • Once confirmed, you will be able to configure your conversion schema to run AEO and VO campaigns

RESOURCE CENTER

We are launching Resource Center, a dedicated tab in Ads Manager with a customized checklist of tasks to guide you through actions you can take to ensure your advertising is set up optimally and prepare for the upcoming impact of iOS 14 requirements. The Resource Center will provide a list of relevant updates summarizing how iOS 14 requirements may impact your specific ad account. Most tasks and updates will link to Help Center articles to further support you through these changes.

FACEBOOK LOGIN:

  • Facebook Login will now have a Limited Login mode that implements safeguards that allow advertisers to choose whether Facebook can use the fact that a person used Facebook to log into an advertiser’s iOS app to target advertising or measure advertising effectiveness. To implement this new version of Facebook Login, advertisers must update to version 9.0+ of the Facebook iOS SDK or Facebook SDK for Unity.
  • For more information on this new version of Facebook Login, including implementation documentation and FAQs, we encourage you to visit our Developers page.

Facebook Developers

Continue Reading

FACEBOOK

Introducing Facebook Platform SDK Version 9.0

Published

on

Today, we are releasing Facebook SDK version 9.0 and additional updates to our Facebook Platform SDKs. These updates include additional features, as well as required actions which may impact your application(s) integration with our platform. This post outlines these updates and the necessary steps developers need to take to avoid disruption where applicable.

Along with the release of Facebook SDK version 9.0, we are announcing the deprecation of all SDK versions below version 9.0. Beginning today, developers will need to begin migrating to version 9.0 to prevent usage of deprecated SDKs for their associated application(s).

Detailed information regarding the deprecation and sunset policy is provided below.

Release of Facebook Platform SDK Version 9.0 and Updates

Facebook Login Updates: A New Limited Data Mode

Facebook Login now offers a Limited Login mode that implements safeguards designed to prevent the fact that a person used Facebook to log into an iOS app from being used to target advertising or measure advertising effectiveness. To implement this new version of Facebook Login, Developers should update their Facebook iOS SDK or Facebook SDK for Unity to version 9.0+.

Learn more about the changes to Facebook Login here

Deprecation of Facebook Platform SDKs Below Version 9.0

Deprecations

Today, we will launch Facebook Platform SDK version 9.0 and begin the deprecation of all prior SDK versions. The deprecation will happen over a two year period (ending on January 19th, 2023) at the end of which all previous versions of the Facebook Platform SDK will be permanently sunset. At that point, no responses will be generated for any API calls made to previous versions (v8.2 and below) of the Facebook Platform SDK. Through this process, the Facebook Platform SDK versioning will align with the Graph API versioning commitment.

As we continue to improve our platform and products, we encourage all developers to adopt our newest version of the SDK. Version 9.0 includes improvements to crash rate prevention and tracking, error testing, memory usage and much more.

We are committed to our SDKs and will continue to make improvements that help developers work with our platform. When developers upgrade to version 9.0, this allows us to focus on the stability of supported SDK versions and improve the developer experience by mitigating potential privacy, stability, compatibility and security concerns that stem from older versions.

New Versioning Schedule for Facebook Platform SDK Major Releases

Moving forward, all new major versions will target annual releases with the goal of aligning the SDK version number to match the latest Graph API version. We will continue to release minor updates to enhance the functionality of our Facebook SDKs and we may release major versions off-cycle if needed.

End of Official Support for Facebook SDK for React Native

Today, Facebook will end official support for our React Native wrapper around the Facebook SDKs for Android and iOS. We are pleased by the community’s efforts that make the Facebook SDK for React Native a success. We believe the community is well equipped to address developer needs going forward. Note that our support for React Native continues and is not affected by this.

The current version of the project will move to Facebook Archive. We recommend the community fork this repo into a new project that can be continuously maintained by the community. We encourage the community to make any necessary changes that they believe will enhance the functionality of the SDK moving forward.

Removal of Auto Initialization of Read Library

Currently, the Facebook Platform SDKs automatically initializes on launch. We will be removing this auto-initialization feature beginning today.

If you currently rely on the Facebook Platform SDKs being automatically initialized in order to get information about your application’s usage, you will now need to initialize the SDKs prior to gathering AppEvents data. More information about initializing the SDKs can be found at – https://developers.facebook.com/docs/

Visit our Change Logs to review specific changes to your SDK and stay informed on planned improvements:

Version Deprecations:

Below are the versions of the Facebook Platform SDKs that are deprecated and associated dates:

  • January 19, 2021 – iOS SDK v8.2 and below
  • January 19, 2021 – Android SDK v8.2 and below
  • January 19, 2021 – Unity SDK v8.2 and below

Facebook Developers

Continue Reading

Trending