앱 인텐트: 사용자 경험 및 앱 기능 향상

앱 인텐트는 핵심 앱 기능을 기기의 다른 부분으로 끌어올려 사용자가 Spotlight, Siri, 위젯 및 제어 센터에서 작업을 수행할 수 있도록 합니다.

### 앱 인텐트로 사용자 경험 간소화
* 🌐 앱 인텐트를 사용하면 개발자가 앱의 핵심 기능을 앱 자체 외부로 끌어올려 사용자가 **Spotlight, Siri, 위젯 및 제어 센터에서 바로 앱에서 작업**을 수행할 수 있습니다.
* 🧠 '흐름'이라는 개념은 즐거운 사용자 경험을 위해 매우 중요한데, **흐름은 생각과 행동 사이의 원활한 전환**으로 정의됩니다. 이러한 흐름을 방해하는 **마찰이나 장벽은 최소화**되어야 합니다.
* 🔍 앱의 핵심 기능을 이해하면 시스템이 **앱의 '상자' 외부에 해당 기능**을 표시하여 앱 간에 전환할 필요성을 줄일 수 있습니다.
* Siri, Spotlight 및 바로 가기와 같은 기능을 구축하기 위한 공통 기반인 **앱 인텐트는 개발자가 시스템이 이해할 수 있는 핵심 동작과 콘텐츠를 정의**하고 앱과 발표자 간의 커뮤니케이션을 처리할 수 있도록 합니다.
* 🎯 중요한 앱 기능을 강조 표시하는 앱 바로가기는 앱을 실행하지 않아도 **Spotlight 및 Siri에서 자동으로 제공**될 수 있습니다.
* 바로 가기 작업을 통해 사용자는 **사용자 지정 워크플로를 유연하게 만들** 수 있으며, **위젯 및 제어 센터 컨트롤**을 통해 앱 환경을 개인화할 수 있습니다.
* 🚀 앱 인텐트를 도입하면 개발자는 **핵심 개념을 한 번 표현**하고 여러 관련 기능에서 재사용할 수 있어 사용자 경험을 간소화하고 앱을 더욱 매력적으로 만들 수 있습니다.

Hi! Welcome to Bring your app’s core features
to users with App Intents. I’m Christopher Nebel,
an engineer on the App Intents team. This is my app. There are many like it,
but this one is mine. Actually, it’s sample code;
it’s available from the developer site. It’s a catalog of trails; we’ll be seeing
it throughout this video. Just, work with me here. Anyway! This is my app, and it is awesome. People tell me that when they’re in it,
it’s a delight to use. What about when they’re not in it? It’s mostly invisible, it’s just a
box on their Home Screen? Not necessarily! With the right code, I can lift my app’s
features out of that box and elevate them to other places
in the device, so that people can perform actions
from my app directly from Spotlight, or by speaking to Siri. Or they can add information
in a widget to their Home Screen.

Or add actions and status to Control Center. So, my app will continue to delight people even when they aren’t in the app. This is what App Intents and the features that it powers delivers. How does that work? Well, you’re in the right place to find out. I’m going to talk about improving flow when using your app, and a family of system features that help you do that. What App Intents is, and how it fits in with those features, and how to get started building App Intents for your app. An important part of a delightful experience is flow. In psychology, that’s the melding of thought and action. Whatever you think to do, you do it effortlessly. On a device, that means the next thing you need is always nearby and easy to get to. If you have distracting extra steps in the way of your flow, that’s called friction. Metaphorically, anything that resists getting things done.

The same metaphor shows up
in lots of other expressions: Things with high friction are rough.
You get stuck. They’re a real drag, man. Things with low friction are fluid.
They’re like a well-oiled machine. They’re smooth. A little friction can be a good thing; don’t get me started
on completely frictionless surfaces, but generally, you want
to reduce friction wherever you can. Friction doesn’t have
to be a single big barrier. Often, it’s a small bump
that you hit over and over. An example when using your device
is switching apps. Your app defines a little world, its
own box, that you have carefully crafted, and within that app, it’s perfect. The catch is that people don’t use just
one app to get things done. They use many. What happens when they need
to move between boxes? Because each of them is in their own box. And by default, the only way to see
or do anything in a box is to go into it.

