![]() So for changes that involve only the literal values, like strings or numbers, no recompilation is required at all. Since Xcode knows what view and what file you are currently working on at all times, it can compile just that file, just that view, separate from the rest of your application - and then inject that implementation back into your application using Swift's dynamic replacement feature.Īnd because the amount of code that needs to be recompiled for every change is significantly smaller than the entirety of the rest of your application, Xcode can continuously and repeatedly do this for every change that you make.Īnd that means the feedback on your changes is much, much quicker.īut there is a whole class of changes that Xcode can optimize even further. And to - and lets you focus on the things that you love doing best, which is building great apps.īut the question is, how? How does this work? How does it do it? Well when you enable Previews in your application, Xcode actually builds your app in a special way. Now Xcode Previews is a new feature of Xcode that allows you to - that institute - minimize the amount of time you spend building and running and configuring your views to verify the changes that you are making. And the solution that we got - came up with is Xcode Previews. So the Xcode team has thought about this problem for a while. And, you know, actually shipping your app to the App Store that we as developers are all familiar with. Or maybe even on a different device.Īnd there is a real tension between verifying that your UI and your app looks as good as it can possibly look under a variety of circumstances. So for example, it needs to look great in dark mode. And a well-behaved app means that your new view, it needs to look good no matter what configuration your user is running it in. But your work as a developer isn't done yet because, as developers, we want to build well-behaved apps. So let's say your designer - you and your designer are now done, and you are happy with the view that you got. It's the building and running and configuring and navigating and getting your app to the state where you can verify that the changes that you are making have the results you expect. And it's not the getting of the feedback. It's not the making of the small changes here and there. And the time-consuming bit here is not the iteration itself. But this is something that's also potentially time consuming. And this is how we get great-looking apps. This sort of iteration, this back-and-forth, is a normal process. But the padding on that text is - it could be a little tighter, don't you think?" You get where I'm going with this story. You navigate through a bunch of screens to the new screen that you have just built. You quit the app, you open Xcode, you make the edit that you want to make. But now that I see this thing in the flesh, that button, that could be a little bit more blue." That - that's no big deal. And they say, "Hey that looks pretty good. You navigate through a bunch of screens that you have already built before to this new screen, show it to them. And you bring it back to show your designer your work. ![]() You take this mockup, and you take it to your desk, and you work on it. Let's say a designer comes to you and brings a mockup for a screen that they have been working on for your Disney application. ![]() And a little bit later I will be joined onstage by my colleague Nate to talk about what Xcode previews are, how they work, and how to configure them to take advantage of them in your workflow - whether you are working on a brand new application using SwiftUI or an existing app using UIKit or AppKit. But today we are going to focus on previewing - on Xcode previews themselves. You have probably seen Xcode Previews in multiple places through the week: in the keynote, in the State of the Union address, and multiple sessions focusing on SwiftUI. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |