How to Build Databricks Apps Faster with AppKit, the Official TypeScript SDK

Summary

AppKit SDK: Official TypeScript SDK with plugins for Analytics, Genie, Lakebase and Files.
Built-in production features: Authorization, streaming resilience, SQL caching and observability ship by default.
AppKit in action: Cursor generates type-safe React apps with hot reloading and resilience.

How to Build Databricks Apps Faster with AppKit, the Official TypeScript SDK

Talk by Mario Cadenas, Senior Software Engineer, Databricks; Victor Ditadi, Senior Software Engineer, Databricks
AppKit is the official TypeScript SDK for Databricks Apps and the fastest way to build an internal data app on enterprise data without hand-building authentication, streaming, retries and caching. Its plugin architecture for Analytics, Genie, Lakebase and Files ships production behavior by default: on-behalf-of-user authorization with token refresh, resumable streaming for long-running queries, automatic SQL query caching in Lakebase, and native telemetry in preview.
The creators of AppKit explain the hidden work behind production apps and show what AppKit now handles for you: on-behalf-of-user authorization with token refresh, resumable streaming for long-running queries, automatic SQL query caching in Lakebase, and native telemetry in preview. A live demo uses Cursor with Databricks app skills to generate an agent-powered app with analytics, type-safe React queries, and a local dev mode with hot reloading. A crash-recovery test shows a long request resuming after the app restarts without duplicating work. The talk closes with Task Flow, a new product for durable, long-running tasks and agent loops, and the databricks apps init command to start your first app.

Chapters

FAQs

What hidden work does AppKit handle automatically?

This video explains that AppKit handles on-behalf-of-user authorization with token refresh, resumable streaming for long-running queries, automatic SQL query caching in Lakebase, and native telemetry. Production apps require all these features but AppKit ships them by default.

How does AppKit's plugin architecture work?

Plugins for Analytics, Genie, Lakebase and Files extend AppKit functionality. This video shows how plugins provide type-safe abstractions for common Databricks Data and AI platform data sources and operations.

What does the crash recovery demo show?

This video demonstrates a long request resuming after the app restarts without duplicating work, proving that AppKit handles resilience transparently. This matters for long-running queries and agent loops.

How can I build my first AppKit app?

This video covers the databricks apps init command to start your first app and shows live generation with Cursor and AppKit skills. Task Flow handles durable long-running tasks and agent loops.

Full transcript

`00:00` Introduction

Um, well, first of all, we did n't expect so many people. So thank you for coming to our talk. Um, yeah, well , let me start. So, I'm Mario, and this is Victor. We both work on the developer experience at Databricks, focusing on Databricks applications. The idea of today's talk is to show you AppKit, a framework designed to dramatically improve the app development experience so you can focus on the value of your app, not the infrastructure or technical details.
So, during this talk, we'll talk a little bit about what AppKit is, and then we'll do a live demo. And then a recorded demo, because it's a little difficult to perform live. And you'll see that just by following a hint, we can create a great app, as far as I'm concerned . And we will deploy it live. So yeah, let's get started. Hmm, yeah, I guess I need to turn that on. Okay, but before that, I have one request for you.
When we're done, please fill out the survey, it will help shape content for next year. This will be very useful. Class. The fact is that the way data is consumed in the field of AI has changed a lot. Maybe we can look back and see how things worked before and where we are headed. Previously, we mostly generated PDF files, such as static reports. Then we had dashboards, beautiful widgets where you could filter data as needed.
And now we have interactive applications that are, you know, more customizable. And now we also have agents. The point of all this is that we move up this stack, and this upward movement makes data more accessible and easier to consume for everyone. How many of you know, have deployed, or built a Databricks application? Okay, a lot of people. How many of you have built Databricks applications using Node. js, React? Okay.
Now I will try my luck. Is there anyone here who has built a Databricks app using AppKit? Oh, wow. Good. Perfectly. I hope that after this talk we can convince you to use AppKit instead of Node. js or even Python. Because it should be much easier. So yeah, a year or so ago we released Databricks applications. As you can see in this wonderful chart created with AI. We have all these cool features that we can implement in our apps.
The problem, or not really a problem, is that you need to build an app. It is very easy to deploy. But the problem is that you need to create all of this from scratch. Well, it's not that simple, is it? So, there's a point where you've already built your application, um... you might have some great data processing logic. Maybe you have a super cool model that works really well. Maybe you have a streaming prototype , and you know, it's easy to do as a prototype, but when you want to make it business or production ready, it's not so easy.
The rest of the work is the hardest part . And you're not really interested in it. So let's call it an " invisible tax." So, as I said, what's above the waterline is what you need: data, data logic, and your interface. The problem is that you also need to take care of something else. And you're not actually interested in that. You need to take care of authentication, impersonation, sometimes streaming, retries, timeouts , observability, durability, and scaling.

`04:35` The hidden work behind production apps: auth, streaming, retries, timeouts

And that's not really your job. You are not interested in this. You just want to build an app and do something useful. The problem is that today you have two options. Um, yes. The thing is, you can " glue" it all together yourself, forcing many teams to build the same thing over and over again . You can reinvent authentication, streaming, or retries. Another option is to rely on third-party libraries that are not designed for this purpose .
For example, imagine you need data durability in an application and you want to use Temporal or Dbos. The problem is that you will have to redesign the entire application to fit the structure of this framework. Which is not at all pleasing. So what if all of this was built into one framework, and you focused only on what mattered: data, interface, and value? This is exactly what we are trying to do with AppKit, which Victor will tell you about.
Yes. So the idea was that instead of these two bad options that we presented, a better alternative could be offered. That's how AppKit came about. "The hard parts built in" is a new framework for building applications. So, overall, the whole idea is pretty simple. It's like you have one piece of code that you get from AppKit, you can build an app, and then build it using what are called plugins. So you have a server, analytics, genify, tasks, and much more to come .

`06:15` AppKit plugin architecture: Analytics, Genie, Lakebase, Files

And each plugin is a certain function or feature. For example, a server-side plugin is a web server that can render your front-end as well as your backend, all at once. The analytics plugin is designed for database queries . You get analytical data. And others, for example, files for UC volumes, etc. The nice thing is that each of them has reliable default settings . So we are already processing a lot of things to some extent.
They are ready for production use from day one and are built for both humans and AI. And this is very interesting, we will talk about this in more detail. So, our goal is: you provide the logic, we take on the complex tasks. You've already seen the iceberg. So basically the idea was to flip the iceberg and instead of you focusing on the bottom part, which is the biggest and most complex part— especially if you're not an engineer, but, say, a product manager or someone on the customer service team who wants to be more data-savvy and build apps.
And now, with big AI language models, it's easy, which is actually a good thing. All those parts that you may not know how to work with or that you spend a lot of effort on. So, AppKit— the goal of AppKit is to take all of that on board. So you... the part you focus on is the smallest part: the business logic and interface of your application. We take care of security, real-time streams, retries, timeouts, which I know is very important.
We often hear about time- outs. And if you develop applications, you've probably already encountered timeout issues . I know this. Telemetry, reliability, scaling. AppKit takes care of all this, and you focus on what's important to you, frankly . So I'll try to be more specific. AppKit does a lot , but I'll highlight five things you no longer need to develop yourself. I divided them into main groups. The first is simply the right behavior, and the second is we are talking about the possibility of obtaining and AI-native.
So, first of all, everything works as expected. That is, it respects the access rights of each user. We handle OBO service principles. If you need to refresh the token, it's all handled, and there's zero authorization code in your app. You don't need to mess with this . We don't want you to do this because I know it's difficult. This is not easy. We know this. So, I can process this as expected. So the user only sees the data they are allowed to see.

`08:42` On-behalf-of-user authorization and token refresh

Which ones are they allowed to see? Another thing is streaming. Another thing that, as we know, is quite difficult to manage. Creating a true enterprise-grade streaming service for your application is not easy. You need to process a bunch of things. You need to manage the lifecycle, heartbeats, parsing, all the state management of the thread. You need to process all of this. And you also need to manage or restart the connection.
So if you log out, the browser closes, or something else, you need to reconnect to that stream. You don't need to run it all again. You need to send, for example, the ID of the last event, there are many things that need to be done to resume the flow. And also timeout management . A very common request we get is: "Can you increase the timeout?" This is not a solution to your problem. This is only a small mitigation, because if you have a larger data volume or a network outage, you will encounter a timeout again.
So what? Will you increase again? This is not an option. You are not solving the problem. You just don't want to or don't know exactly how to process it, which is okay because it's not easy. I mean, frankly . So, again , AppKit takes care of this . You have no problem with timeouts. You run a query and get the result. You receive a request. Don't worry. If it takes 1 minute, 10 minutes, or an hour, you will get a prompt.
And the third thing that's really cool: your SQL queries live in SQL files. They are isolated, which allows us to do more things. So, for example, parameterization and caching are already built in, which is very convenient in Lake Base. If your application has Lake Base connected and you use AppKit, every SQL query that takes a certain amount of time is automatically cached for you in Lake Base. You don't need to do anything about it at all .