which means now you can’t see
or do anything in any of the other boxes. You have to leave your current box
and go into another one. That is, you have to switch apps. And switching apps isn’t really hard,
but it’s not free. It takes time and thought while you
navigate there and back. That’s friction. What if the device understood what’s
in your box, your core features? Then, it could present them higher up,
outside your box, and make them quicker and easier
to get to. There’s a whole family of system features
based on this idea, making the experience
of using your device flow. Let’s look at a few examples, all
of which I’m going to build later. These are based on my example app, which shows a catalog of trails
in the area, with various details about them. Some features help me get
to the right place in the app faster, such as searching in Spotlight.

Say I’m at the Home Screen,
and I want to look at my pinned trail. So I trigger Spotlight. Before I even type anything, Spotlight Suggestions guesses
that I want my example app, and offers the app shortcut that I need. Imagine that it hadn’t guessed that,
so I have to type: e, x, a. Now it’s sure I want my example app,
so there it is as a Top Hit, with the app shortcut
even more prominently placed. Or, from anywhere, I could have just said
what I wanted to Siri. Some features don’t just make it easier
to switch apps. They make it so I don’t need
to switch apps in the first place. Let’s say I want to keep an eye
on the conditions for my favorite trail. Instead of opening the app every time
I think of it, I can add that information
to my Home Screen with a widget. Now I can glance at it
as I’m doing other things.

I could add it to the Lock Screen, and then I wouldn’t even need
to unlock my phone. Or I can add a custom control
to Control Center, which I can reach while using
any other app. There are many other features
like these, and we keep adding them. Last year, we added the Action button. This year, we’re adding Camera capture,
Apple Pencil Pro: squeeze, and more. All of them elevate your app's features
out of their box, to become part of
the whole device experience, and streamline the flow between thinking
I want to do this and it’s done. There's an important distinction
among these features: Who chooses what to elevate? With features like Spotlight,
you, the developer, choose. You highlight important actions
in your app, and the device presents them
automatically in the right spots. Likely actions from your app
are always close by, no matter where people are on their
device, giving them that sense of flow.

With features like Widgets and Controls, people choose. You provide flexible components, and then people can choose precisely the ones that matter, and build the right workflow for them. In other words, they can personalize their experience of your app, making their device an extension of, and even an expression of, themselves. That’s good for them, and it’s good for you, the app developer. Because the more people can mold your app to fit themselves and their lives, the more likely they are to keep using it. At this point, you might be saying, this sounds great, I want my app to flow, what do I do? Glad you asked! The answer is, you adopt App Intents. And you say, wait, what? I thought we were talking about Siri, and Control Center, and all those other cool features. And I say, we are. Allow me to explain. App Intents is not a feature in itself. It’s a common foundation for building features.

All these features we’ve talked about, Siri, Spotlight, Shortcuts, and so on, have a common theme: They take the core features from inside your app, actions, and content that are meaningful to someone using your app, and present them outside your app. To do that, you need to expose your app’s core features in a way that the system can understand. App Intents is the framework to do that. It handles two big parts. First, it lets you define what your core actions and content are, so system features like Siri and Spotlight know what they can present. Second, actually presenting something means a bunch of back-and-forth communication between your app and the presenter. For example, if someone tells Siri to do a thing in your app, Siri has to send a message to your app to do the thing, and then your app has to send a message back saying that it did it, and here are the results.

App Intents handles that communication, so you can concentrate on implementing
the actual behavior of your features. And once you’ve done that,
to support one system feature? That same work is useful across
a range of system features, because they’re all based on App Intents. So you can share code between them, and even support several features
with the exact same code. There are three top-level things
you’ll write, and I’ll show how in the next section. Intents perform an action,
like Opening a view or Starting a hike. They’re the commands,
or verbs, in your app. Entities are objects, like a Trail
or a Collection. They’re the nouns. If intents are verbs,
and entities are nouns, then App Shortcuts are sentences. They package together a verb
and a noun or a blank to fill in a noun, and whatever other options
are needed into a single thing that describes an important function
of your app, something that you know anyone
who uses your app will want to do.

