Diligesker IT/AI Digest

Tag: Local AI

  • Gemma 4 12B brings local multimodal AI closer to laptops

    Gemma 4 12B brings local multimodal AI closer to laptops

    Gemma 4 12B is Google’s June 3, 2026 open model for local multimodal AI, aimed at laptops with 16GB of VRAM or unified memory. Google says the 12 billion parameter model accepts text, image, and audio input while using a simpler encoder-free design. The model sits between the edge-focused Gemma E4B and a larger 26B Mixture of Experts model, and Google is releasing it under Apache 2.0 with support for Hugging Face, Ollama, llama.cpp, MLX, vLLM, and other local inference tools. That makes it a useful test case for teams deciding which AI features can run on a user’s machine instead of a hosted API.

    The short version

    • Google introduced Gemma 4 12B on June 3, 2026, as a middle option between its edge-focused E4B model and a larger 26B Mixture of Experts model.
    • The model is designed for local use on consumer laptops with 16GB of VRAM or unified memory, according to Google’s launch post.
    • Gemma 4 12B routes vision and audio input into the LLM backbone instead of relying on heavy separate multimodal encoders.
    • The developer path is broad from day one: Hugging Face, Ollama, LM Studio, llama.cpp, MLX, SGLang, vLLM, LiteRT-LM, and Unsloth all appear in Google’s materials.
    • The practical question is quality under real quantization and local speed, not whether local multimodal AI is useful in theory.

    What happened

    Google announced Gemma 4 12B as a unified, encoder-free multimodal model built for agentic workflows on local machines. The company says the model sits between Gemma’s edge-friendly E4B model and its larger 26B Mixture of Experts model. The main constraint is explicit: Google is targeting consumer laptops with 16GB of VRAM or unified memory, not only remote GPU servers.

    The launch post also says Gemma 4 12B is released under the Apache 2.0 license and ships through common developer surfaces. Google’s listed paths include Hugging Face, Ollama, LM Studio, Google AI Edge Gallery, llama.cpp, MLX, SGLang, vLLM, LiteRT-LM, and Unsloth. That broad support is part of the story. A local model is much easier to evaluate when a developer can run it through the same tools already used for small language models and local inference servers.

    Why Gemma 4 12B is worth watching

    Gemma 4 12B is worth watching because it treats local multimodal AI as a product constraint, not a lab demo. Google’s technical post says the model replaces the heavier vision encoder used in other medium Gemma models with a 35 million parameter vision embedder. Raw 48×48 pixel patches are projected into the LLM hidden dimension, while audio input is sliced into 40 ms frames from 16 kHz audio and projected into the same input space.

    That design should reduce some of the overhead that comes from running separate vision and audio encoders before the language model ever starts generating. It does not prove the model will beat larger cloud systems on hard reasoning, coding, or long context tasks. It does make a different trade-off: fewer moving parts, lower memory pressure, and a simpler path for teams that want an assistant to read screenshots, summarize voice input, or process local files without shipping data to an API.

    What does Gemma 4 12B change for developers?

    Gemma 4 12B changes the local model conversation from “can I run text chat locally?” to “which multimodal features can I keep on the user’s machine?” For developers, that is a concrete product question. A local model can cut round-trip latency, reduce inference bills, and keep sensitive images, documents, or audio inside a controlled environment.

    The developer guide gives examples around local image processing, video understanding, audio input, coding, and desktop integrations. Those examples should be treated as starting points rather than benchmarks. Builders still need to test token speed, memory use, quantized quality, speech accuracy, and vision reliability on their own hardware. The better near-term fit is probably narrow workflows: support tools reading screenshots, note apps handling voice edits, desktop agents inspecting local documents, or internal utilities where privacy matters more than frontier-model accuracy. For more AI model coverage, see the IT & AI archive.

    What the discussion is missing

    A public Hacker News thread was not available from the source material I checked, so the missing discussion is the real-world local performance data. Google’s posts give the architecture, memory target, tool support, and example integrations, but developers will still want independent runs across Apple Silicon, consumer NVIDIA cards, and lower-memory machines.

    The useful questions are fairly plain: how fast does Gemma 4 12B run in llama.cpp or MLX after quantization, how much quality drops at common quantization levels, whether the audio path works well outside clean demos, and how vision answers compare with models that use dedicated encoders. There is also a deployment question. Apache 2.0 licensing and broad tool support make the model easier to test, but production use still depends on evaluation, logging, safety checks, and a fallback path when a local model gives a weak answer.

    The practical read

    Gemma 4 12B should be evaluated by teams that already have a reason to keep inference local. If the workload needs top-tier reasoning, large-context code review, or polished multimodal answers across messy inputs, a larger hosted model may still be the safer default. If the workload is private, repetitive, latency-sensitive, or cost-sensitive, Google’s 12B model deserves a test slot because the memory target, Apache 2.0 license, and local tool support line up with real deployment constraints.

    A sensible evaluation would start with three checks. First, run the instruction-tuned model through the toolchain your team already uses, such as Ollama, llama.cpp, MLX, or vLLM. Second, test the exact input mix you care about: screenshots, short audio, local documents, or video frames. Third, compare the result against a hosted baseline and a smaller local model. Gemma 4 12B only matters if it beats the smaller local option enough to justify the memory cost while avoiding enough hosted inference to change the product economics.

    Sources

  • Surface Laptop Ultra makes Microsoft’s MacBook Pro fight about local AI

    Surface Laptop Ultra makes Microsoft’s MacBook Pro fight about local AI

    Surface Laptop Ultra is being framed as Microsoft’s answer to the MacBook Pro. That comparison is useful, but only up to a point. The more interesting question is whether Microsoft and NVIDIA can make a Windows laptop feel credible for local AI work instead of stopping at spec-sheet bragging.

    The short version

    • Windows Latest reports that Microsoft has introduced Surface Laptop Ultra, a high-end Windows on Arm laptop built around NVIDIA’s RTX Spark platform.
    • The headline specs are aggressive: a 20-core NVIDIA Grace CPU, Blackwell RTX graphics, up to 128GB of unified memory, CUDA support, and claims around 120-billion-parameter local model runs.
    • The hard part is not raw GPU marketing. Microsoft has to prove battery life, heat, x86 compatibility, creative-app support, and Windows on Arm developer tooling in daily use.
    • Hacker News readers mostly argued about price, fan noise, and whether large local AI workloads belong on a laptop at all.

    What happened with Surface Laptop Ultra

    Windows Latest says Microsoft used Computex 2026 to show Surface Laptop Ultra, a new top-end Surface laptop built with NVIDIA. The reported platform combines a 20-core NVIDIA Grace CPU, a Blackwell RTX GPU, fifth-generation Tensor Cores with FP4 support, NVLink-C2C between CPU and GPU, and up to 128GB of unified memory.

    The article also says Microsoft tuned Windows 11 on Arm for the platform. That includes scheduler work across 20 cores, power and thermal management, higher GPU-accessible memory limits, shared-memory page handling, Prism emulation changes for older x86 apps, and containment primitives for local AI agents.

    Those details matter more than the MacBook Pro comparison. Apple’s current advantage is not one chip or one benchmark. It is the boring, valuable mix of performance, battery life, unified memory, silence, app support, and predictable hardware behavior. Surface Laptop Ultra has to compete with that whole package.

    Why this is worth watching

    Surface Laptop Ultra could become a useful test case for the next phase of AI PCs. A lot of AI laptop talk has been stuck on NPU TOPS. This machine points at a different lane: local inference, CUDA-backed experimentation, video work, 3D rendering, and agent workflows that need a bigger shared memory pool.

    If the 128GB unified-memory configuration works as described, the appeal is obvious for developers who want to prototype with local models before moving serious jobs to the cloud. It could also matter for creators who already live inside Adobe, game engines, 3D tools, and GPU-heavy production software.

    The catch is that Windows on Arm still has to earn trust. Native apps are better than they were, and Prism emulation has improved, but professional buyers do not want a science project. They want Premiere, Photoshop, anti-cheat-protected games, IDEs, drivers, plugins, and weird old utilities to behave without becoming the day’s main problem.

    That is why this story fits the broader IT & AI archive: the hardware is interesting, but the platform question is the real story. Microsoft needs the laptop, the operating system, and the developer ecosystem to land at the same time.

    What Hacker News readers are arguing about

    The Hacker News thread was less impressed by the launch language than by the practical tradeoffs. Price came up first. Several commenters guessed that a 64GB or 128GB RTX Spark laptop would land somewhere around premium workstation pricing, with DGX Spark comparisons making a sub-$3,000 product sound unlikely.

    Fan noise became another sticking point. Some readers thought Microsoft’s promo emphasis on cooling was a strange way to chase MacBook Pro buyers, because one of Apple Silicon’s strongest selling points is how quiet it feels during normal work. Others pushed back: if you are running large local models or GPU-heavy creative jobs, fans are part of the deal.

    The most useful split was about local AI itself. One camp asked why anyone would run large models on a Windows laptop instead of using a server. The other camp wanted exactly that portability: a machine you can take to a coffee shop, run a coding model without depending on cloud access, and keep working when Wi-Fi is bad or locked down.

    There was also a familiar Windows skepticism. Some readers treated “built on Windows” as a warning label. Others brought up older Surface devices they still like, especially for unusual form factors, pens, keyboards, and portable creative work. The thread did not settle the question. It did make the buyer profile clearer: this only makes sense if local GPU work matters enough to pay for weight, heat, and price.

    The practical read

    Treat Surface Laptop Ultra as a platform bet, not a simple MacBook Pro clone. The spec list is strong enough to make Windows hardware interesting again for local AI, but the first reviews need to answer five plain questions.

    Can it stay quiet and fast under long AI or rendering jobs? Does battery life hold up when the GPU is actually doing work? Do x86 apps, anti-cheat systems, Adobe tools, drivers, and dev utilities behave on Windows on Arm? Is CUDA support easy to use on the laptop, or does it feel like a demo path? And does the price make sense against a MacBook Pro, a desktop workstation, or rented cloud GPU time?

    If Microsoft gets those answers right, Surface Laptop Ultra could give Windows developers and creators a serious local AI machine. If not, it will be another impressive Surface idea that people admire from a distance.

    Sources

  • NVIDIA RTX Spark turns the local AI PC fight toward Windows

    NVIDIA RTX Spark turns the local AI PC fight toward Windows

    NVIDIA RTX Spark is Nvidia’s attempt to make the local AI PC feel less like a cloud workaround and more like a real Windows machine. The company says the platform combines Blackwell RTX graphics, Grace CPU cores, and up to 128GB of unified memory in slim laptops and small desktops. That is a direct pitch to developers and creators who want CUDA, local inference, and everyday PC software in one box.

    The short version

    • NVIDIA RTX Spark laptops are pitched with up to 1 petaflop of FP4 AI performance, up to 6,144 RTX GPU cores, and up to 128GB unified memory.
    • The bigger story is not gaming alone. Nvidia is trying to bring CUDA-heavy local AI development into Windows laptops and compact desktops.
    • Asus, Dell, HP, Lenovo, Microsoft, and MSI are listed as partners, which makes this look like a platform push rather than a single demo device.
    • The open questions are price, battery life, thermals, Windows on Arm compatibility, and whether real local LLM workloads run well enough to justify the hardware.

    What happened with NVIDIA RTX Spark

    NVIDIA RTX Spark is a PC platform built around what Nvidia calls the RTX Spark Superchip. The company describes it as a single processor that fuses NVIDIA AI acceleration with RTX graphics for creators, developers, and gamers. The headline configuration reaches up to 128GB of unified memory, which is unusually large for a consumer laptop class device and useful for local AI workloads that quickly run into memory limits.

    The pitch is easy to understand: keep more AI work on the machine. A developer could prototype an agent, run smaller models, test CUDA code, or do creative work without sending every step to a remote GPU. That does not remove the need for cloud compute, but it could make the first loop faster and cheaper for some teams. If you follow AI hardware and developer tools, the broader IT & AI archive is the right place to track this shift.

    Nvidia is also selling RTX Spark as a Windows PC story, not a lab box story. That matters because a laptop has to survive normal laptop questions: does it sleep properly, does the battery last, do creative apps behave, do games run, and does the fan sound reasonable under mixed workloads?

    Why this is worth watching

    The phrase “AI PC” has been stretched thin. A lot of recent PC marketing has centered on NPUs, meeting effects, or small assistant features. NVIDIA RTX Spark is a heavier bet. It puts the focus on local model work, CUDA software, RTX graphics, and large unified memory.

    That makes the comparison set more interesting. Apple Silicon has strong unified memory and a mature Arm transition. AMD’s Strix Halo points at high-end integrated graphics and local AI experiments. Traditional RTX laptops already have CUDA, but usually with a split between system memory and VRAM. NVIDIA RTX Spark tries to combine pieces from all three worlds.

    The catch is that specs do not settle this market. Local LLM performance depends on memory bandwidth, quantization, prefill speed, software support, and thermal limits. A machine that looks excellent in a product page can still feel awkward if the developer workflow is fragile or the best apps are not native.

    What Hacker News readers are arguing about

    The Hacker News discussion is less about whether local AI is useful and more about whether Windows is the right home for it. One camp is skeptical of Microsoft and Windows on Arm. Their concern is simple: previous Arm Windows machines had compatibility gaps, and a high-end AI laptop still has to run normal Windows apps, developer tools, games, and drivers.

    Another camp is more pragmatic. For them, the operating system matters less than getting a portable CUDA machine with enough unified memory to run local models. Some commenters framed it as a possible alternative to Apple Silicon Macs, AMD Strix Halo laptops, or a desktop full of used GPUs. The useful caveat in that argument is memory bandwidth. Several readers pointed out that 128GB of unified memory is attractive, but bandwidth and real model throughput will decide whether the machine feels fast.

    There is also a hardware-nerd thread around what Nvidia and MediaTek actually built. Commenters picked apart the CPU side, the relationship to DGX Spark, and whether the same silicon will be constrained by laptop power limits. That is the right kind of skepticism. RTX Spark may be a strong developer machine, but the first reviews need to show sustained performance, Linux behavior, Windows on Arm compatibility, and price before anyone can call it a MacBook or workstation replacement.

    The practical read

    If you build AI tools, NVIDIA RTX Spark is worth watching because it could make the local development loop more realistic on Windows. The sweet spot is not training frontier models on a laptop. It is running smaller models, testing agents, doing CUDA-first prototyping, and moving fewer early experiments to paid cloud GPUs.

    If you are buying hardware soon, wait for benchmarks. Look for sustained tokens per second, prefill speed, memory bandwidth, battery behavior under AI workloads, fan noise, Linux support, and whether your actual Windows apps run natively or through translation. A spec sheet can tell you the direction. It cannot tell you whether the machine is pleasant to use.

    Sources

  • CPU LLM inference: Gemma runs on a 2016 Xeon

    CPU LLM inference: Gemma runs on a 2016 Xeon

    CPU LLM inference usually sounds like a compromise you make when a GPU is unavailable. Christina Sorensen’s test makes the compromise more interesting: Gemma 4 26B-A4B ran at roughly reading speed on a 2016 Intel Xeon E5-2620 v4 server with no GPU, 128GB of DDR3 memory, and a long list of ik_llama.cpp flags. The useful lesson is not that old Xeons are suddenly better than GPUs. It is that memory bandwidth, KV cache size, speculative decoding, and engine control matter more than a simple hardware checklist.

    The short version

    • The test used one Intel Xeon E5-2620 v4, 8 physical cores, 16 threads, 128GB of DDR3 RAM, and no GPU.
    • Gemma 4 26B-A4B is described as a roughly 25.2B parameter Mixture-of-Experts model with about 3.8B active parameters per token.
    • The run needed about 82GB of memory at the full 262K context, with roughly 25GB for weights and 56GB for KV cache.
    • The practical win came from engine-level tuning: MTP speculative decoding, CPU-aware MoE routing, runtime repacking, Flash Attention, and explicit KV-cache handling.
    • For builders, the test is a reminder that local AI can make sense for privacy or batch jobs, but power draw, noise, and setup time still count.

    What happened

    Sorensen published a detailed run of Gemma 4 26B-A4B on a recycled server that looks weak by current AI standards. The CPU is a single Xeon E5-2620 v4 from 2016. It has AVX2, but no AVX-512, no AVX-VNNI, no BF16, and no integrated GPU. The memory is the saving grace and the bottleneck at the same time: 128GB is enough capacity, but DDR3 is slow compared with modern laptop memory.

    The run did not use a simple wrapper. The command line included --spec-type mtp, --draft-max 3, --cpu-moe, --merge-up-gate-experts, --run-time-repack, --flash-attn on, --mla-use 3, --mlock, and --no-kv-offload. Some of those flags are about speed. Some are about avoiding wasted work. Some are there because the engine has to be told, explicitly, that there is no GPU to lean on.

    The memory accounting is the part that should make people pause. At the full 262K context, the run needed 82,355 MiB for model tensors plus cache. The KV cache was larger than the model weights. That is a good mental reset for CPU LLM inference: once the context gets large, the short-term memory of the conversation can become the thing that dominates RAM.

    CPU LLM inference in plain terms

    The decoder phase of an LLM is often memory-bound. Each new token requires the system to stream model weights through memory and cache. On a GPU server, high-bandwidth memory hides a lot of that pain. On an old CPU box, the memory wall is right in your face.

    That is why the details in this post matter. Speculative decoding tries to get more useful tokens out of each expensive verifier pass by pairing the main model with a smaller drafter. CPU-aware MoE routing tries to keep expert weights from thrashing the cache. Runtime repacking reshapes weight matrices so the CPU can read them more efficiently. Flash Attention and MLA reduce the amount of attention and KV-cache data that has to be materialized in memory.

    None of this makes the setup friendly. It actually proves the opposite. If the only way to make CPU LLM inference usable is a 25-flag command, missing documentation, and logs that quietly downgrade unsupported settings, then the open-model stack still has a usability problem. The model may be open. The working recipe is harder to get.

    Why this is worth watching

    The interesting part is not nostalgia for old servers. It is the gap between “can run” and “can run well.” Local AI is full of that gap right now. A consumer tool may hide all the knobs, which is fine until the defaults waste RAM, miss a CPU optimization, or let a model swap to disk.

    This matters for teams that want local inference for internal documents, private workflows, or overnight automation. A slow local model can still be useful if the job is summarizing PDFs, drafting code comments, classifying logs, or running background research. For more stories like this, the IT & AI archive tracks practical AI tooling rather than launch-day hype.

    The catch is cost. A repurposed server is not free if it burns power, runs loud, and takes hours to tune. The right comparison is not “old Xeon versus H100.” It is “owned hardware for patient workloads versus hosted inference for fast ones.” CPU LLM inference belongs in that second-level decision, not in a slogan about replacing GPUs.

    What Hacker News readers are arguing about

    The Hacker News thread is mostly useful because it pushes back on the romance of the homelab. Several readers liked the privacy and offline angle, especially for data that should not leave a home or company network. Others pointed out that rack-era Xeon machines can be noisy, hot, and inefficient. One commenter compared old Xeon boxes with newer small Intel systems and argued that the modern machine is often faster while using far less power.

    A second thread of discussion focused on measurement. Readers questioned whether a tiny prompt such as “Why is the sky blue?” tells enough about real workloads. Coding, log analysis, and document tasks often start with thousands of input tokens, so prompt evaluation, prefix caching, and long-context behavior matter as much as output speed. That skepticism is fair. Reading-speed generation is useful, but it is not a full benchmark.

    There was also a more technical argument about cache and CPU choice. Some readers noted that older Xeons vary a lot, and modern consumer CPUs can have comparable or better cache behavior. Others brought up AMD 3D V-Cache and high-memory consumer systems as a better direction than keeping loud server hardware alive. The strongest practical takeaway from the thread: local inference is attractive when privacy or control matters, but hosted models may still be cheaper for casual batch jobs once electricity and time are included.

    The practical read

    If you are building with local models, treat this as a checklist, not a buying guide. Start with the workload. If the job is interactive chat, an old CPU box will probably frustrate users. If the job runs in the background and handles sensitive data, a slower local model can be fine.

    Then check memory before you check FLOPS. Model weights are only part of the footprint. Long context can make the KV cache bigger than the model itself, and swapping will destroy performance. After that, look at the engine. A wrapper that is easy to install may be the wrong tool if it hides the settings needed for your hardware.

    For app builders, the ASO angle is simple: local AI features should be marketed around privacy, offline use, and patient background work, not raw speed. CPU LLM inference is credible when the product promise matches the hardware reality.

    Sources

  • Bonsai Image 4B brings local image generation to the iPhone

    Bonsai Image 4B brings local image generation to the iPhone

    Bonsai Image 4B is PrismML’s attempt to make a modern 4B-class image model small enough for local image generation on everyday hardware. The company says the ternary version generates a 512×512 image in 9.4 seconds on an iPhone 17 Pro Max, while keeping the diffusion transformer near 1.21 GB.

    The short version

    • Bonsai Image 4B is based on FLUX.2 Klein 4B, but stores the diffusion transformer weights in 1-bit or ternary form.
    • PrismML reports an 8.3x transformer footprint reduction for the 1-bit model and 6.4x for the ternary model, compared with the FP16 FLUX.2 Klein 4B transformer.
    • The ternary Bonsai Image 4B model keeps 95% of the reported benchmark performance of FLUX.2 Klein 4B across GenEval, HPSv3, and DPG-Bench.
    • The practical question is not whether this replaces cloud image APIs. It is whether fast, private, throwaway image generation can move into mobile and desktop products.

    What happened

    PrismML released Bonsai Image 4B, a family of compact image generation models aimed at local hardware. The models keep the FLUX.2 Klein 4B architecture, but change the representation of the transformer weights, which are the heaviest part of the image generation pipeline.

    The 1-bit variant uses {-1, +1} weights with FP16 group-wise scaling, for 1.125 effective bits per weight. Its diffusion transformer is 0.93 GB, down from 7.75 GB for the FP16 FLUX.2 Klein 4B transformer. The ternary variant uses {-1, 0, +1} weights with FP16 group-wise scaling, for 1.71 effective bits per weight. That version is 1.21 GB.

    The full deployment payload is larger than those transformer numbers because the text encoder and VAE still matter. PrismML lists 3.42 GB for 1-bit Bonsai Image 4B and 3.88 GB for the ternary model on Apple Silicon, compared with 15.97 GB for the full-precision FLUX.2 Klein 4B pipeline.

    Why this is worth watching

    Bonsai Image 4B is interesting because image generation is usually constrained by memory, serving cost, and latency. A model that fits on a phone changes the shape of the product, even if the best cloud systems still win on raw output quality.

    Bonsai Image 4B tradeoffs to test

    Local image generation can make sense when the user is iterating quickly, testing prompts, creating drafts, or working with private material. A mobile app can offer previews without sending every prompt to a remote server. A desktop creative tool can make cheap local drafts, then reserve cloud calls for final renders. For more stories like this, see the IT & AI archive.

    The benchmark claims are also specific enough to watch. PrismML reports GenEval 0.723, HPSv3 12.22, and DPG-Bench 0.851 for the ternary model, or 95% of FLUX.2 Klein 4B’s reported performance. The 1-bit version is smaller and lands at 88% of the same baseline. That gives developers a clear tradeoff: tighter memory and storage, or better prompt fidelity and visual quality.

    What Hacker News readers are arguing about

    The Hacker News thread is mostly impressed, but not blindly so. A useful chunk of the discussion asks whether this is a product breakthrough or a strong compression demo. Some readers point out that the transformer is under 1 GB in the 1-bit case, but the full inference stack still needs the text encoder and VAE, so the real app footprint is several gigabytes rather than a single tiny model file.

    Several commenters focused on practical deployment. People asked about minimum RAM, Mac compatibility, ComfyUI or Ollama-style integration, WebGPU support, and whether the browser demo works reliably. That is the right skepticism. Local AI only becomes useful when ordinary developers can install it, run it, and recover from dependency trouble without spending a weekend in build scripts.

    The strongest pro-local argument in the thread is about cost and iteration. If users generate many rough images, local inference can feel less metered than a cloud API. The strongest objection is that commercial teams may not want the support burden of running image generation on customer devices. Both can be true. Bonsai Image 4B is likely more relevant first for creative apps, offline tools, privacy-sensitive workflows, and developer experiments than for every production image feature.

    The practical read

    If you build mobile or desktop software, treat Bonsai Image 4B as a signal rather than a finished answer. The signal is that local image generation is moving from novelty to plausible product primitive.

    The next thing to test is image quality plus everything around it: install size, cold start time, battery drain, heat, memory pressure, prompt reliability, safety controls, and how often users actually need cloud quality. If the feature is quick sketching, private drafts, app-store-friendly creative tooling, or offline editing, Bonsai Image 4B deserves a closer look.

    The App Store angle is also real. Bonsai Studio gives PrismML a direct way to let users try the model on an iPhone, and it gives app builders a preview of how on-device AI features may be marketed: not as infrastructure, but as instant creative capability inside the app.

    Sources