All right. Good evening, everyone. My name is Eugene. I'm an engineer on the Messages team and I am super excited to be here tonight to speak with you about what's new in iMessage apps. Let's dive in here. We've got a couple of things on the agenda this evening. First one, we want to show off a little bit of what's new in the iMessage app area in iOS 11. Some of the stuff you saw in the keynote plus a little bit more.

After that, we're going to be introducing our awesome new Direct Send API. After that, my colleagues Jay and Stephen will be coming on stage to talk to you about our new Live Message Layouts. And finally, we'll be wrapping up the talk with a couple best practices tips and tricks for your iMessage apps.

So a lot of what we're talking about this year builds off the fundamentals that we established last year with iOS 10 and the introduction of the Messages framework. So if you need a refresher about the Messages framework or iMessage apps in general, we highly recommend watching our previous year session iMessage Apps and Stickers Part 2, which is available on the developer portal.

So give that a look if you'd like a refresher. So let's get into the cool stuff. What's new in the Messages app area. So as you all saw on Monday, we've updated a little bit of the Messages app UI for iOS 11. So I just saw on Monday when a user enters the conversation now we put all the app icons right there at the bottom of the screen which makes it really easy for users to launch applications right when entering a conversation.

As with iOS 10, your application still lives in kind of the keyboard area but we still have the application icons down at the bottom. Now users can scroll this application list left and right to quickly find the application they want to launch. We've also divided the strip into two different sections, as you can see up here. The left-hand side we have the users favorite section which is ordered by the user, and on the right-hand side we have the most recently used applications.

So users can also rearrange their applications out of the recent section and into their favorites for easy use and for accessibility right when they enter the conversation. So we think this is a great way for users to enter a conversation, tap the app they want and be able to use your application immediately.

One really cool change their making this year revolves around how we handle app installations. So now in iOS 11 if you download an application from the iMessage app store or you download from our primary app store we will enable your application by default and the Messages app drawer. In addition --

So in addition, we will order your applications icon to the very first item in the most recently used apps so users can find it easily and launch the application immediately. So there's just a couple changes that we have for the Messages app UI. A lot of it you guys have today. Next up we have our brand new Direct Send API. We're super excited to share this with all of you.

So in iOS 10, the only way to share content out of your Messages app would be to call an insert API which puts your message into the Messages entry view. And so while this works great for many applications, for some user experiences like this game when the users say makes the game move next logical step would probably be the message actually being sent and inserting that message into the entry view kind of adds an extra tap. So we thought this year how can we make this easier, how can we make this a better user experience? So in iOS 11 you can send any content that you would have normally inserted into the Messages entry view directly from your application.

So how does this work? In iOS 10 we introduced MS conversation which defined the following insert APIs. Insert message ,insert sticker, insertText, and insertAttachment which supports any of our standard Messages attachment types. In iOS 11 we have a very simple analogist API called Send Message, Send Sticker, Send Text, and Send Attachment. So calling into anyone of these will bypass the Messages entry view and insert -- send you a message immediately in the conversation. So really quick and easy API.

So you may ask which API -- which user experience is best for my application, both Insert Draft and Send Message APIs are first party citizens in iOS 11, and it's up to you to decide which one is best for your application. So the Insert Draft API is still the recommended API for most applications as it allows for richer composition experience.

For example, user can insert a message and then say append a comment to the end of the message, or send with a screen effect or a full screen moment. So it's a really great way to enrich the content that you would already be sending. In addition, it gives the user an opportunity to verify the content that will be sent which is extremely important.

On the other hand, Direct Send API offers a superfast quick and easy user experience that's great for, say, games and stuff like we saw above. So it's great for any application where the insert flow has tapping the entry view button feel like an extra step that you really don't need.

However, when using this API it is extremely important to maintain user trust in your application. So it's important to very clearly indicate to the user exactly what content is going to be sent and also to clearly denote to the user exactly what user interaction or interface element within your application will trigger send. So to help promote a great user experience with a direct send API Messages enforces a couple requirements on this APIs use.

Firstly, your application must be the visible Messages app on screen. As you may know, your Messages app extension may be running in the background within Messages and not actually be the current foreground application. So first requirement is your application must be visible. In addition, our target user experience for this is to have the user tap the screen or interact with your application and then to have a send be triggered. So to facilitate this, Messages will detect user interaction on your app and allow for a direct send API call to be made upon detection of that user interaction.

