React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.

react-native

Learn React-native

Use Expo Orbit to install past builds from EAS as well as from your local machine.

You can also use Orbit to easily view and launch all your connected simulators, emulators and physical devices.

🔗 [Expo Orbit](https://docs.expo.dev/build/orbit/)

Use Expo Orbit to Install Past Builds

Reconfigure your eas.json and app.json so you can install the development, preview and production builds all on the same device.

An app on your phone is uniquely identified by the bundle identifier on iOS and the package on Android, so to make the builds unique we have to make these IDs different based on the build profile.

📖 [Docs](https://docs.expo.dev/build-reference/variants/)

Install Multiple Variants of Your iOS and Android Apps on the Same Device

Set up credentials to upload your Android build to Google Play automatically.

For automatic uploads, you'll need to set up all the app metadata on your Google Play account, including setting up app assets. You'll also need to configure and set up a Google Service Account.

📝 [Create a Google Service Account](https://github.com/expo/fyi/blob/main/creating-google-service-account.md) 
📝 [Store Assets](https://docs.expo.dev/guides/store-assets/)
📝 [EAS Submit Docs](https://docs.expo.dev/submit/introduction/)

Upload an Android App to the Google Play Store Automatically using Expo Publish

Set the build number to increment automatically and learn when to increment version numbers.

While you’re developing your app, when you submit an app with a specific version + version code to the App or Play Store, you cannot submit another app with the same values.

The best practice is to set the build number to increment automatically.

The version number can be incremented manually after each store release.

📖 [Docs](https://docs.expo.dev/build-reference/app-versions/)

Increment Version and Build Numbers for iOS and Android apps using EAS

Create the app on the Google Play Store, create the first production build on EAS, upload it to Google Play, and publish it to an internal testing group.

For sharing apps via Google Play, you will need a paid Google Play developer account. It is preferable to have an organisation account if you're looking to monetise your app (you'll need to verify your organisation before you can create apps). But if you you are building apps as an individual developer, you can use the individual developer account. 

When creating an individual developer account, you have some additional restrictions:
1. You must submit proof of ID and home address to create the account
2. If you want to monetise your apps, your home address will be shown on the Google Play developer page
3. You will need 20 testers to test your app for 14 days before you can apply for production access

🎮 [Google Play Console](https://play.google.com/console)

🔗  [Register for a Google Play Developer account](https://support.google.com/googleplay/android-developer/answer/6112435)

🔗 [Required information to create a Play Console developer account](https://support.google.com/googleplay/android-developer/answer/13628312?hl=en-GB)

🔗 [QR Code Generator](https://www.qr-code-generator.com/)


Create an Android Release Build with EAS and Upload to Google Play Store

Create an Internal Distribution (Preview) build for sharing your app in internally in production mode.

This can be used to share your build with your team or testers without submitting it to Google Play.

📝 [Docs](https://docs.expo.dev/build/internal-distribution/)

Create an Internal Distribution Build for Android with EAS

Create a Development Build that runs on Android Emulator or Device.

This build can be used for local development on Android. You can use the same apk (the build artifact) on both an Emulator (that you can install via Android Studio) or on a real android device.

🔗 [Expo Website](https://expo.dev/)

📝 [Docs](https://docs.expo.dev/build/introduction/)

🔗 [Android Studio](https://developer.android.com/studio)

Create a Development Build for Android with EAS

Submit your Production Build to the Apple App Store and install it via TestFlight.

When submitting a build to Apple with EAS Submit (or otherwise), it will first get added to TestFlight which is essentially a pre-prod environment for Apple. This will allow you to install and share the actual production build to testers before releasing it to users.

App names on the Apple App Store must be globally unique. So if you've chosen a name for your app that is already taken - like Plants - you will have to choose a different name for the App Store Listing page. Note that this is only the case for the app name on the App Store listing page, and you can still use your preferred name elsewhere.

**TestFlight Internal Testing** - as soon as you upload your build to App Store Connect and it finished processing, it is available for internal testing. You can add users to the internal testing group by email, and the users must be registered on your Apple Developer account.

**TestFlight External Testing** - this is a separate testing group that allows you to share the build with anyone either by sending them an email invite or using an invite URL. Before you can share the build, you must first submit a build for external testing and wait for it to be approved by Apple, which usually takes a couple of hours.

**Release** - in order for the build to actually show up on the Apple App Store, you will need to create a Release on App Store connect and submit it for review. This review usually takes about a day.

🔗 [TestFlight](https://developer.apple.com/testflight/)

📝 [EAS Submit Docs](https://docs.expo.dev/submit/introduction/)

📝 [App Store Assets Docs](https://docs.expo.dev/guides/store-assets/)

Submit an iOS App to the Apple App Store and TestFlight using EAS

Create an iOS Release build for distribution.

This build gets submitted to the Apple and can only be installed via TestFlight or the App Store.

Create an iOS Release Build for the Apple App Store with EAS

Create an Internal Distribution (Preview) build for sharing your app in internally in production mode.

This is the only way to share your iPhone app without submitting it to TestFlight and is often used for QA testing or internal demos.

📝 [Docs](https://docs.expo.dev/build/internal-distribution/)

Create an Internal Distribution Build for iPhone with EAS

Create a build to run on your physical iPhone device that can also be used for local development.

📝 [Enabling Developer Mode](https://docs.expo.dev/guides/ios-developer-mode/)

📖 Further reading: [Push Notifications Docs](https://docs.expo.dev/push-notifications/overview/)

Create a Development Build for iPhone With EAS

Set up a Distribution certificate and an Ad Hoc provisioning profile for iOS internal distribution builds.

Here we learn how to sign Apple app builds to make them installable on Apple devices.

In order to install your own app on any Apple device, you need an Apple Developer account and a subscription to the Apple Developer Program.

🔗 [Apple Developer Program](https://developer.apple.com/programs/)

⚙️ [Code Signing Illustration](https://www.linkedin.com/posts/kadi-kraman_an-illustration-of-what-code-signing-with-activity-7132420058076581888-s6TM)

Use the EAS CLI to Configure App Store Credentials for Internal Distribution Builds

Create an iOS build for developing locally on a Simulator.

This is the only native iOS build you can do on EAS without having an Apple Developer account and being enrolled in the Apple Developer Program.

It can be used for local development on an iOS simulator, so you can only do this on a Mac, because you must be able to install Xcode to get access to the iOS simulators.

⚙️ [Xcode](https://apps.apple.com/us/app/xcode/id497799835)

🔗 [Expo Website](https://expo.dev/)

📝 [Docs](https://docs.expo.dev/build/introduction/)

Create a Development Build for iOS Simulator with EAS

Set up an existing Expo Go project to use Development Builds.

Expo Go is a Sandbox Environment designed for learning prototyping and getting started with mobile development quickly. The major limitation of Expo Go is that you are completely unable to add or edit any native code in your app. This might be a trivial limitation at the start of your project when you're prototyping and experimenting, but most production quality apps will eventually need to have more control over their native app bundles.

This is where development builds come in. A development build is basically your own customised version of Expo Go: you build the native side of your app yourself and get to have all the control over what libraries and configurations are included.

Thanks to CNG (with prebuild) the native projects are generated automatically based off of your app config and package.json.

📝 [Expo Go](https://docs.expo.dev/get-started/expo-go/)

📝 [Development Builds](https://docs.expo.dev/develop/development-builds/introduction/)

📝 [Continuous Native Generation (CNG)](https://docs.expo.dev/workflow/continuous-native-generation/)

Set Up Your Expo Go Project to Use Development Builds

Create a new React Native project using the Expo CLI.

You can use any of the supported package managers: **npm**, **yarn**, **pnpm** or **bun**. In the video (and throughout the course) we use **yarn**.

You can also choose a template to use for your project. In this video we choose the blank TypeScript template, but you can choose a different template if you prefer.

📝 [Docs](https://docs.expo.dev/get-started/installation/)

Create a React Native App With Expo CLI

Expo Application Services ([EAS](https://expo.dev/eas)) is a cloud build service used to build and publish React Native apps.

This course will show you how to create the common types of builds for iOS and Android on EAS. We'll cover Development builds for local development, Preview builds for internal testing, and Production builds for release.

Additionally, you'll learn about:
- app versioning
- automatic store uploads
- setting up store listing pages
- installing multiple app variants on the same device
- installing past builds with [Expo Orbit](https://docs.expo.dev/build/orbit/)

## iOS

An overview of build signing, and why an Apple Developer account needed in order to install builds on a real device.

How to create:
- an iOS simulator build
- a build to use on your device for local development
- a build to share with your team without uploading it to App Store Connect
- a release build to use on the App Store

You will also learn how to upload your build to App Store Connect, share it on TestFlight and create a Release.

## Android

How to create:
- a build to use for development on an emulator or a device
- a build to share with your team without uploading it to Google Play
- a release build to use ob Google Play

We'll cover what is needed to create a new Google Play account, and the current restrictions for individual accounts.

You will also learn how to set up auto-submit on Google Play.

Build and Deploy React Native Apps with Expo EAS

Start with a plain React Native app initialised using the React Native TypeScript template.

We will install and configure urql, use urql's useQuery hook to fetch all stories from the locally running graphQL API, and render them in a FlatList.

**Resources:**
- React Native TypeScript template: https://reactnative.dev/docs/typescript
- urql docs: https://formidable.com/open-source/urql/docs/

**Android:**
- run the app with `yarn android`
- use `http://10.0.2.2:3000/graphql` instead of `http://localhost:3000/graphql` for the API endpoint

**Checkpoint:**
- [Initial commit (create from template)](https://github.com/kadikraman/news-flash/commit/a04dccad8fa090b07fdf8a94f904ba7551448ead)
- [Add initial project (remove template UI code)](https://github.com/kadikraman/news-flash/commit/08a6d0f078b36f9e35a28f6a71175b8c2dd260ad) <-- video starts from here
- [Add urql and useQuery](https://github.com/kadikraman/news-flash/commit/66d6fcfb5b797da98456d4ff6e433ab6990207de)

Add urql to a React Native Project and Fetch Data With the useQuery Hook

Install React Navigation v6 and use the Bottom Tabs navigator to add two tabs to the app: the Home tab and the Bookmarks tab.

To do this, we'll wrap our app in a `NavigationContainer` component and set up the two tabs in that tab navigator. In the process, we'll convert our `Stories` component to be the `Home` page of our app.

**Resources:**
- React Navigation: https://reactnavigation.org/
- Bottom Tabs Navigator: https://reactnavigation.org/docs/bottom-tab-navigator/

**Expo:**
- If installing on an Expo managed project, install the dependencies with `expo install react-native-screens react-native-safe-area-context` - [read more](https://reactnavigation.org/docs/getting-started#installing-dependencies-into-an-expo-managed-project)

** Android:**
- If using plain React Native without Expo need to add some native code before rebuilding the app as described [here](https://reactnavigation.org/docs/getting-started#installing-dependencies-into-a-bare-react-native-project)
- Then rebuild the app with `yarn android`

**Checkpoint:** [Add a bottom tabs navigator](https://github.com/kadikraman/news-flash/commit/443cc44108a0bd9f6a00952191a2d9bdd892b6ea)

Add Bottom Tabs to a React Native App with React Navigation v6

We'll use the Stack Navigator from React Navigation v6 to display a modal for the story details page.

Then add TypeScript types for the navigation state to ensure correct typing.

**Resources:**
- React Navigation: https://reactnavigation.org/
- Stack Navigator: https://reactnavigation.org/docs/stack-navigator/

**Checkpoint:** [Add a story details modal](https://github.com/kadikraman/news-flash/commit/2eecf76fcb536cf6affe597e87c3b05d1ffe2bf2)

Add a Modal with Typed Navigation to a React Native App with React Navigation v6

We will update the TypeScript types to support passing variables between screens. Pass the story ID and title to the modal screen. Display the story title on the modal title. Use the ID from the screen params to fetch the full story details in the story details modal.

**Resources:**
- urql `useQuery` hook: https://formidable.com/open-source/urql/docs/api/urql/#usequery

**Checkpoint:** [Fetch story details](https://github.com/kadikraman/news-flash/commit/caabca1bf9e7e6e33276e636f9cdd5bd63fc583c)

Add GraphQL Query Args with urql's useQuery Hook

We'll refactor the Story out to a separate component, create a fragment for the story fields and reuse the fragment in the bookmarks query.

We'll see how using Fragments makes it easy to query for data throughout our application.


Fragments: https://graphql.org/learn/queries/#fragments

Use GraphQL Fragments to Query Same Fields on Multiple Queries in React Native

Hardcoding your script to search for only one type of file (like `.md`) is a major limitation. This lesson shows you how to make your script smarter by teaching it to infer the desired file type directly from the user's natural language prompt.

You'll implement a two-stage AI process. The first stage analyzes the user's request to determine the file extension they're interested in (e.g., `md`, `txt`). The second stage then uses that file type to dynamically search the file system, find the relevant files, and execute the command.

**Workflow demonstrated in this lesson:**

* Add a preliminary `generateObject` call to extract a `fileType` from the user's initial prompt.
* Define a list of supported `fileTypes` (e.g., `['md', 'txt']`) and use a detailed prompt to guide the AI, instructing it to choose from the list or use a default.
* Dynamically construct the `globby` pattern using the inferred `fileType` (e.g., `*.$[fileType]`).
* Implement error handling to inform the user if they request an unsupported file type or if no files of the specified type are found.
* Demonstrate how the script defaults to searching for Markdown files but can correctly search for other types when specified (e.g., "summarize my profile from my pdf").

This technique adds a significant layer of intelligence to your script, allowing it to adapt its behavior based on the user's intent and making it a far more flexible and intuitive command-line tool.

John Lindquist

Dynamically Inferring File Types from User Prompts in Local AI Scripts

Hardcoding command logic and prompts directly into your script makes it rigid and difficult to extend. This lesson demonstrates a more flexible and powerful pattern: defining your script's commands as individual Markdown files in a dedicated directory.

This approach allows you to easily add, remove, or modify commands without touching the core script logic. You'll learn how to dynamically load these command files, present them as options to the AI, and inject the corresponding instructions into your prompt, creating a truly modular and extensible tool.

**Workflow demonstrated in this lesson:**

* Create a `commands` directory to house your command definitions (e.g., `summarize.md`, `translate.md`).
* In each file, write the specific prompt or instructions for that command.
* Use `globby` to discover all available command files at runtime.
* Create a `commandMap` that maps the filename (e.g., "summarize") to its file content.
* Update the Zod schema to use an `enum` of the dynamically discovered command names.
* Dynamically construct the final text generation prompt by injecting the instructions from the user-selected command file.
* Add a `profile.md` file to demonstrate how the script can act on user-created content with the new file-based commands.

By the end of this lesson, your script will be architected for easy expansion, allowing you to build a robust library of custom commands simply by adding new text files.

Creating Dynamic, File-Based Commands for Local AI Scripts

AI models won't always give you the answer you expect; sometimes they'll return invalid data or "hallucinate" a response that doesn't fit your schema. This lesson teaches you how to make your local AI script more robust by implementing essential error handling for user commands.

You'll learn how to validate the AI's output against a predefined list of valid commands and gracefully catch errors when the model generates an unexpected response, ensuring your script fails predictably and provides helpful feedback to the user.

**Workflow demonstrated in this lesson:**

* Define a list of `validCommands` (e.g., `summarize`, `translate`, `review`) to constrain the AI's choices.
* Wrap the `generateObject` call in a `try...catch` block to handle cases where the AI's output doesn't match the Zod schema.
* Implement a type guard function (`isValidCommand`) to check if the command returned by the AI is in your list of valid commands.
* Provide clear error messages to the user, indicating what went wrong and what the valid commands are.
* Test the script with invalid commands (like "taco" or "delete") to confirm that the error handling works as expected.

By adding these checks, you make your script significantly more reliable and user-friendly, preventing it from crashing on bad input and guiding the user toward correct usage.

Handling Invalid Commands and AI Errors in Local Scripts

Once your script can understand a user's command and identify a target file, the next step is to perform an action. This lesson shows you how to use the Vercel AI SDK's `generateText` function to process a file's content and produce a relevant, AI-generated response.

You'll learn how to read the content from the file path you've already identified, combine it with the inferred command into a new, more detailed prompt, and then pass it back to your local AI model to generate a final text output, such as a summary or a review.

**Workflow demonstrated in this lesson:**

* Import the `generateText` function from the `ai` SDK.
* Read the file content from the `filePath` returned by `generateObject`.
* Construct a new, structured prompt that includes the original command (e.g., "summarize") and the full content of the file.
* Pass this new prompt to the `generateText` function.
* Log the resulting AI-generated text to the console.
* Run the script with commands like "Summarize our TypeScript config" or "Review my package file" to see the full, context-aware output.

This lesson completes the core cycle of your AI script: understanding a command, reading the relevant context, and generating a useful, text-based result, all on your local machine.

Generating Text with a Local AI Model Based on File Content

A command is useless without knowing what to act upon. This lesson elevates your local AI script by giving it context from your project's file system. You'll learn how to find all relevant files and empower the AI to intelligently select the correct one based on your prompt.

The core technique involves using the `globby` package to scan for files and then feeding that list into a Zod `enum`. This constrains the AI's choices to a valid set of files, allowing it to accurately determine which file you're referring to in a natural language command.

**Workflow demonstrated in this lesson:**

* Install and import the `globby` library to find files based on a pattern (e.g., all `.json` files).
* Add a `filePath` field to your Zod schema.
* Define the `filePath` as `z.enum(files)`, where `files` is the array of file paths returned by `globby`.
* Pass a natural language prompt like "Summarize our typescript config" to the script.
* Observe how the AI correctly identifies `tsconfig.json` from the list of available JSON files and returns it as structured data.

This lesson is a crucial step toward building powerful, context-aware tools that can intelligently interact with your project's files based on simple, human-readable commands.

Providing File System Context to Local AI Scripts with Globby and Zod Enums

Hardcoded prompts are great for testing, but a truly useful script needs to respond to dynamic user input. This lesson shows you how to make your local AI script interactive by capturing command-line arguments.

You'll learn how to use Node.js's built-in `parseArgs` utility to take a user's natural language command directly from the terminal and pass it to your local language model for processing.

**Workflow demonstrated in this lesson:**

* Import the `parseArgs` function from the `node:util` module.
* Configure `parseArgs` to accept positional arguments from the command line.
* Replace the static, hardcoded prompt with the dynamic input provided by the user.
* Run the script with different sentences (e.g., `"Download a file"` or `"I want to download a file"`) to demonstrate that the AI can correctly infer the core command regardless of the phrasing.

By the end of this short lesson, your script will be able to accept and process commands directly from the user, making it a flexible and reusable command-line tool.

Processing Dynamic User Input in Local AI Scripts

While command-line chats with local AI models are useful, the real power comes from scripting. This lesson walks you through the initial setup for creating powerful, local AI-driven scripts by combining Ollama, the Vercel AI SDK, and Zod.

You'll learn how to take a natural language command, like "Concatenate all of the markdown files in my Downloads folder into a single file," and use the `generateObject` function to intelligently extract structured, actionable data from it.

**Workflow demonstrated in this lesson:**

* Install and set up the `ollama-ai-provider`, `ai`, and `zod` packages.
* Create a local AI model instance using Ollama and the Gemma 3 model.
* Define a Zod schema to specify the exact data structure you want to extract (e.g., `{ command: string }`).
* Use `generateObject` to pass a natural language prompt to the local model and receive a structured JSON object that matches your schema.
* Run the script using `bun` to see the local model successfully infer the "concatenate" command from a full sentence.

This foundational lesson unlocks the ability to build sophisticated, automated workflows by translating human language into machine-readable commands, all running entirely on your local machine.

Scripting Local Language Models with Ollama and the Vercel AI SDK

### **Build Powerful, Local AI-Driven Command-Line Scripts**

Go beyond simple AI chats and unlock the true potential of local language models by learning to script them. This course will guide you step-by-step through the process of building a flexible and intelligent command-line tool that can understand natural language, interact with your file system, and automate complex tasks—all running entirely on your local machine.

Starting with a blank TypeScript file, you'll learn how to combine the power of **Ollama**, the **Vercel AI SDK**, and **Zod** to create a script that's not just functional, but smart. We'll begin by teaching the AI to parse a simple command from a sentence. From there, we'll progressively add layers of sophistication: processing dynamic user input, making the script aware of your project's files, and generating meaningful text-based output.

You'll also learn critical patterns for building robust and extensible tools. We'll cover how to handle invalid commands and unexpected AI responses gracefully. Then, you'll refactor the script to use a modular, file-based system for its commands, allowing you to easily add new functionality without touching the core logic. Finally, we'll add a layer of intelligence that allows your script to infer exactly what you mean, right down to the type of file you want it to process.

By the end of this course, you will have built a powerful, personalized AI assistant and gained the foundational skills to create sophisticated local automations for any task you can imagine.

**What You'll Learn:**

* How to script local language models using Ollama and the Vercel AI SDK.
* To parse and process dynamic user input from the command line.
* To use Zod schemas, including `enums`, to validate and structure AI model output.
* Techniques for providing file-system context to your scripts with `globby`.
* How to generate context-aware text based on file content.
* Robust error handling for invalid user commands and unexpected AI responses.
* To build a modular and extensible tool by defining commands in separate files.
* To intelligently infer user intent, such as dynamically determining file types from a prompt.

Build a local AI-powered command-line assistant from scratch. Learn to use Ollama, Vercel AI SDK & Zod to parse input, automate tasks, and run scripts offline.

This lesson demonstrates how to give Cursor direct access to your terminal output using the [Nx MCP extension](https://nx.dev/getting-started/ai-integration?utm_source=youtube&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI), enabling automatic error detection and fixing in monorepo projects.

**Workflow demonstrated in this lesson:**

- Encounter a runtime error when serving a Vite application in an Nx monorepo
- Install and configure the Nx Console extension with MCP integration
- Ask Cursor to check your terminal for errors and fix the underlying issues
- Watch as the AI accesses running task details and terminal output through Nx MCP tools
- Observe how it analyzes workspace relationships to identify incorrect imports and missing dependencies

**Key benefits:**

- Seamless Error Handling: AI gains direct access to terminal output and running task information
- Automatic Diagnosis: Accurately identify the root cause of errors without manual copying
- Context-Aware Fixes: Leverage workspace knowledge to implement proper solutions
- Reduced Context Switching: Eliminate the need to manually relay information between terminal and AI



Juri Strumpflohner

Enable Cursor to directly access the terminal to read the output and fix issues

See how Nx MCP gives AI coding assistants direct access to terminal output and running tasks, enabling automatic error detection and fixing.

This lesson demonstrates how to solve the predictability problem when using AI to generate code in monorepos by combining Cursor with Nx generators.

**Workflow demonstrated in this lesson:**

- Explore how Nx generators provide predictable scaffolding for new libraries
- Set up [Nx Console with MCP](https://nx.dev/features/enhance-AI?utm_source=egghead&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI) integration to expose generator capabilities to Cursor
- Use the AI assistant to brainstorm a new feature with the help of the Nx MCP tools
- Have Cursor leverage the Nx MCP tools to trigger the appropriate Nx generator for creating a React-based feature library
- Observe how the AI assistant takes the generated library and further integrates it into the codebase

**Key benefits:**

- **Predictable Code Structure**: Ensure generated libraries follow your project's and organization's conventions
- **Consistent Setup**: Maintain uniform configuration across TypeScript projects and package.json files
- **Guided Implementation**: Combine AI instructions with structured, predictable code generation

Enable Cursor to generate predictable project setups

Learn how to combine Cursor AI with Nx generators for predictable library creation in monorepos, ensuring consistent structure across your codebase.

React Native

Search Results