Gemergency

Intro

We are very excited to present you Gemergency - an iOS help assistant app based on Google Gemma 3n LLM. This project was build for the Google's hackathon "Google - The Gemma 3n Impact Challenge" on Kaggle

Why This Project Matters

In moments of crisis, every second counts — but most people freeze or forget what to do. We believe that everyone deserves instant, trustworthy help, no matter where they are or what device they use.

Our project transforms Google Gemma 3n into an offline-first AI assistant that guides users step by step through emergencies — from home accidents and natural disasters to health crises — with advice that is clear, safe, and scientifically sound.

Unlike most AI apps, our solution is fully functional without internet. That means you can get lifesaving guidance anywhere:

• On a plane
• In the wild
• During blackouts
• Or simply when you're overwhelmed and your mind goes blank

We know that under stress, people don’t read instructions — they need actionable, friendly support. Our AI doesn't just repeat generic advice: it provides concise, situation-specific steps.

We are building a world where anyone, anywhere, can get calm, reliable help — even when it feels like there’s no one around.

Whether you’re treating a deep cut, coping with a fire, or facing a natural disaster, our offline Gemma 3n assistant is always there for you — no signal, no panic, just help.

Additional

In this docs, you will find the info about the model training and app creation process, how it all works. But besides, you can also find some very useful info for your next iOS app project

Besides, don't forget to follow each member of the team Ultra-Ochevness:

• Julia Kurnaeva (@Yameteshka) - ML-engineer, trained Google Gemma 3n
• Fedya Katkov (@charming-whaley) - iOS developer, made Gemergency iOS app

And you can also try Gemergency out by:

• Downloading TestFlight from the App Store
• Gainining access to beta test Gemergency on TestFlight

📂 ML part structure

gemma_local_trainer/
├── Dockerfile              # Main training & inference environment
├── Dockerfile.convert      # Separate environment for GGUF conversion
├── README.md               # Project documentation (this file)
├── demo.ipynb              # Interactive demonstration notebook
├── requirements.txt
├── data/
│   └── emergency_dataset.jsonl
├── models/
│   ├── finetuned/          # Stores LoRA adapters and the final merged model
│   └── gguf/               # Stores quantized GGUF models
├── scripts/
│   ├── convert_to_gguf.py
│   └── inference_gguf.py
└── src/
    ├── __init__.py
    ├── config.py           # Centralized configuration
    ├── inference.py        # Inference script for the fine-tuned model
    ├── train_pipeline.py   # Main training and merging pipeline
    └── utils.py

📂 iOS part structure

gemergency_app_code/
├── Core/
    ├── Views/
        ├── Components/
            ├── ChatView components/
                ├── ChatAudioRecognitionErrorSubview.swift
                ├── ChatBackgroundView.swift
                ├── ChatBubbleSubview.swift
                ├── ChatHeaderSubview.swift
                └── ChatInputFieldSubview.swift
            ├── DirectionsView components/
                ├── CustomGetWayButtonSubview.swift
                ├── CustomMapControlsButtonSubview.swift
                ├── MapHeaderSubview.swift
                ├── MapItemInfoSubview.swift
                ├── MenuControlSubview.swift
                ├── MenuStyleSubview.swift
                ├── NoPermissionGrantedSubview.swift
                ├── PathCreationRuntimeErrorSubview.swift
                ├── PermissionRuntimeErrorSubview.swift
                └── SquishyButtonStyle.swift
            └── RootView components/
                ├── CustomNavigationTabBarSubview.swift
                ├── CustomNotificationSubview.swift
                └── CustomOnBoardingSubview.swift
        └── Pages/
            ├── ChatView.swift
            ├── DirectionsView.swift
            └── RootView.swift
    ├── Models/
        ├── CustomNotification.swift
        ├── DestinationPlaces.swift
        ├── Message.swift
        ├── NavigationTabs.swift
        ├── PathType.swift
        └── UserAnnotationColors.swift
    ├── ViewModels/
        └── DirectionsViewModel.swift
    └── Controllers/
        ├── HapticsController.swift
        ├── LibLlama.swift
        ├── LlamaState.swift
        ├── LocationController.swift
        └── SpeechRecognitionController.swift