Subsequent direct send calls will fail until we detect another user interaction, so kind of keeping with one-to-one the user press something on your screen and a send is allowed. So to help you as developers understand what's happening with the send API, we are introducing two new air codes, MSMessage air codes. We have sendwithoutRecentInteraction and sendwhileNotVisible. So as always, use great air handling so your application can catch these dates.

And that's Direct Send. It's very simple. I think it's going to be a great user experience for the apps where it makes sense for. Definitely consider whether Insert Draft or Send makes the most sense for your application, and we're very excited to see what you-guys can build with it. All right. So next I'd like to invite Stephen up stage to introduce you to Live Message Layouts.

Hi everyone. So today I'm excited to return to the stage to you to talk to you about Live Message Layouts. Now in iOS 10 we introduced Messages framework and the ability for you to bring your app experience right into Messages. When you would build your iMessage app, your app could be shown here in the keyboard area in Messages or in a full screen presentation, and these would be the compact and expanded presentation styles that you could use.

And then when you would send the message your app would use a template driven -- or we would use a template driven layout approach for your app message. Now this template layout had customization objects or options such as image and the text properties here, and it allowed you to provide some pretty good rich app messages, however, it's still limited by what the template provides. In iOS 11, I'm excited to announce that you can now completely customize what your app messages look like using these liveLayouts.

So this is actually a view provided by the application itself here in the Messages transcript. The app could also drive a view as a draft message, and in fact can provide custom views to represent many messages simultaneously in the transcript. Of course we support the world where maybe your app isn't the only one on screen, but really we only care about your app. We're here to talk to you about that today.

So I'd like to give you a quick demo of what that looks like in action. So here I have a simple iMessage app that I've built called Event Countdown, and this is just a simple list of upcoming events that I'm excited about and want to share with my friends via Messages.

So for example, if I tap the batch here you'll see a completely custom message is presented here as a draft message. It's live updating, it has this great countdown that's building anticipation for the upcoming event. And when I send it, that same view is put in the transcript that would be seen on the other side. In fact, if we go into the recipient side or to see what a recipient might have sent or the other side might have sent, here I have an invitation from Eugene.

This is a similar app message, but my iMessage app has chosen to render a completely different view on the receiver side. I'm representing an unaccepted invitation at this point. If I tap this app message bubble here, I mark the event as accepted and now it switches to that live countdown mode.

I was able to do all that without even having to launch my iMessage app in this context. Now here in the top right I have a little infoButton. Not all experiences are appropriate to try to shove into an app message. By tapping this infoButton, I can actually request that my app be presented in a different presentation style to see more information about my event. So I hope you can see that here with Live Message Layouts you can build a really rich user experience, complete with interactions and live updating content, and it's really easy to do.

So let's talk about how this works. So here when the iMessage app is being shown in the compact presentation style, we have instantiated an instance of the MSMessages app view controller subclass and configured it in the compact presentation style. When an app message with a liveLayout is shown on screen, we'll instantiate another instance of that same base class and configure it with a transcript presentation style.

In fact, for each message displayed in the transcript we will instantiate a new instance of this class configured again in that transcript presentation style. There is a strict one-to-one relationship between these instances and an app message that they represent on screen. So that's a quick overview of Live Message Layouts. Now to walk you through more of the API and how to get started, I'd like to invite Jay on stage.

Well thanks, Stephen, for the introduction. My name is Jay and I'm here to introduce to you some of the new APIs we've added for Live Message Layout. So let's get started. As some of you may be familiar, you were able to customize your app bubble using MSMessageLayout. With existing MSMessage template layout you're only able to customize a limited set of appearances such as captions and images. In iOS 11, to support a fully customizable bubble we're adding a new subclass MSMessageLiveLayout. So let's take look at this real quick.

As you can see, there aren't that many things to fill out as you have to do for the template layout. Well that's because now you have the opportunity to fully express how these app bubbles should look like. Though you may have noticed that there is one property called Alternate Layout and so what is this? Now there will be a few instances where your app bubble won't be supported by the receiving devices.

In cases such as they don't have your extension installed or they're just running on older Apple iOS versions, iOS, macOS, or watchOS. So in these scenarios, they'll be seeing this template layout as a fallback representation by if they can actually support their extension then they'll be seeing the bubble on the right.

