SwiftUI On All Devices

All right, thank you. Welcome. It's so great to see you all here and it's great to see so many people excited about SwiftUI. My name is Jeff Nadeau. I work on macOS frameworks and I'll be joined in a little bit by my colleagues Ada Turner and Meghna Sapre . Now we hope you've had the chance to learn about SwiftUI all throughout the week but if you need a summary, here it is. SwiftUI is the shortest path to building great apps on every device. And what we're here to focus on today is the 'every' in every device.

Now when we think about building applications for all of our Apple devices, these are the technologies that we think about. We use AppKit on the Mac. UIKit on iPhone and iPad, TVUIKit which is built on UIKit for Apple TV, and then on the watch we use WatchKit. These UI frameworks were designed around the strengths and capabilities of the respective devices. And so naturally there are some differences between them. And historically we haven't been able to take code written for one and move it over to another device without modification. But for the first time ever, we're introducing a UI framework that you can use on any of these devices. That's unprecedented and it's a big opportunity for you as app developers. But these devices are so different so how is it that we've built one UI framework that works on all of them? Well, SwiftUI was built from the ground up to accommodate many different UI paradigms. So whether you're using a keyboard and mouse, or a multi touch display, or the Siri remote, or even the digital crown on your Apple Watch, or assistive technologies like voiceover and switch control, SwiftUI was designed to accommodate all of these. And it has great support for our platform design conventions out of the box. We've brought together experts from every platform to make sure that when you use an element in SwiftUI on a given device that it looks and feels right at home. The result is a system where your knowledge is transferrable across devices. Everything fits together in the same way. So even when you're working with-- you're building support for some specific piece of hardware, say the Touch Bar on a MacBook Pro or the digital crown on an Apple Watch, or the Siri remote, the tools for doing this have a kind of consistency and familiarity that makes them really easy to pick up. Now, on top of just general design philosophy we also have a number of elements that are in common across-- SwiftUI across all devices. So for example, every platform has the idea of a toggle control. You've got some kind of piece of Boolean state that you want to be able to toggle and you have a label describing what you're toggling. And so even though our expression of this control could be very different on each device-- it might be a switch or a check box or a toggle button-- we can offer a single API that describes this on any device.

SwiftUI also has a common layout system. So when you're using a stack or a spacer or a padding, these tools work the same on every device. And what that means is that once you've learned to lay out an application on one device, you've learned how to lay out an application on any. We also have some more advanced controls like picker for example. Picker picks one element from a list of many and this control expresses itself in a variety of ways. So on MacOS it might be a pop-up button. On iOS or WatchOS it might be this wheel style picker. And given how different they are, you might not use them completely interchangeably from device to device. But the one thing that's constant is the relationship to your data. When you've adapted your model to work with one of these controls, you can easily transplant that from device to device. Now we don't have time to go over all of the different elements available in SwiftUI so you should check out the SwiftUI essentials talk for more information about that. Now, does that mean that I can really use SwiftUI to design a single app that's going to work great across all these devices? Is it going to let me write code to adapt seamlessly from a 4k television all the way down to a 44 millimeter watch face? Well of course not.

You know, there's no such thing as a one size fits all app. If we decided to just stick to the common denominator between all these devices, we'd be missing out on the things that make each device great. And there's no magic abstraction that can do that for you. You have to decide what the right design is for your app on each device. Now what SwiftUI can help you with is you can share your skill set and toolset that you've learned building from one device across many others.

And there are definitely going to be opportunities to share code along the way, just where it makes sense. And so we think it's kind of important to think about this less as write once and run anywhere and more like learn once and apply anywhere. Now to put these principles into practice, we need to build an app.

But really it's more like we've built four apps, one for each of our platforms.

And the app that we've built is called Landmarks. The purpose of Landmarks is to research and visit landmarks throughout the country. We definitely want to look at photos and get visitor information about these places. I think it would be great to get maps and directions to a destination.

And if we're planning a trip, marking favorites is a great idea. And when we think about bringing this app to all of our devices, we can tell ourselves a story about how we think the app belongs and fits on each one.

So for example, on AppleTV it's a natural place to couch surf for places to go. And because it's a big screen experience, that might be something that you do with family or friends or roommates. And we definitely want to mark favorites to research later. And the Mac would be a great place to do that research. It's a good place to compare and contrast info, maybe have some more advanced sorting and filtering controls, and really read up on all the details. On iPhone, we obviously want quick information about each landmark but since it's so common to navigate with our phones, we should also be able to get driving directions as well.

And iPhone of course is also a phone so if we need to place a phone call to call ahead, it's a natural place to do it. Finally on Apple Watch, that's where we want to get at-a-glance info about what's most important to us. And it's the perfect platform to receive important notifications when anything changes. Now the cool thing is that the iOS version of this application is already available to you today. It's part of a new documentation series to teach you how to view SwiftUI. You start from the very beginning and you can build this application up step by step. It's already available for download today and it's a great way to learn how to build an iOS app. And so as a result, we're going to be focusing more today on bringing this application to AppleTV, Mac, and Apple Watch. And to start us off on that journey, I'd like to hand it over to my colleague Ada Turner to talk to us about SwiftUI on AppleTV. Thanks Jeff. Hi. My name is Ada Turner and I'm really excited to talk to you today about SwiftUI for AppleTV.

Designing apps for the TV means designing for the biggest, boldest screen in the entire home and that comes with some challenges and considerations unique to AppleTV. Luckily, SwiftUI allows you to create great experiences that are optimized for the living room using the same skill set and toolset that you've learned when developing for Apple's other devices.

Today I'd like to focus on three key points for designing great experience on the biggest, boldest screen. TVOS is a 10 foot experience, not a mobile experience. People interact with your apps using the Siri remote not a touch screen or a mouse and keyboard. And it is especially important for TVOS apps to have streamlined navigation so people can jump right into your app's content. Now, what is a 10 foot experience? It's this, not this.

Your apps should emphasize rich and immersive experiences like beautiful imagery or video as opposed to accomplishing tasks like taking notes or getting directions.

When sharing SwiftUI code with your AppleTV app from other devices, carefully consider which experiences make the most sense when displayed on a large screen viewed from across the room with longer periods of use and potentially more than one viewer at a time. Let's take a look at which features we decided to support on Landmarks for TV and which ones we left on the cutting room floor.

The easiest choice to make was to include the gorgeous photographs of the landmarks which will look great on the big screen. Gathering in the living room to pick out favorites together is one of the key features of our TVOS app so we can't forget that.

And we'll also include basic tourism information such as hours of information and cost so that people can make informed decisions about where they want to visit as they browse.

Now, although our data supports it, we decided that we're not going to include lengthy details about the history of each landmark as content like that really isn't appropriate on the TV. We also decided not to include advanced sorting and filtering as features like that make a lot more sense on the Mac or iPad. And finally, although our data includes geographical coordinates, we decided not to implement geofenced notifications as traveling with an actively running TVOS app is a very rare use case. Next, let's talk about focus. People interact with TVOS apps using the Siri remote which is optimized for effortlessly swiping through your app's interface. It is critical that your entire apps interface be intuitively navigable using focus. Luckily, many of SwiftUI's standard interface elements such as lists, buttons, text fields, and toggles, all work seamlessly on TVOS, adopting different appearances and behaviors that look great on the big screen and interact using focus.

If you implement your own custom controls, SwiftUI provides a focusable view modifier that allows you to control whether or not your view can become focused and execute a block of code when your view gains or loses focus. You can also use the on play pause command and on exit command view modifiers to respond to people pressing the play pause and menu buttons on the Siri remote when your view is focused.

Thank you. Finally, let's dive into some best navigation practices on TVOS.

Long, vertically scrolling tables of content with deeply nested levels of navigation work great on the Mac or iPhone, but on TVOS people want an effortless browsing experience that emphasizes content. Using SwiftUI's easily composable stack views, list views, and scroll views, we can create an interface like this on Landmarks for a TV with vertical stacks of horizontally scrolling shelves that really take advantage of the widescreen display on the TV and allow people to browse between different categories without having to navigate between different pages.

First, let's take a look at how we might structure the top level navigation of a SwiftUI app for AppleTV. Tab view is the primary means of navigation for many TVOS apps. It allows you to break your app's content up into distinct categories that are easy to switch between and provides a persistent indicator at the top of each view that lets people know where they are in your app.

Navigation view allows you to nest pages of content and optionally display a navigation bar with a title or buttons.

I'd like to make a quick note on structuring your app's top level navigation on TVOS versus iOS.