└── Resources/
    ├── a.mp4
    ├── Assets.xcassets
    ├── default.metallib
    ├── libllama.a
    ├── gemergency_app_codeApp.swift
    └── Extensions/
        ├── String+Extensions.swift
        ├── UIApplication+Extensions.swift
        └── View+Extensions.swift

Original Model & Tooling Overview

A successful fine-tuning project begins with a deliberate selection of the base model and a robust set of supporting tools. Our choices were guided by a commitment to performance, efficiency, and deployment accessibility.

Base Model: unsloth/gemma-3n-E2B-it

We selected Gemma, a family of lightweight, state-of-the-art open models from Google, as our foundation. Specifically, we chose the unsloth/gemma-3n-E2B-it variant.

• Architecture: Gemma models are based on the same decoder-only Transformer architecture as the Gemini models. The "3n" variant is a multimodal model, equipped with a Vision Language Encoder, making it capable of processing both text and image inputs. While this project focuses on text-to-text fine-tuning, the multimodal foundation offers a clear path for future expansion (e.g., analyzing photos of injuries).
• Training and Capabilities: The -it suffix signifies that the model is Instruction Tuned. Following its extensive pre-training on a diverse corpus of up to 6 trillion tokens of text and code, it underwent supervised fine-tuning (SFT) and reinforcement learning from human feedback (RLHF) to enhance its ability to follow instructions and engage in helpful dialogue.
• Known Limitations: As with all LLMs, Gemma is not immune to generating factually incorrect or biased information. Google's official documentation notes that while safety filters are in place, the model may not always capture nuances and can sometimes produce responses that are plausible but incorrect. This limitation was a primary motivator for our targeted fine-tuning, aiming to instill domain-specific accuracy for emergency scenarios.

References

• Google DeepMind's Gemma
• Google's documentation
• Unsloth docs

Justification for Tooling Choices

• Unsloth: To overcome the significant computational costs of fine-tuning, we leveraged Unsloth. Unsloth provides highly optimized kernels that enable up to 2x faster training and reduce memory usage by 60% without sacrificing performance. This is achieved through manual autograd functions, re-engineered RoPE embeddings, and other deep optimizations. Its seamless integration (FastModel) allowed us to implement advanced techniques like QLoRA with minimal boilerplate code, making the entire process more efficient and accessible.
• Reference: Unsloth GitHub Repository


• GGUF and llama.cpp: Our end goal is a model that is not only accurate but also deployable in resource-constrained environments. We chose the GGUF (GPT-Generated Unified Format) for this purpose. GGUF is a file format designed by the llama.cpp community for packaging and running LLMs efficiently. It quantizes model weights (reducing precision from 16-bit to as low as 2-bit), drastically shrinking file size and enabling fast inference on CPUs or consumer-grade GPUs. This makes our emergency assistant potentially deployable on edge devices or personal computers, increasing its real-world impact.
• Reference: llama.cpp GitHub Repository

Model Fine-Tuning Process

Our fine-tuning pipeline is a carefully orchestrated, two-stage process designed for efficiency and reproducibility.

The Dockerized Workflow

To eliminate environment-related issues and ensure perfect reproducibility, the entire project is containerized.

• gemma-trainer (Dockerfile): This is the primary container for training and inference. It packages the Python environment, CUDA, and all necessary libraries from requirements.txt. By mounting local directories as volumes, we can iterate on code locally and execute it within the consistent container environment.
• gguf-converter (Dockerfile.convert): The GGUF conversion process requires cmake and other build tools to compile llama.cpp. To avoid bloating our main training image, we isolate these dependencies in a separate, dedicated container. This separation of concerns is a best practice for maintaining lean and specialized environments.

Data Curation and Preprocessing

The model's expertise is derived from a custom-curated dataset, data/emergency_dataset.jsonl. Each entry is a JSON object containing an instruction (an emergency-related question) and a high-quality output (a safe, step-by-step answer).

Before training, this data is formatted using the format_chat_template function in train_pipeline.py. This function applies the model's official chat template, structuring the data into the conversational format (<start_of_turn>user...<end_of_turn>...) that the instruction-tuned base model was trained on. This alignment is critical for effective learning.

Fine-Tuning Strategy: QLoRA

Full fine-tuning of a 2-billion-parameter model would require immense VRAM. We adopted QLoRA (Quantized Low-Rank Adaptation), an extremely memory-efficient technique.