So how do we use this API? It's very similar to how you did in iOS 10. First, create the template layout. And with a template layout you're going to create liveLayout. And with a liveLayout say it's a message and send. So really similar to what we did in iOS 10.

So that was it for the MSMessageLiveLayout. We have some new additions in MSMessagesAppViewController. Now as some of you may be familiar, this was the principle class through extension point. So by configuring this view controller you're able to customize the appearance in your app in the keyboard area, in the compact mode.

So the bubbles in the transcript are also backed by View Controller, and in fact they have the same class. Okay. So what does this mean? That means that this view right here in the bottom and that view on the top are coming from the same class. So to distinguish these two cases we've added a new presentation style transcript.

So when it comes time to configuring these view controllers, you can use a combination of presentationStyle and selectedMessage to determine what you want to show in your view controller. And one really simple pattern you can follow is something along the line of path factory pattern where you can return appropriate child view controller depending on the state of these properties. So you're going to have one for transcript and one for compact. So if you're already following a similar pattern and code it will look something like this.

So for the compact case we have a helper method presentSummaryViewController and this helper method you will create the right child view controller and configure a view controller appropriately. For the case of expanded, you'll have another helper method presentDetailViewController and will do something very similar to what you did for the compact case. So to handle another case for the transcript, we can just have another helper method something along the line of presentTranscriptViewController.

So that was it for the presentation style, but we actually have one more thing to go over before you get this live bubble started. And that is sizing. Now, the view controllers are intended to use for transcript will conform to the new protocol called MSMessagesAppTranscript Presentation. It has one method called ContentSizeThatFits. In this function, return a size that best represents your view in the transcript. So to illustrate, here's an example. Now, we want our size to always fit all the sub views nicely without getting clipped or any extras base or anything like that.

For this particular example, we have the map view timer and the button. And we decided that we'd only care about the size of the map view or the timer changing, but we want the button to adjust accordingly based on the system font. So let's give it a static number, 217, for the map view and the timer, and then the line hide right here will be the size of the button that takes the system font into consideration. So by adding these two numbers we'll get the right size or the right height that encompasses all the sub views in our view.

So with this configuration, I think the height is about 235 points. Now keep in mind that this function will be called again when there is a change in transcript size, change in locale or change in system font. In these events, these functions will be called again for a new size. So here's an example of change in system font. As you can see, the fonts are slightly bigger.

In this case, we just said that we didn't care about the map view or the timer growing or shrinking so let's look at the same 217. But because we're using a dynamic font for the button, it automatically picked up a size. And with this configuration, you can appropriately return 244. We'll take this value and resize your view accordingly.

So that was a lot of talking. To summarize everything I just talked about I'd like to show a quick code demo. And I know a lot of you-guys are very eager to be at the bash so we'll work on a sample app that shows you a countdown timer to the bash.

Okay. Cool. So we have our nice X Code here and this is the device I have on the table right now. So in this demo I'd like to show how you can extend an existing iMessage app and start using our LiveMessageLayout. So if you remain on iMessage app it will look something like this.

So you have an app in the compact mode and when you're trying to send it will show a template layout. So how about we start using LiveLayout instead templateLayout as showing on the shelf? So let's get to the code. And here I'm in MSMessagesAppViewController sub class. And somewhere in this code were probably creating a template layout. So let's look for that.

Found it. So we have this helper function called sendMessage and it seems like we are creating the message, configuring it, create a templateLayout and then set that layout to the message and we're inserting it into the conversation. So I think this is a great place to start using our liveLayout objects. So here I'm going to go ahead and create a liveLayout. There's the template layout. And then we can set that as Messages layout property.

And let's see -- okay. So with this change you should be seeing a liveLayout. And this is definitely a liveLayout, but this doesn't look right. This actually looks exactly like what you just saw in the compact mode. So what went wrong? Let's get back to the code and let's try to find out where we're actually creating this table view controller that you see in the compact mode. And a good place to check that right now, I'm going to go into willBecomeActive, okay, I see updatePresentation. See what this does. Oh and I see presentViewController.

Now this seems like a problem right here. For anything that is not expanded we're always creating a table view controller and, as mentioned before, the same view controller class is used for both transcript, compact and expanded so we need to handle case for transcript which is not supporting this code right now.