`10:45` Automatic SQL query caching in Lakebase

And if you run the same query again or need that value again, it will already be in the cache. Many people do this, and many find it difficult to implement because you need to not only integrate Lake Base, but also configure cache management on the backend through Lake Base. Again, as I said, with the analytics plugin, we do all of this for you. The most surprising thing, in my opinion, is that all SQL files have end-to-end type generation: if you create a bad query that accesses a non-existent column, it will throw an error during development or build, not in production.
So, all this is done to ensure that the system works correctly. The second group of capabilities I talked about is native observability for AI. You get traces , logs, and spans in your OpenTelemetry sidecar. This works the moment you deploy your app and AppKit understands that you have enabled telemetry . This is a feature that is currently available in preview mode . I don't know if you've seen her yet. Turn it on. This is a really great feature.

`12:00` Native telemetry and observability for AppKit apps

If you use AppKit, it understands this and sends telemetry from all over AppKit. So all your requests, LLM agents, and in-app conversations are getting into the surveillance system via AppKit telemetry. This is a very powerful tool that requires no implementation on your part. Again , you don't need to configure anything . The only thing you need to do is enable the feature, otherwise nothing will work. And the last part, perhaps the most powerful, is that AppKit is natively AI-centric .
This means that from day one of development, we use multiple evaluation cycles where we apply LLM to analyze the impact of changes in Git on the performance of the models. So, we have the expected results . We create prompts, test their usage, and analyze the results. This is based on what we expect. This is bad, this is even worse, and so on. So, for every feature we develop, for every change, we do a lot of evaluations to make sure that LLMs know how to work with App Kit.
And the results are really good. And all of this creates a great foundation for what Mario is going to show us now —a real-time demonstration. Perfectly. I want this. I don't think I need it. Okay, so let's do a little... what? Let's do a live... um... Why am I... Why am I... What am I hearing? When I speak, I hear something. Okay. Ahem. Sorry. Okay. Hmm, cool. So, let me insert this before I explain while it's coming together.
Um, basically, I took the data from OpenFlights and loaded it into Databricks before that . Um, and I actually had to create this prompt. It's a little special because we have some network limitations here. Um, so to make it simpler, this is a warning that this app has already been built. It took exactly 6 minutes. Here it will take less time because everything is prepared. Um, but you can see Cursor here with our Databricks app skills prepared for App Kit.

`14:06` Live demo: building an agent app with Cursor and AppKit skills

He is compiling the application . Um, so when it's ready, we can explore the code a little bit. This is, in fact, the assembly process . As you saw earlier, the server is quite simple. He is making some changes. But this is the backend. There is nothing more . This is just the backend. Um, just add plugins there. You can also expand it and make more customizations, but out of the box, you only need a few things. This is the backend you need.
Nothing more, right? Um, then here, sorry, let me scroll a little . So, we'll have an agent in our app, as well as some analytics. And of course, we need a server to make all of this work . Um, what you see here is that he has some tools. I won't spoil what this tool does. Maybe you can guess from the name , but I wo n't reveal the secret yet. So now, if we go here, hopefully Cursor is done. Yes, okay. That's all you need to create an agent, okay?
It's just an agent in markdown format. Here you can determine what you need, what tools the agent should use. You see, I'm pointing out that you can use an analytics plugin and set global filters. Next, we have requests. You see the queries here are pretty simple. It's much easier, you know, to have syntax highlighting, and it's probably easier to define them here rather than inserting them directly into the code. So, we have a few queries here.
Okay, it's over. While it's finishing, let me open two terminals. First of all, I'm going to launch Oops. I'm going to run the deployment. And while it's deploying, one thing we have now: before deploying, the system checks if everything compiles and if everything passes. So when you deploy, you don't get errors in the service. This, you know, is a little annoying. So we provide this in advance to make the job more convenient.
So, let's launch, let's launch the app. What you see here is Sub Kitty, which generates types and uses a cache. Then, it's for servicing models. Here you have agents that are in your application. And here you can see all the endpoints. All of these endpoints are implemented by plugins. They work automatically , as soon as you add plugins, they just appear. So, let's open the app. Are you excited to see this? Good. So, here is the app.
Oh, sorry. Yes, let me open it up a little closer. Or, well, look, if I... So this is the app that we have, right? Looks good, doesn't it? We see that there are some filters here. We can, for example, say, "Okay, let's look at the United States." And the globe is changing. But this is an outdated approach, right? Why don't we just interact with our agent and ask them something. So, what am I looking at? I don't know if you see that or maybe it's too small.
But the agent has an application context. He knows what we see. He really tells me here all the routes connected to the United States. Perfectly. So, can you show me the internals, excuse me. routes for the United States. Let's say for the USA. Let's ask. Good. So the agent essentially interacts with the application, and I just ask questions. Hmm, I don't know. What, what do you think? What I think is cool is, right?
Perfectly. So, um, yeah. Let's run a few checks in the code. Um, yes. So, as we've already seen, um, okay. Cursor, please. What are you doing? Good. Yes, sometimes I don't know why it has a problem, for example, files disappear in the interface. Hmm, no problem. So, to sum it up , um, we just created an application with a server. Then we have global filtering tools that are designed to interact with the interface. And here are the types that we generate for you.