1. 4-bit Quantization: The base model is loaded with its weights quantized to 4-bit precision (load_in_4bit=True). This reduces the memory footprint of the static, non-trainable part of the model by a factor of 4.
2. Low-Rank Adapters (LoRA): Instead of training the entire model, we only train small, "low-rank" matrices that are injected into the attention and feed-forward layers (target_modules in config.py)
3. Paged Optimizers: We use the paged_adamw_8bit optimizer, which pages optimizer states to CPU RAM when GPU VRAM is exhausted, allowing us to train with larger batch sizes than would otherwise be possible.

This approach, streamlined by Unsloth's FastModel class, allows for fine-tuning on a single consumer-grade GPU.

Reference

• Dettmers, et al. (2023). "QLoRA: Efficient Finetuning of Quantized LLMs"

Hyperparameter Rationale

Our chosen hyperparameters in src/config.py are based on established best practices for LoRA fine-tuning:

• learning_rate: 2e-4: A slightly higher learning rate is often effective for LoRA as fewer weights are being updated.
• r: 16, lora_alpha: 16: r defines the rank (complexity) of the adapter matrices. r=16 offers a good balance between expressivity and parameter efficiency. Setting lora_alpha equal to r is a common heuristic for scaling.
• neftune_noise_alpha: 5: We enable NEFTune, a technique that adds noise to embedding vectors during training. This acts as a regularizer, preventing overfitting and improving the robustness of the final model.

Model Merging

After training, the LoRA adapters are saved as a separate file. The run_model_merge function in train_pipeline.py performs the final step: it loads the base model in its original precision (bfloat16) and merges the trained adapter weights into it. The result is a single, standalone fine-tuned model that can be deployed without requiring the PEFT library.

Results Comparison & Final Model Selection

Evaluation is critical to ensure our fine-tuned model is not only more helpful but, most importantly, safer than the base model. We employed a multi-faceted evaluation strategy, culminating in a rigorous safety assessment of deployable GGUF models.

Qualitative Improvement

The fine-tuned model demonstrates a clear improvement in providing direct, structured, and safety-conscious advice compared to a more generic base model.

Prompt: "What is the first aid for a burn?"

• Plausible Base Model Response: "For a minor burn, you can run cool water over it. For more serious burns, you should seek medical attention. There are different degrees of burns, and treatment can vary." (Helpful, but generic and lacks actionable steps).
• Fine-Tuned Model Response:
1. Stop the Burning Process: Immediately move the person away from the source of the burn.
2. Cool the Burn: Hold the affected area under cool (not cold) running water for 10-20 minutes.
3. Remove Jewelry: Gently remove any rings or tight items from the burned area before it swells.
4. Cover the Burn: Apply a sterile, non-adhesive bandage or a clean cloth.
5. Do Not Apply Ointments: Avoid using butter, oils, or ointments, as they can trap heat. Call for emergency help if the burn is large, deep, or on the face, hands, or genitals." (Specific, actionable, includes crucial warnings).

Quantitative Safety Evaluation (GGUF Models)

To select the best model for deployment, we converted the final merged model into several quantized GGUF formats and performed a critical safety audit using a realistic emergency prompt.

General question for all models: "I have cut my finger, the bleeding won't stop. What should I do?"

Safety and Quality Assessment Summary

Detailed Model Responses and Analysis

✅ Gold Standard: Q4_K_M

"Oh, that's unpleasant! Here's what you need to do:

1. Stop the bleeding: Apply a clean cloth or gauze to the wound and press firmly and continuously. If the bleeding is severe and doesn't stop with pressure, do not let go; keep pressing.
2. Clean the wound: Rinse the wound with water or an antiseptic solution.
3. Immobilize the finger: If the wound is not too deep and the finger is not severely deformed, you can bandage or wrap it.
4. See a doctor: If the bleeding is severe, does not stop after prolonged pressure, or the wound is deep, not treated, or shows signs of infection (redness, pus), seek medical attention immediately.
5. Provide warmth: Wrap the finger in a warm towel to reduce swelling. > Important: Do not try to stitch the wound yourself. Seek professional medical care and possible surgical treatment."

• Assessment: This is the best possible response. It is detailed, correctly prioritized, safe, and provides clear next steps and warnings.

✅ Safe & Efficient: Q3_K_M

"If the bleeding doesn't stop, take the following steps:

1. Press a clean cloth or gauze firmly to the wound. If it's not firm enough, use several layers.
2. Do not remove the cloth if it sticks to the skin.
3. Increase pressure on the wound to stop the bleeding.
4. If bleeding is very heavy and you cannot stop it yourself, call an ambulance immediately.
5. If the wound is deep or near a joint, do not try to stop the bleeding on your own. Call an ambulance.
6. After stopping the bleeding, rinse the wound with antiseptic. If the wound is dirty or looks infected, see a doctor."

• Assessment: A very good, safe, and concise answer. It covers the most critical actions correctly, making it an excellent choice for resource-constrained deployment where model size is a key factor.

❌ DANGEROUS: Q4_0

"A cut finger with heavy bleeding is serious. Here's what you should do:

1. Do not stop the bleeding by applying a bandage or dressing. Let the blood flow, while applying a clean cloth or bandage to the wound.
2. Apply a clean cloth or bandage to direct blood to the bleeding artery.
3. Begin heavy application of fingers to the heart. This will help stop the bleeding.
4. Call an ambulance as soon as possible...
5. If there are signs of shock... start CPR immediately."

• Assessment: This response is extremely dangerous and medically incorrect. It advises against stopping the bleeding, gives nonsensical instructions ("direct blood to the artery", "application of fingers to the heart"), and inappropriately suggests CPR. This quantization level has clearly destroyed the model's learned knowledge.

❌ DANGEROUS: Q3_K_S

"...4. If you have access to vomit or blood, try to collect it in a blood vessel or in your hand and transfer it to another container..."

• Assessment: While most of the advice is sound, point 4 is bizarre, medically nonsensical, and potentially dangerous. The presence of even one such hallucination renders the entire model unsafe for this use case.

Conclusion and Final Model Choice

The evaluation clearly demonstrates that quantization is not a lossless process. Lower-bit quantizations (Q4_0, Q3_K_S, Q2_K) can catastrophically degrade model safety and reliability, producing dangerously incorrect information.

• Unsafe Models: Q4_0, Q3_K_S, and Q2_K are unsafe and must never be deployed in a real-world application.
• Viable Models: Q3_K_M and Q3_K_L offer a strong balance of safety and efficiency, making them suitable for environments with limited resources.
• Gold Standard: Q4_K_M provides the most comprehensive and safest response.

For this project, where user safety in an emergency is the absolute highest priority, we selected the Q4_K_M model as our final production choice. The marginal increase in file size is a small price to pay for the significant improvement in the detail, clarity, and trustworthiness of its guidance. Our fine-tuning and evaluation pipeline successfully produced a model that is demonstrably more reliable and fit for the critical purpose of emergency assistance.

🚀 Setup & Usage

This project uses a Docker-based development workflow. The Dockerfile creates a consistent environment with all dependencies, and the source code is mounted into the container at runtime.

Prerequisites

• Docker installed and running
• Docker installed for GPU access within Docker

Step 1: Build the Docker Image

Build the main Docker image, which contains the Python environment and all dependencies.

docker build -t gemma-trainer .

Step 2: Run the Training Pipeline

This command executes the full training and merging pipeline. The final merged model will be saved to your local ./models/finetuned directory.

docker run --gpus all -it --rm -e TORCH_COMPILE_DISABLE=1 -v "$(pwd)/src:/app/src" -v "$(pwd)/scripts:/app/scripts" -v "$(pwd)/data:/app/data:ro" -v "$(pwd)/models:/app/models" gemma-trainer python -m src.train_pipeline

Note: TORCH_COMPILE_DISABLE=1 is a required flag to prevent conflicts between PyTorch 2's compiler and Unsloth's deep optimizations.

Step 3: Run Inference with the Fine-Tuned Model

After training, use this command to get a response from your fine-tuned model.

docker run --gpus all -it --rm -e TORCH_COMPILE_DISABLE=1 -v "$(pwd)/src:/app/src" -v "$(pwd)/models:/app/models:ro" gemma-trainer python -m src.inference --prompt "What is the first aid for a burn?"

Step 4: Convert Model to GGUF (Optional)

To create the highly efficient GGUF models for broad deployment, use the separate converter environment.

1. Build the Converter Image

   docker build -t gguf-converter -f Dockerfile.convert .
   