I'm going to leave this code as it is now. I'm going to create a new function so they can start handling this case. So I have this presentTranscriptView and I have this [inaudible], I have to know if it's for me or if it's pending because I want to decide if I need to show the invitation button or not.

So now that I have this transcriptView I can go ahead and add it to a sub view with the Auto Layout Magic. Then I have to call this method somewhere so I'm going to go back to updatePresentation. It's right here. And here I can start configuring this viewController for transcript.

TranscriptView, event, conversation, and for everything else I'm just going to do what we've always been doing for compact and expanded. Cool. So let's see how this change will look like. So with this change you should always see the event detail in app bubble. So it's succeeded. So I'm going back to our device.

Right. Shut up. Cool. So I see something now, but it is kind of big and I don't know where the map view went but we're getting there. As you can see there's like an awkward wide blue space. It is definitely bigger than I expected. So what went wrong is seems like we didn't implement content size that fits the last part of this liveLayout adoption. So I'm going to go ahead and implement that real quick. And then from the demo, from the slides, you wanted to height to be about 217, and then for the title button you want it to by dynamic and it was fetched from transcriptView.titleFont and then lineHeight.

We want our width to be the maximum width possible which is the path and size parameter so we can just return the exact value. And then for the height, we can add these two values. And this would be a good size to return two messages. So let's see how that looks like.

Okay. So it's loaded. Much better. This is what we saw in the demo. Nice little size with the events and the timer ticking. We only have like an hour and twenty minutes until bash, so hang in there. So I'm going to send this. There we go. It's in a transcript live and the timer's ticking. So this was a quick demo to how to adopt Live Message Layout. So let's talk more about some of the interactions in viewControlLifecycle. I would actually like to bring Stephen back on stage to talk more about it.

Thank you Jay. All right. So, now we've seen a little bit of an introduction of what it looks like to use the new API, to use Live Message Layouts in your iMessage app. If you'll think back to the demo I did at the beginning of the session, we had some interactive elements to our iMessage app bubbles. And so I'd actually like to return to Xcode now to do just that. So return to my device here. We're going to go back to Xcode just where we left off. And I'm going to get my device ready for this demo.

Excellent. Okay. So the first thing we want to do is here we have this EventCountdownTranscriptView and that's the view that gets imbedded in that app message in the transcript and so we want to configure that with some inner activity. So I'm going to go ahead and jump into that class and you'll see that I have a number of properties here that are configured, and here in setupSubviews I have a tap adjuster recognizer that's set up so that when the user taps my view this method user to tap gets called. If I jump to the implementation, of course the implementation right now is empty and it's ready for us to add something.

So the inner activity we'll want to add first is specifically when the app message represents an unaccepted invitation. So if the event is not for me or if the app message is not for me and it's not been accepted then we want to have that interactive element to it. So the first thing we'll do is say if is not accepted and it's not from me then we'll change our view flag to have is accepted equals true.

And the other thing I want to do is update the model that I have here. Normally I would use correct MVC and also update maybe my service to indicate that the event has been updated, but for the purposes of this demo I'm just going to mark this in the defaults.

Great. So I've updated some state now I need to update my view state, so I'll just use a quick animation block here to call into my updated view state and then I'll trigger a layout pass. Now this updateViewState, it just looks at the different flags and properties on my view and configures the view correctly. So wait for our demo device to come back up and I'll show you what that looks like in practice.

Great. So here we have our unaccepted invitation being shown in our demo and it's ready for us to test out that interaction that we just added. So if you see that when I tap that message that state gets updated and we see that live countdown, and you can tell that I have very little time left so I better keep going.

Now the one thing that we're missing here is that nice infoButton on the top right that really gave me that rich detail about the event that I don't want to necessarily put here in my app message. So if I go back to the code here you'll see that this infoButton is just waiting to be implemented. But before we do that, we need to add the infoButton to the view hierarchy. So here in setupSubViews you can see that I have this infoButton that's already been configured, including with that target action I just need to add it as a sub view.

I also want to add some constraints like it's laid out properly. And then we'll go and jump into the implementation for infoButtonTapped and call into our delegate. Now the delegate of this view is our app view controller, and the app view controller is the object that knows how to change presentation styles, so I need to call out to it.