Features like Spotlight and the Action button will then offer that function, that sentence, so people can do it quickly and easily. Together, these define how your app appears across the device. Now that you have a general idea, let’s write some code. I’m going to add some features to my app to help it flow. Five of them, in fact: A simple Shortcuts action with no parameters. A Parameterized Shortcuts action. A Home Screen Widget. A Control Center control. And app shortcuts for Spotlight and Siri. That sounds like an awful lot, but they’re all based on the App Intents framework, and that’s going to help me share a lot of code between the features. Let’s get started. The Shortcuts app is a powerful tool where people can explore, combine, and remix actions to create their own custom shortcuts. For example, my teammate loves mountain biking with his daughter, so they used the actions from my app to build a custom shortcut.

that picks a random biking trail
in an area. As the developer, I might not prioritize
this feature. It’s kind of specific. But I can offer flexibility
in the form of Shortcuts actions, so they can build it for themselves,
and tune it to be exactly what they want. I recently added a feature
to Pin a trail to the top of the list. That way, when I’m planning a trip there,
I can open its details quickly, so I can answer questions like
how do I get there, or can my friend bring their dog? Works great, but I want to be able
to get to that trail quickly even if I’m not currently in the app. So let’s make a Shortcuts action that opens the pinned
trail details in the app. When I’m done, it’s going look like this
in the Shortcuts app. In the App Intents framework,
a Shortcuts action is an intent. All intents appear by default
as actions in the Shortcuts app.

An intent is a type that conforms
to the App Intent protocol. It has two required pieces: A localizable title, which will appear
as the name of the action, and a perform method,
which does the action. Intents should always be actions that are
meaningful to someone who uses the app. Here, OpenPinnedTrail
not internal implementation. Perform methods always have a result, but the result may be empty,
as it is here. For this intent, I want it to open
the app when it runs, because I’m showing a view in the app. App Intents will handle
that for me if I tell it to, which I do with openAppWhenRun
like this. An intent can also have extra parameters,
extra information needed to do its job. This intent doesn’t need any,
but I’ll come back to one that does. And that’s it! My new intent shows
as an action in the Shortcuts app library.

If I make a shortcut with this action,
I can run it in the Shortcuts app. I can take that one step further,
and add it to my Home Screen. If I tap it, it runs, and my app opens
with the pinned trail details, just like I wanted. That’s not bad, but I also want an action
that lets me pick the trail to open, so I can make a shortcut
that opens a particular trail, or that asks me for a trail when I run it. To do that, I need to make
an intent with a parameter. This is going to look very similar
to the first intent. In fact, I’m going to start
by cloning the first intent and changing its name. Intents that open their parameter
in the app have a special protocol, OpenIntent, so I’m going to add that. Open Intent implies openAppWhenRun,
so I can delete that. And I need to add the parameter
that the protocol defines.

A parameter is just a normal property
marked with @Parameter, so you can add extra metadata
like a localizable title. I said it should be a trail. Trails are a core content type in my app,
so I’ll make it a trail entity. Two things to remember here: First, entities should be things
that are meaningful to someone who uses the app. So this isn’t a database row,
or whatever my implementation is; it’s a trail. Second, a parameter that refers
to an entity should be an entity, not data describing one. So this isn’t a trail name, or UUID;
it’s a TrailEntity. I update the perform method
to navigate to the parameter. And I’m done, except for the part where
I have to define the TrailEntity. Fortunately, that’s not very hard. An entity is a type that conforms
to the AppEntity protocol. You can conform your model type directly. This works well if your model is small
enough to all fit into memory at once.