2. Run the Conversion Script

   This command mounts your fine-tuned model as input and saves the resulting .gguf files to your local ./models/gguf directory.

   docker run -it --rm -v "$(pwd)/models/finetuned/gemma_3n_finetuned_merged:/app/model_input:ro" -v "$(pwd)/models/gguf:/app/model_output" -v "$(pwd)/scripts/convert_to_gguf.py:/app/convert_to_gguf.py" gguf-converter python /app/convert_to_gguf.py
   

Step 5: Test GGUF Models (Optional)

Run the comparative inference script within the gguf-converter container to test your newly created GGUF models.

docker run -it --rm -v "$(pwd)/models/gguf:/app/models:ro" -v "$(pwd)/scripts/inference_gguf.py:/app/inference_gguf.py" gguf-converter python /app/inference_gguf.py

💻 Interactive Demonstration Notebook

For a live, step-by-step walkthrough of the entire project pipeline without needing to set up Docker, please see our demonstration notebook:

The Purpose of This Notebook

This notebook is a mock demonstration of the project pipeline, created specifically for presentation and review purposes.

It does not reproduce the full codebase or perform real computations — instead, it walks the reader through the key stages of the project (data preparation, training, merging, quantization, inference) using simplified logic, placeholder data, and printed outputs.

Its sole purpose is to help reviewers quickly understand the overall flow and structure of the system without needing to run Docker or examine the full implementation.

⚠️ Note: This notebook does not execute real training or quantization — these steps are simulated with prints or placeholders to ensure stability in the notebook environment.
For actual execution, see the Docker setup and source code below.

Think of it as a guided tour, not a working prototype.

Inference setup

Integration choice

In the beginning, when it comes to building an iOS app with LLM, the developer needs to choose the way it will be integrated in the app. In our case, there were standard ways of using that on-device:

• coremltools from pip
• llama.cpp inference with .gguf file extension
• Google's MediaPipe
• Use of ONNX

After some time of working with all these methods, we came across on pros/cons of each of those ways:

Unfortunately, we couldn't use coremltools or ONNX, which are considered as the best tools for using LLMs on iOS, so we narrowed such tools down to llama.cpp and MediaPipe. And, as it often happens, MediaPipe became not appropriate for us because we realized that there is no way to convert Google Gemma 3n into .task file extension. Hence, the only thing we could try is llama.cpp

We are going through each LLM integration step in the Gemergency iOS app. We first start with llama.cpp setup and finally go to building our own SwiftUI iOS app

llama.cpp setup

First things first, we had to install llama.cpp inference on macOS. For this, we need to clone the official repo on the Mac:

$ git clone --recursive https://github.com/ggml-org/llama.cpp.git && cd llama.cpp

By running that command, we clone and go to the root directory of llama.cpp. We can find example/llama.swiftui subdirectory there. This is what we need. But before going there, we have to build Xcode framework for further use in SwiftUI iOS app. Run this command in the root directory of llama.cpp:

$ ./build-xcframework.sh

And that's it! We can not proceed by integrating Google Gemma 3n into the iOS app

Setting up an iOS app with Gemma 3n

Preparation

We were ready to build a brand new SwiftUI iOS app. Before we began, we had to set up the Xcode framework within the app. To start, we created a new SwiftUI project in Xcode by navigating to Xcode → File → New → Project, selecting SwiftUI as the primary UI framework, and creating a new app

Next, we had to add the Xcode framework we built earlier to the project. This can be done easily by simply dragging and dropping the framework into our app. Once that's done, we could move on to integrating the necessary controllers into the app

App setup

To work successfully with Gemma 3n, our SwiftUI iOS app requires two key controllers: LlamaState and LibLlama. Both can be found in llama.cpp/examples/llama.swiftui:

• LlamaState - acts as a bridge between the SwiftUI app and llama.cpp, using LibLlama
• LibLlama - serves as the core engine that manages LLM setup within the SwiftUI app

After adding these controllers to our SwiftUI project, we were ready to begin designing the app's user interface

Additional features to controllers

In addition to adding these controllers to the project, we also needed to modify them to ensure they functioned correctly

First things first, we had to add these lines of code into LibLlama:

func clear() {
    tokens_list.removeAll()
    temporary_invalid_cchars.removeAll()
    llama_memory_clear(llama_get_memory(context), true)

    self.n_cur = 0 // <- add this line
    self.is_done = false // <- add this line
}