On iOS if you use a tabbed view, it will typically be the top level view of your app and each of its child views may be a navigation view with your app's content as the navigation view's root view. With this structure, when people navigate deeper into your app's content, the tab bar will remain visible allowing people to easily switch tabs at any time. Here on photos the tab bar remains visible on the bottom of the screen after navigating to the details page so that people can easily switch tabs without having to navigate backwards.

However, on TVOS if you use a tab view you will actually want to make the navigation view the top level view of your app and set its root view to the tab view with your app's content as the direct children of the tab view. With this structure, when people navigate deeper into your app's content, the top bar will disappear and we want this behavior because TVOS is all about full screen experiences that emphasize your app's content.

Here on photos for TV the tab bar disappears when we navigate deeper into the album's details so that people can focus on the contents of the album. SwiftUI views are highly composable so it's super easy to rearrange your app's navigation structure for TVOS. The nested relationships between the tab view, navigation views, and content views, are all visually indicated by the inherent structure of your code. Now, let's put some of these principles into practice and tune up landmarks for TV. First we will no longer be needing this navigation bar button title.

Next we'll get rid of this navigation button and data header label.

Let's see how this looks.

This is definitely an improvement but we've got a ways to go. This long, vertically scrolling list doesn't quite feel right on TVOS so let's use a scroll view with a nested HStack instead of a list.

And let's display all of the landmarks within a category inside of a row.

Let's take a closer look at the row.

It's very similar to category landmarks with the addition of a VStack containing a header label and an HStack wrapping the four each landmarks. One thing to note here is that instead of a plain text view, I'm using a custom view called landmark card as the label for the navigation button and I'm sharing this view directly with the iOS app. Let's give this a run.

This is starting to feel a lot better. By changing only a few lines of code, I now have a nice, big inviting buttons with images and a vertically scrolling list that really takes advantage of the wide screen. One thing I'd like to point out here is that while we're still using the exact same navigation button view in landmarks row, its appearance has changed. The chevron on the right hand side of the view is gone and the background is different. This is because navigation button is no longer being displayed in the list view and has automatically adapted its appearance. Now, while the horizontally scrolling content looks great on the big screen, it might be a little too horizontal. Let's vertically stack the categories by changing the main view's HStack to a VStack.

And adding a nested scroll view around the row's HStack.

Let's give this a run.

Ah, this is feeling really, really great. It's super easy to browse between different categories and browse the landmarks within each category.

Finally, let's take a look at the details page. Well, this beautiful edge to edge photograph of the landmark would be looking pretty nice if it wasn't obscured by all of this high density text. Let's see what we can do to make improvements for AppleTV. So let's take a look at the details view. It's a pretty simple view. We have a background displaying a photo of the landmark, a favorites button, and some historic details. Let's try displaying tourism details. Try one last time.

Ah, that's looking so much better. Only the most relevant details are being displayed with nice large fonts that are easy to read from across the room. We can mark a few landmarks as favorited for when we do more detailed research on landmarks for MacOS.

Now, back to you Jeff. Thanks Ada. I love that Ada was able to take a pretty standard list-based UI and really make it feel at home on AppleTV just by rearranging a couple of pieces that she already had. I think that really shows how powerful this framework is. So now let's turn our attention to MacOS. Now there's a lot that goes into making a great Mac app and I could probably fill the whole hour if we had it, but I'm going to focus on a few key points that SwiftUI can really help you with-- high information density, multi windowing support, keyboard shortcuts, and support for the MacBook Pro Touch Bar. Let's start with high information density.

We generally have a lot of screen real estate to work with on the Mac and so we can use that to provide more information at a glance. That can make it easier to make more, to make better decisions and make comparisons if you have all that information all in one place.

And because we have a precision pointing device on the Mac, we can tolerate smaller click targets and denser controls. Now that doesn't mean that your app should look like an airplane cockpit, but it does mean that you can provide more functionality in one place and leave more room for your content. And the Mac is a great place to read lots of text content if you have text content. So app sessions are often longer on the Mac and you're usually using it seated so it's very comfortable to just scroll through some text and read it. Now SwiftUI automatically adjusts the spacing and paddings between elements to be appropriate for the Mac. And you can use the control size modifier to access the small and mini sized controls that we have available on the MacOS system. And that might be great if you want to make an entire inspector use small controls.