so all the necessary instances
already exist. Or, you can make your entity its own type
that merely refers to your implementation. This is useful if you only
create model instances as you need them, or if your model instances
have expensive properties that aren’t needed for your intents. In this example, I‘m going
with the second approach, so TrailEntity will refer
to my underlying model type Trail. An entity may have Properties here,
the trail name. It’s very similar to a parameter, but it’s on a content object,
not a command. An entity must have three things: A display representation, so the device
can do things like draw them in a menu; a persistent identifier; and a query. Right. What’s a query? Before I tell you what a query is,
I should tell you what a query does. A query turns questions asking
for entities into actual entities. And choosing a value
for the intent parameter is going to ask two questions:

First, what entities are there? So the device can show a list of options,
someone can pick from. When they pick one,
it’s going to save the ID for that entity. Then, when it’s time to run the intent,
it sends that saved ID, and the query needs to answer
the second question: What entity has this ID? Given that answer, it can fill
in the intent parameter, so your intent code gets an entity,
and not just an ID. What does that code look like? A query is a type that conforms
to EntityQuery. There are several different ways
to ask for entities, not just the two I already mentioned,
what options and what has this ID, but also searching for a string,
searching by predicate, and so on. So EntityQuery has several sub-protocols,
one for each kind of question. The what entities are there question can be handled by EnumerableEntityQuery, which defines a method allEntities,
like this.

This is the conceptually simplest
form of query. App Intents can derive the more
complicated ones from this if you build with the iOS 18 SDK. Of course, it only works if you can
actually return all your entities at once, so your whole model
has to fit into memory. If that’s not the case, or if you can do a better job than
the automatically derived queries, then you should use
one of the other query protocols. But this example is simple enough
for it to work. The what entity has this ID question
is answered by EntityQuery itself, with this method, entities(for:). Together, these handle everything
parameter configuration needs to work. And now my intent is ready to run. But there’s one more thing I should add,
which is a parameter summary. Without one, my intent looks like
this in the Shortcuts app. This works, but it’s hard
to read and understand because the trail that it’s going
to open is below the fold.

A parameter summary is a natural language sentence
that describes what the intent will do, including the values
of all the essential parameters. In this case, the trail to open. Now it’s easier
to see what this intent does, and it’s readable as I edit the parameter. Let’s see it in action. When I tap the Trail placeholder,
I get a sheet to pick a trail. The query provides the options,
and powers searching. When I pick one, it appears inline so I can immediately read
what this action will do when it runs. That’s the parameter summary at work. I actually don’t want
to choose a trail now. I want to choose one when it runs. So I’ll clear that parameter and save the shortcut to my Home Screen. Now, when I tap the shortcut, I get a
similar picker, again, powered by the query, and it works straight from my Home Screen
or anywhere I can trigger the shortcut. Shortcuts actions are the ultimate
in adding flexibility to your app.

People will build them into all kinds
of workflows that you never imagined. Let’s look at a more focused
form of flexibility, that lets you view information
at a glance: A widget. Most details about a trail
don’t change often, if ever. It’s not going to move to a new location. Probably. We do have earthquakes. Conditions, however,
can and do change routinely, so it would be handy
to keep an eye on them. That’s a perfect use for a widget. They’re
designed for glanceable information. I could make a widget that just shows
the details of my pinned trail, but I want to keep
an eye on a few different trails, so I can choose whichever one is nicest. To do that, I need to make my widget
configurable so I can set which trail to show. That means my widget is going to have
a trail parameter, much like my Open Trail action. In order to make a widget,
I need a widget definition.

This isn’t a WidgetKit video, so I’m skipping a number of details
like the view and timeline provider. If you want to know more about that,
refer to the WidgetKit documentation, and for more details about
how widgets work with App Intents, check out Explore enhancements
to App Intents from WWDC23. The relevant part here is the body, and especially the intent parameter where I set the configuration
intent type for this widget. The configuration intent is an intent that conforms
to WidgetConfigurationIntent. Funny how that works. Like all intents,
it needs to have a title. And I said I wanted this widget
to be configurable with a trail, so I’ll add a parameter. It’s supposed to be a trail, and I already
defined a trail entity for my open intent. Can I re-use that? Funny you should ask. Yes, you can. I’m making it optional so it can be empty when the widget is added
to the Home Screen.