You'll see that this method hasn't been implemented yet in my delegate. So we're going to jump over to that delegate really quick. Here is a delegate protocol declaration where we see that method hasn't been defined. So go ahead and add it. And then we'll jump over to where this protocol is implemented and add our new method that we just added.

Now all we need to do is request that new presentation style and that's it. When I do that, the app view controller requests that new presentation style and Messages will instantiate the new view controller in that expanded presentation. So this is the same thing that was just implemented here in the code. We have the infoButton in the top right, and when you tap it we get that nice expanded presentation with the additional content. So that's it. We have a completed demo that's showing you -- thank you.

So with the completed demo you see that we can add completely custom layouts that really add some richness to that experience in the transcript, including inner activity and live updating content. So when we think about interaction with these live message layouts, we really want to keep it simple. Stick to simple button taps and tap gestures, and let me use the scroll views.

This app message is being imbedded in a fairly complicated UI, the Messages transcript, and the user's used to interactions like vertically scrolling the transcript, horizontally scrolling the transcript, and other gestures that take place. And so if you add too many complicated things here it can be disorienting to the user. The other thing to remember is that there's no keyboard input allowed for these app message views, and so if you want keyboard input you should request an expanded presentation style where your app can use the keyboard.

Now these views are really light weight for a reason. When you think about their lifecycle, they're only instantiated when the user comes into the conversation to look at it. As soon as the user leaves the conversation or leaves the app, your iMessage app will be torn down. So it's not an appropriate place to put something like a 3D game engine.

If you do want to do that, you should request that expanded presentation style for the user to take part in your extended interaction. Now I want to cover this again because I think this is important. When requesting the expanded presentation style, your transcript app view controller is not reconfigured with new presentation style -- it's left in place in the transcript.

If no view controller exist in the compact or expanded presentation style, Messages will instantiate a new object, configure it accordingly, and then add it and show it here. If one does exist then it will reconfigure it to the new presentation style. And this is specifically if it already has one that is compact or expanded.

It will then change the selected message on that view controller and you will get the didn't select message callback on that view controller. Now the transcript app view controller that's left in place as is or the static selected message because it always represents that message in the transcript.

Now when we talk about lifecycle a little more of your iMessage app, in iOS 10 these methods on MSMessagesAppViewController applied specifically to your extension lifecycle because there was only one instance of the view controller created and it was closely coupled with the lifecycle of your iMessage app, so you could rely on it for extension lifecycle notification.

However, in iOS 11, we can instantiate many instances of your principle class. So these methods really pertain more to the view controller lifecycle and you need to think of it from that perspective. If you do need to pay attention to extension lifecycle events of your iMessage app, you should observe the NS extension related notifications.

Now in a particular instance of your transcript app view controller is created, the lifecycle methods proceed like this. First, we'll initialize the view controller and call viewDidLoad. Then we'll call willBecomeActive and didBecomeActive with conversation as part of the Messages API contract. Then the view appearance methods will be called as your view controller is inserted into the view hierarchy for display. Lastly, contentSizeThatFits will be called. Now when willBecomeActive and didBecomeActive with conversation are called, you have all the information you need to correctly configure your view controller by looking at that presentation style and selected message on the view controller.

Now when thinking about contentSizeThatFits getting called last, this is because it may be called multiple times. Think about the Messages application on an iPad in split view mode. As the user changes the size of the Messages app, the metrics of the Messages application, and therefore the transcript, change. We'll then call into your contentSizeThatFits method with an updated size or maximum size, and you should update your app size accordingly.

It can also be, of course, updated for dynamic text size changes and locale changes. The last thing I want to cover is pending messages. Now remember, your view controller can be configured to represent app messages in a transcript presentation style both for an unsent message and the message that has been sent in the transcript.

Now most of the time you should keep the same application view in both states because the user is really previewing the content that's going to be sent here. But if you do need to differentiate between the two, you can check the isPending flag which is a new property on MSMessage that will let you know the difference between these two states.

So that's all we have for you today to introduce Live Message Layouts. Remember, this is interactive iMessage apps in the transcript, which I think is incredibly cool and I can't wait to see what you build with it. We're using the same MSMessage app view controller sub class, and the new layout, the MSMessagesLiveLayout with a new presentation style for you to use as a tool to build these rich new experiences. I'm really looking forward to what you build with this and I think you're going to come up with things that we haven't even thought of yet. And with that, I'd like to bring up Eugene to introduce some best practices when using the Messages framework.