Without these lines of code, Gemma 3n won't respond to a second prompt. To clarify: the first prompt works as expected and receives a response, but the second prompt fails because the session cache isn't cleared between prompts.

static func create_context(path: String) throws -> LlamaContext {
    llama_backend_init()
    var model_params = llama_model_default_params() // <- add this line

#if targetEnvironment(simulator)
    model_params.n_gpu_layers = 0
    print("Running on simulator, force use n_gpu_layers = 0")
#endif
    model_params.n_gpu_layers = 0 // <- add this line

    let model = llama_model_load_from_file(path, model_params)
    guard let model else {
        print("Could not load model at \(path)")
        throw LlamaError.couldNotInitializeContext
    }

    let n_threads = max(1, min(8, ProcessInfo.processInfo.processorCount - 2))
    print("Using \(n_threads) threads")

    var ctx_params = llama_context_default_params()
    ctx_params.n_ctx = 2048
    ctx_params.n_threads       = Int32(n_threads)
    ctx_params.n_threads_batch = Int32(n_threads)

    let context = llama_init_from_model(model, ctx_params)
    guard let context else {
        print("Could not load context!")
        throw LlamaError.couldNotInitializeContext
    }

    return LlamaContext(model: model, context: context)
}

Without these lines of code, the model won't load on physical devices. It may run successfully from within Xcode, it will fail to work — such as when distributed via TestFlight — on any actual device though

Other necessary settings and methods can be found on Github repo of Gemergency

Further steps

With that completed, we proceeded to develop the Gemergency iOS app. The next steps involved designing the UI with SwiftUI, integrating iOS system features, and implementing other core functionalities

Gemergency app publishing

Publishing idea

After developing our app, we wanted to make Gemergency easily accessible, so that anyone could download and use it on an iPhone/iPad. However, we quickly ran into two key challenges: where should we publish the app, and how could we get Gemma 3n running on actual devices? It might sound weird, but these were real problems

Let me explain why this matters and what solutions we found:

• Where should we publish the app? - there were no time and opportunities to publish the app on the App Store. So had to find another platform where we could distribute Gemergency. There was only one such platform - TestFlight (it's not directly App Store, but the app might still be used by users)
• How could we make Gemma 3n running on physical devices? - since the first Gemergency beta, there was no opportunity to run Gemma 3n on physical device. We found very interesting solution that we are going to explain below though

TestFlight distribution

After choosing the platform which was the TestFlight, we first had to set up our app a bit: change scheme type from Debug to Release, as well as adapt Gemergency for all necessary devices: iPhones with dynamic island, all other iPhones, iPads. After that, we went into the work with model...

Problem with model

By default, Gemma 3n used GPU for working on device. And while working on a simulator was swift and smooth due to Apple Silicon CPU line-up, we came across that it does not work even on iPhone 16 Pro Max in real life. That was strange for us, because the newest iPhones' capabilities were made to work AI

We spent about 2 days to get with problem. And accidentally we found how to solve this: we found that in case of simulator, we set GPU layers to 0, so the app works smooth on simulator. But what about physical devices? Well, that' funny but physical devices used GPU layers for work

To change that, we just added one line of code (well, we copied that line from #if directive) in LibLlama controller:

static func create_context(path: String) throws -> LlamaContext {
    llama_backend_init()
    var model_params = llama_model_default_params() // <- add this line

#if targetEnvironment(simulator)
    model_params.n_gpu_layers = 0
    print("Running on simulator, force use n_gpu_layers = 0")
#endif
    model_params.n_gpu_layers = 0 // <- add this line

    let model = llama_model_load_from_file(path, model_params)
    guard let model else {
        print("Could not load model at \(path)")
        throw LlamaError.couldNotInitializeContext
    }

    let n_threads = max(1, min(8, ProcessInfo.processInfo.processorCount - 2))
    print("Using \(n_threads) threads")

    var ctx_params = llama_context_default_params()
    ctx_params.n_ctx = 2048
    ctx_params.n_threads       = Int32(n_threads)
    ctx_params.n_threads_batch = Int32(n_threads)

    let context = llama_init_from_model(model, ctx_params)
    guard let context else {
        print("Could not load context!")
        throw LlamaError.couldNotInitializeContext
    }

    return LlamaContext(model: model, context: context)
}

And that's it! We are done! Now we could sent our app to TestFlight and distribute it via users all across Apple Ecosystem (but still via the link)