but it’s otherwise the same type
as the parameter in the Open Trail intent. Now, I have a trail-conditions widget
that’s configurable for any trail, so I can add as many as I need. The trail entity and its query
that I already wrote handle picking a value
for the configuration, so I didn’t need to write that again. That was remarkably straightforward,
so let’s do another one: A Control Center control,
which have a new API in iOS 18. Like the widget, I want the control
to be configurable with a trail. When tapped, it should open
that trail’s details in the app. This is only going to cover
the App Intents-related parts of Controls. For the full Control details, see “Extend your app’s
controls across the system”. With that in mind, let’s get started. The basic outline of a control
is that it’s a special type of widget, ControlWidget. Which has a body that defines what
the control looks like and what it does.

A configurable control, which is what I’m aiming for, is configured using an App Intent. Much like a configurable widget, so I add an AppIntentControlConfiguration. I said it should act as a button, so I'll add a ControlWidgetButton. This is the basic shape for a configurable button control. I still need an intent type to hold the configuration so I can build the button contents, and an intent instance to handle when the button is tapped. Let’s think about this for a second. I said I wanted the configuration to have a trail parameter. That sounds kind of like the Open Trail intent I made earlier. Can I re-use that? You bet I can. The one thing I need to change about OpenTrail is to declare that it conforms to ControlConfigurationIntent. That’s an extension, and doesn’t require anything that the intent doesn’t already have, so the body is empty. Once that’s done, I can fill in the type.

and use the configured instance
of that type to build the image
and text for the button. And here’s the really clever bit. I still need an action, which is an intent instance,
and it should open the configured trail. Again, that sounds like OpenTrail. But, I don’t need to make
a new OpenTrail instance, because I already have one
as the configuration intent. I can simply pass that as the action, because it already has the Perform method
I need and is configured the way I want. Let’s see it work. This is the new configuration mode
for Control Center. I’ve already added the new control
at the lower left, here, and configured it to open
the Monterey Bay Coastal Trail. If I stop editing, the control is now live, so if I tap it, the intent runs, and my app opens
to the trail details I configured. Now, I’ll make one of my app’s
actions available automatically

in Spotlight and Siri, opening
the details of the pinned trail. To do that, I need to make
an App Shortcut. An App Shortcut is a wrapper
that you, the developer, create around an intent that highlights
it as an important function of your app. Various features will then offer
that App Shortcut, such as Spotlight, the Action button, and Apple Pencil Pro, without needing your app
to be running or even have run at all. Let’s look at the code for that. I define a single AppShortcutsProvider with a static member,
which is a list of app shortcuts. An AppShortcut wraps an intent. Here, the OpenPinnedTrail intent
I created earlier. Notice that this is an intent instance,
not a type. That means that I can pre-fill some
or all of the parameters here. So I could take a very general intent
with lots of parameters and wrap it as an AppShortcut
that does something very specific.

It will prompt for any unfilled required
ones when the shortcut runs, so it works either way. It depends on
what experience you want to provide. This intent doesn’t have any parameters,
so the parentheses are empty. Since App Shortcuts
are available from Siri, there’s a list of phrases to speak, each of which must contain the app name, and for places where it’s displayed
visually, such as Spotlight, a title and image. Notice one thing that’s not here:
Any sort of registration code. The App Intents framework automatically
detects the provider and handles registration, so my App Shortcuts are available
as soon as the app is installed. With that, the App Shortcut now
appears in Spotlight and can be spoken to Siri. Both Spotlight and Siri
are handled automatically; someone using their device doesn’t need
to do anything more than install the app. But, if they want to customize their
device, App Shortcuts are also available.