`20:07` Type-safe React frontend generated from your SQL queries

So when we go into the client in the frontend , which is essentially React, we can open, um, let me... Class. So, you can import components from AppKit. Um, we're using a hook here. And you can see what we're doing— let me maybe expand on that a little bit more. We just need to query against the query key we have. Um, so what we saw earlier, we have these requests in a folder, and we're just waiting for that specific request that we need.
And the cool thing about it is that if I do this, my editor already knows , if I do... Sorry. Down. Well, because. So, that's it. So, he already knows that it's an array. Suppose the element is zero. So, this is completely typed based on your queries. This is extremely useful for agents because they know exactly what data they are using. Now, why don't we test the deployment? Okay, deployment complete. So, let's open it.
Perfectly. So, we have Databricks running in Databricks. And it's the same thing , right? Um, let me show you a really cool feature that we have: I can use my local development environment and then use a remote server that's running. So I can mix them both, and I can actually run things in Databricks, like with all the proxies and stuff. Um, and I can see exactly how it will behave when the application is launched. So , let me move this to Cursor because I want to do something specific.
Oh, thank you. Good. So what you see here is that I have a parameter that says dev true. So, this loads my local resources. So anything I change in local resources will be reflected here. But this does not change the application itself. It only changes here, for me. So, I'll ask Cursor to change this to "demo flight." All of this uses hot reloading of the model. So the changes will appear here without a reboot or any other action.
We just need to wait for the Cursor. Perfectly. So, this is a change . Now, if I delete this, this is the actual deployed application. No changes, right? You can preview exactly what you will see before deployment. Ahem. Perfectly. There's something else, but I can't show it because we don't have two laptops to demonstrate. Or maybe there is, I don't know. But we also have a link sharing feature . You can share it with a colleague and they can click the link, and you will be prompted on your terminal to confirm whether you want to grant access.
If you approve, your colleague will see exactly what you see. And if you make any changes, he will see them in real time. I think this is a pretty cool feature for collaboration. And so, I think that's all . So now we can move on to... Yeah, I guess that's fine. Sorry. Okay, so this is ... Okay, and here it is. Sorry. Let me find... Where is it? Yes. So now we have this. Good. Perfectly. Should I run this? No, not me.
Yes. So, I want to show you something new, this is a kind of preview. Let me start here, great. Maybe you'll do a full screen. I don't know. Yes. Class. Right. Good. This is a preview of the test we are going to run here. This is a recording because it's difficult to show live— anything can happen during a test, and events may not appear in the order expected. So yes. I'll explain why. So, we have this app. It runs in production mode, which is a test of the application's stability .

`25:11` Crash recovery demo: resuming a long request after a restart