All right. Thank you, Stephen. Live Message Layouts, super exciting. So we want to wrap up our talk today with just a couple best practices tips and tricks for your iMessage apps just to give your apps that little extra shine and polish that we think will make them look really great. So, we have a couple of tips for you guys today.

Let's get into it. So the first thing we'd like to talk about is the iMessage app area insets. So this is the area at the bottom of the screen underneath the app strip as well as at the bottom of the screen in expanded mode. So similar to like navigation controllers, Messages UI can include the area displayed by your application so you can have that nice blurred effect when scrolling scroll views. So to determine your app area insets, you can look at the UIViewController top and bottom layout guides, or new in iOS 11 check out UIViewsafeAreaInsets. These will define all the areas of your application's view that are un occluded by Messages UI.

Of course, you can always use Autolayout to add constraints to the UIViewController's top and bottom layout guides. So for applications linked on iOS 10, we will continue to use old legacy insets. But a great way to keep up with the change in UI Messages and have your application adapt appropriately is to properly adopt either the UIViewsafeAreaInsets or UIViewController top and bottom layout guides.

Next up we have message summary text. So iOS 10 introduced MSMessage and a property on it called summaryText. In iOS 10, summaryText was used for Messages with an MS Session attached to it, so kind of session based messaging and we'd insert a very small succinct summary inline the transcript of that message. In iOS 11, we are expanding the use of the summaryText property to all MSMessages sent.

So where do you see the summaryText? MSMessage summaryText will now be used in the conversation list preview as well as places like notification center so you can give context to your application's message notifications. So this is a really great way for users at a quick glance to see the content that you send in your app message. So iOS 11 summaryText and every single one here, MSMessages.

Next up we have stickers. So the introduction of sticker packs in iOS 10 we're seeing tons of them released. I absolutely love them, download new ones every week. Keep up the awesome work on the sticker packs. We love it. We do want to give a couple tips about making your sticker packs faster and send quicker.

Overall, sticker pack performance is a function of your sticker's file size. This function of the sticker's file size is a function of your sticker's pixel size as well as its frame rate. A really great resource for you to look at is the Messages Human Interface Guidelines which is available in the developer portal which will tell you the target sticker sizes for either the small, medium or large stickers that we support.

In addition, consider the frame rate of your sticker. Stickers with higher frame rates or longer loop times have a higher memory overhead and will negatively impact the performance of your sticker application as well as negatively impact send times. So for quick fast sending stickers and quick launching sticker apps, make sure your stickers are sized correctly and either use short loops or lower frame rates. So looking forward to seeing all the new sticker packs you guys make in iOS 11 as well.

And last up on our list is MFMessageComposeViewController. MSMessageComposeViewController is the Messages share sheet that can be invoked from your parent application. So in iOS 10 we introduced a new property on the share sheet called Message, which predictably takes an MSMessage instance. So if you already have an iMessage app, your parent companion app can actually send the same application balloons either a template layout or a live Layout that you can send in the Messages app itself.

So you get a very nice consistent sharing experience between your parent application and your iMessage app. App balloons that are received, can either then be opened within your iMessage app or can bounce the user out to their parent application via the open URL command. So definitely take a look at Message property on MFMessageComposeViewController.

And with that we've wrapped up our tips! Just a couple things for everyone to keep in mind. Look at your layout margins. Set summaryText on all MSMessages in iOS 11. Consider sticker sizes and frame rate for faster sticker packs. And also keep on making awesome stickers. And finally, you can now send app balloons from MFMessageComposeViewController. So certainly check that out for consistent user experience.

So what did we learn today? We went over a couple new things with MSMessages app UI. We saw the direct send API for an awesome new setting experience in your iMessage apps. Stephen and Jay led you through Live Message Layouts. I cannot wait to see what all of you build with that. And finally, a couple best practices tips and tricks.

If you'd like more information check out our session webpage right here. In addition, we also have a couple related sessions happening tomorrow. We have, at 10:00 a.m. in this hall, Introducing Business Chat, which I know all of you are probably really excited to hear about. In addition, we are very lucky this year to have one of our Messages HI designers who will be doing a design short tomorrow at 11:00 a.m. in the Executive Ballroom. Thank you for being here tonight and enjoy the bash! Thank you!