In the Action button and Apple Pencil Pro. So that’s four features
for one piece of code. And if you have existing App Shortcuts? They already work with Apple Pencil Pro, same as they automatically worked
with the Action button last year. This is looking good, but
the Siri interaction isn’t quite right. First, it’s going to show a view, which means I have
to at least be looking at my device. Second, it’s going to open the app, which is going to bounce me out
of whatever app I’m currently using. So let’s replace that intent
with a slightly different one that returns the information instead. I’ll make an intent, but
this one won’t open the pinned trail. It will show it in a snippet, and speak it
if the user isn't looking at their screen, or doesn’t have a screen,
like a HomePod or AirPods. I’ll start with a stub perform method. Step one is clearly
getting the pinned trail.

But what’s step two? How do I show or speak information
without using my app? I use the result. The result of a Perform method
isn’t just a value. It’s a rich combination of things,
including dialog that Siri can speak and a view snippet it can show. If I say that my result conforms
to ProvidesDialog and ShowsSnippetView, I can use a different method to create
the result that takes dialog and a view. I can supply just dialog,
or just a view if that makes sense, but here I’m going to do both. I’ll write what I want Siri to say, which may be different
from the text in the snippet. I’m using an interpolated
string here for convenience, but this parameter is actually
an Intent Dialog instance, which allows separate Full
and Supporting dialog if you need it. And I supply a SwiftUI view. I’ll spare you the exact details of my view and use
a separate function to get it.

but I could have put it inline, using a trailing closure
with a view builder expression. In either case, the view is archived like
a widget, so it can be relayed to Siri. So you can use any SwiftUI features
that widgets support. Now, when I ask Siri, it will show me
the pinned trail conditions in a snippet, if I'm looking at the screen. When I dismiss it,
I'm right where I left off, so I don't have to find my way back. If I'm not looking at the screen,
Siri will speak the dialog to me. If my phone is in my pocket because
I'm busy looking for my boots, I can ask my HomePod across
the room for the conditions and I don't even need
to take my phone out. Ok, wow. I just added
a redonkulous number of features to streamline how people can use my app,
and it wasn’t even that much code.

This is what App Intents does. It lets you express your
core concepts once, and then re-use them
across many related features. Wrapping up: You can improve flow when using your app. People will get things done faster,
they’ll enjoy it more, and they’ll be able to tune how they use
your app and build it into their lives. To do that, adopt features like
Siri, Shortcuts, widgets, and more, all of which let people use your app
even when they’re not in your app. The way you adopt those features
is to use App Intents, because it’s the foundation
for all of them. That means you need
to learn fewer different APIs, and you can share code between features. Want to learn more? Of course you do! Here are some great videos to watch next: If you’re still fairly new to App Intents
and honestly, even if you're not see Designing App Intents,
on what makes a great App Intent.

If you want to find out more about how App Intents work with Siri, see Bring your app to Siri. If you already have App Intents and want to find out what’s new since last year, see What’s new in App Intents. Thanks for watching, and we can’t wait to see what you do with App Intents!

WWDC24: Bring your app’s core features to users with App Intents | Apple

Hello and welcome to the official Apple Developer YouTube channel.

Apple Developer

앱 인텐트로 앱의 기능 향상시키기

앱 인텐트는 사용자가 기기의 다양한 부분에서 앱 기능에 액세스할 수 있도록 하여 마찰을 줄이고 흐름을 개선합니다.

앱의 핵심 기능을 앱의 '상자' 외부에서 Spotlight, Siri, 위젯 및 제어 센터를 통해 쉽게 액세스할 수 있도록 하는 것이 목표입니다.

이 기능은 사용자 경험을 개선하고 여러 앱 간 전환 과정을 간소화하기 위해 설계되었습니다.

스포트라이트 추천 및 앱 바로가기를 사용하면 앱을 전환하지 않고도 예시 앱에 쉽게 액세스할 수 있습니다.

위젯과 제어 센터를 통해 사용자는 자신의 경험을 개인화하고 중요한 정보에 빠르게 액세스할 수 있습니다.