Next multi windowing. You know multiple windows have been just a staple of the MacUI for decades, and people love using multiple windows. They love using multiple windows to compare content across windows side by side. It's often nice to pull a single item out into its own window so you can focus on it in detail. And many people love organizing their windows spatially across their desktop and spaces. And these are all capabilities that you unlock if you support multi windowing. And SwiftUI makes this super easy. I'll show you an example of that in a little bit. Next, keyboard shortcuts. Keyboard shortcuts are an essential part of a MacUI. Mac users and especially power users love using keyboard shortcuts to access common actions and just fly through your app's navigation. And supporting keyboard shortcuts in SwiftUI is really easy and I'm going to show you an example. So let's say we have a tab view. We've got three tabs for explore, hikes, and tours, and what we want to do is bind each of these tabs to command one, two, and three, so that we can switch between them really quickly. Now when we want to set up a keyboard shortcut on the Mac, the first place that we go is actually the Mac menu bar. We like to put keyboard shortcuts into the Mac menu bar because it makes them more discoverable and it ensures that whatever actions we're hooking up here are also accessible if you're using just a mouse. Now you could do this in code. I've gone ahead and set it up in my storyboard. And then what I've done is defined some commands for each of these keyboard shortcuts. A command is just a name for a command that can be sent through the SwiftUI hierarchy and we can use them to wrap the selectors sent by each of these menu items.

Putting it all together, all we have to do is use the on command modifier attached to the view that we want to recognize commands on. In this case we pass in the command that we just defined a moment ago, as what was a block of code to run when the command occurs. Here we're just setting the selected tab variable that our tab view is already bound to. So when we use one of these commands, the selected tab variable updates, the tab view notices and updates itself as well.

If you want to know more about recognizing keyboard shortcuts and other system level integrations like this you should check out the integrating SwiftUI talk from this year.

Finally, the Touch Bar. The Touch Bar is another great way to accelerate common actions on your Mac. It brings the most common and contextual actions right at your fingertips. And supporting the Touch Bar in SwiftUI is easier than ever.

I'll show you an example. We define a Touch Bar in code and then just like we're populating a list or a stack, we just put the elements that we want in the Touch Bar one by one.

And when we want to attach this to a view, we'll just use the dot Touch Bar modifier, passing in the Touch Bar that we're just defined. And it's that easy. Whenever this view is the focused view or the nearest ancestor of the focused view, these controls will appear in the Touch Bar hardware.

Now let's go back to our demo so we can put some of these into practice for Landmarks for MacOS.

Okay here we are in Xcode.

Let's just build and run Landmarks for MacOS so we can see where we're starting.

Okay, we have a fairly standard master detail view here where we've got a list of landmarks on the left and the details on the right.

We've also added some filtering controls so that we can go filter down by category or we can choose to see only our favorites. Now the really neat thing is that this list I've got here on the left side is actually something that I shared completely with iOS. And that was great. It gave me a really big head start to making this app. And I didn't have to do any adaptation. I didn't have to adapt it to a new data source or delegate protocol or anything like that. I just got it for free.

But I do think that this list could look better on the Mac. I wish I could see more elements in my scroll view at once and I'd love to have more details in each row.

Let's start by taking a look at how this is defined. In our landmark list we've gone ahead and actually defined a Mac landmark list that wraps this landmark list which is a common element that I discussed earlier. Structuring our project like this is really handy because it means that I can still mostly share the implementation of this list but it gives me a place to put my Mac specific customizations. Let's follow this to look at how this is defined. We have some filter criteria that just describes the configuration of our filter controls that we looked at earlier. We have a binding to the selected landmarks the list-- so that the list can show and modify it. And we have some user data so that we know what landmarks are favorited. And the list is pretty simple. You've probably seen this a number of times already. We have a list we use for each to iterate over all of our landmarks to display. And then we create a landmark row for each one. And this is a hard-coded type here. It's just, this is the type of row that we're using right now. Now we could start doing something like poundif [assumed spelling] to exchange what landmark where we're using on each OS but I really don't want to do this as a hack. I want to build a tool that I can reuse. And so let me show you how I'm going to do that.

So I'm going to redefine this list to be generic over the type of landmark row that we're going to use. And then I'm going to add a property which is a closure from the landmark to the row type that we've just defined as a generic type.

And then instead of using a hard-coded type here I'm going to delegate the creation of the row to my block. Now, to adapt that in my Mac landmark list, all I have to do is update my type definition here, add the closure that I just described, the row provider, and return a row type. Luckily like any good TV demo I had one baking in the oven all along so we'll just use that one.

Let's take a look at how that looks now.