I want to execute a query called a synthetic aggregate query. This request takes about a minute or a little longer. It seems like 1 minute. So what I'm going to do is if you look here, we have a button, I don't know if you can see it well. Yes, this is not the best option, yes. Not the best option. So, actually, it's about what he does, for example, he " put" the server. You are blowing up the server, the node. js server, so the application will shut down.
So I run... the idea is to simulate a failure scenario. And failures can happen. Unfortunately, this can happen at any moment. This could be a failed deployment, a network outage, or something that happened in the pod. Different things happen. This can happen often. It will happen. So the idea is that I'm executing a query, something happened in the middle, right? As you can see, here the interface says: " Hey, I can't load the data because you no longer have a connection to the backend."
The frontend runs on the client side in your browser, so the client is still displayed, but if you look at our interface, it has already updated. And if you look here, it shows the status, which is "failed", right? So, the bottom line is that something happened. Imagine any scenario, any possible scenario that could happen, and I'll just start all over again . Imagine I fixed it, or I'll just redeploy my app. So, as you can see here, Uh, let's wait.
Okay, now. So, he stopped the app because the app was still running, just the backend of the app—no, but the concept of the app was still working . He is reassembling the application. He did the whole deployment process, all of it. And he launches the app. He launched the app again. I didn't update the browser, although I could have in this situation, but there's no point in doing so. And I click to start again. And the first thing that's interesting, as you can see below, is the so-called recovery.
So I'm not doing the same query to the repository yet. I am re-invoking the request based on the previous one. And a request that takes about 1 minute, even the first one, before the crash, took over 10 seconds . It was over in three because the deployment went pretty quickly. I didn't expect it to be so fast. That's why it was a bit difficult to do it live. So, as you can see, the meaning is already here. We're bringing it back.
So even if the entire app crashes, you won't lose anything . You didn't duplicate your work. You did not duplicate your calculations. And of course, you can apply this to SQL repository analytics, but also to agent cycles. And all this has its price. So yes , this is one of the demos we wanted to show. In fact, this is one of the new features that will appear in AppKit. And that's exactly what I want to talk about in a little more detail.
I think we know. I want to talk a little bit about what's coming up for AppKit, I have a lot of new features and even a new product. So, I want to talk a little more about sustainability. Resilience is probably the hardest part. Do you agree or not? As we have shown, we need to survive failure. The fact is that resilience is more evident today. Very clear today. The first main reason is that we have a larger surface area.

`28:30` Why resilience matters for long-running queries and agent loops

So, if a task takes 1 second and you are referring to normal Postgres transactions, that is 1 second of operation. This is 1 second of open connection and network operation. It's only 1 second. But now the task takes 30 minutes, 10 minutes, 1 hour. The larger the surface, the longer the query takes and the higher the chance of problems occurring. And the second reason why it's more obvious is that the experience is much more visible.
It's pretty simple. This is more tangible, sorry. It's more tangible. For example, if a task takes 1 second and fails, and your backend retries for some reason and everything works, the client will never notice. Maybe the user didn't even see it. Oh, it takes... No, it doesn't take 1 second anymore. This takes 2 seconds. No, he doesn't... He won't notice it. But if you wait 30 minutes and the task fails, you have to wait another 30 minutes— that's a big chunk of your life, and you have to do it all over again.
So this experience is very noticeable, and it's not a good thing. And the third reason why sustainability is more apparent is cost. The same. If you're accessing a database, a regular transaction, there's a good chance you have no idea how much it costs to perform a unit of work. How much does one select or insert cost in Postgres? Especially if you don't have a lot of data. But now, with SQL calculations and especially tokens, it becomes quite obvious.
You spend, say, $5 , $10, $100, $1,000 and you have to try again. It becomes obvious and you see, "Hey, you spent this and then you spent it again because you had to recycle." Therefore, it became quite clear to us that for AppKit we needed a so- called reliable execution engine. There are many options on the market , we have tried them all, well, almost all of them. But they all face two main problems. First, they are heavy.
Some of them are very difficult. And not only the driver itself, but also the dependencies. They rely on external infrastructure to operate. And that's not very good. Some of them require a separate cluster. You created an app in 5 minutes. And now you need a dedicated cluster to make this reliable? This doesn't make sense. Some require Kafka, S3, Foundation, ClickHouse, and many other external infrastructure. And each such service adds costs.
The cost of creating this was really low. And all this is much more expensive. And besides, who will manage all this? App developer? Does he know how to manage all this? So, this is not entirely appropriate. And those who consider themselves easy, which is quite common, are not suitable for long-term tasks. They are designed for standard workflows. That is, I clearly know what happened. We create a user, a profile, send an email, and every operation goes to the database.
This is quite understandable, because we know the classic workflows. And with agent cycles, things change, and they try to adapt their infrastructure to new development methods. The problem is that these changes concern the fundamentals. So changing it is not that easy. Some of them rely on an external database for streaming. Others don't even have streaming. Can you imagine the operation of an agent loop without streaming?
I don't think this will work well. So we decided to create our own engine. That's it. So basically the goal was that we needed something lightweight, because if you're building an app in 5 minutes, it has to be lightweight. If it is larger than your application, it is wrong. It should be built-in. It should work together with your application. Not in terms of resource consumption, but to be close to your application.
This is very important for the data collection infrastructure. No clusters, no brokers. This should be a library, not a new platform. It should be simple but effective. And it should be built for long-term tasks. So, streaming, partial progress, crash recovery. All of this should be thought about from day one, from the very basics. If streaming, if something we do affects it, we're doing something wrong. And the third, and this is the main opportunity, is that we own the entire stack.
This is true. We own all the infrastructure. We can do many things. So if you build our engine, you can, the engine can connect, integrate, and it can distribute data on its own. This is auto-sharding, an open source library for scaling resources. We can recover from OBO, which others can't, because OBO is essentially "on behalf of the user," meaning I'm using an access token generated at runtime, but it fails, and if it takes more than an hour, the access token might expire, so they can't recover from OBO.