앱 인텐트는 개발자가 앱 외부에 표시할 앱의 핵심 동작과 콘텐츠를 정의할 수 있도록 Siri 및 Spotlight와 같은 기능을 구축하기 위한 공통 기반을 제공합니다.

앱 인텐트는 커뮤니케이션 프로세스를 간소화하고 서로 다른 시스템 기능 간에 코드를 공유할 수 있게 해줍니다.

인텐트, 엔티티 및 앱 바로가기는 앱 인텐트 프레임워크와 관련된 세 가지 주요 구성 요소이며, 앱 바로가기는 사용자에게 중요한 기능을 제공합니다.

앱 인텐트를 기반으로 하는 프레임워크는 바로 가기 동작, 홈 화면 위젯, 제어 센터 제어와 같은 다양한 기능의 생성을 지원하여 코드를 공유하고 유연하게 바로 가기를 사용자 지정할 수 있도록 합니다.

트레일 탐색을 위한 바로 가기 만들기

바로 가기 앱에서 바로 가기를 만들면 트레일을 쉽게 탐색할 수 있습니다.

홈 화면에 바로가기를 추가하면 특정 트레일에 더욱 빠르게 액세스할 수 있습니다.

트레일 엔티티의 매개변수에 인텐트를 통합하면 사용자가 열 트레일을 선택할 수 있어 바로가기를 더욱 유연하게 사용할 수 있습니다.

앱 인텐트 및 위젯으로 유연성 구축하기

앱 인텐트는 복잡한 쿼리를 처리하고 바로 가기 앱에서 가독성을 높이기 위해 매개변수 요약을 제공할 수 있습니다.

바로 가기 작업은 최고의 유연성을 제공하며 홈 화면에서 트리거할 수 있습니다.

위젯은 한 눈에 보기 쉬운 정보를 위해 설계되었으며, 트레일 열기 작업과 마찬가지로 매개변수로 구성할 수 있습니다.

위젯의 구성 인텐트는 위젯구성인텐트를 준수해야 하며, 열린 인텐트에 대해 정의된 트레일 엔티티를 재사용할 수 있으므로 유연성을 높이기 위해 선택 사항으로 설정할 수 있습니다.

iOS 18에서 트레일 관련 위젯 및 컨트롤 구성하기

트레일 관련 위젯은 트레일 엔티티와 해당 쿼리를 사용하여 구성 값을 선택하면 모든 트레일에 대해 쉽게 구성할 수 있습니다.

iOS 18에서 버튼과 같은 구성 가능한 컨트롤은 앱 인텐트를 사용하여 구성할 수도 있으며, 탭하면 구성된 트레일을 열 수 있습니다.

개발자는 인텐트 인스턴스를 사용하여 앱의 특정 기능을 강조 표시하는 앱 바로가기를 만들어 Spotlight 및 Siri에서 앱의 동작을 사용할 수 있도록 할 수 있습니다.

앱 바로가기는 별도의 등록 코드가 필요 없이 Siri 및 Spotlight를 통해 액세스할 수 있습니다.

Siri를 통한 접근성, 사용자 지정 옵션, 동작 버튼 및 Apple Pencil Pro와의 호환성, 기존 바로가기와 함께 작동하는 기능 등 네 가지 주요 기능을 제공합니다.

작성자는 사용자가 기기를 적극적으로 사용하지 않을 때에도 스니펫과 음성 형식으로 정보를 반환하여 Siri와의 상호 작용을 개선하고자 합니다.

앱 인텐트를 사용하면 다양한 앱 기능에서 핵심 개념을 효율적으로 사용하여 사용자 흐름과 경험을 개선할 수 있습니다.

Siri, 바로 가기, 위젯과 같은 기능을 채택함으로써 사용자는 앱을 적극적으로 사용하지 않을 때에도 앱과 상호 작용할 수 있습니다.

이러한 접근 방식은 사람들이 작업을 더 빠르게 완료할 수 있을 뿐만 아니라 앱을 일상 생활에 더욱 원활하게 통합할 수 있게 해줍니다.