Now this is a lot better. My rows are a little bit more compact. I've added some more details to each one and I can even see at a glance which ones are favorited, and that's really nice. And the great thing here is that my list implementation is still completely shared. So if I still had-- if I had like really advanced filtering, sorting, or grouping logic, or if it was especially fancy, let's say I had some asynchronous work that was going to a database or to the internet, you know personally I only want to write that code once. And now we can and we don't have to compromise on our design to do it. The next thing that I'd love to be able to do is to double click one of these rows to pop it out into its own window. And that's also really easy. I'm going to show you how. The first thing that we need to do is create a window and on the Mac, even when we're defining our views with SwiftUI, we use AppKit to define our windows.

Now I could do this in my storyboard but the code is really short so I'm just going to show it to you. We have a window controller and then I've defined a convenience initializer that takes a SwiftUI view, puts it into a hosting controller, and then creates a window around that hosting controller. I've also written a little bit of convenience code here that just keeps track of which windows exist per landmark already so that if I double click on a row that already has a window, it'll bring the existing window front instead of creating a new one every time.

Let's go back to our list and add this integration. So, detail-- let's add a quick convenience method-- shared-- to show a window for a given landmark. And then to attach it to my row, I can just add a tap action with a count of two because I only want it to recognize double clicks, and then in this tap action I'll call my show detail for landmark method.

Now, when I double click on my rows, I can pull them out into their own windows and I can put them side by side, arrange them however I'd like. And because these are still AppKit windows I can use all of the great windowing features that are built in. So if I like tabs I can merge them into tabs and it's just like that. I get that completely for free which is really great. And with that, I think that the Mac version of this app is starting to look pretty good so I'm going to go ahead and go back to our slides. So now that we've seen SwiftUI on AppleTV and Mac, it's time to turn our attention to Apple Watch. You know SwiftUI is the first truly native framework for building apps on Apple Watch and I think it's going to really broaden our horizons for what's possible. And to walk us through some of those possibilities, I'd like to hand it over to my colleague Meghna. Thank you. Thanks Jeff. With SwiftUI and all the amazing things you've learned so far you are bound to be on track to build an app that provides an awesome experience on all devices. Hi, I'm Meghna and now I'm going to talk to you about bringing this great experience to your Apple Watch App. While your experience may be rooted in your application, building for WatchOS means so much more. Complications, Siri shortcuts, and notifications all contribute to showing the most timely information right on your Apple Watch face. Apple Watch is all about showing the right information at the right time. For the purposes of this talk, I'm going to focus on the app and notifications. We'll start with talking about how SwiftUI allows you to display elements and lay out your Apps UI like never before.

But first things first. A good rule while building an Apple Watch experience is to aim for the primary information or the most critical action to be available within two or three taps. While designing this experience, the aim isn't to shrink down your iPhone app but to bring the most timely and relevant actions to the context of your wrist. With that, let's dive into some SwiftUI simple concepts. If you have content that exceeds the bounds of a full screen, you can wrap it in a SwiftUI scroll view. SwiftUI also gives you this great new digital crown rotation API which lets you completely control rotation and haptics. This API also opens the door to using the digital crown in all new ways to modify interface elements. This is something that was never possible before. You're also probably familiar with groups in WatchKit. SwiftUI now gives you much more powerful ways to organize your content with horizontal and vertical stacks.

Tabulating information has never been easier than with lists and with list sections.

Lastly, identifying what your users care about the most on your Apple Watch App will help you decide what kind of data to surface. With the views and controls provided by SwiftUI, you can easily build an interface that conveys the most crucial information first. Notifications are a great way to give timely updates, however, too much information or content that isn't useful may lead people to turn them off for your app.

SwiftUI gives you the ability to easily provide intuitive and beneficial controls so people can respond from within your app and not have to dismiss the notification. Making your notifications actionable as possible, you can allow people to quickly respond.

When you send your notification can be just as important as what you send in it. Try to use what you know about how someone uses your app and with that information you can send the most timely information at the most appropriate time. With these powerful new SwiftUI concepts and a better understanding of what makes a great Apple Watch experience, let's take a look at the landmarks app where we put some of these concepts to use. Using the app you've built with SwiftUI for all the other devices you're going to have a functional Apple Watch App. However, it may not be the best Apple Watch experience. I'm going to show you how, with a few tweaks and updates, you're going to be able to bring this app more in line with the context of the wrist.

Well the first thing you see here is that we've built a landmarks list. For the watch landmarks, we've gone ahead and customized the details cell. We've included an image for some context. We've included some tool details and we've also added some contact capabilities. Now some of these things like the contact capabilities don't add too much value to say, an AppleTV app but they work great inside an Apple Watch App.

But that was still way too much content to scroll so what we decided to do is to narrow it down to just our favorites. To do that we created a simple Swift filter.

Since we've narrowed this data down, we also wanted users to have an option to see all the landmarks if they chose to. That was possible with adding this button. This button simply toggles the state between showing all and showing favorites based on the view that you're in. SwiftUI gives you this unique ability to pick the pieces that interest you for your app and compose the views that work best for your interface.

We wanted to be able to focus on each cell more when we scroll. With SwiftUI we were able to do that with the carousel list style. This list style is great when you have a fewer number of cells or when you have cells with interactive controls. Here our cell has buttons for contacting, for making a phone call, for adding or removing the landmark from favorites, and having some navigation capabilities.

Lastly, notifications. For the landmarks app we wanted to notify you when a new tour has been added. We wanted to add some images so you can decide if you're interested in this tour. And also give you the ability to book it from within the notification. Using the power of Swift, you not only have the textual information but you also have this gorgeous, rich animation moving the images. Instead of just talking to you about it I'm going to show you how we built this.

So what you see here is that I've created a structure for a new tour notification. Now I've already gone ahead and hooked this notification up to my notification controller which means that whatever is in this body is what you see inside the notification after I run this scheme.

This struct takes in a landmark as a parameter which is what the notification will ideally pass to it. Now let's go ahead and add some text.

Okay so what we've done here is that we've created a stack that includes some textual information. The only reason I have a stack here is because I'm going to add some more data inside this.

In here we have decided a struct called slideshow which takes in an array of strings. These strings are image names.

We have a variable which is called the current index which is essentially just to track which image you're on at this point.

Tour image is a custom struct that I've created which is a view. It takes in an image name that aligns the image correctly inside my app.

Let's see how this looks in the previews so far.

Now, the next thing I want to be able to add here is an ID for an image. That way when we animate this we will have a proper track of what view needs to be inserted and what view needs to be removed.

At this point it looks like-- okay we have our text here, great-- at this point it looks like we can go ahead and add this slideshow struct inside our notifications body.

All right so once this updates we should be able to see this view here. This looks great. Now like we talked about here, we should be able to support multiple images inside this struct. For that, we would need to calculate the next index. Let's go ahead and do that. Now in here I'm simply calculating the next index and I'm updating the current index.

What I also want to do is animate this change. With a simple animation, every time my current index is updated it will have some fluid string animation which looks pretty good.

Now, we've created this but we haven't actually hooked it up to anything. Inside our ZStack ideally what we'd want is that after a particular interval in time we'd want the image to change and move on to the next image. So I created an extension on a view which has a view modifier. Show next image is a simple view extension which essentially invokes a timer that after every two seconds switches on to the next image index.

Now the last thing I want to add here is this gorgeous slide transition we saw, which is this easy command right here. Okay, let's see how this looks.

Okay so we have these images scrolling through. We have some actions that we had hooked up to the notification controller before.

As you can see-- thank you. Like you see, with very few changes we were able to create this gorgeous, rich notification which in WatchOS was never a possibility before. With that, let's go back to Jeff.

All right, thank you Meghna. I think it's so cool to see something so rich and interactive appearing just in the context of a notification. I think SwiftUI is going to really broaden the horizons for what's possible on WatchOS. Now this has been just a whirlwind tour so let's kind of revisit and sum up what we've learned today. The first thing is that when we're thinking about bringing an application to a given device, take a design first approach. This isn't about saying that I've got this code and I'm going to try and get it working over here. It's thinking about what's the right expression for my app on this device and working backwards from there. But, you can share some code sometimes. For example, we didn't really call it out but every demo that you saw today is effortlessly sharing the model code. The model code has been compiled into each target identically.

And you can share view code, you just have to use good judgment about when you do it. And SwiftUI can help you along the way by making it really easy to re-factor out small, reusable components that make more sense to reuse across devices.

And finally, we're not here to write once and run anywhere. The real power is in your knowledge. When you learn once, you can apply that to any device and I think that's really powerful.

As always, this talk lives online. There you can see the video replay and get associated resources and I want to thank you for your time. We cannot wait to see what you build with SwiftUI. [ Applause ]