|
I think, um, the best approach that I found is to really kind of start from either the top down or the bottom up, however you perceive the hierarchy of your application. Really, the big structural parts. Those tend to be the things that are most affected by the design. They're the things where, you know, if you're gonna take your content and bring it edge to edge and get your, you know, your navigation and your controls on top, that's the structure that you're updating. And those also tend to be the things that are kind of like reflected in the structure of your code, too, right? So you're gonna start there, see how your code needs to change, and then kind of focus in on the small stuff after that. I don't know, Mohammed, did you have anything to add to that? Um, not much, really, I think that's perfectly spot on. I would say, like, as a first step, you know, recompile your app with the new SDK, and see how close you are. You might be pleasantly surprised and find that, you know, you've been using a lot of standard controls, and you get a lot automatically. And then, you know, after that, carefully consider where elements of the new design apply to your UI, especially when you've built any sort of custom controls or custom UI that might benefit from a refresh. Um, another question, I may be sticking with you, Muhammad, that, um, that we got in the labs on Monday, um, if I've got, uh, an app that's working, do I need to migrate to Swift and Swift UI to use the new design? Uh, no. I mean, are, kind of, three UI frameworks, all fully support the new design, so you're able to hopefully migrate your app with, as little effort as possible, especially if you've been using the standard controls, as we said before. Excellent. That is \good news. You know, we want folks to adopt the new design. It is beautiful, it's cohesive, and so you can get to it from where you are now. Um, so... Yeah, because getting a cohesive, kind of, cohesive look across the OS was kind of really our motivating factor here. Yeah. Excellent. All right, let's turn to some questions from the room, and I appreciate you folks sending these in and keep them coming. The next one, I'm going to actually send towards you, Jacob, and this question comes from Marco. What's the reasoning behind choosing a liquid glass over frosted glass as we see in vision OS? I I think we really want to bring, like, the content to life, and so being able to sort of see through the glass, and sort of have it float more over, is one of the things that will sort of really help that. So, like, having said that, our glass as it becomes, you know, as it becomes larger, it does become more frosty, right? So we have sort of embraced this technique of adapting the glass based on the size that it is. So you will see that when glass is applied to bigger platters, then it does take on a more frosty look than it when it's applied to smaller items like navigation bars and tool bars. And that really resonates with me, also, because, in Vision OS, everything feels big, and so the fact that there's more frosted glass there sort of is in line with the design overall. Yeah. Yeah. Um, Muhammad, the next question, I think I'll throw your way, And this comes from Damien, and Damien's question is, what are some best practices for apps that use customized navigation bars? Yeah, I think if you've had the chance to play with the new OS and the new design, you can probably appreciate that the design is as much about behavior as it is about static look and the new materials. So, you know, things like transitions and how you eye elements react to user interaction are super important for UI elements to feel like they're part of the design. And matching them with custom UI is gonna require a lot of effort. So we've done a lot of the work for you in the standard controls. So, as a first step, I would consider whether you actually need a custom UI element here, or whether the system provided ones can fit your needs. Check out new APIs for things like subtitles and custom views in bars, which are added to support, you know, some of the most common customization use cases. And if you still feel like you need something custom, there are a few things to keep in mind, make sure that your properly respecting safe areas, using APIs like SwiftUI's safe area bar, That should ensure that things are, you know, positioned in the right place and react correctly across different screen sizes and different devices. When working with glass, make sure that you group buttons that are related in shared glass containers. So, you know, your custom bar can kind of look like it's part using the same design language. And make sure to mark those glass containers as interactive. We have a lot of details about these things in kind of the various adoption talks for the three UI frameworks. So, you know, I would say if you try to use standard stuff, and if you have to use custom stuff, try to use, you know, try to follow best practices for glass and custom controls, which, again, we go into a lot more detail about in the individual talks. That's great. Another thing that I heard, I'm talking to folks at our Tuesday event here at the Developer Center, where we welcomed 698 developers to talk to engineers and designers about the new design, so it was a fabulous event, so thanks to all the folks who joined us for that, but another thing that came up was that many folks customized their navigation bar to bring in some, like, branding color, or that sort of thing. And one of the things that we found, for example, in the news app, where we were actually branding navigation bars for different publications, that if we lowered that branding into the content area, it would be behind the liquid glass controls, which then get this beautiful color through that material, And then when people scroll away, the branding moves up with it, but as people enter the page, they're introduced to this brand color in a very dynamic way. So I think that is a really cool effect. I really enjoyed seeing that in the design talks. Yeah, that's a great call out. Yeah. Um, the next question I'm gonna throw your way, Ali, and this comes from Omar, first of all, amazing work. So I want to know why the new APIs aren't backwards compatible in Swift UI and other frameworks, because then we have to use if else to work around that. And so I'd like to understand, Omar would like to understand, why we, you know, restrict things to the newest, Alaska, Can you speak to that a little bit? Well, we have actually made existing APIs work with the new design, where it made sense. In fact, that's why, if when you rebuild your app, we were using existing API's paradigms, they will come across with new design and shining through, and your apps will work both on the old OSs and new OSs. In cases where we have added new APIs, these depend on deep integration across our framework stack, and the graphics stack, you know, and these are not things we're going to be able to provide on the old OS, and will not make sense. So I think those cases, where you need to reach for a new APIs, you know, we want you to think deliberately about how it makes sense in the context of our iOS 26 macOS 26 systems and use them. And that's when if else makes sense. You know, you still maintain compatibility with the paradigms and anything that doesn't exist on the old system, but you take advantage of the brand new APIs and the design on the new system. Anyone like to add to that in our experience, adopting it across apps? Maybe just to expand on something that LV hinted at, I think, if you're reaching from one of these new APIs, it's probable that you're doing something that's very specific to the new design language. And so, it's, in many ways, a good thing to do that with intentionality, right? And to actually have that conditional there and say, Hey, when I'm working with the new design, I'm gonna, on purpose, have some different code for that, versus what I wanted to do on the previous operating system. Excellent. Um, thanks for that insight. Um, Jacob, I'd like to turn to you for the next question. Um, and the question is, are there any liquid glass materials in iOS or macOS? And this question's from Felix, thanks, Felix, um, or macOS, that are only available as part of dedicated components, or are all the materials available through new UI kit, or Swift UI, or AppKit fuse. Yeah, uh, thank you for the question. Yes, there are some materials, or some variants of glass that you only get through controls like sliders and segmented controls and tap bars. But for the most part, we believe that you should be, like, we have regular and clear, and those should satisfy all sort of the requirements that you have in an app. But if there is reasons, for why that's not sufficient, we highly recommend that you file the feedback request. Yeah, this is, uh, this is, uh, thanks for that call out. Jacob, this is a great time to file feedback requests. Um, we'll be working on these, these OSs going forward, Beta 1 is available. I'd encourage you to try it out. Carefully consider whether you're going to put that on a test device. Um, I, uh, I saw lots of developers that were showing me it on, on their carry phones, and that's, uh, appreciate your confidence in us. So, but please, do file feedback. Now is a great time to get that to us. So, Muhammad, I'm gonna throw the next question to you. This comes from Alexis. If I were to create a new app today, how should I design it to make it future proof using liquid glass? Well, once again, I think using standard system controls and trying to work with those controls work your design around kind of the standard system look and feel is probably the best way to do it. After that, you know, using a framework provided APIs with UIs declarative API generally leads to kind of less adoption in the future, because, you know, you are expressing more of your intent rather than, you know, drawing pixels on screen and, you know, producing a specific visual effect. That's kind of really basically it. You know, when it comes to glass, you know, close attention to the design sessions that are being offered this year, our wonderful designers go into a lot of detail about, you know, the design motivation behind liquid glass, and, you know, best practices for using it in your app. And that's a great call out, and I'll take the opportunity to hype our upcoming lab on designing with liquid glass and the new design system, which follows this one. So I think there's probably still time to sign up for that, and that'll be a great place to get design questions in, as well. So... Jeff, I'm gonna throw the next question. your direction, and this is a NS split view controller question. Is it possible to implement your own sidebar on MacOS without using NS split view controller, but providing the same liquid glass appearance? Or does that look only available if I adopt an a split view controller in my app? Thanks, that's a very good question, Felix. I think, on a technical level, possibly anything is possible. You probably could put something together that looks approximately correctly. I don't think I would recommend it, though. I think there's a lot of unseen complexity to the system implementation of that. Not only the actual material itself, but it's interlayering with scroll edge effects, both underneath it, and also on top of it. And even, as we've been iterating on over the beta period, like, when you enter full screen, the sidebar has behaviors for that, too. Like, there's all these little system behaviors that really require the level of abstraction that NSPU controller provides, right? Because then the framework can go ahead and get all those details right for you. So you could try, but I don't think I would recommend. Blazing your own path. Thanks, Jeff. Um, Mohammed, I'd like to, uh, to throw the next question in your direction. This comes from Brian, um, and, um, it's a little lower level, so, uh, so dig in. So regarding scene delegate and scene based life cycles, Brian was just looking for some confirmation that app delegate is not going away. Um, and, uh, if that's correct, um, do you have any advice to offer on what should be moved Cassine delegate, what should stay in app delegates, How should people think about dividing that code? Uh, yeah, it's not going away. Um, it still has its purposes for application level interactions with the system, um, like, you know, managing scenes at a higher level. The general recommendation is to move a code that relates to your absene or the UI into the scene delegate. Another important thing to keep in mind is that when we talk about adopting scenes, that is not necessarily the same thing as supporting multiple scenes, An app can be seen based, but still only support a single scene. I'd recommend reading the tech note about migrating, you like it, scenes, or migrating apps to the UI kid scene based life cycle on a developer website. and do check out talk about building flexible apps, being offered this year. Yeah, and thanks for the call to that talk, that, um, a very important talk, phenomenally excited by iPad OS 26, and the ability to do window management, and have menus on the Mac. It warms my longtime Mac developers heart to see stoplight buttons in the corner of a window. And so, really would encourage people to check out that video. It's a super good introduction to where we're going with that new design, so I appreciate that. Ali, I'd like to throw the next question to you. What happens if an app's not ready for adopting the new design? What can developers do if they aren't able to migrate their app fully by the time the LS is available? It's a great question. First of all, of course, existing binaries, when we're on with the existing design, they do not adopt the new design, so there's no concerns there. As far as when you do build your app against the USDK, you will get the new design by default, and that will give you, as we said earlier, standard controls will come across, and you will be able to evaluate whether any custom drawing and any custom controls you do, how they come across. Now, if it turns out, you do want to ship your app with the USDKs to take advantage of functionality and ship it as early as possible, of course, which we want, you know, Our recommendation is to get your design ready at the same time, too, but you might want to spend some time on the design, deliberate with designers and so on. So, um, there is an infobilist key that allows you to opt your app out of the new design while shipping against the USDK. The intent of this key is to be temporary. We intend to remove it in our next major release. So, this gives you a while, where you can ship your app and continue to refine your design, and then release your new design when you're ready. And thanks for that input. I would encourage folks to try building with X Code 26, and see where you are. I think a lot of folks have been very pleasantly surprised with how quickly they could move to it. So see where you are with Beta 1, and before you make decisions about whether you're going to need to defer, but, of course, if you need to, you know your app, and so I'm glad we have this opportunity through the P list key to buy a little bit more time. So I want to address the next question to Jacob to start, And this is one about accessibility. And so this comes from Tim, Thanks for the question, Tim. How is Apple planning to improve or ensure accessibility, in UI that's using liquid glass? Tim felt like that, in the initial beta, there's some things that are a little bit hard to read on the screen because of the layering. Can you speak to that little bit, Jacob? Yeah, absolutely. I think, first of all, like, we are continuing to refining things, and in particular, in the area of accessibility with the accessibility modes, that's sort of something that's very much in the forefront of what we are continuing to refine. In general, like we have two different kinds of glass, as I mentioned earlier, regular and clear. And in most cases, you need to reach for the regular, and regular will sort of do, the intent is that regular would do all the right things, from an accessibility perspective. Leah, you should use much more rarely, and is really sort of, you know, intended when sort of the shape of the bat, no, there's not too much content inside the glass that you need to sort of decipher. because clear will let a lot more of the content behind through. The other things, as you may have seen in the build, like regular reacts to the content that's behind. So if the content gets stuck, the glass ticks on a dock appearance, if the content gets lighted, the glass takes on a light appearance. And so, regular, in general, is gonna offer a sort of much better contrast for the content that you have behind. But of course, like, there might be cases where you're seeing where it doesn't quite be right, and we certainly would want to hear feedback in those areas. I think the other thing, just as important with glass, If you're doing custom things, like, it's really important when you have content that scroll under, that you also consider adopting the scroll edge effect, as that also helps the improves legibility. So you don't have sort of trouble reading the content that's in the glass. Ali, do you have anything to add to that? I think Jacob covered it pretty well. I just want to maybe to reiterate that, you know, legibility is a priority. We'd love to hear your feedback. and also accessibility of course, as well. We have accessibility modes that have several options to make sure expability comes across in a way that they're dressed as a wide variety of use cases. And in beta one, as we have some release notes about it, as well, things are not really there, but accessibility in some front, so that's something when they continue to improve through the betas, of course. Yeah, and I just, I'm gonna reiterate, is there a word for reiterating twice, that, you know, all of Apple's own apps have been adopting liquid glass, and so we're tuning for those use cases, but now is the opportunity for you to try it out, and we can also tune for your use cases, like our developer community is diverse, and doing all kinds of amazing things. And so we really would welcome that feedback on how the readability works in your app, how you're able to adopt accessibility with these things. And so now is a great time to look at that. All right, I appreciate it. The next question, um, has come from multiple people. I'm going to shout out both Greg and Paul for sharing questions along these lines. But the general question here is, do y'all have any advice for how to adopt the new designs, for folks who are targeting older versions of, for example, iOS? Muhammad, do you want to start with that one? Uh, sure, yeah. Um, I'm gonna sound a bit like a broken record here, but I think, again, using, using standard controls is the way to go. You know, I think if you watch the adoption sessions, you'll find that a lot of the advice in those sessions is to use APIs that have been available for a while, outside of the things that are truly new, you know, mostly things that relate to the material, to materials and puzzled by some of the new transitions. You know, when you're working with anything custom, I would do my best to integrate it with the system controls in a way that doesn't make assumptions about either the sizes of those controls or their layouts, or, you know, the colors that are being used or things like that. Um, we have, we've long had APIs that have allowed you to do that kind of thing, you know, things like auto layout constraints, dynamic colors, things along those lines. I think Jeff, you probably have some good context to add to this as well. I'm gonna tag you in here to help me out. Yeah, um, I think... I think, definitely, any time that you can kind of, like, ratchet up the level of abstraction, really, 'cause if, you know, it's, like, if you're at the very finest level of custom drawing, of course, then, yeah, you're responsible for making sure that that custom drawing is compatible across the different versions versus, if we zoom all the way up, you think about, like, Swifty Y, the entire framework, that level of abstraction for describing what your app should be, gives the framework a lot of latitude to provide you with, like, the best possible experience on this OS, and then also on this OS. And so, you know, that's something where, right, yeah, you make something like a navigation split on in Swift DI and you're just getting the right thing. Yeah, so drilling in a little bit on some details from Paul's question, and maybe, maybe Jacob, you can chime in on this also. So Paul's interested in using some of the custom effects, so using a glass effect container, glass effect, glass effect ID to get custom morphing of controls, which I have to say, if you haven't tried this, open X code 26, and try it, it is so fun. And we show some of that in the Swift UI talk on the new design. And in the other talks as well, those APIs that I mentioned are Swift UI specific, but if I want to use these things in my app, but I'm also back deploying to support, you know, for example, iOS 18, how should I think about doing that? Do I need to design these morphing effects, and so on, and think about those as just being something for IOS 26, and then implement it differently for past OS's, or what do you think is the best way to think about that? It depends very much on sort of how broadly and where you are applying it in your app. Like, so, like, I think what I would think about is, like, that piece of the UI where you're considering doing this, can you sort of, as Muhammad and Jeff alluded to, can you abstract it? And can you then sort of handle the if available logic in there? Because, like, you stayed there, you want to back deploy to earlier versions of iOS. And so, I think that's kind of how I would look for it, look at it, is like, how can I sort of abstract the piece of UI that I do want to show with glass material? But in such a way that, like, sort of at the calling side, I don't have to worry about whether I'm running on iOS, 18, I'm running on iOS 26. I think it's sort of a high level, abstract question, but it's difficult to get into, sort of without the details, but that would be my guidance, is try and deal with it, sort of, an abstraction, so you create a component that's responsible for this new eye, and of this UI, and then that component, in turn, will have the right behavior on the different OSS that is running on. Excellent. Thanks, Jacob. Ali, I'm gonna throw the next question at you, Maybe you can throw it around the horn, if you want. But this question comes from Nuno. So, I have a multi platform productivity app that requires heavy customization using AppKit and UIKit. collection, table, outline views, If I'm moving to adopt the new design, should I be looking to move to Switch UI life cycle? Can I stick with native, um, UI kit, nap kit, APIs? What are some of the trade offs there? I mean, first of all, if you are moving to new design, you do not have to go change the way your app is architected or built as, you know, we've said before, the APIs are sported in all three of our frameworks, and you can continue to work the way you were. And, you know, if any existing app, any app that's been around for a while, if it's like the apps we have, you know, our big apps that we ship on the system, these days, they are a mixture of app kit, UI kit, Swift UI, as well, because, and they're also objective C and Swift as well, and we sport all this, you know, this all works, and the new design should also come across as well. So, using swift your eyes on a binary choice, it's not like you have to switch to the Swift UI life cycle. You can customize the views, and these are all for existing code bases. If you are a brand new code base, you know, you can still, for instance, choose to start with a swift dry life cycle, which is, of course, cross platform, but then still use reach for AppKit and UIKit, or you need to. So you have a lot of flexibility there. Now, if there's any question, any specific question you have that you're still stuck on, you know, please feel free to reach out to us, and maybe we can help you with that. Yeah, and that's a great call out, Ali. I should have mentioned earlier. We do have one on one lab opportunities available. during the rest of the week, and so you can sign up for those in the developer app, and talk with an engineer directly about specific questions, which is a great way to get help. And, of course, as I mentioned at the top, also, you can take those questions to our developer forums, where we've got folks who are available cancer those. So the next question I'm going to throw to myself, which is what are some best practices for adopting the latest Swift UI APIs alongside existing UI code bases, especially for performance and interoperability. I'm gonna take this opportunity to hype a couple of things. The first thing I want to give a shout out to is the brand new Swift UI instrument. which is a great way to evaluate the performance of the Swift UI pieces of your app, and assign the costs of those components back to wearing your code, the updates are being triggered. so that you can tune your code for the best performance. And in general, so the other thing I want to hype is, tomorrow at this time, we have a Swift UI lab where we can talk in more detail about both integrating Swift UI into existing UI kid apps, and about the new instrument. But in general, as Ali was saying, we have large complex apps at Apple that are using a mix of all these frameworks and all these tools, and so, we are confident that we have the tools in place in order to combine the frameworks and produce the best result in your app for the people using your app. And so we appreciate you trying these things. So the next question I would like to send Jacob's way to start, and the question is, is it possible to implement your own controls in Swift UI, but providing the same liquid glass appearance, or is it only possible when using standard controls? Yeah, thank you. Yes, you can implement custom controls. So you would use the glass effect modifier, you would also want to mark the glass as interactive, right there, as a modifier to do that. And I highly recommend that you watched a session called Builder Swift UI app with a new design. There's a lot of great callouts, sir, and techniques in there. In general, I think the other small thing that I will mention, like, if you're building controls, and like you have more, like, it's very typical to have multiple pieces of glass together. You want to make sure you group them in a glass effect container, so you get the right kind of morphing between the elements. Yeah, that's a great call out, and all three of the talks on implementing with the new design, go into this, but the glass effect container actually assures the correct visuals also, because if you have two glass controls too close to each other, they might try to sample each other, and that's not gonna work out well, And so the glass effect container helps the system know what area to sample to get that glass effect. And also, thanks, Jacob, for calling out the implementation talks, but I do want to also mention that we have the landmarks app available on developer.apple.com for download. And it has custom liquid glass controls. Its badges are implemented using glass effect. And so there's an example available that you can poke at, also, and see how that actually works. So the next question, I'll start with you on this one, Jeff, and then maybe you can throw to Muhammad. in iOS 26, and MacOS 26, is it possible to change the liquid glass tap bars background color, specifically the actual glass tint color? There are some ways to provide tint to bar items that are on glass. I think the purpose for doing this might vary. I think, if it's just for branding purposes, that's generally not how we're using color in this case, we really are trying to, in the design language, focus, it's like a semiotic thing, almost, of where you see color, it is indicating something, right? It is indicating state. It is indicating a really key action, and it's kind of supposed to reflect, like, a specific kind of interactivity. And so, it is, you know, it is possible, but definitely, like, make sure that you're using it for the right reason and kind of thinking about the design in that way. I don't know if Muhammad had something to add to that. an expert on bars. Yeah. Yeah, I mean, the only thing I would add is, again, just to kind of reiterate something that Kurt said earlier about pulling in color, or getting kind of any additional color that you want, to be expressed, by layering it creatively with the glass. You really want the material to be familiar and consistent with other instances of the material in the OS. So rather than, you know, considering a design where you actually tint the material, which we don't actually have support for across the board, especially in kit owned controls. You want to think about how you can get kind of your additional color, your branding, or what have you to play nicely with the material that's there. Again, if you think there really is an important use case where you want to have the glass be blue, for example, and you think that use case doesn't necessarily clash with some of the meaning that Jeff mentioned, or, you know, like, you'll notice across the OS, done buttons are, like, fully tinted to kind of highlight them. Do file feedback, let us know what those scenarios are, We do take that feedback seriously, and we consider how to augment our APIs in the future. That's, uh, that's a great ask there. Um, the thing that I find when I'm, um, you know, using the new design is that the, um, the tinted glass controls really draw the eye, and so using them as a call to action is fabulous, because it, like, motivates me to move forward. But if we use tint too much, that can actually distract, because it is such a strong call to action. You don't want to be in people's face all the time calling them to do something, when they're trying to just use your app. So there's a real balance to strike there. All right, next question, I think we'll stick with you on this one, Muhammad. This comes from Steven. Um, and this may be a short answer, but, um, our size classes affected by the changes to the, uh, the iPad, uh, OS 26 design. Uh, they're not changing. They, we still think that size classes have their place. I think they're useful for really tailoring designs for smaller windows. One thing that's always important to keep in mind is to never kind of fall into the trap of thinking of a size class as a fixed break point. Always keep in mind that size classes arrange, and, you know, just because today, you know, you've noticed that it's at a specific point value, your design and your implementation should never assume that that value is always gonna be the same, or that your UI doesn't have to handle different sizes. There are other factors that, you know, that your UI should be able to handle, that might influence the size of your content, things like dynamic type, or other accessibility settings. So always be flexible, is the best way to think about it. Excellent. Thanks, Mohammed. Um, Ali, I'm gonna throw this next question your way. This comes from IlK. Um, and, uh, I'm gonna have to pronounce a, uh, an emoji out loud, but I think I can manage that. We did it in a song on Monday, so we have a new app that we'll release in a few weeks. What's the optimum strategy you can offer for us to migrate the brand new app to the new design and liquid glass, sweat smile. Well, first, congratulations on releasing a new app, and, um, so optimum strategy. Hmm, I don't know if there is an optimum strategy, but, you know, I think a new app is, you know, likely to benefit from the new design, But, I mean, since you're releasing in a few weeks, you know, you're probably very close to shipping it on the new release, but, you know, just you have the opportunity to build, run, and attest to it to X Code 26, to see how your app comes across, and whether there are any key things, which may benefit, maybe, from, you know, looking over and so on. I don't know if that's an optimum strategy, but, you know, we do recommend you just try with X Code 26 against the USDK, so see if there's any key things that stand out, that you can maybe think about applying. Jeff, do you have other thoughts on this? Yes, I mean, I think, um, if you're a new app and other kind of bit of good news, is that you are probably doing more modern things, using more modern APIs, You know, if you're a Mac app, you likely haven't chosen to adopt NS drawer, and, which has not been updated for the new design since it's been deprecated for, like, a decade now. So that's another nice thing is that, like, the more modern ways of building apps are more likely to be right on track, right? Those are the kinds of APIs that are the best fit. But not that you mentioned STR, I'm sure developers are curious about what it's all about. You don't have to go to an archaeology session to hear more about that one. Oh, and now I have an idea for a dub dub video for next year. Thanks, Jeff. Um, Jacob, I'm gonna throw the next question your way. Do you have any recommendations on preparing Swift UI code for the launch of iOS 26? while maintaining good UI practices for prior iOS versions without just splitting our code base. Some of it is sort of reiteration of what we've said before, like, but building on top of standard views whenever it's possible. Like, if you can use standard tool bars and navigation bars, right, like that, that's then you'll get sort of everything more or less for free. So, to the extent that you can use standard views, that's what you're going to want to do, like, and handling back deployment, like use the if pound available, and I think that's, I think the rest of it is just rehashing, you know, all of these things, and perhaps what I said earlier is, like, if you have a case where you are adopting the new thing and it's difficult, like, you end up sprinkling all these, if available everywhere, like consider sort of abstracting it into a component by yourself and let that handle the differences between the different oasis. Excellent, thanks Thanks Jacob. So the next question comes from CP, and I'll try to handle this, and y'all can tell me if I'm wrong. So I'm working on accessibility, and what accessibility pieces, and especially regard to buttons, should I be most focused on as we factor to fully use liquid glass? So, we talked earlier about the two types of liquid glass, regular and clear, and we mentioned how clear should be used in limited cases. So, a good example of this is the play button in an AV player is a clear liquid glass button, and its content, it really shows through the material, the video that's behind it. But that's the case where the button's position and the icon and its size all make it fairly clear to people using the app that, you know, this is the play button. But as you're mostly you're going to want to use regular glass, but some other things to think about with regard to accessibility is the various modes that we make available to people using our devices. So for example, we have reduced transparency, which will make liquid glass more frosty for people using it. We have increased contrast, which pushes elements towards the extremes of all black or all white instead of, instead of some of the more grays that we might get with some vibrancy. Also, reduced motion is going to decrease the intensity of the morphing effects, and so on. And so, if you're doing custom controls, like the basic glass effects will take advantage of these features, but you can also read these things out of the SwiftUR environment, or out of traits, in order to make your own custom work react to those also. And so that's something to think about as well. So the, uh, next question, I think, is probably best directed initially at, um, at Yuma Mohammed, um, and it's about, uh, searching and searchable. And so the question is that search bars now seem to be positioned at the bottom on iPhone. Is there an option to move those around? How does that interact with tabs and tab views? Yeah, we have a few options available with a new API. Now, the bottom line search field is the default in a lot of cases on iPhone, but you'll probably notice, even the apps that come with the system, that is not necessarily the only option. We do still have some top aligned search fields. So you can customize that using the search, search field placement, in Swiss UI, and you can, please check out the various sessions for UI could adoption for details on those APIs. Also recommend checking out the new default tool bar items with QI, API. And when working with a tab view, using searchable as preferable, since it gives you the default integration with the tap bars, which gives you that great morph animation, well, it gives you, initially, that just, you know, separated placement, which is, you know, kind of a big part of the design language, and it gives you that nice transition when the user focuses the search field. And again, lots of a lot more details about this in the talks about the new design, for the individual UI frameworks for Swift UIUI kid. Thanks to Bob, I personally really love having the search field at the bottom, because, um, you know, the phones have gotten bigger, but my hands haven't, and so it's super easy to, now, tap that search field and get to what I'm looking for. Um, so I appreciate that, uh, that design tweak. Jeff, the next question I think I'm going to throw your way, and this comes in from Edwin, so Edwin's wondering, and, first of all, Edwin has installed Mac OS Tahoe, and thank you for doing that. But now he's wondering how to see how his app would look on pre Tahoe for people who haven't upgraded to Mac OS Tahoe yet. Is there a developer setting to do that? Is there some field that he could change? He's curious what the best way is to sort of approach that development problem. The question, there isn't a switch that you can flip like that. Um, and I think, even for the applications that are kind of in a compatibility mode on Maco Ostaho, there are certain UI elements that are more system provided, like alerts in certain panels, that are going to use the new design, even if the main application is in a compatibility mode. So I think to get the full picture of what your app experience is gonna be on a particular operating system, you should test on the operating system that you're gonna target to. Thankfully, these days, like, the virtualization support on Apple Silicon is amazing. I use it all the time. It's really, really handy. And so that's a really great strategy if you don't have, like, a spare Mac or another partition handy, is spin up a VM and actually run it in that operating system. Right. Um, I'll leave next question, I'll throw your directions. This comes from mighty. How do we configure the icon of our app when a user is using clear mode? It's a good question, and, you know, I'm not an icon designer, but we do have icon composer, We have our new app bundled with X code that lets you design the new layered app icons. And these icons are, you know, work in all the modes we support on our systems. And my understanding is, it does let you customize aspects of your app icons for different icon modes, and preview them directly in the app. Now there are other sessions about this, so I recommend you maybe attend some of those, or maybe ask questions in the design lab. We have later, if you have questions that, you know, I haven't answered yours, 'cause I haven't really tried the app myself for real work, so... Maybe one of my fellow panelists who have, as an answer. Well, I can chime in, because I am also not a designer, but I had a lot of fun playing with icon composer yesterday, which I wish I downloaded, and started playing with some of my apps, and I was showing some of my results to some design colleagues, and they confirmed that I am not a designer, but the app is a lot of fun to use, and it lets you customize for modes. You just drag assets into it, it'll layer them, applies glass effect, you can tune the effect. It's a lot of fun to play with, and the results are really, really nice. So I encourage you to try that out. icon composer is available in X code, so if you download X code, it has the option to launch icon composer, and then the output of icon composer, you can just drag into back into X code to compile into your app. We also have available from the developer site, icon composer, as a separate download. So if we have design friends in the audience, and you don't want to download all of the bits, you can pull down icon composer separately, as well. Jacob, I think I'll throw this next question, your direction. This question comes from Clayton. Is liquid glass mandatory? Is there a way for developers to opt out? Are parts of it optional? For example, can we still use custom tab bars? even if we use liquid glass elsewhere? Yeah, thanks for the question. As Ali answered earlier, like, we do have this infopilisky that you can use to opt out, but it's obviously, it's opting everything out, when you do that. And it's really there to help the transition, like, so you can sort of transition, like, in, like, on your own schedule. So, you can obviously build custom components, and you can choose those custom components can be in glass or not. It's like, I think sort of an important thing is, like, we're not asking everything to be changed to glass, So I think maybe calling out some of the design sessions on this, it's like we're not expecting that every single control, every single piece of UI gets updated to be class, right? We actually have some design thinking behind that. So there are sort of key elements that would benefit from being pulled out and be and use glass. So I don't know those session names off the top of my head, but I highly recommend like it to watch those. I don't know whether Ali you have anything else to add here. No, you covered it pretty well, Jacob. Thanks. Um, a bit of a follow up, Jacob. This is from Alan. Um, uh, can we use liquid glass effect on text, like the time on the lock screen or custom shapes in general? On text, no, not directly. on custom shapes, yes. So the glass effect modifier in Swift UI does allow that you apply it to custom shapes. So, like by default, the glass effect is a capsule, but you can sort of apply it to any shape. It does come with extra, like, memory and performance costs that can impact your app. So, I think, in general, it will be good to think about, like, you know, like, what's the real use case for it? Like, it's something that we use very, very sparingly, like, most of Apple's glass is applied effectively to capsules, roundabrets and so on. and not very custom shapes. Excellent. Thanks, Jacob. So we're nearing the end of our allotted time here, and there's a question I'd like to throw in for everyone on the panel. So as a former UI frameworks engineer myself, one of the things I always loved to see was how our developers took these APIs that we created, and just built cool things with them. Like, we can't wait to see what you build is a dub dub cliché, but it's also a true sentiment. Like we really are inspired by that. And so I'm curious to ask each of you, as Apple's own apps have adopted the new design, What are some things that surprised or delighted you? Uh, I'll jump in, if, uh, do you have the... I mean, overall, you know, the thing has been amazing to see, but one thing that really made me go Wow, was when we're looking at Jeff Apkitt's session, rehearsal, and you showed that the screenshots for App Store showing the page for a nothing, I'll name drop Balatro, and that just made me go, Wow, 'cause they adopted the glass sidebar in with the extended content underneath, it looked gorgeous, and especially the background that App chose, so that's the kind of thing that's like, Wow, this is just amazing. And the other thing is, like, ex coach, for instance, I think, they really traded a lot, X code is, you know, quite a productivity app, of course, you know, more so than a bunch of the other apps were shipping, and, you know, they traded a lot, and I think they really end up in a pretty good spot with, you know, using the APIs and also providing feedback towards that. So that was another thing that I think, you know, that were pretty thrilled, but... Sure, sure. Jeff, you want to go next? Yeah. Just like you stole mine, because I like that example so much that I put it in the video, but yeah, I think, you know, even just photos is a really great example, where I'm scrolling through and looking at pictures of my daughter, you know, whatever, and it's just, it's the way that the design copes with this content that could be anything, right? Any kind of photograph, any kind of, you know, media, and the adaptivity and just the way that it reacts and, like, elevates it, I think, is super, super cool. Excellent. Jacob, you want to go next? Example, I used to work on Apple books, and so, and there's a lot of beautiful artwork for the book covers, audiobook covers. So seeing it come to life there, and especially, like, when we got the new sort of mini player, and its interaction with the tap bar, and all the animations, I think that was sort of a special moment for me when all of that was working, and was really fluid. How about you, Mohammed? I don't have a specific example, but the thing that I really enjoy the most is just seeing how the APIs combined together in very interesting ways. You know, when you're working on something as a UI frameworks engineer, it can be really easy to get, like, laser focused on the component that you're working on. And to see the creative ways that developers combine things together, it's just really awesome to see, like, things that we never kind of anticipated, and the times when, you know, they combine into something, like, really beautiful and serendipitous is just fantastic. Nice. I appreciate that. I'm gonna call out one more thing, which, um, isn't exactly related to current APIs, but, um, but I happen to know, um, that Ali is the product owner for, um, text edit, and, um, Ali, maybe you can, maybe you can tell the story. How much did you have to change to adopt the new design and text edit? It was zero lines of code. I think the new icon delivery was the only thing we're adding to Texas. So, that does emphasize that when you're leaning on the standard controls and the framework APIs, the UI frameworks teams who are so gracious to share their time today are really doing a bunch of work for you. And so, I really appreciate that. So that is about all the time we have today for this group lab. I'm so thankful to all of you |
