[MUSIC PLAYING]
CHARLOTTE LIANG: All right.
Welcome to building a SwiftUI app with Firebase.
Hello.
How's it going, everybody?
I hope you had a great Firebase Summit day at Firebase
in New York City.
I'm Charlotte Liang.
I am a software engineer on the Firebase team,
and my job is to make it easy for you building
mobile apps on Apple platforms.
Perhaps some of you have already started building a SwiftUI app.
I'm really curious to learn about your development
experiences with Firebase.
So after this talk, I'll be around the Firebase launch
by the end of the day.
So don't hesitate come talk to me.
I'm looking forward to see some of you there.
As you heard from the keynote, our mission
is to make it easy for you building mobile apps
and to grow your users.
Firebase is trying to remove the building block
so you can focus on what you're really good at, making
an app that your users love.
And we try to make it easy to integrate our SDKs
case across all Apple platforms, from tvOS, Mac OS, iPadOS,
to watchOS, so you can expand your business
across the whole Apple universe.
And thanks to the nature of SwiftUI,
it is possible to write the same code that can run
around different Apple devices.
Let's talk about Swift for a moment.
The language helps eliminate a lot
of errors which results in a much faster development cycle.
With a simple code base, you can now
write beautiful Apple applications
in a much shorter time.
As you start building a SwiftUI, we
learned that Apple has made some changes to the life cycles.
And you probably wonder, has anything changed with Firebase?
Well, this is what today's agenda is about.
First, we're going to talk about what
is the best way to initialize Firebase in the SwiftUI app.
Then we can talk about some of the new things
we added in the SDKs.
So now using Firebase in the SwiftUI app is much easier.
And lastly, we're going to take one
of the things we learned today in the real life examples
to show you how to run your app with confidence.
And to demonstrate all this, we're
going to write the Recipe app together.
This is a SwiftUI app that me and my colleague Peter Friese,
which is in the crowd here--
we build the app together for just about two weeks' time.
I have to give credit to Peter, who
is a phenomenal app developer who
built this beautiful app here.
And we use SwiftUI's navigation API
that connects to the Cloud--
Google's Cloud products-- to display
some delicious-looking recipes.
I hope you'll be hungry by the end of the talk
to try out the new features in your app as well.
But first, let's add Firebase to our app.
After you register your app, download the PLIST file.
You can now install the SDK directly
from your Xcode using the Swift Package manager.
And now it shows a SwiftUI version
of the code to show you how to initialize Firebase.
Let's take a closer look.
Now if you start with a SwiftUI lifecycle of application
the app now launch with a custom stripe that
conform to the app protocol.
However, we still recommend to initialize Firebase
in the app delegate through which
to retrieve the best results.
So you're going to use a UI application delegate adapter,
which is a property wrapper.
What it does is that it tells the SwiftUI to use your own app
delegate.
And then, inside your own app delegate,
you can now initialize Firebase just like you used to.
Now that we started with Firebase,
let's talk about what exactly the products that we
use to really quickly help the apps
run our development flow so we can enter this foodie market
in a much shorter time.
First, you want to get the user's login.
Your users are uploading their personal informations.
You want to make sure they're protected.
For this case, my grandma's secret recipe.
After your users login, you can now upload your recipe
information to the Cloud.
Here, we're using Cloud First Door
to server database and the Firebase storage
to serve the file storage.
For this case, it will upload the images of the recipe
to the Cloud so that later, when your users sign in
from a different device, they're able to retrieve
their informations as well.
And here, all our Cloud products are
built on Google Cloud, which will give you
the infinite scalabilities.
It means that when your app becomes viral,
like TikTok viral, when there's millions of user coming
into your server, you don't have to worry about your server get
crashed because Google Cloud just automatically take
care of that.
Amphibious authentication provides a variety
of security providers, from email passwords
to a list of social media login, including
Facebook, Google Sign-in, Twitter,
and sign in with Apple.
It also supports game center login for game developers.
After you log in with your users,
now it's time to set up the recipe
informations in the database.
Here, we're using Firestore, which
is a NoSQL real-time database.
It supports real-time read and write
between your app and the Cloud.
Here, I want to introduce to you this new property
wrapper called FirestoreQuery.
It makes it much easier for the user in SwiftUI.
It's really powerful, and it does two things.
The first thing is--
traditionally, when you fetching Firestore data,
it becomes like a data object.
And you still have to decode it so you
can access as the internal informations--
for this case, the recipe.
I'm trying to replay the videos.
Let's do it again.
Yeah.
Traditionally, you have to decode it.
But with this property wrapper, you
don't have to decode anymore.
And the second magic is a live sync with your UI.
So it lets you see on this demo--
anything you change on the Console, which is in the Cloud,
it automatically reflects on your app.
With Property Wrapper, you don't have
to do anything extra to tell UI, hey, it's time to refresh,
because Property Wrapper automatically
listen to the change of the parameter,
just like a state object.
And the best part is you only take one line
to implement this.
This is really convenient.
Here I want to call out-- this is a collaboration with one
of our open source contributors whose name is Flo.
This is what I love about having an open source developer
community, where Flo is able to detect the use case that
works for him.
And he worked with the Firebase team to launch this feature.
So now all the Firebase users can use this.
Now let's take a look at how we can set this up.
First, we're going to use Firestore Console to set up
the data.
So you want to start with a collection called Recipes.
And inside, it has a list of document.
Each document represent a recipe.
And on the third column, it shows all the fields
you want to set up, which is the property
of the recipe, like description, name,
image location, et cetera.
And now let's go to the SwiftUI app.
We're going to start writing a stack of recipes
with a list of variables that mapping to the data
that you set up on the Console.
Here, we'll conform to a codeable protocol.
Because we added codeable support,
now it's much easier to encode and decode
data between this recipe object and your Firestore data.
But with the property wrapper, it's even easier.
Now you just have to specify this one line of code,
and you don't have to handle decoding anymore.
So by creating a Firestore query,
by giving a collection path--
for this case, the recipes--
and they automatically translate whatever on the Console
to this array of recipe.
And now you can directly use it in the UI.
And here it integrate over all the elements in the recipes
and display the informations to this app.
And now that we realize the beauty
and the power of Property Wrapper,
we add in Remote Config as well.
Now you can define a property wrapper
that listen to a config key.
So if you need multiple config parameters in your UI app,
you can define multiple property wrappers.
And they automatically sync with your UI
whenever your config is activated.
Here, we want to emphasize that you still control when
the Remote Config is activated.
And this is another collaboration with one
of our open source contributor, whose name is Fumito.
As Firebase team is trying to modernize our SDKs,
developers like you, Flo, or Fumito,
are the driving force to shape the future of our SDKs.
Because you're building the app, you
have the first hand experiences, and you
live through your pain points.
And each of you have a different kind of business.
So we really encourage you to voice your feedback.
I use GitHub channel as the communication,
no matter is file feature requests, bug issues, or even
just send a pull request.
I'm really looking forward to seeing
more of these kind of collaborations coming up
in the future.
And here how we implement it.
We start with a RemoteConfigProperty
by providing a config key that you want listen to.
And here, there's a fallback value.
It is used when--
for example, if there's a config key
doesn't exist in the Remote Config system,
or maybe you put in a typo.
And then the value will return as a no.
But if you don't check in your UI code,
it will crash because Swift is a strict type language.
So to make it easy for you, you can now have a fallback value
to always tell this property wrapper to fall back
to a default value, even if such a value doesn't exist.
And now you can use this config value directly in your UI.
And you can also call on RemoteConfig to fetch
and activate when this view component become
visible to your app, so that the property wrapper always
listen to the latest activated config values.
And this is how it shows up in the app.
Now you can see the system image has changed from a circle shape
to a square shape.
Now let's take a look at how exactly
we can take advantage of these things we just learned
into real-life examples.
One of the greatest things of using Remote Config
is to launch your features in a more controlled fashion, right?
Perhaps you don't want your users
to always download new versions whenever
you launch a new feature.
And you also want to perhaps just roll out
to a small group of users before you
launch to the general public.
And while you're targeting a small group of users,
you might also monitor for crashes and performance.
And if you detect anything that is unexpected,
you can find the root cause, fix the issue,
and then launch it when you're confident.
And you can do this whole flow with Firebase products
without building in-house solution.
For our case, we want to launch a mini game,
but we weren't sure how the public receive it.
So we're thinking to launch it only to a specific audience.
We're thinking the vegans.
Here, we're using a analyticsScreen API
in the Google Analytics SDK.
What it does is it log as analyticsScreen view event
that you can specify the extra parameter.
For here, we type in the recipe type.
Because this is a implemented with a custom
view modifier internally, so it makes it more SwiftUI friendly.
You can now call this directly attached to any view
components in your SwiftUI.
So for here, we're attached to a RecipeDetailsView.
So what it does is any time a user tap into a recipe,
we're logging the device type-- recipe type.
So now we collect all this recipe
that our users are tap into, and now we
want to focus on the vegan.
So we're going to the analytics console
by creating an audience called Vegan lovers.
And it has a screen view event contains the parameter only
contains vegan.
And now you can enable this feature
by going to the Remote Config Console.
I created a condition with a matching audience in Google
Analytics with the Vegan lover.
And now you let the game run for a while.
You observe the data from Google Analytics and Crashlytics
dashboard, and it seems that you get a lot of retention
from analytics results and with the minimum crashes.
Now you're confident to roll out this feature.
And that's it.
If you're curious about more of these kind of customizations
or A/B testing, check out the app personalization feature
in Remote Config.
And don't forget to check out our repo in GitHub.
This is the best channel where you can contact me and my team
directly regarding talking about more of your business,
use case, or follow feature request.
I hope you enjoy the rest of your stay in New York City,
and thank you for listening in.
[APPLAUSE]
[MUSIC PLAYING]