`34:22` Task Flow: durable long-running tasks for Databricks apps

And we want that. Because you want people to only have access to what they need to have access to. So, based on all of this, we created Task Flow. Task Flow is a new product. This is a long-running execution engine for Databricks applications. It is optimized for long-term tasks, designed for our own infrastructure. And, essentially, you run private agent tasks. It doesn't matter how long it takes— seconds, minutes, or hours.
You stream progress, checkpoints, and if there's a crash, like I told you, in that demo I showed, the whole application crashed, and I ran it again, the application was working with Task Flow, it should recover and continue from the last state. So, this is one engine that you can do a lot with . This is in private preview, we actually released it privately this week. So if you are interested in using it, if you want to test it, if you have any problems with DBOS or "the boss", many say differently, temporal OS or any other, let us know.
Now, talk to anyone and you'll probably come across me. And yes, a nice feature of TestFlow is that it is one engine, but there are three ways to launch it. So , the first one that I've already shown is inside AppKit. So, you will be inside AppKit. So if you use AppKit, it will be in the kernel, so you don't need to worry about it. But if for some reason you don't have AppKit, but you have an application on Node. js.
Okay, we'll share , we have binary files that you can import into your application. And the third option, which you might not have expected , is Python. We also provide, it also compiles under Python. So, if you have a Python application, you can use that too. And yes, it's quite interesting. And the last thing I want to highlight is a few new things coming to AppKit. We do a lot of functions for BI. So if you have, for example, a toolbar that works a little awkwardly and you want: oh, AppKit can create a better experience, smoother, etc.
And we are adding many useful features for BI applications. For AppKit: native metrics catalogs, better write- back chart components, much better features focused on BI capabilities. So, if your BI dashboard is n't performing very well, there's a good chance that with all the automations that Matter has shown, you can quickly improve the performance of your dashboards. Another new feature is the database plugin. We have what we call a database connector, so integrating ClickHouse is pretty easy, but we want to do more than just make integration easy .
We want to make it easier to use your data. So if you use one schema, you generate routes, types, hooks, validation. OBO LS is built in so everything works really well and it's type safe so you can make requests safely from the server and browser. And you have to make sure that we handle all those primitives that I talked about: retries, timeouts, and all that. And the tasks that we've already talked about: long-lived tasks that can withstand failures, as I explained, no duplication of costs, you don't have to wait 30 minutes again, you don't spend more money on the agent cycle that burns tokens.
None of this. So, smart recovery is a recovery that does not need to be run again. And this is one of the many things we're adding to AppKit. Thank you, Victor. Okay, last slide. It is more of a call to action. If you want to build your first AppKit app, here is a command you can use in the CLI. Or you can open the documentation. I hope you can scan the QR code. There is a complete guide where you will find everything you need for AppKit.

`38:10` Build your first AppKit app

If you don't want to type commands, just install our tools and they will do it for you. So you don't need to enter any commands . Yes, thank you very much. And that was it.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.